Abstract

We’ve heard this story before: big-game developer gets tired of big-game team size, pressure, and politics, and switches to making small games. New companies filled with people escaping the retail AAA industry, developing these “casual” games, are popping up all the time. These aren’t the silly little things that get forwarded to us in email and hold our attention for 30 seconds. These are games that make money, and hearken back to the days of yore when a couple geeks in a garage could put together a hot shareware title in a few months and get rich quick. The big difference today is in the tools. We can build bigger, better, prettier, more advanced games with fewer people in less time and for less money than ever before!

One of the most respected (and reviled) tools for making interactive content is Flash. Well, what about Flash as a game development platform? It has grown in power considerably over the years. The casual games we build today are equivalent in production quality to the AAA games that were shipping around 10 years ago. Can we do it in Flash instead? And why would we want to?

This paper is the story of the Oberon development team’s experiences with building games in Flash. All of us came from big games where we built our own tech (the author was a C++ game systems engineer for nearly ten years), so why did we choose Flash as our development platform instead of building our own casual games platform? What was so hot about Flash, and what caused us headaches? And, most importantly, when should we avoid using Flash entirely?

Casual Games

Before we get started, we should first talk about what exactly a “casual” game is. Most of the time, this term is referring to a game that…

…is between 3 and 10 megabytes in size (56K modem users usually won’t be able or willing to download anything bigger).

…sells for around $20 in the impulse buy zone. About the same as a CD, or a cheap date.

…works on ancient computers with equally ancient operating systems.

…is exclusively distributed online through channels like MSN or RealArcade.

…has a vastly different audience than retail PC/console games.

…is developed for a fraction of the price and resources as a big retail game.

Also, casual games will frequently have a web-hosted “teaser” that players can play forever for free, with a more full-featured “deluxe” version that is downloadable. The deluxe version is almost always copy protected by the distribution channels, and limited in some way until purchased (often a simple 60 minute timeout). And in many cases, the old shareware model still works, nagging the user with guilt screens to pay.

That’s a lot of constraints. Most of the time, we’re ruling out requiring a 3D card. If there’s 40 hours of gameplay, it better reuse a lot of art, because it just won’t fit into 5 megs. 8000 lines of voice-overs are out of the question. And forget about using an expensive middleware solution – while dropping $50K on a physics engine in a $10 million Xbox title may be no big deal, it will instantly destroy the budget of a casual game.

The Development Platform

In order to meet our constraints, we have the following requirements for our theoretical casual games development platform:

• The executable code must be small. After we subtract the space needed for the installer and DRM wrapper (sadly, this can be a megabyte or more), the audio, and the art, we don’t have much left. Forget about bloated C++ template libraries and big third-party DLL’s. It’s even worse on the Mac due to the fatter PPC instruction set (fortunately, Mac users are on broadband more often than Windows users).
• The content must be small. We can’t get away with PNG’s and BMP’s and WAV’s. We’ve got to store our content in JPG’s or JP2’s and MP3’s or OGG’s.
• We’ve got to grab players’ attention. We want to be able to build and integrate visuals that “pop” without having a programmer get involved, sequencing complicated animations by hand.
• The engine needs to avoid fancy API’s that probably don’t exist on the client machines. Nobody is going to have DirectX 9 installed, or the .NET Framework, or the right GDI+, or know how/want to download and install them. We’ll be lucky if they have a recent version of shfolder.dll. They’ll have ancient hardware drivers. And don’t even think of dropping support for Win98! (Win95 is apparently ok to drop, though, according to our stats.)
• Performance is a huge concern. Many of our players’ systems will have old CPU’s and minimal memory. They’ll be riddled with spyware and viruses, which makes the CPU and memory problem even worse. This engine must be tight, efficient, and fast.
• The toolset needs to support rapid iteration. Wasting a day of time could be one or two percent of the entire production schedule! So we’ll need a scripting language, a good layout and animation tool, a flexible object model, and try to data-drive it all.
• We’re going to want to make a web version of the game as a teaser. So we need to have a route to the web that doesn’t involve contracting out an expensive rewrite in Java or Flash.

