So what is so hot about Flash? Briefly, the main advantages are:
By Scott Bilas, Oberon Media, Inc.
- 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.
What is a Flash Game? >>>