Mobile Phone Gaming with Java.

I've been hearing a lot about "Casual Games" recently and have been thinking about looking into making some myself. While developing for the PC or Apple Mac is probably the simplest way to do this, it's not very interesting since I do that all the time anyway. Developing games for mobile phones, however, is much more novel and also more challenging because of the comparatively limited power, so I decided to start investigating how to do this. After downloading and installing the J2SE and J2ME development kits from Sun, I began experimenting with the provided phone emulator and my actual PDA to see what could be done.

As John Carmack wrote, a major obstacle when designing games for phones is the method of input. For example, on my Phone/PDA all I have to work with is a D-pad with a "Fire" button in the middle. First of all, having the fire button in the center of the movement buttons is not a good design for any sort of game where input needs to be quick and precise, and, secondly, my phone detects only one button press at a time, so there can be no diagonal movement and no movement while pressing fire. These are serious limitations for any sort of dynamic game.

One solution that I have come up with is to use the touch-screen instead of the D-pad. This allows the player to control their movements with the stylus and use the fire button without the D-pad interfering. Unfortunately, not all phones have a touch screen, so designing a game that relies on a stylus for input would prevent it from being played on several devices. Also, the phone emulator provided with the J2ME development kit does not provide touch-screen emulation.

Turn-based gameplay seems to be the best idea here. Something like Advance Wars or a Final Fantasy 6-style RPG would work well with a bit of thought. For dynamic games, things such as Pong or Pac Man would work well because there is no need for a Fire button and only one directional button needs to be pressed at once.

An overdue update.

It's been a while since I posted something here, so here's an update on my progress.

Firstly, the bad news: The SURGE game engine project has now been cancelled. It's a pity, because it got quite far, as can be seen from this features list:

• Milkshape 3D .MS3D support for ragdoll actors. Animation data was ignored. Automatic texture loading was implemented.
• Quake III .MD3 support for non-ragdoll actors. Automatic texture loading was implemented.
• Incomplete Quake III .BSP support for the game world. Bezier surfaces were neither drawn nor added to the world collision data (though Polygon and Mesh surfaces were) and the actual BSP visibility culling data was ignored by the renderer. "Flare" (or "Billboard") surfaces were not drawn either. Automatic texture loading was implemented.
• Simple .TGA support (only uncompressed 24- or 32-bit .TGA files were allowed).
• A basic actor system that could handle either skeletal or morph actors transparently.
• Realistic physics via ODE.
• Cross platform. Uses only APIs that are available on several platforms (OpenGL, SDL, ODE, etc.).
• Optional multithreading (to speed up physics calculations on multi-core machines).
• Some basic audio.
  

There are a few reasons why I stopped working on this project but one of the main reasons was that ODE 0.8 and 0.9 seem to have a bug that causes the physics system to crash under certain scenarios. This bug seems to be quite rare with any sort of collision other than trimesh-trimesh. However, it happens almost instantly whenever two trimeshes touch each other - for example, when a ragdoll touches another ragdoll, or the world (I represented the world BSP data as an ODE trimesh). As my engine was designed on the basis that ODE would always be the physics system used, switching to another physics engine would require me to essentially remove about 50% of the code from the engine.

Now that I come to look back on the project a few months later, the coding wasn't very good. Graphics, logic and physics code were all intermixed and not seperated out very cleanly. The fact that ODE was so integral to the engine working correctly is testament to this.

However, after talking a break for a few months, I'm now working on a completely new project that will hopefully be much better, codenamed the "Tidal" project. The name was chosen because it continues a sort of theme - Edd has been working on the Drift engine and my previous engine was called the Surge engine, words which I think have a sort of oceanic quality to them (to be set adrift, the surge of the tides, etc.), so I decided to continue my naming along these lines.

Tidal is currently almost at the same point that Surge was before I abandoned it:

• Extremely modular design. This is to avoid the problems I had with Surge being too reliant on ODE. The motto for Tidal is "Don't rely on the API." It also makes the code cleaner.
• Cross platform. The engine's .h files don't need any specific APIs (unlike Surge), meaning that their partner .c files can implement them however they want. For example, graphics.c could use OpenGL, DirectX or even software rendering to implement the core rendering functions specified by graphics.h.
  
• Written entirely in strict ISO-C90 compliant code. There's no real reason for this aside from I feel that it'll make development more interesting.
  
• Milkshape 3D .MS3D support (although it's not actually used for anything yet). Most of the code for this was taken from Surge.
• Quake II .MD2 and Quake III .MD3 support. Automatic texture loading has been implemented in a much better way. MD2 files have a small issue with some texture coordinates being wrong due to the way I've loaded the MD2 data into structs designed to hold MD3 models but this is not really a problem right now, especially since MD3s should be the main "morph" mesh format used anyway. Most of the MD3 code was taken from Surge.
• Incomplete Quake III .BSP support for the game world. Most of the code for this was taken from Surge.
• Simple .TGA support (only uncompressed 24- or 32-bit .TGA files are allowed). Most of the code for this was taken from Surge.
• Realistic physics.
• New ActorClass-based actor system. Complete, aside from scripting (which I'm working on now). Currently, ragdoll actors are not supported.
• Very incomplete features include: Shaders, audio, networking and a GUI system.
  

Once the scripting system is finished, it should be possible to make a simple game. I'll be adding support for more file formats as the project goes on.