I’ve just completed my “quest” on porting my latest game (Chrono&Cash) to HTML5 and actually in a shape that is fit for distributing and showing it to others. As usual I got flooded by people asking me what libraries, frameworks or tools I used for porting, so I figured it was about time I wrote a blog about my porting exercise and next time I can just point people to this ;)
First things first, why don’t I use any cross-platform libraries or tools? Because I’m a control freak! I like to know what my code does and when and why it does it. There are excellent cross-platform solutions out there, but I always have the fear of surrendering all my game code to them. What if the people or company behind it suddenly stops supporting it? What if they suddenly change parts of their tools so that I have to change my game code or way of working?
I never found it flexible to use other people’s standard code, it always feels bulky and not to the point of the things I wanted to do. I’ve also noticed running my own code allowed me to quickly update or modify code to work with new hardware (Xperia Play) or special awesome stuff (Joypad and iCade for both iOS AND Android) allowing me to get some great business opportunities that I would not have gotten if I had to wait for the framework-people to update their framework so that I could eventually update my game code.
Anyway my point: there are great tools out there, but this article is not for those who use them.
I usually do my game development in Android and in the recent years I’ve build a solid framework that handles the life-cycle of an Android app. It also has all the stuff for running the main threads (gameloop, logic loop, rendering, etc) and the handling of input from various controllers. This is nothing more then a few classes, we are talking about maybe 3 or 4 classes I copy+paste into any new project I start.
Next to those classes I obviously have my own little ways of doing things, so often I copy+paste a bunch of classes from previous games to handle my enemy-objects, bullets, special-effects, player code, etc. This is just a great way to get a quick start on prototyping new code. Only thing you should worry about is old functions or variables that eventually end up not being used but still called in initializations and such. Nothing some simple cleaning can’t fix.
Once I have my game running and completed on Android and when I consider it ready for distribution, I boot up my xCode environment, and start a new project based on my iOS framework written in Object-C.
The iOS framework is basically the same functionality as the Android framework but obviously completely different because it’s a different system. It also handles the input, threads, and life-cycles of an iOS app, but there is hardly a line the same as the Android version.
Most of your time is put into getting these frameworks, it might take a couple of games to get things right. On Android I modified this base framework many times in the recent years, simply to keep up with the changes made in the Android system. And on iOS I’ve been improving things to handle the various hardware specifics that I didn’t even know how to handle for my first couple of games (rotations, mute buttons, and other such stuff).
Once I have my new project created on iOS, the “fun” part starts. For every Android class file (player, monster, fx, bullet) I create an iOS class file with the same name, and copy+paste the Android code into these class files.
Then I walk through every line and modify where needed. This sounds obvious, and probably as a big task. But in reality, most code is not really that much different between languages. Here is a little screenshot showing the initialization of the Chrono&Cash Monster class in both the Java (Android) and Object-C (iOS) version:
As you can see, there are very little differences, and here is another part of the code showing some actual game logic translated from Java to Object-C:
So this last image is the actual game logic, which makes up what? about 80% maybe 90% of a game? and it’s almost the exact same code!
Now there are some small things I usually keep in mind when developing a new game. When I’m working on Android I try to also think if a specific piece of code or solution is also going to work on iOS. This can save a lot of problems when I have to port it later.
Porting my Android Java code to Javascript was basically easier because of the similarities in those languages. The HTML5 framework is also pretty simple as handling input, rendering and threads was mostly hooking into the browser which already takes care of most of the stuff anyway.
I also use pre-rendered graphics for all the text in a game. This also saves time and headaches when porting to a new platform. As long as you can render images on a platform, you will be able to render the text in the exact same way on each one.
There are more little things that I’m probably forgetting about now, but those are things you run into automatically on your first time porting a game. Your first game port probably takes the longest since you are still learning the tricks and language, but once you have a framework and know how to translate code-specifics, it’s a very simple thing to do.
