One of the first things that got us excited about haXe was the ability to write code once and deploy with relatively little effort to Windows (exe), Flash (web/swf), Android (app/apk) and iOS (app/ipa). We started by targetting Flash, since this was a platform that most of us were already familiar coding for.
Already we've discovered that not all Android devices on the market support AIR, so using native Flash assets and just compiling to apk isn't an option with Flash CS5.5. But something that became apparent after a bit of digging around - and may not be immediately obvious to the first-timer - is that even if we could just deploy from Flash to Android, movieclips are not very good resources to use anyway. Placing a movieclip on a stage immediately puts extra work onto the CPU - maintaining it's appearance, checking for and responding to events and so on, all mean that a movieclip comes with a pretty big overhead.
Movieclips are also drawn using the target device's CPU, not a GPU. On a PC this isn't a great issue, but for mobile devices, where every CPU clock means a little more battery life is ebbing away, it's not great!
So we're looking to build a sprite-based game, but to manage everything in code;
That means no movieclips, no timelines, no doing anything the easy way! We're going to load the bitmap data, then display it on-screen ourselves, in a custom-built rendering routine.
It's almost like going back to game-coding from the early eighties.
Forget all your fancy event-driven object-oriented development of the last thirty years and strip your code back to three simple procedural loops, called using a single timer. It's the basis of almost every game, ever:
get user input
We're going to try to build a simple game (space invaders clone) using these techniques here, in Flash and haXe and compare the two. Unlike most game development guides, however, we're going to do things the way a programmer would do in the real world.
Most tutorials will teach you about defining your game states, abstracting the data types, planning your code and so on. These are all very valid and useful game-development strategies. But in truth, most of us write games back to front when starting out with a new set of tools. Instead of worrying about the planning and the design, we tend to write games in a slightly different order:
- get something to display on the screen
- move it about a bit
- create some "proper" sprites
- animate the sprites through a recognisable sequence
- move multiple sprites around
- write some rules for the sprites to follow
- make one or more sprites respond to user input
- go back to the drawing board and design our game!
So here goes.
Assuming you've a working haXe environment (good luck with that one - it took us over 16 hours to get something working, and even now we're not sure we could repeat it successfully!) here are some examples of how to get some sprites onto your device: