Updates have been few and far between recently. But that's because of some exciting news (well, it's exciting for us anyway). After six months in Wales, we're heading back to the digital centre of the UK - sunny Brighton!
That means hooking up with the cool kids at dotbrighton and BuildBrighton again, working on some cool group projects, as well as advancing our haXe development and mobile games learning.
Check back for updates as we put all this moving business behind us (arranging visits to view properties, travelling up and down the country, loading and unloading equipment as well as moving houses) and get back to nerding about and making more cool stuff!
Saturday, 31 March 2012
Tuesday, 6 March 2012
Creating a simple sprite-based game with haXe
The first thing to note, when using haXe for cross-platform development is that not all platforms are the same. That's fairly obvious, but can lead to un-optimised code for different platforms, so it's important to understand the nature of your target device.
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
update sprites
draw scene
That's it.
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:
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:
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
update sprites
draw scene
That's it.
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:
Friday, 2 March 2012
Mobile development with haXe NME
Once again real life and work got in the way of nerding about - only this time we managed to combine the two for a while; a few of us are learning mobile development for Android/iOS and the most obvious way forward, as experienced Flash developers, was to go for Flash CS5.5 with it's built-in AIR support.
We've been asked to make a simple app for a tablet (originally an iPad2, but most likely an Android tablet) or a smartphone/hybrid (something like the Samsung Galaxy Note springs to mind) so we've been learning all about tool-chains and cross compiling. Ideally we'd have liked to have stuck with Flash/CS5.5 and AIR, which is ideal for cool kids with the latest smartphones. Creating an app in Flash CS5.5 is a doddle and creating an .apk file is as easy as hitting "publish". Copy the .apk file onto your phone via a usb lead, then use My Files to install the app. If your phone doesn't already have it installed, the app will prompt you to download Adobe AIR (one-time only).
But this is where things started to wrong for us!
We'd only got as far as installing the app when a message popped up to say that our handset wasn't compatible with AIR...
It seems that many smartphones (and tablets) on the market are still running ARM6 processors (such as our Galaxy Ace handsets) and AIR doesn't run on these. We could just ignore these, concentrate on making apps for handsets nearer the top-end of the market and go back to Flash. But there's something about cutting out a large proportion of users, many of whom will be getting Arm6-based handsets (because they are free) on two-year contracts, that doesn't sit right with us. So we've been looking into AIR-free compilers....
It's been a bit of a nightmare!
There have been loads of suggestions, tips and recommendations and we're indebted to the guys at dotBrighton for keeping us going. One thing we're keen on doing is keeping CPU usage to a minimum (with a view to extending battery life while running our apps). Of all the set-ups we've seen, haXe NME looked like it offered what we were looking for - and, it uses an AS3 type syntax with familiar libraries, so the learning curve shouldn't be too steep.
It took over 16 hours to get haXe installed and working properly. There are no easy-start guides on the 'net - we should really have been a bit more organised, written down exactly what we did and how we did it and created one for others to follow. But the truth is, it was so convoluted and we ended up downloading massive 600Mb+ files two and three times (first manually, then allowing the installer to try, then uninstalling and trying again) that we'd only end up with a guide on how not to set up a programming environment!
Something still doesn't ring true that we've used up over 20Gb in disk space just getting this lot working...
But in the end, after installing Java runtimes, Java SDK, Android SDK, Android NPK, Flash Develop, haXe NME, C++, Visual Studio Express, Cygwin and a whole heap of other crap we didn't fully undesrstand, we managed to get and environment working that allowed us to compile the Actuate example from the haXe NME website
Here's our end result. The video shows up to fifty sprites (filled shapes) of differing degrees of transparency with a couple of pngs we added ourselves, to try out the png support.
[video here]
With alpha-support for pngs, and the ability to draw moving objects at different depths, things are quite exciting. A tile-based sprite-blitted game can't be too far away, surely?
We've been asked to make a simple app for a tablet (originally an iPad2, but most likely an Android tablet) or a smartphone/hybrid (something like the Samsung Galaxy Note springs to mind) so we've been learning all about tool-chains and cross compiling. Ideally we'd have liked to have stuck with Flash/CS5.5 and AIR, which is ideal for cool kids with the latest smartphones. Creating an app in Flash CS5.5 is a doddle and creating an .apk file is as easy as hitting "publish". Copy the .apk file onto your phone via a usb lead, then use My Files to install the app. If your phone doesn't already have it installed, the app will prompt you to download Adobe AIR (one-time only).
But this is where things started to wrong for us!
We'd only got as far as installing the app when a message popped up to say that our handset wasn't compatible with AIR...
It seems that many smartphones (and tablets) on the market are still running ARM6 processors (such as our Galaxy Ace handsets) and AIR doesn't run on these. We could just ignore these, concentrate on making apps for handsets nearer the top-end of the market and go back to Flash. But there's something about cutting out a large proportion of users, many of whom will be getting Arm6-based handsets (because they are free) on two-year contracts, that doesn't sit right with us. So we've been looking into AIR-free compilers....
It's been a bit of a nightmare!
There have been loads of suggestions, tips and recommendations and we're indebted to the guys at dotBrighton for keeping us going. One thing we're keen on doing is keeping CPU usage to a minimum (with a view to extending battery life while running our apps). Of all the set-ups we've seen, haXe NME looked like it offered what we were looking for - and, it uses an AS3 type syntax with familiar libraries, so the learning curve shouldn't be too steep.
It took over 16 hours to get haXe installed and working properly. There are no easy-start guides on the 'net - we should really have been a bit more organised, written down exactly what we did and how we did it and created one for others to follow. But the truth is, it was so convoluted and we ended up downloading massive 600Mb+ files two and three times (first manually, then allowing the installer to try, then uninstalling and trying again) that we'd only end up with a guide on how not to set up a programming environment!
Something still doesn't ring true that we've used up over 20Gb in disk space just getting this lot working...
But in the end, after installing Java runtimes, Java SDK, Android SDK, Android NPK, Flash Develop, haXe NME, C++, Visual Studio Express, Cygwin and a whole heap of other crap we didn't fully undesrstand, we managed to get and environment working that allowed us to compile the Actuate example from the haXe NME website
Here's our end result. The video shows up to fifty sprites (filled shapes) of differing degrees of transparency with a couple of pngs we added ourselves, to try out the png support.
[video here]
With alpha-support for pngs, and the ability to draw moving objects at different depths, things are quite exciting. A tile-based sprite-blitted game can't be too far away, surely?
Subscribe to:
Posts (Atom)