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.

Taking control of the Content

A better approach would be start working on tools and tools integration even before writing any code. Working on a 2D game like platformer or a side scroller, one of the first things you need is a decent level editor and to setup a content pipeline for game level data.
One possible solution would be to roll your own full featured editor. This would require a substantial amount of time and resources, and divert the focus for the game to tools. In my experience, this is not very practical if your goal is to get going quickly and work on the actual game.A much quicker solution would be to leverage existing editing tools to create the game levels.
One such tool is the Flash IDE (Flash CS4/CS5) – it has powerful editing features and is very easy to use. In a recent game project I managed to save time by using it to build my own levels. Since Flash is commonly used to build levels for nearly a decade, many developers found ways to customize it to their needs.

For me this was a new experience, and a challenge to conquer: could I really complete a game in one weekend? The way I see it, some developers run half marathons, and I do the TOJam, which in itself is a marathon of sorts.

UPDATE:  Posted a link to Play the game in the Postmortem Article.

The different games that I’ve worked on so far had a schedule from 6 months up to 3 years. I know something about game production, and I figured its just a matter of good planning and narrowing the scope of the game, so that it could be done in 3 days.

The Game

Our game is a side scroller called ‘Pileup’, in which a cart drives on tracks using mostly gravity and the goal is to get the cart to the exit point. Game elements include track switches and elevators. It was developed from an early concept of an Angry Birds clone to a roller coaster type game with physics.

We used our own game framework as a base for the game code, most of it was written on the two weeks prior to the jam. I will cover the more technical aspects in a later post, were I intend to provide a full post mortem of the game.

The Team

Our team was composed of myself, Gavyn Elrick, Pavel Samsonov and Junko Shelton. Up until the jam itself, all previous work was done individually and most of it was code only, so we had to manage the tasks somehow. I had to double as a game producer and keep track of the progress during the jam.

First Impressions

The event was a lot of fun – people came with lots of energy and creativity. Peeking into each other monitors was very interesting, different technologies from Flash to Unity, XNA, and even HTML5. The place was packed with over 250 artists and coders enthusiastic to show off their creative skills.

The desktop machines supplied by George Brown College were surprisingly convenient -  despite the fact that I usually dislike Macs, I found the Mac Pro running Windows 7 (with Bootcamp) extremely fast, and heavyweights like Flash Builder 4.5 and Photoshop run  like a dream.

Planning

Surprisingly, the most difficult part was nailing down a game concept. Since I already had a basic game framework I kept saying to everyone: ‘Coding is the easy part, just get me a good game idea and we’ll take it from there’.

We struggled with the game concept for a few weeks before the jam. At first we tried to come up with some idea that is simple enough to do in a short time, but can still be fun to play (even for a very short time). All we could think of is ‘throw things at some breakable objects and have them bounce around’. Not very original. After getting some more input from friends this changed into ‘roll this ball shaped character somehow to the target point’ in different sceneries – that looked simple enough.

We actually started the jam without a solid game concept. By lunch time we had it more or less done, and then we just went with the ‘cart on tracks’ idea as the base of the game.

Code Like Hell

From there it was simply coding the game elements and designing the levels. Between two coders and two artists the progress was slow and steady. Time flew and things finally started to fall into place on Saturday evening, when we got the first playable level.

We somehow made the deadline of Sunday 8pm. I got very little sleep that weekend, and the longest sprint was about 40 hours straight.

Final Result and Conclusion

So we ended up with about 3-5 minutes of gameplay in 3 levels. Having completed the game jam, I came with some new found realizations about game production that is compressed to a very short time:

• Narrow the scope of the game. If it looks you are not likely to develop a feature within the limited schedule, pass on it and spend the time on what is within reach.
• Stay focused. When an idea looks even half good, hammer it down without hesitation. It may not come out great, but you’d be able to improve on it once it materializes.
• Know your limits. Build upon the tried and true, that part that is proved to work. Experimenting during final coding is too risky, and you’ll waste valuable time.

All in all, doing the TOJam was a wild ride, and totally worth it.

Probably the biggest complaint is the build time. If you leave automatic build on (the default) any save or build command will slow the system to a crawl, sometimes for a few minutes at a time – crippling the ability to code efficiently. In an average work day, probably 1-2 hours are lost to waiting for the builder in a debug cycle of modify-build-test.

Part of the problem is because it’s based on the eclipse platform – a huge and inefficient app that is sucking out system resources. No wonder, since eclipse itself is a java application – the java VM simply doesn’t cut it when it comes to heavy lifting, even with top of the line hardware (e.g. Quad core with 4 GB of ram).

Most coders tolerate it because it’s better than notepad, or the Flash CS4 scripting panel.

So why do we have to put up with it?   You can expect that when paying over $500 for an IDE, it should be professional, well-oiled, and with solid performance.

Adobe, please take a cue from Microsoft Visual Studio and provide a decent command line complier that is not java based, one that can utilize multi-core processors – that belongs to the 21^st century. Is it too much to ask?