So what about Flash? Can we really make games with it?

What is Flash?

Flash has come a long way since the days of Punch the Monkey and Win advertisements. Flash 7 (known as MX 2004 at retail) is a modern interactive platform, with a powerful design and animation authoring tool, an object-oriented type-safe dynamic scripting engine, bitmap rendering with antialiasing and subpixel precision, and advanced video and audio playback features. “Flash” is actually three components: the player, the file format, and the authoring tool/IDE.

The Player

Everyone knows what the Flash Player is. Nearly every computer on the internet has Flash – according to NPD, its penetration is higher than Internet Explorer’s, at 96%. We load Flash in our browsers every time we visit web sites with irritating advertisements. For the version 7 Player, it’s a 1 MB ActiveX control (OCX) that compresses to 560K, usually installed in C:\windows\system32\Macromed\Flash.

The player consists of:

• A virtual machine. This interprets and executes bytecode for ActionScript, Flash’s scripting language. As with any managed environment, the system uses a garbage collected memory manager. The VM’s execution engine can be fairly slow – more on how to work around this later in the paper.
• A hierarchical frame-advancing visual object model. Flash maintains a hierarchy of MovieClip objects (and Graphic and Button, but those are less useful) in a layered display list, where each object has its own frame-subdivided timeline, and layers map onto z-order. The clips can be laid out in the IDE, or created and rearranged from code based on exported symbols in the library. Each has a parent, which eventually goes out to _root. MovieClips can also be loaded dynamically from external SWF’s into anywhere in the hierarchy.
• A set of media decoders. Flash can decode and play back multiple streams of compressed audio and video simultaneously. It has decoders for ADPCM, MP3, and NellyMoser (for voice). For video it supports Sorenson H.263 and Sorenson Spark. Because of the ubiquity of Flash on the web, and the quality of Spark, many sites such as Amazon are starting to use Flash for video playback instead of the traditional Real, Windows Media, or QuickTime players.
• Rendering algorithms. Flash has a set of fairly advanced algorithms for rendering vector graphics, including lines, splines, gradients, and antialiased, filtered bitmap fills. Flash is a vector engine, but its support of bitmap fills means it’s also a bitmap engine – when a bitmap is dragged onto the stage, Flash actually creates a four-sided shape then attaches a bitmap fill with an identity texture transform matrix. Each shape fill can have a texture transform as well as a simple shader for playing with the color and alpha of texels as they are rasterized. There are many examples online using Flash to render simple 3D objects in this way.
• A framework library. Much of this is just the standard library we would expect from any JavaScript implementation – basic string functions, arrays, sorting, math, etc. Flash also adds support for TCP communications (no UDP unfortunately), asynchronous loading, XML, and more.

The File Format

The Flash file format is known as SWF (from Shockwave Flash, pronounced “swiff”), which has gone through many revisions over the years. SWF is a tag-based binary format designed for streaming, with zlib compression on top to keep it small. It’s important not to confuse Flash with SWF – while the Flash environment has a closed FLA document format (more on this later), and the Player is closed source code, SWF as a file format is free and open – the spec is complete, and easy to find on Macromedia’s site:

http://www.macromedia.com/software/flash/open/licensing/fileformat

Here is a more programmer-friendly version:

http://sswf.sourceforge.net/SWFalexref.html

Many apps have been created that output directly to SWF, such as vector drawing programs, charting programs, screen capture software for demos, presentation software, and enterprise frameworks such as Flex and Laszlo. There is even an MSIL-to-SWF compiler by Robin Debrueil that lets us write code in C# or VB.NET and compile into SWF.

There are a few potential alternatives to SWF that meet some of our requirements, but not nearly enough:

