Jordan Mechner is a game industry pioneer – he created and coded Karateka in the early 80s for the Apple II as a one man team and made it to #1 selling title, using revolutionary techniques to achieve realistic character animation and cinematic story telling. He later on continued to create Prince of Persia using the same techniques and found even greater success.

As a gamer and developer who grew up in the 80s, I got to play the original Karateka on the Apple II and the even better porting if it on the Commodore 64. It was definitely one of the best 8-bit arcade games ever made. For anyone too young to remember, those were the days with no internet, only floppy disks (or cassette tapes) as the common storage device, and crude development tools.

In those days, programming was a craft. For nearly a decade, a program had to fit into less that 64K of RAM and use so called ‘Hi Res’ graphics with only 16 colors (or even less if you used an Apple II) for any compelling visual. Most coding was done with 6502 assembly language (that’s machine code) –  can’t get any hard core than that.  What more can I say, I just love the 80s

Reading Mechner’s journals, you get a glimpse at the creative process including small daily details and challenges that game developers were facing in those days. Not surprisingly, most are still true today.

I specially liked this entry that describes how he creates the animation frames for the character:

April 29, 1986

[...] I still think this can work. The key is not to clean up the frames too much. The figure will be tiny and messy and look like crap… but I have faith that, when the frames are run in sequence at 15 fps, it’ll create an illusion of life that’s more amazing than anything that’s ever been seen on an Apple II screen. The little guy will be wiggling and jittering like a Ralph Bakshi rotoscope job… but he’ll be alive. He’ll be this little shimmering beacon of life in the static Apple-graphics Persian world I’ll build for him to run around in.

This is a fascinating read – check it out the page for The Making of Prince of Persia – with its funny video trailer showing the actual video footage with the gameplay scenes.

This book is a great source of inspiration for any creative person. You feel the excitement all the way through. Imo, this is a must read for any aspiring game developer, and I highly recommend it.

For a game that runs on a [desktop] browser, player update may be required. This should not be a problem, except for some older versions of Mac OS X that can only run Flash 10.x, but not Flash 11. This is the case for OS X 10.4 (Tiger), and 10.5 (Leopard) – so if you want to target these your only option is to have your game compiled to Flash player 10 specs.

The best bet for this case is to target player version 10.3. First of all make sure you are not using any of the Flash 11 specific features (Stage3D and native JSON). Next you need to set the compiler option so the output SWF file would run properly on the older player, since the Flex 4.6 SDK defaults to Flash 11.

To do that, you need to invoke the swf-version compiler option. On any of the decent IDEs there is access to compiler command line options. Flash Builder, FDT and Flash Develop have it inside project settings, and if you are using ant script to build the code, the command line options are available in the mxmlc tag.

Simply add the following to the additional compiler arguments:

-swf-version=12

The swf-version compiler option specifies the SWF file format version of the output SWF file. Features requiring a later version of the SWF file format are not compiled into the application. This is different from the Player version in that it refers to the SWF specification versioning scheme. In this case 12 is the scheme for player 10.3.

As an added bonus, you’ll be able to debug the game code as if it is running in the target version. Any code that requires Flash 11 will cause a run time error with stack trace – that comes in handy in case there you left ‘invalid’ features hiding in the code.

I found that most of the tutorials on sprite sheets are for the Cocos2D engine (in Objective-C for iOS). Here I will show a practical and convenient way to animate sprite sheets in AS3, making the game perform well on both Flash in browser and AIR mobile.

There are a few off the shelf engines that use variations of spritesheets, among them Starling (Flash 11 only) and Flixel. These may be perfect for certain type of projects, but I decided to write my own classes to minimize the dependency on 3rd party code.

Demo

Click image to see the demo

Download the full demo code from BitBucket here.

The Tools

You would need a code IDE (FlashDevelop, FDT or Flash Builder) and an image tool that can pack textures. I use the popular TexturePacker, in my opinion the best texture tool for developers. If anyone knows anything better, please comment.

Preparing the assets

The animated sprite is created by the artist  with their animation package of choice. This is a sequence of images that form the animation frames.  In this case (and most others) all frames are the same size.

Open TexturePacker and import the individual images into the projects. Select json as the data format, check ‘Allow free sizes’ and make sure ‘Allow rotation’ is not checked. Publish the texture to the output folder. The setting I use can be seen here.

There are many different options with TexturePacker, that are out of scope of this article. For more in depth look, check out Chris Fletcher’s tutorial here.

Once published, you end up with a large PNG file – the texture sheet, and a json file to go with it.

Reading the texure with the AnimTextureSheet class

I created the AnimTextureSheet class to encapsulate a texture sheet and its data. After loading your animation assets, you get a BitmapData from the sheet PNG and a string from the json file. After decoding the json string, the function populateFrameArray serialize the frame data into an array which is then passed into the  newly created AnimTextureSheet.

	var seqRaw:Object = JSON.decode( sheetData );
	var animData:Array= [];
	populateFrameArray(animData, seqRaw.frames);
 
	// Sort
	animData.sortOn("id");
 
	// Create and initialize the tile sheet
	var tileSheet:AnimTextureSheet= new AnimTextureSheet();
	tileSheet.init(texture, animData);

Once initialized, the tille sheet is ready to go, and the  drawFrame() method can be called to blit a frame into a destination bitmap buffer.

UPDATE
When compiling with Flash Player 11 (or Flex 4.6) there is a build error due to the new native JSON parser:
Can not resolve a multiname reference unambiguously. JSON [..]
To resolve the problem, simply change the first line to read:
var seqRaw:Object =  com.adobe.serialization.json.JSON.decode( sheetData );

Play it

