Day #4, Saturday, June 26th.

Keep reading below if you’re interested in today’s progress. Comments are welcome! In case you missed it, also don’t forget to read the report on my first three steps in Android game development.

Today, I studied the source code of Replica Island and I cannot deny that some bits and pieces were quite inspiring. Particularly, I liked how Chris sets up his pool of game object components and I reimplemented basically the same solution. This leaves a negative connotation for me but there’s really no better solution I could come up with myself. The only extension I would like to make in the future is to use a more data-driven system for building game objects (e.g. reading them from XMLs) in order to leave more freedom to a game designer who does not necessarily have to be the programmer at the same time. But that’s certainly nothing for a first, small Android game. I also found patterns I already used elsewhere, like wrapping the OpenGL state in order to avoid unnecessary calls to glBindTexture if the texture was already bound, etc.

Besides the game object and component pooling, I worked on the player’s weapon system. I abstracted this into a component which queries the input system’s trackball state and creates a projectile game object in a given interval if the trackball is pressed. The different weapons now simply differ in parameters like projectile name, position offset and firing rate, but the underlying implementation is the same. The projectiles emitted by the weapons, however, may be very different since they may have different movement controllers attached later (already looking forward to implementing some kind of homing missile). Projectiles which don’t hit should be released to the game object pool, so I created a DestroyGameObjectComponent which checks the game object for certain parameters like it’s position or hitpoints and releases it if one of the criterions is met.

While writing the trackball code, I recognized that my HTC Hero’s trackball is not handled at all by View.onTrackballEvent(MotionEvent). Instead, I had to overwrite View.onKeyUp(int, KeyEvent) and check for keyCode==KeyEvent.KEYCODE_DPAD_CENTER. Moreover, I often don’t get the first trackball click; I have to move the trackball first before it gets activated. If someone has experience with that, I’d be glad to know whether this is a bug or a feature. One last pitfall I discovered is that GLSurfaceView does not receive input events by default, the focusable property has to be set to true first.

I also had an idea how to implement the levels easily and I’ll probably start this very soon when I need to spawn some objects anyway. Levels will be controlled by an invisible game object which consists of a component dedicated to spawn enemies, obstacles and power-ups. The component allows for providing a list of spawn-events (for bigger enemies and enemy formations, e.g. “create enemy x after time y at position z”) and spawn rates (for simple stuff like obstacles and power-ups, e.g. “create power-up x every y to z seconds, but no more than n times”) and is parametrized the same way as all other components are, using the GameObjectFactory.

Eventually, while writing this posting, I tweaked the background slightly to scroll with the glider on the vertical axis and adopt the glider’s horizontal speed. Looks much better now.