• SVG from the W3C. Scalable Vector Graphics is a standard popular with the open source community, but not much of a competitor to SWF, primarily because of the tools available to build SWF’s. The only SVG authoring tools currently available are very primitive – they are today where Flash was 5 years ago.
• XAML from Microsoft. This hasn’t been released yet, but it looks like a good, comprehensive system. However, until we see an authoring tool, we can forget about it. There is at least one SVG-to-XAML converter (from Xamlon), but that doesn’t solve the problem with the authoring tool. Not that it matters much anyway – XAML and the composition engine to render it cannot be considered standard on desktops in the casual audience for ten years, at least not if the number of people running Win98 today is any indication of how people drag their feet on upgrades. And when it’s released, it will likely have the same problem as the .NET Framework does today (even worse, as “Avalon” requires .NET) – the redistributable size will be in the tens or hundreds of megs, overwhelming the download size of the game.

The Flash player is available on Windows, Mac, Linux, and PocketPC. For mobile phones the Flash Lite player is increasingly supported, although this player only supports relatively primitive Flash 4 level scripting.

This is the equivalent of Visual Studio for composing Flash content, and it’s what Flash developers spend most of their time using. Contained within its integrated development environment are the following major components:

• A code editor. Don’t use it, it’s terrible. Better than Notepad, but nowhere close to a tool like Visual Studio. At Oberon we avoid using Flash’s built-in code editor for anything over 10 lines of code, and instead use PrimalScript by Sapien (www.sapien.com). PrimalScript supports standard features we’ve all become accustomed to, like IntelliSense, unlimited undo, source control integration, etc. Despite it being buggy and overpriced, it’s worth using. Because of the dynamic nature of JavaScript, it’s easy to mess up and spell something wrong, or pass the wrong parameters into a function, without the compiler catching it. The IntelliSense feature helps to avoid these silly mistakes, which can save a lot of debugging time.
• An animation editor. This is one of the most powerful features of Flash. Animations are done using familiar tools like layers, tweening, onion skin, easing in/out, etc. Most people are familiar with Flash’s vector animation abilities, but the same system works with bitmaps as well, which are simply treated as fills on vector shapes (i.e. textures with transforms).
• An editor for vector art. While most of the art is likely going to still be bitmaps, it’s frequently useful to use the vector engine for drawing the gradients, line art, and fills that are so common in game UI’s. And when it comes to prototyping something quickly, it’s trivial to bang out some decent looking programmer art in a few minutes.
• A compiler. Flash’s scripting language is called ActionScript 2.0, which is actually an advanced version of JavaScript based on the ECMAScript 4 draft spec. This version takes the dynamic JavaScript language and adds features such as static typing, classes, interfaces, and type safety.
• A content build system. This is the compression and packaging step, converting bitmaps and audio into JPG and MP3. Code and content are wrapped up into a SWF, which is Flash’s packaged file format. Versions since 6 have supported zlib compression of the SWF, so the files can be very small.
• A debugger. This is probably one of the worst features of Flash. The debugger supports standard features like breakpoints, watching variables, and a call stack trace, but don’t let the feature set fool you. It is poorly implemented, has terrible usability, and is almost criminally slow and unreliable. When projects get over a certain size, the debugger becomes impossible to use, and the only choice is to fall back to “printf debugging” (i.e. debug via log analysis). Most of the time this works well enough, and the tough-to-debug cases can be handled by copy-pasting a subset of elements into a test file and debugging from there (more on this later).
• A help system. Flash stores all its help in HTML files, but the interface to it from the IDE is pretty awful compared to a viewer like the MSDN Library uses. Some tools such as PrimalScript can index this content and provide a better viewer for it, but only slightly. It’s good for context-sensitive F1 style help, but that’s about it. Fortunately there’s a great workaround: the Flash Resource Manager, which is a free tool that integrates help from Flash with a decent interface, but also will search a variety of online resources such as the amazing FlashCoders mailing list, Macromedia Tech Notes, Fullasagoog, and many others. It can be found at http://www.markme.com/mesh/archives/004700.cfm.
• A content manager. Flash has a good system for managing content. It will import art and audio stored in most major formats into its “library”, which is organized as a tree structure. This is convenient for developers – artists and composers can store their assets in version control in whatever folder structure they like, and engineers integrating it can organize it in the library in a format that is more convenient for them.

