Archive for category Tech

When you see it, you’ll swap bricks

Hi !

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.
  • Browser : Java compiled in Javascript with GWT and running WebGL using gwt-g3d and Html 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.
In the end, porting the game is just swapping the system-specific middle bricks. This allow to keep the game exactly the same. The code can evolve at the same time on each platform. This saves a lot of time.
Thanks for reading.

Leave a comment

Html5 Canvas vs WebGL

I started exploring the possibility to develop a game for G+ ( let’s imagine that I can start by porting a random game where you jump around on columns ).

One remaining question was to decide between WebGL and Canvas2D.
I found a blog entry on Jeff  Muizelaar site that allows anyone with a modern browser to benchmark the performance of Canvas and WebGL.
The results I got were the expected ones. They’re almost the same as what i obtained on Android between Canvas and OpenGL.

Here are the pros and cons :
WebGL :
+ Super fast and powerful rendering
+ Lots of possibilities for a 2D game, such as shading, lighting and zooming.
+ GWT API with gwt-g3d
– A bit complicated
– Low compatibility : Chrome & Firefox only
– Uncertain future due to security issues in the current specs

Canvas2D :
+ Easy to code
+ High compatibility : any HTML5 browser
+ GWT API with gwt-g2d
– Low performances : laggy with more than 50 sprites ( on non-accelerated browsers )

On my G+ post about this it has been suggested ( and on the Google Game Developer Central ) that the use of Chrome frame can solve the problem of the low compatibility of the WebGL.

In the end, the choice for WebGL was easily made.
Tales of Pocoro draws more than 200 sprites on the screen, so Canvas would never allow a descent framerate.
Those security issues and early stage specs are still a real problem, but let’s be optimistic and hope for the best.

I’ve started working with the GWT-G3D library, I’ll talk about it in my next post.