A friend of mine recently asked me to explain him how come i could “port easily” ( my words ) an android game to desktop or even to browser. After having answered him, i thought it might be interesting for other people.
Port is quite easy because the base language stays the same, it’s Java all the way, designed to use OpenGL :
- Android : Java running Dalvik VM and using embedded OpenGl wrappers and native UI.
- Desktop : Java running under a JVM, using JOGL and Swing UI.
When i built my game framework i kept in mind that i might have to port the game to another system, so i made a nice separation between what i call “technical components” ( middle orange bricks ) and “game components” ( grouped as The Game ).
Those technical components make the links between the OS/System and the game components. It means that when porting a game, i just need to change / adapt the technical components to port the game.
In my case the technical components are :
- Action Manager : receives input from the system and convert them into actions and broadcat them to the game components. For example, on Android, touching the Virtual D-Pad Left on the screen, moving the trackball to the left, or striking the left arrow on the keyboard, lead to the broadcast of the same action : “move left”. Depending on the system, the way inputs are sent to this manager are totally different.
- Persistence Manager : manages all the save system basically. On Android, it uses the Preferences mechanism. On desktop, it’ll be on the file system. On browser, i’ll probably use Google App Engine database system.
- GL Renderer : On each system you have to understand how to initialize GL Context and manage the textures in memory. It’s OpenGl on each system, yet wrappers are quite different.
- UI Manager : UI are a real pain to code. It’s not fun at all and can lead to many bugs. I choosed not to code a UI system in my games and rather to rely on existing system. On Android, i used some custom and themed alert dialogs. On desktop, JOGL allows to blend Swing components with the OpenGl surface. On browser, Html and WebGl are blended by the CPU ( at the moment ).
- Sound Manager : Playing music and sound is quite different from one system to another. On Android and desktop it’s rather straightforward. On a browser it’s another story. Fortunately, i found gwt-voices and it works quite well and looks a lot like what can be found on Android.