The IDE manages FLA files, which are the source for creating SWF’s. All art and audio used by a FLA are stored directly inside of it in a lossless format. The FLA also maintains a reference to the original file on disk, so when the asset changes on disk, it can be updated in the FLA. The disadvantage of this is that assets must be updated manually (although this can be automated as part of a scripted build process). Artists working on bare PNG’s can’t simply check in new art and expect to see it, unless they tell an engineer to update it in the FLA. Artists working on FLA’s directly will need to remember to update their libraries to get the art they just changed in. But on the other hand, the advantage of this process is that assets can be updated only when the engineer is ready for it. There are no problems with someone checking in new assets that accidentally break the build, because the integrating engineer will have to know about every change that is made.

“Publishing” the FLA initiates the build process, and will result in a SWF, usually with graphics compressed to JPG and audio compressed to MP3. The type and level of compression are configurable on a per-asset basis, as well as with global defaults.

Flash’s IDE is scriptable via a language called JSFL, which is JavaScript plus a DOM for the environment. The library for JSFL can be extended with DLL’s written in C. Nearly every feature of the IDE can be used from JSFL. In fact, any command the user performs is recorded in a history buffer for undo/redo, and most commands have a JSFL equivalent. It’s trivial to drag-select a set of commands in the history and save them as a JSFL function. This is a convenient way to learn JSFL coding – just do the operations manually, then save the code and make adjustments from there.

Panels and custom tools can be created in the IDE that look and operate just like the UI that ships with the IDE. The UI for these is (unsurprisingly) implemented as SWF’s configured with an XML language.

Flash MX 2004 Pro costs $700, which is on par with most IDE’s. It uses a product activation system that permits two installations per copy, which is convenient for working on Flash at work on the workstation or at home on the notebook. It’s available on Windows and Mac – the interface is nearly identical on both versions, and the FLA format is the same, so files can be interchanged. In the few places where a path can be stored in a FLA (such as for publish settings), each platform will accept path separators from the other platform.

So what is so hot about Flash? Briefly, the main advantages are:

• A great authoring tool for interactive content. Integrates most features needed for making a game.
• Flash is everywhere. For the web version of a game, 96% of the audience won’t need to download anything except the game. More importantly, many people won’t be able to install arbitrary ActiveX controls, or use a Java plugin, whereas Flash is preinstalled with Windows on corporate machines.
• Near trivial porting to Macintosh. Open up another 5% of the market to an audience desperate for decent games.
• Easy conversion from a full game to a web version, or if going the other way, a natural path to take from web version to full downloadable game.
• Cost is essentially free – there is a small cost for the Flash IDE, but it’s nearly free to distribute (just some minor licensing things to worry about that don’t cost anything). Royalty-free licenses for decoders such as MP3 and Sorensen Spark are included.
• Ease of finding artists. There is a huge talent pool to draw from for creating art or animations for Flash, either on staff or contract.
• Embed your game in PowerPoint when giving a GDC presentation!
• A gigantic community and secondary market. There are thousands of Flash related web sites with tutorials, articles, and discussions. There are hundreds of Flash add-ons or components for sale.
• Easy copy-paste to test things out. Flash permits drag-and-drop or copy-paste from one FLA to another, and it automatically brings along any dependent objects into the new library. This can make it incredibly easy to try out quick ideas outside of the main game, and is the one case where it’s worth using the debugger.

The main advantage of using Flash, though, is that it’s simply well-suited to the task of making games. An entire gameplay mechanic can be prototyped in a few hours, with decent art, in an easily packaged form that runs on a PC, Mac, or Linux, through a web browser or standalone...royalty-free. If we want to scale up to larger games, i.e. go from prototype into downloadable casual games, then there are some tricks to use to make it work, but nothing too awful (there’s more on this later in the paper).

