Every, even most simple game requires some architecture specification. Inspired by Google I/O talk by Chris Pruett, I made up following game application foundations for Android game:
Architecture is based on three threads: main thread created with every Android application, rendering thread and simulation thread. Simulation should keep watch on timer, update game word, calculate physics, AI, etc. Rendering thread draws a frame as frequent as possible, and it’s independent from simulation. If very long draw call is encountered, the simulation wouldn’t have to wait for it to finish and would continue to update itself, ensuring smoother synchronization with rendering.
Rendering thread must be set up with instance of renderer class implementing IRenderer interface. This way renderers can be easily attached to application. I hope we wouldn’t be forced to use anything beside simple Canvas renderer, although if heavier optimization is required, switching to some fancier renderer which uses OpenGL ES to draw textured squares shouldn’t be a problem.
I have already made some prototypes with flying plane, scrolling background and simple enemies. Game runs fine until garbage collector kicks in, and when it does, everything freezes for about 200-400 miliseconds(!). It happens very often, successfully ruining all gameplay. Of course, that prototype was written very casually, but it appears that almost all memory would have to be allocated before actual gameplay to stop garbage collection during it.
