It's time to talk about Battlewizard, our mobile game development plaform.


One of most important troubles developing mobile games is the really broad range of target devices to support during each development.Although we develop for handsets with Java support (specifinally J2ME, CLDC 1.1 and CDC 1.1), we should take into account that it's quite different develop to one Nokia 3100 than another Sony Ericsson S700. Their screens are different, their computation power are different and their supported API are quite different (S700 supports 3D through JSR-184)

This "fragmentation problem" affects us in many ways: we must manage all graphic content to show in the screen, since screen sizes, number of colours and resolution may vary; we must manage game package size, due each handset allows one maximum size; we must manage our heap occupation; we must manage all amount of persistent data (Record Store)... and no end of aspects more.

The traditional solution to this problem is to develop the same game several times, trying to reuse as much code as you can. That is: a big team develops a game, but repeat their code for all devices to support, trying to extract and reuse every common code, and changing some sections to fit each handset peculiarity. This generates tons of repeated code, prone to errors, and very stiff to be changed.
Lets think during last stages in game development, most great ideas come up, and those ones are which becomes the game something funny and playable. At that point, all code is written, so we must try to make this code as flexible and agile as we can.
This approach needs a large team of developers, at least one programmer for each device to support, and it is followed by some of most large mobile game companies, like GameLoft.


Another possible solution is to develop the whole game for one single platform, and contract other company (usually low-cost one from one developing country like China). This company will be in charge of porting the game to others devices and platforms. Regardless ethic opinions (who realized about working conditions in Third World countries?), this solution needs more money and extra coordination between us and the other company. Needless to say, once porting has been completed, game code becomes unchangeable, and we don't be able to add or remove features for specific devices.

Third solution is called Battlewizard: with our tool it's possible to develop one game, with one code base, and working for all handsets you want to support. Even one single programmer would build up to 150 or 200 different versions without effort. Is it magic? No it isn't, simply "fragmentation problem" is tackled from the begining of the development and using right tools.
Do you want to release your game for small screens (128x128) and big ones (240x320)? Just define both profiles, add all graphic content taking into account each screen sizes and build all versions for all devices which fit in those screen sizes.
Do you need to deliver you game for MIDP 2.0 and Nokia handsets? Just define both profiles, and when game was built, specific engine will be used for each kind of device.

Battlewizard consists of several modules and layers:

• An Integrated Development Environment (IDE), with you can add all game contents: graphics, fonts, sprites, levels, AI behaviours, device profiles, etc.
• A programming API to handle all contents built with the Battlewizard IDE and certain task and tool usually needed in games: collision detection, several isometric renderers, etc.
• One specific implementation for each kind of programming API supported by Battewizard, in such a way we'll have MIDP 2.0m MIDP 3.0 (under definition), nokiaui and much more APIs. Depending on version to generate, one specified implementation will be used.
• A middleware for on-line games, which allows you download some game contents once it's installed in your phone.
• A internal scripting engine, to send executable code through GPRS/GSM and be able to modify agents behaviour, or add new dynamic content to your games (for instance: new game logic, new kind of enemies, etc.)

Battlewizard supports any J2ME games (both CLDC and CDC), although we're working in Symbian and Brew versions.

But as usual, magic doesn't exists: main inconvenient with this solution is all game version must fit at minimun of all supported devices. For instance: if we supports a range of devices with heap sizes from 500 KB up to 4 MB, our game should be programmed taking into account memory peaks for 500 KB device, although most powerful device memory will be wasted.

Well, I think it was a good introduction . Next we'll talk more deeply about Battlewizard and all task we can achieve with it.