So, a while ago now I created an iterative Android game engine, and used it to port Raiders. It went pretty well, and I got good performance out of it. But an almost inevitable truth I have come to accept in starting a new project based off an old (This time being porting Railways to Android) is that by the time I revisit the old code, I’ve learned so much more that it makes me wince to even read it.
There have been occasions where I’ve reduced the size of a source file by three times or more, simply by applying much more precise implementation conventions. It ends up faster, more memory efficient and easier to read and tweak. This is all good!
While I was contemplating this new port, it occurred to me I could make things a lot simpler for myself by creating a general
Engine class, and simply extending it whenever I wanted a specific game implemented.
The general philosophy I’ve adopted for making games on Java and Android has been an iterative game loop and render loop. This means that for each frame, every in-game object gets one
update() call (so move once etc), then one
render() call to draw it. When the Java engine was made threaded, performance increased even more, but the same could not be applied to my Android phone, which is only single core. After an attempted implementation, performance was pretty inconsistent, which I chalked up to perhaps the constant changing of Thread context. We may never know.
Getting back to the new ideas, I’ve cleaned up my Android engine to the point where the state machine is internalised along with all the touch IO. To implement a new ‘menu <-> in-game’ style game all I have to do now is extend the engine and override six functions:
loadMenuMembers()– Allocate all objects that appear in the menu
loadGameMembers()– Allocate all objects that appear in-game
menuUpdateLoop()– Update all interactive objects in the menu
gameUpdateLoop()– Update all the interactive objects in-game
menuRenderLoop()– Render all the menu objects
gameRenderLoop()– Render all the in-game objects
These functions are called at the appropriate times by the superclass engine, and so the rest can be ignored by the coder, leaving them to focus on only the elements of their game.