Since announcement of the blog, we have been having conversations on what to develop as our first widget. Our initial thoughts were to develop some form of photo viewer for m3Dcam, feeding in to the latest photos submitted to the site. This represents the functionality of a typical widget (accessing RSS text/image feeds).  However, we’ve decided it would be more interesting (for us at least) to develop a widget that is not represented by those currently available; a side scrolling arcade game. When we last checked, the only other example of a real-time (RT) game was a Breakout clone (screenshot shown right).

There are a few factors that might explain the lack of this type of game:

• The WidSets framework is compatible with a wide-range of mobile phones (most phones supporting MIDP 2.0/CLDC 1.0+). This includes fairly basic phones that are now a few years old, so they might be lacking in resources that real-time games are so keen to consume, such as processor cycles and memory. WidSets widgets are distributed centrally, and are only made available for download if they are deemed as robust and generally suitable for public use by the WidSets team. A greedy widget could potentially compromise the stability and responsiveness of the Java ME based WidSets framework, so may be rejected on this basis.
• Creating a real-time game is not a trivial undertaking on any platform and the WidSets framework is tailored more toward applications that make use of internet connectivity rather than (real-time) games.

So whilst most widgets are understandably oriented toward accessing internet information and services, we think there’s a case to be made for more diverse (and trivial) widgets, such as games. So why use the WidSets framework instead of creating a Java ME game? The answer is simple; distribution. Independent developers, like us, can create widgets which are catalogued and available for download (via the library widget) alongside those created by larger, more established companies/organisations and it’s more likely a widget will be downloaded on merit rather than because of a connection to a popular IP, brand, or due to marketing/affiliation etc. Whilst we intend our game to be single-player affair, we could take advantage of some the inherent connectivity of WidSets by perhaps implementing a shared high-score table.

Having decided on creating a game, the next step is our design criteria. Different phones have different performance characteristics. The three main factors which will determine how level our playing field is are; screen resolution (1), input mechanism (2) and framerate (3). So, with this in mind, how are we going to keep the experience consistent across different phone models, which is necessary in order to compare the scores of different users?

1. In order to cater for different resolutions, we’ll use graphics primitives such as lines, rectangles and triangles. In this way, we can easily scale the graphics in proportion to the display dimension in way that’s not feasible using bitmap graphics. Instead of considering this as a limitation, we’ll try and use this as a feature by recreating a retro vector game look and feel. Drawing graphics primitives is also generally a lot faster than drawing bitmapped graphics.
2. Different phone models have different keypad layouts, ergonomics, number of keys etc. We’ll accommodate for this by using a single button interface to control the game. Nokia themselves are proponents of single-button games and have produced an interesting article entitled Turn Limitations into Strength: One Button Games.
3. Anyone who remembers playing an old real-time DOS game with no framerate limiter will appreciate how machine performance can affect a game’s difficulty. To mitigate for this, we’ll base the movement of our game objects on the time difference between frames (delta). Essentially, we’re scaling movement in the same way that we’re scaling our graphics.

One last consideration: as the WidSets framework is currently based on CLDC 1.0, there’s no floating point support in Helium script (i.e. floats or doubles). We’ll make use of fixed-point arithmetic to overcome this.

In the next blog, we will start building up the basic framework for the game, posting source code along the way (Helium script).