The hierarchical visual object model in Flash is the main reason for this fast prototyping ability. It’s difficult to describe how powerful it is without showing a demo, but here’s an attempt. Take for example any graphical object that can have multiple states, such as:

• A toolbar that, based on mouse proximity, may slide on or off the screen, or alpha in and out.
• A player avatar that can have many different skins, and within each skin are several different poses, each of which is animated.
• A checkbox that has states for hover, down, up, and disabled.
• An object that, if the player destroys it, breaks into fragments and explodes with an effect.
• Room decorations that can be added to a scene, such as a clock, nightlight, potted plant, candle, or spider web. Each of which may have multiple states, such as ticking, not ticking, lit, not lit, alive, and dead. Each of those states may be animated, and there may be animated transitions from one state to another.

In all of these cases, the results can be accomplished with a small amount of visual programming. Let’s focus on how we would implement the toolbar:

1. Create a movie clip “Toolbar” that contains all of the screen elements on the toolbar such as a background, buttons, text, etc.
2. Create a new clip “ToolbarAnim” that contains just one instance of the Toolbar.
3. It starts out with one frame. Give it an extra frame, and name the two frames “On” and “Off”.
4. Go to the second frame, and drag the Toolbar instance so it is off-screen.
5. Now add a new object, say a vector rectangle that spans both frames. Convert it to a movie clip called “ToolbarHotSpot” then keyframe it, and in each frame, size it for where the mouse can be to keep the toolbar open. Convert this rectangle to a movie clip, and set its alpha to 0. Name it to “_hotspot” in both frames.
6. In frame “On” have _hotspot respond to onRollOut with gotoAndStop( “Off” ). And in frame “Off” have _hotspot respond to onRollOver with gotoAndStop( “On” ).

Now we have an auto-hiding toolbar, and it took just a couple minutes to create. Actually, it took longer to write about than it did to create. That’s a fun trick, but the power of nested clips really starts to show if we were to decide to make the toolbar animate off-screen as it is hiding. To do this, we’d throw a bunch of frames after Off, tween the off-screen motion with some ease-out selected, and change the gotoAndStop( “Off” ) to gotoAndPlay( “Off” ) with a stop() in the last frame. That takes about 30 seconds to do.

Every single one of the multiple-state graphic examples described previously can be done in this way. In Flash, a state machine for a graphical object can be represented by a named frame in a MovieClip. And a hierarchical state machine is simply a set of nested MovieClips. If we want animated transitions between states, we can simply insert frames that do the effect we’re looking for, followed by a stop() somewhere at the end (plus maybe some additional code, such as an event callback to notify the game that it’s done). If we want more complicated behaviors, we can create a class that extends MovieClip, and associate it with one of our clips.

Let’s go through one more example. Say we need to represent a game level in Flash, with decorations like furniture, plants, wall outlets, etc. We would create an object called Decoration and export it so the code can create it and place it in the level based on the XML level data. Inside of the Decoration we’d make one frame per different object, and name each frame according to its contents. The code can switch among them using gotoAndStop() on the Decoration to go to the correct frame that shows the object we want (again, based on XML data at level load time). Now let’s say we wanted to add states – a candle can be lit or extinguished. We would go to the object on the Candle frame within the Decoration object, convert it to a movie clip, create frames inside it for the Lit and Extinguished states, and then out in our game code, now we can use gotoAndStop() to switch between these states. Now, say we want to go even further, and show a fireplace that can be lit or extinguished, but we want to show it starting to burn, or start to go out. We can add more frames and insert a bitmap sequence (or other animated effect) and switch to gotoAndPlay() instead to show a transition.

This simple method of visually sequencing behaviors is the most powerful concept in Flash. Objects can be made deeper, more complex, more interactive, in a clear and intuitive way, without breaking any code that was working with a higher level of hierarchy. In the previous example, the fact that the candle can be lit or extinguished doesn’t affect the level load logic, which only knows that the object is a Candle. Artists can go into an assets file in this way and add effects or animations to objects without requiring an engineer, and without breaking the game.