Each time a user loads up my game and requests a level the level will be sent from my server to the game. This happens regardless if the player had previously downloaded the level at some point. The only exception is that I store levels in a shared object during a game session (Well, sorta. I won’t go into great detail here, but there is some client-side caching going on, but it’s not guaranteed). The implications of this are that:

1. I’ll used a LOT of bandwidth sending levels to players
2. Players will spend a fair amount of time downloading levels

By reducing the size of the level files I can mitigate both of these issues. Enter compression. Or perhaps “mapping” is a better term. The question becomes how to compress XML? One of the qualities of XML is that is must be well-formed, that is, it must be a well-constructed, logical structure to hold data. In the case of a tile-based level this means there will be lots of repeating data. For example, a tile node in XML might look something like

<tile>
    <tileType>myType</tileType>
    <tileImage>myImage</tileImage>
    <someTileData>blah</someTileData>
    <someMoreTileData>blahblah</someMoreTileData>
</tile>

So that’s not that much data until you take into account that the minimum size of a level for this game is 32×18 cells for a total of 576 cells, at minimum. The quick and dirty way to cut down on the file size is to remove “pretty printing”. In XML parlance this refers to the nice indentations that make XML easily readable by humans. Since my XML will only ever be read by software it doesn’t need to be pretty. By removing pretty printing I was able to achieve a nice reduction in file size. However it still wasn’t good enough for me.

The next step I took was to map things like tile types and names — anything that was used over and over again in the game — to a static object. Something like this:

public class TileData
{
    public static const TILE_TYPE:String = "1";
    public static const TILE_NAME:String = "2";
    public static const SOME_TILE_DATA:String = "3";
    public static const SOME_MORE_TILE_DATA:String = "4";
    // and so on and so forth
}

Doing this allowed me to replace things like “my relatively long tile type” with “a”. This mapping is completely arbitrary and the only real constraints are that the mapping go from a long name to a shorter one (not strictly a constraint, but if you don’t do this why bother?) and that the mapped name be unique for the mapping type.

So now, after running through my mapping utility my xml looks something like this:

<tile>
    <tileType>1</tileType>
    <tileImage>2</tileImage>
    <someTileData>3</someTileData>
    <someMoreTileData>4</someMoreTileData>
</tile>

So that can be a decent reduction in file size for xml, but we can take this one step further by also mapping the node names:

public class CellData
{
    public static const TILE_NODE:String = "a";
    public static const TILE_TYPE_NODE:String = "b";
    public static const TILE_IMAGE_NODE:String = "c";
    public static const SOME_TILE_DATA_NODE:String = "d";
    public static const SOME_MORE_TILE_DATA_NODE:String = "e";

}

Resulting in:

<a>
    <b>1</b>
    <c>2</c>
    <d>3</d>
    <e>4</e>
</a>

Or, with no pretty printing:

<a><b>1</b><c>2</c><d>3</d><e>4</e></a>

So, mapping xml data to static objects in ActionScript can put a pretty significant dent into the size of an xml document but what about the drawbacks? The primary downside of this is keeping everything straight. Node names must be unique, in that you cannot map both “myNodeA” and “myNodeB” to “A”, they must be mapped to separate values. This means you have to keep track of what’s been used an what has not been used.

This method also makes it very difficult to look at your exported xml and find any possible errors if you find yourself in a debugging situation. The final issue that I’m running into is that I need to maintain the map in two locations: my level editor application that produces the xml and my game that consumes it (well, technically the editor also consumes this data as it can open saved files). This last issue is largely a matter of cut and paste, but it is one more thing.

Some Implementation Details

So all this theory is good and well, now for some details. My level editor is an AIR application written in Flex Builder 3 using the Cairngorm framework. The game is using tile based levels and each level file is a list of each tile, or cell, that contains data of interest (i.e., one that is not blank) and some meta data for the level (think level name, creator, data created, etc.).

When a level is open in the editor all of this data is held in value objects. I then maintain two mapping classes — the static classes mentioned above. One of these classes maps xml node names, the other maps common tile values. None of the meta data is mapped as it will effectively be unique for each level. When a level is saved I gather up all the cells and meta data, loop through all this data and look up the mapping for each property and construct an XML object.

// Assuming we have a TileVO like this
public class TileVO
{
    public var tileType:String;
    public var tileImage:Number;
    public var someTileData:String;
    public var someMoreTileData:int;
}

// When I save it would look something like the following

// ... begin snippet

