One of the more common questions I’ve been receiving via e-mail and finding on forums is about programmers familiar with some other language (Java, C#, C++) aiming to switch to ActionScript 3 for developing web/Flash games.
The benefits of this transition are broader distribution (easy to reach thousands of players, or more, within days), trivial cross-platform support, and simplification of user experience (no install, configuration, or uninstall – just visit a URL). As tradeoffs: total file size matters for loading/download time, and keeping up performance can involve a few tricks. However both of those tradeoffs are matters developers are historically used to working with for other reasons, such a limited media storage and older processors, so there are traditions and patterns for designing to get the most out of such constraints.
I’ve already written a number of entries and sample projects about AS3, but they’re a bit spread about. Since I’ve been pulling together the same links for multiple replies, it seemed time for a new summary post specifically on this subject.
MXMLC Install and Basics
MXMLC is the name of the command-line compiler used to translate ActionScript 3 code into a SWF file for usage in the Flash player/plug-in.
- Part 1: MXMLC Command-Line Compilation – download and usage
- Part 2: Flash Game Core Tutorial – images, input, audio, collision, real-time updates
- Part 3: Motion Tutorial – button-like key handling, move-to-click, gravity bounce
Recompilation Scripts, Opening the Debugger – Using scripts for recompilation, and getting started with the command-line debugger
Remember to add a MochiBot to swfs as a way to keep track of plays. Many plays occur not on the original sites submitted to (Kongregate, Newgrounds, or otherwise), but instead on dozens or hundreds of other sites where the swf gets reposted. Using a few lines to add MochiBot to the project makes it possible to see where on the internet the game has been rehosted, and makes it easy to see simple graphs and counters for total plays.
It’ll be handy to bookmark Adobe’s official ActionScript 3 reference site to verify which functions and variables are available on existing classes, as well as checking which imports are needed for particular types of built-in functionality.
Beginner AS3 sample code (zip) – Very basic, but functional and ready for compilation
Everyone’s Platformer – Advanced platformer example, built from the ground up, that incorporates external file loading, optimized collision detection, a built-in level editor, and a variety of other features
This engine was used as the foundation for Vision by Proxy: Second Edition.
Everyone’s Platformer Level Editor Manual – Usage documentation for the level editor built into Everyone’s Platformer
2D Platformer Advanced Collision Detection – Technical and conceptual documentation about the collision detection in the Everyone’s Platformer AS3 example above
One not by me, but particularly useful if you have more retro-style games as the target, is the EZPlatformer example for Flixel. We used this tutorial as the foundation for Zylatov Sisters, as described in the entry on process for that project.
How to Monetize?
My main advice on Flash game monetization is to hold off a bit before aiming to do it. I make this suggestion for two reasons:
- Focusing on money for early projects can get in the way of freely exploring design ideas and technical lessons, stunting opportunities to develop the skills that can later pay off.
- Prematurely going after money is unlikely to be successful anyway, a bit like someone trying to sell their first attempts at poetry or oil painting. It generally takes considerable practice and experimentation to get to that level.
Although there are a variety of platforms available to support microtransactions, most of the people I know that have made money through Flash games did so through either licensing their games (getting paid to site lock and rebrand them), using their games to help win competitions leading to XBLA/PSN/WiiWare deals, or as portfolio samples to land decently paying (if inconsistent) contract work.
I don’t know anyone doing particularly well from ads in Flash games. Perhaps someone somewhere is, but as far as I can tell ads junk up the experience, and rarely make enough to justify that negative effect on the design. If deliberating the addition of ads, do the math as to the number of views necessary for the ads to produce any non-trivial earnings – and consider the risk that the inclusion of ads may turn off some folks from returning to the game or sharing it. It is not simply a matter of deciding whether to make no money or some money, the latter by sticking ads in or on the game; if that “some” amounts to a really trivial amount relative to the time put into it, it may wind up serving no real purpose other than annoying players off the bat.
Elephant in the Room: HTML5 (as of 2011!)
I touched on this question briefly a couple of months ago in Picking a Programming Language, but let’s address it head-on with a bit more detail here.
For interactive websites, yes, HTML5 is absolutely replacing Flash.
For real-time videogames, HTML5 seems to still be a long way from taking Flash’s place.
HTML5 renders differently on various browser and platform pairings. Like any website code subject to browser implementation, this can result in far more complicated testing, and even require branching in the code to account for different set ups.
HTML5 has trouble with basic audio. One common workaround for HTML5’s audio inadequacies is to use Flash for the audio. This clearly defeats whatever anti-Flash reasons drive some people to use HTML5.
(If you are using HTML5 for audio though, avoid using mp3.)
Out of the few dozen HTML5 games I’ve seen, their main selling point is that they’re made in HTML5 – not that they do anything new or different that players find value in, not because they were faster or easier for the developers to make, and not on account of the games being particularly good.
To double check my concerns about HTML5, I went to HTML5Games.com, an aggregation site. I tried to play a well rated, top ranked game, but every few seconds the game reloaded every tab that I had open, including the tab that the game was in. I was never actually able to see it in action, but at least closing that tab put everything back to normal. While I recognize that every HTML5 game doesn’t fail that severely, it probably doesn’t take many experiences like that one for a non-programmer to abandon a games site. I’ll bet that game works fine in Google Chrome, which has excellent HTML5 support, however if we’re going to require our players to install and use a particular browser our web games will immediately be at a major disadvantage.
Nor has it actually mattered much that these real-time HTML5 games are more likely to work on mobile devices than Flash. For interactive websites, it matters that HTML5 runs on mobile devices. For real-time videogames, typically programmed to use keyboard controls, or using mouseover/hover effect, etc. even if the swf ran flawlessly on mobile devices, most Flash games wouldn’t be usable on those platforms anyway without a substantial redesign. Moreover, Internet Explorer still has limited HTML5 support, and since it’s the default browser on the dominant operating system that’s a pretty significant set of users being lost as a tradeoff.
But, someone as recently asked, what about the Angry Birds implementation in HTML5? Though it’s admittedly an impressive port, it came only after the game’s massive success on iPhone set up the company to have resources for thoroughly testing and accounting for every browser and OS combination to get their completely designed game ported. (The core gameplay of Angry Birds, as a bit of an aside, follows in the footsteps of the style popularized earlier by the Flash game Crush the Castle.)
HTML5 seems to offer the cross-browser quagmire of web design to game design. Although, if the goal is to make an interactive multimedia website, HTML5 fits that task great. HTML5 is also a viable candidate for non-real-time games that primarily consist of navigating menus and clicking buttons to select choices. For the types of real-time games I develop, AS3 still looks like it will be the reasonable choice for the foreseeable future.
Do you live in Los Angeles? Let's make games together!
As of November 2015 we meet Thursday evenings in Beverly Hills.
Subscribe by e-mail to receive monthly updates with future Game Developers Like You interviews (my new content will be at GameDevsLikeYou.com)