Need to display video on the web? Use the HTML5 <video> tag, with a Flash fallback just in case some of your users haven’t quite caught up with the times. Of course!
Need to build a browser-based casual or social game? Use Flash. Wait, what?
Whatever you might have to say about Flash, it is still the best technology for developing 2D games in the browser, and is set to remain so for a good while. Others may catch up in time, but they are not there yet. Browser inconsistencies in areas key to game development such as audio support and rendering speed, coupled with entirely absent features like microphone and webcam support, hold them back.
Developing games in Flash right now could not be easier though! There is a range of excellent tools for both code and visuals, and a huge community of Flash game developers to tap for advice, feedback and general discussion. That same community has also produced a lot of well built, mature, and open source libraries and engines specifically targeted towards making games.
Perfect for rapid idea development and large games alike, these engines handle the most common elements needed in a game, leaving you free to concentrate on what makes yours unique and fun. Which one you choose depends on your personal needs and preferences, so let's take a look at the three most popular engines around.
If asked to name a Flash game engine, I suspect most developers would reply "Flixel". The project has been around since 2009 when Adam Saltsman released the first public version to the world, and quickly gained popularity and a large user base; a success helped along by Adam’s own game built in the engine – Canabalt – achieving viral fame.
Flixel is based around a ‘blitted’ graphics system. This works by copying the pixels from your in-game objects’ graphics and compositing them all for you each update into one image, which is then displayed by Flash. In many cases this can be faster than letting Flash handle the drawing itself, making it a great choice for graphically intense games. It does mean though that all your graphics have to be in PNG/JPG format, so if you want to work with the vector format native to Flash you’re going to have to use one of several workarounds.
The rest of Flixel’s features make an impressive list; tilemaps, collisions, particles and an excellent debugger all come as standard, and there are some unique features in the list too. You won’t find multiple cameras, path-finding or a recording/playback system in the other engines covered here. Easy to pick up and use, with a wealth of online tutorials and forums to turn to when you hit a wall. Flixel is great for those just getting into game development, and for those who want to go from idea to playable game as quickly as possible.
PC and Mac. Flash and HTML5. Tea and coffee. Rivals locked in seemingly eternal battle. So it is with Flixel and our second engine: FlashPunk, first released in 2009 by Chevy Ray Johnston. Blitted graphics, a feature list almost identical to Flixel and matching performance means the choice between them will come down to the small details and your own preferred coding style.
FlashPunk’s only major unique feature is an animation library, allowing you to easily apply programmatic motion to in-game objects. You will also find the collision detection – checking for object overlap – to be much more advanced. However, there is no physics featured out of the box, leaving you to develop your own or plug in an existing physics library. Whether this is a plus or not is really going to depend on your needs; built-in physics means faster development, but external libraries means more freedom and control.
The idea of control is evident across the FlashPunk project, with space left for you to substitute your own code or other libraries for many of the core features. This contrasts with Flixel's much more prescriptive attitude, and can be a definite advantage for developers looking to stretch the limits of the engine and enjoy a little more freedom code-wise.
Our third engine takes the concepts of freedom and control to their extreme. The PushButton engine is the product of PushButton Labs, a collection of game developers from GarageGames. The team is famous for releasing the Torque engine; revolutionary for being one of the first professional grade game engine available cheaply enough for independent developers to afford a licence. While the project is now no longer in active development, it can be considered feature-complete and fully usable.
It's clear that practices from traditional game development have been brought across to the PushButton engine. At its heart is an entity system; everything in your game is simply an identical ‘entity’ in a list of entities. The difference between each entity comes from the behaviours applied by plugging in combinations of components. Every part of your game logic sits in these components, as does graphical rendering – both blitting and normal Flash graphics are usable – and even the ability to be located in space. This allows for incredible flexibility, but at the cost of complexity and verbosity. Even simple tasks in PushButton can require several long lines of code, whereas other engines take one. You will find a lot of features already included as components, but you will almost certainly need to write a few of your own.
Most importantly, the entity system really shines in larger teams. Members can write components completely separately from one another, safe in the knowledge that they will operate together perfectly. Large social games will often need large teams, so PushButton is ideally suited to Facebook games like Social City. For smaller projects though, perhaps with one or two programmers, the cost of writing a lot more code can outweigh the benefits.
Need to take your idea from sketch to playable game quickly? Use Flixel.
Need to use external libraries or bend the engine to your will? Use FlashPunk.
Need to work in a large team or use vector graphics natively? Use PushButton.