var xml:XML = new XML();
var tileXml:XML;
for each (tile in tiles)
{
   tileXml = <{CellData.TILE_NODE}></{CellData.TILE_NODE}>;
   tileXml.appendChild(<{CellData.TILE_TYPE_NODE}>{tile.tileType}</{CellData.TILE_TYPE_NODE}>);
   tileXml.appendChild(<{CellData.TILE_IMAGE_NODE}>{tile.tileImage}</{CellData.TILE_IMAGE_NODE}>);
   tileXml.appendChild(<{CellData.SOME_TILE_DATA_NODE}>{tile.someTileData}</{CellData.SOME_TILE_DATA_NODE}>);
   tileXml.appendChild(<{CellData.SOME_MORE_TILE_DATA_NODE}>{tile.someMoreTileData}</{CellData.SOME_MORE_TILE_DATA_NODE}>);
   xml.appendChild(tileXml );
}

// ... end snippet

Looking at this you’ll notice that I don’t actually map the value of the properties here, rather the mapping is how all the values are always stored, in memory or on disk.

To read this data in and map it back to value objects there is a slightly different syntax:

// ... being snippet

var tileVO:TileVO;
var tiles:Array = [];
for each (var tileXml:XML in xml)
{
   tileVO.tileType = tileXml[CellData.TILE_TYPE_NODE];
   tileVO.tileImage = tileXml[CellData.TILE_IMAGE_NODE];
   tileVO.someTileData = tileXml[CellData.SOME_TILE_DATA_NODE];
   tileVO.someMoreTileData = tileXml[CellData.SOME_MORE_TILE_DATA_NODE];
   tiles.push(tileVO);
}

// ... end snippet

Having just been robbed on about $25 I’m keeping my installer file and license key in a safe place so I can’t be taken again. I would love to recommend making a switch to some other FTP client, but sadly, I think SmartFTP is the best one available for Windows. So instead I’ll recommend that everyone who purchases a license for SmartFTP keep the installer file and license file in a safe place.

Sure enough the entries were there:

<compilerSourcePath>
      <compilerSourcePathEntry kind="1" linkType="1" path="properties"/>
      <compilerSourcePathEntry kind="1" linkType="1" path="locale/{locale}"/>
</compilerSourcePath>

At this point I’m not really sure what the kind and linkType properties are for other than the fact that 1 is the default for both of them. I’ll post back as I found out more. In the meantime this has allowed me to add build paths to my projects with Flex Builder 3 on Windows 7 x64.

UPDATE.

Seems turning off the Logitech software I use for my mouse and keyboard resolves this problem altogether.

You can read the full article here: Creating Application Menus in Mac OSX with Adobe AIR.

BKWLD also has it’s own blog so I’ll be blogging about work-related topics and things I learn about Flex through work there. You can follow me here.

It stared with getting the front bumper off which was secured with about 16 bolts and one metric (yes, metric on a 1973 American car) bolt. This took awhile since we didn’t think two of the bolts needed to be removed to pull the bumper off. We were wrong, a trend that would continue with this project.

Next we removed the hood and fenders all so we could remove the “Ventura” insignia on the fenders and then we started on the rear bumper. The rear bumper that, much like the front one, we thought we had ready to remove. The rear bumper that ate a wrench and necessitated the over-nighting of new wrenches. The rear bumper that had to have a stripped bolt drilled out of it. The rear bumper that still took twenty minutes to remove after all the bolts were removed. It’s off now.

While waiting on the wrenches needed for the rear bumper we went to work on the rest of the car’s insignia. This included a “Custom” and Pontiac logo on each side behind the rear windows and a “Custom Hatchback” insignia on the the back. Figuring these insignia were much the the ones on the fenders we took apart the interior to gain easy access to the bolts from the inside. Turns out the interior was welded in such a way to make accessing them impossible.

So we started pulling them off.

And this proceeded for about an hour with little progress. We tried razor blades, knives, screwdrivers all to get some leverage. None of it worked. In the end we invented the ultimate insignia removing tool. This tool is constructed from microfiber cloth and duct tape. It starts with a thin piece of duct tape that gets progressively thicker until it connects to the microfiber. Using this we were able to remove all the remaining insignia in about fifteen minutes.

Presently the Ventura is sanded and ready to be primed. Some pix are below.

Just today I found a bug that seems to affect 64-bit Windows user in the Project Properties dialog. The bug in question is that the “Flex Modules” section of the properties dialog is blank. So there is no way to add or remove modules from the project build. To fix this, open the Properties dialog (Project > Properties), click on “Resources” and resize the window horizontally to be as thin as possible. Then click on “Flex Modules” and resize the window to be usable again and BAM! just like magic the modules appear!

UPDATE

I’ve found that an easier way to do this is just adjust the divider between the list on the left hand side of the dialog and the right hand content area. Just adjusting the divider a smidge will cause everything to magically appear.

To change the font size in Flex Builder click Window > Preferences…. In the dialog that pops up click General > Appearance > Colors and Fonts and expand the Basic rollout. In the Basic rollout there are a bunch of options, click Text Font and then click the Change… button that appears. It should be smooth sailing from here.