To actually display the animation,  we need a display object to hold the bitmap. For that purpose I created the AnimSprite class, that is based on flash.display.Bitmap. This class in only for convenience - you can create your own – it demonstrates the possible use cases for an animated sprite.

	private function createAnim():AnimSprite
	{
		var anim:AnimSprite = new AnimSprite();
 
		anim.initialize(_texSheet);
		anim.addSequence("all", arFrames, 16);
 
		anim.play("all");
		return anim;
	}
 
	// Call on enter frame event
	protected function onFrameUpdate(event:Event):void
	{
		if (pause){
			return;
		}
		for (var i:int = 0; i < arSprites.length; i++) 	{
			AnimSprite(arSprites[i]).updateAnimation();
		}
 
	}

The above code shows how AnimSprite is actually used.

1. instantiate the AnimSprite
2. initialize it with  a tile sheet
3. add one or more sequences (indexed frames) with an individual frame rate
4. add it to the stage.

To play it:

1. Call play() to start playing a sequence
2. call updateAnimation() on every frame

How it works

AnimSprite uses partial blitting technique to animate. It uses the bitmapData as a frame buffer that holds the frame image that gets displayed. On every update, the updateAnimation()  function checks if the animation frame need to advance, and if so calls advanceFrame() – that sets the dirty flag when the current frame index is changed.  The the following method is then used to draw the frame:

	protected function drawFrameInternal():void
	{
		dirty = false;
 
		bitmapData.fillRect(bitmapData.rect, 0);
		mAnimSheet.drawFrame(curIndex, bitmapData);
	}

Check out the code for more details on the AnimSprite class.

That’s pretty much it. Let me know if you find any bugs or problems.

This article is cross posted on #AltDevBlogADay. See my other articles published on #AltDevBlogADay here.

Mapping Objects and Assets

Before actually making the first level, we need to create a manifest of all game objects. These can be anything from background elements, pick-ups or characters. Most are represented by static bitmaps or sprites-sheets where the game object is displayed using a single asset.

The idea is to map a logical game object (class) to a physical asset (bitmap or simple shape). For simplicity, we assume the size of the asset defines the bounding box of the logical game object. Each entry in the manifest will pair the class name with the asset file name, and a class ID. Its recommended to use some kind of naming convention with prefixes etc.

Building the Basic Level

Next we create a level template. This is a project with an empty level that would serve as a base for all future levels. Create a new Flash project (fla) and import all your assets into the library and save the file.

Flash keeps library objects either as the source assets or movie-clips, with the latter used as a container for a display object that can be manipulated.
For each of the source assets, create a movieclip for it (using F8), and name it to match the class id in the manifest. Save the file and start dragging objects to the stage. You can define a layer for graphic elements that are not exported and place there references, guides and bitmaps from the mock up. Make sure to have a rectangle that represents the screen bounds.Use the first level as template for the rest, reusing the same library objects.

Exporting the Level

The flash project file (fla) is how a levels is saved. This would be an intermediate file that will only be used to modify the level on design time. To actually use it in the game, we need to export the level data to a format that can be loaded at runtime.

Export the level data means we serialize it to XML, which will contain entries for all instances of game objects, each with is metadata (like class name, position, rotation and size). For that, we make use of JSFL – the JavaScript Flash API that’s included with the Flash IDE.

The following JSFL script creates an XML file and saves it in the current folder. To run, use Commands -> ‘Run Command’ and then point to the script file (should be saved with jsfl extension). After the first run, the script name will appear under the ‘Commands’ menu for quick access.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

//==========================================
//
// Export all stage instances to xml
 
	var doc = fl.getDocumentDOM();
	doc.selectAll();
 
	var sel = fl.getDocumentDOM().selection;
	var myXml = "\r\n"
 
	var iLen = sel.length;
	for (var i = 0; i < iLen; i++) {
		var s = sel[i];
		if (s.instanceType != "symbol") continue;
		myXml += "    <child type='" + s.libraryItem.name + "'";
		myXml += " x='" + s.x + "' y='" + s.y + "'";
		myXml += " rotation='" + s.rotation+ "'";
		myXml += "/>\n";
	}
 
	doc.selectNone();
        myXml += "</level>";
 
	flash.outputPanel.clear();
	flash.trace(myXml);
	var exportFileName = doc.pathURI.replace(/%20/g, " ").replace(doc.name,
                                doc.name.replace(/\.fla$/, "") + ".xml"); 
 
	flash.outputPanel.save(exportFileName);
	flash.trace("File saved to " + exportFileName);

Here is a sample of the resulting file:

A major advantage of this export is the ability to easily customize the XML data by changing the script to add different properties for each entry (lines 15-18).

Loading the Level

1. Read list of game objects from XML into an array.
2. Iterate on the array. For each item:
   1. Pass the class name to a factory method to create a new instance of the object.
   2. Locate the asset (resource) associated with the object, by looking it up on the object manifest map.
   3. Call the init function on the newly created instance, to populate it with the asset and metadata.
   4. Place the object on stage
3. End

Your mileage may vary, but that should do the trick. Here I assume all game entity classes are based on one base class, and make use of polymorphism to construct and populate them.

Round Trip and Edit Cycle

As mentioned before, the level is also saved as a native ‘fla’ file, as intermediate, so it can be loaded and exported at any later time. The most effective way to edit a level is by instant round tripping between the game (preview) and the editor. Round tripping is the process of moving from runtime back to design in order to edit or modify the level data.

Round Tripping

With a build of the game ready to run and the export script in place, this is made possible.Typically, the designer will have the level editor still open after exporting the data. Running the game will load the data and serve as a preview. If the game runs on a browser its only a matter of refreshing it to reload new data. Now all that is left to do is follow the sequence:  Edit –  Export –  Preview, rinse and repeat.