First of all, it’s not going to work. At best you can stop indie developers from copy-catting the big players in the industry by talking ethics. You’re not going to have any effect on the massive tide of dollars Zynga is riding by imploring their developers to reconsider doing what Zynga is asking them to do.

Furthermore, when we use ethics to attack the techniques used by abusive freemium titles, we are implying that these techniques are too effective and that there is no recourse available to us but to abstain from their use. As if they were some kind of super weapon. Which is ridiculous, because every one of the problematic techniques relies on flat-out bad game design. Really, the recipe for a lucrative freemium game is to take a solid game design and strategically break it in several places. Then you charge the player to get past the things you broke.

We should be looking back at arcades and asking ourselves what killed them and the equally exploitative design choices that they encouraged. It wasn’t a sudden epidemic of ethics on the part of developers and publishers that killed arcades. Better games killed arcades. Games that didn’t lure you in with one relatively easy level and then beat you up for your lunch money. I think that our current situation is exactly the same, minus the better games. It’s about time for history to repeat itself.

So, my question is, why are we fighting inferior game design with ethics, rather than with superior game design?

Each colour corresponds to a different task that my application performs. Perhaps blue represents AI execution time, red represents rendering, and teal represents mouse handling. The graph on the left reports the time spent on each task I am tracking per update. The green area gives me an indication of whether Flash is dropping frames due to the execution time of my code. On the right is a bar graph showing the relative weight of each task over the lifetime of the application. More details on use after the cut.

Get it from GitHub.

There are a few simple steps to tracking performance with this tool. The first is to create the graphs themselves.

The GraphTimePerUpdate graph is configured with a target time per update, which should be chosen depending on your frame rate. The limit specified in the next line controls the scale of the graph. In this example, an update which uses exactly 99 units of time will fill the whole vertical height of the graph. Then we create the display at the desired size and add it to the stage.

private function createPerUpdateGraph():void
{
	_perUpdateGraph = new GraphTimePerUpdate();
	_perUpdateGraph.targetTimePerUpdate(33);
	_perUpdateGraph.limitTimeForDisplay(99);
	var graphData:BitmapData = _perUpdateGraph.createDisplay(300,200);
	var graphBitmap:Bitmap = new Bitmap(graphData);
	addChild(graphBitmap);
}

Creating the GraphTotalTimeSpent graph is a much simpler process. We only need to create the display and add it to the stage.

private function createTotalGraph():void
{
	_totalGraph = new GraphTotalTimeSpent();
	var graphData:BitmapData = _totalGraph.createDisplay(24, 200);
	var graphBitmap:Bitmap = new Bitmap(graphData);
	graphBitmap.x = 300;
	addChild(graphBitmap);
}

With our two graphs constructed, we need to configure the PerformanceMonitor that drives them. The first three lines declare the performance metrics that will be tracked, and what colours to use when rendering them. The following lines plug the graphs into the PerformanceMonitor to receive updates.

private function configureMonitor():void
{
	var monitor:PerformanceMonitor = PerformanceMonitor.instance;
	monitor.initializePerformanceMetric("rendering", 0, 0xff0000);
	monitor.initializePerformanceMetric("ai", 1, 0x0000ff);
	monitor.initializePerformanceMetric("mouse", 2, 0x00ffff);
	monitor.addReporter(_perUpdateGraph);
	monitor.addReporter(_totalGraph);
}

With that configured, the PerformanceMonitor is ready to go. All that remains is to report metrics and tell the PerformanceMonitor to update. For this example, I am just randomizing the first two metrics and basing the second off of mouse movement in order to illustrate how to report them. Normally you would use getTimer to determine the time to execute some complex functionality and then report the result of that.

private function handleEnterFrame(in_event:Event):void
{
	PerformanceMonitor.instance.recordPerformanceMetric(0, Math.random()*5 + 10);
	PerformanceMonitor.instance.recordPerformanceMetric(1, Math.random()*5);
	PerformanceMonitor.instance.update();
}

private function handleMouseMove(in_event:MouseEvent):void
{
	var xDiff:Number = mouseX - _lastX;
	var yDiff:Number = mouseY - _lastY;
	var distance:Number = Math.sqrt((xDiff*xDiff)+(yDiff*yDiff));
	PerformanceMonitor.instance.recordPerformanceMetric(2, distance);
	_lastX = mouseX;
	_lastY = mouseY;
}

I’m not so sure about adding the additional overhead of selling merchandise on site, especially at the onset. Although, decent quality concessions are a pretty easy sell with game developers, as the TOJam concession stand demonstrates every year.

Game jams bring us together to achieve a short term goal every once in a while, but I’m really interested in a studio concept that would see local developers working closely on an ongoing basis. I hope this idea goes somewhere. I’m going to start bringing it up with other local developers and see if there’s any traction.

The Rules

Let’s get the obvious one out of the way first. Rules have a couple of parts that I plan to treat separately. Any rules, in its simplest form, consists of a trigger and a response. All rules can be broken down and expressed in this form, and in terms of responsibilities at the code level the division makes sense. These two concepts are troublemakers. They tend to need access to every system and object in your game to do their jobs, which gets messy fast.

Trigger

A trigger’s responsibility is to recognize a scenario and report that recognition to the system. They must be informed of state changes and have the ability to poll systems for information.

Response

A response has the responsibility of executing a change to the game’s entities. They require the ability to manipulate the relationship between objects and game systems, change object properties and potentially trigger non-game functionality (metrics reporting, client/server protocol, etc)

The Infamous GameObject

Making a Katamari of System Data

There’s a common problem in game development. You have various systems that each need their own object-specific data, and you have your game object. In most cases, the game object class rolls through your code like a Katamari picking up odds and ends from every minor subsystem and feature in your game. Avoiding the Katamari game object anti-pattern is probably one of the best things that a game engine can strive for. If this is allowed to happen, the game object class becomes monolothic and inevitable naming collisions result in awkward or confusing variable and method names. How often have you seen duplicate position variables to handle world coordinates vs screen coordinates?

Divide and Conquer

There’s actually no compelling reason to store all of the data for a single conceptual object in one class. It feels natural to associate a single software object with the single conceptual object that it represents, but it’s neither necessary nor wise. A better system is to create multiple views of an object. A PhysicsView might have a bounding box, mass, x-velocity, and y-velocity properties, for example. A PlayerStatsView class might hold the player’s health and energy. Neither system needs to be aware of the other or the data it uses.

Synchronization

We’ve separated our systems from each other and sequestered their related data, so we need a method to synchronize data between the Views which actually represent the same or related information. I’ve identified two ways of doing this which I’m planning to test out in my initial implementation.

If a value is encapsulated in an object, rather than being a native type that is passed by value, you can share that reference between the View classes. This solution performs well and is easy to implement, but it only works in situations where the value should be exactly the same from the perspective of both systems.

The second method of synchronization is through explicit synchronization classes which are fully aware of the two (or more) Views that they will synchronize. These are much less flexible in terms of how they are integrated. They must make an assumption about the order in which systems are updated. However, they are flexible in terms of how values can related to each other.

Atomic Power

I have shied away from dynamic objects for a long time because I associate them with Actionscript 1.0 debugging nightmares. It’s time to dust it off and employ the technique where it makes sense. If we separate all of our object data, we still need a centralized way to access that data from responses and triggers without having to hunt around in a dozen places for it. Enter Flash’s “Atom” type, denoted by an asterisk (*).

If we store references to all of the views on the atomic object, we can still benefit from the speed advantage of strict typing, because any performance-sensitive system works with a strongly-type View class. At the same time, we don’t need to maintain a game object class with variables defined for every possible type of data that an object might need to hold.

An additional benefit is that every game object only has to carry the data that it actually needs with it. You won’t be stuck creating infinite subclasses of GameObject to add specific capabilities. Composition over inheritance.

Objects At Rest

It’s very important to note that with this system, objects have no functions to call. Views should not have any function either, aside from those which report state information. The great thing about this type of system is that when your objects have no behaviour, you can test the behaviour a lot more easily, and mix behaviours a lot more freely, just by pointing the appropriate system at your game objects.

Templating

Most of the time, games need to create several similar or identical objects. This is pretty straightforward if you’re just subclassing left and right, but if we’re using composition there’s a little more legwork involved. The game engine will need a templating system which can take care of creating the appropriate Views and assigning them to the game object, as well as applying any initial rules and plugging the game object into the appropriate systems.

That’s our cast of characters for the time being. It will be a little while before I can get to part three; crunch time is upon me for two projects at once and I want to keep working away on AScalpel, but I’ll have it up as soon as it’s ready.

There is also a sample application included with the AScalpel library which is already integrated. Compile com.andrewtraviss.ascalpel.sample::BouncingBallSample.as as an application to view it.

Setup

Downloads

1. Latest AScalpel build from GitHub
2. Latest Minimal Components from GitHub

Project Setup

Start by creating a new Actionscript 3.0 project and copying the AScalpel and Minimal Component source files into the source directory. Once that’s done, you need to do two things to get AScalpel up and running. By default, AScalpel isn’t configured to handle most situations. The AScalpel package includes a helper class to configure it for common cases. Once you call StandardBit101Components.install, the system is ready to handle basic data types using the Minimal Components.

In order to actually see the editors you need to add AScalpel to the display list. AScalpel is a singleton, so you’ll need to access its display through AScalpel.instance.display. Be sure to keep this object on top of your game.

Your Main constructor should look something like this now.

[SWF(width="600", height="450")]
public class Main extends Sprite
{
	public function Main()
	{
		StandardBit101Editors.install();
		addChild(AScalpel.instance.display);
	}
}

Simple Integration

Opening the Object Editor

Before we get started, we’ll need an object to play with. For the sake of example, I’m going to use a simple bouncing ball demo. Here is our BouncingBall class without any metadata.

package com.andrewtraviss.ascalpel.sample
{
	import flash.display.DisplayObject;
	import flash.display.Sprite;
	import flash.utils.getQualifiedClassName;

	public class BouncingBall
	{
		public function BouncingBall()
		{
			_sprite = new Sprite();
			redraw();
		}

		public function redraw():void
		{
			_sprite.graphics.clear();
			_sprite.graphics.beginFill(_color);
			_sprite.graphics.drawCircle(x,y,_radius);
			_sprite.graphics.endFill();
		}

		public function get radius():Number
		{
			return _radius;
		}
		public function set radius(in_value:Number):void
		{
			_radius = in_value;
			redraw();
		}

		public function get color():uint
		{
			return _color;
		}
		public function set color(in_value:uint):void
		{
			_color = in_value;
			redraw();
		}

		public function get sprite():DisplayObject
		{
			return _sprite;
		}

		public var x:Number = 0;
		public var y:Number = 0;
		public var xVelocity:Number = 0;
		public var yVelocity:Number = 0;
		public var name:String;

		private var _radius:Number = 1;
		private var _color:uint = 0x000000;
		private var _sprite:Sprite;
	}
}

Once we have our object class, all we need to do is create an instance of it, and use AScalpel to open it. Our updated constructor looks like this.

[SWF(width="600", height="450")]
public class Main extends Sprite
{
	public function Main()
	{
		StandardBit101Editors.install();
		var ball:BouncingBall = new BouncingBall();
		addChild(ball.sprite);
		addChild(AScalpel.instance.display);
		AScalpel.instance.open(ball);
	}
}

If you run this simple example, you should see a tiny editor window with nothing in it.

There’s nothing in it because we haven’t  told AScalpel anything about the BouncingBall class yet.

A Little Bit About Metadata

If you haven’t worked with metadata before, it’s fairly simple. All metadata is enclosed in square brackets, as in [Editable]. If there are parameters being passed with metadata, they are placed in parentheses inside the square brackets. For example, [Editable(explicitCommit="true")]. Metadata is available at runtime through the describeType method. This spits out an XML that contains every detail about the object you apply it to. AScalpel uses this XML to create its editor windows.

Adding Basic AScalpel Metadata

The easiest way to integrate with AScalpel is to simply slap the [Editable] tag on the line above each property you want to edit. For example:

[Editable]
public var x:Number = 0;

In our example, I chose to make all of the public variables and getter/setters editable except for the name property. If you do that and run the example again, you’ll see something that looks much more useful than the last time.

You can now edit all of these properties. There’s a problem, though. As you type numbers into the fields, the object reacts to the changes instantly. This is probably not what you want in all cases. When you type in 400 for x, the object shouldn’t move to 4, then 40, then 400. AScalpel has a solution for this problem. For the position and velocity properties, we’ll use the explicitCommit option.

[Editable(explicitCommit="true")]
public var x:Number = 0;

And now that section of the editor looks like this. When a property is marked for explicit commit, the editor creates a button for that property which applies the current value when you click on it.

Advanced Integration

Specifying Editors

Continuing our above example, there are a few things that could be improved. The colour field accepts a uint value instead of a proper colour hex value, which is cumbersome to work with. To solve this problem, we can tell AScalpel to use a different control to edit the colour field. By using editorClass we can use any custom class as an editor. In this case, the Minimal Components Color Chooser control is enough, and is part of the standard installation. So we can just change the Editable tag for the color property like so.

[Editable(editorClass="com.bit101.components.ColorChooser")]
public function get color():uint
{
	return _color;
}
public function set color(in_value:uint):void
{
	_color = in_value;
	redraw();
}

Which gives us this.

Editor Properties

Perhaps we want to limit the radius of the ball within a particular range. The NumericStepper component supports minimum and maximum, so we will use that. We can set the minimum and maximum, and the step size on the NumericStepper just by adding those properties into the Editable tag. If AScalpel doesn’t recognize a metadata property, it will check for that property on the editor class and try to apply the value to it.

[Editable(editorClass="com.bit101.components.NumericStepper", minimum="1", maximum="30", step="0.1")]
public function get radius():Number
{
	return _radius;
}
public function set radius(in_value:Number):void
{
	_radius = in_value;
	redraw();
}

I will post an Advanced User Guide later on to describe how to create custom editors and change the default behaviour of AScalpel.

Preparation

Every year, I’ve handled preparation a bit differently. There’s a few practices that have emerged which seem to pay off quite well once you sit down at TOJam to start working on your game.

Focus Your Game Design

It takes quite a bit of time to balance and refine a game mechanic and make it really fun. If your game requires a few mechanics working together before it starts to be fun, chances are you won’t have nearly enough time to balance them out after you’ve finished implementing them all. You may not finish implemnting them all in the first place. I’ve done big concepts before and it is a nerve-wracking experience. You can get a whole lot done and feel surprisingly unaccomplished because it’s questionable whether you’ve actually got a complete game.

If you take a look at the award winners each year, you’ll  notice that they all do one thing and do it extremely well. This is not coincidental.

Plan in Stages

We decided to try a staged approach for Der Baron Von Ubercheesen: Cheese Factory. We laid out our plan with some definite milestones, and listed the things we wanted to have complete in order to call that milestone done. It didn’t lead us to be 100% successful, because the idea was just too big, but what we had done felt polished and cohesive. We used the same type of approach for Flip The Beach the next year, and it really clicked. There were a few advantages to this approach.

Completing a milestone gives you a little momentum boost. It also gives you a point where it makes sense to stop working for a moment and just test out the game so far. Take a break, look around at the other games in progress, give any conscious team members a high-five. Then package up a playable build and put it somewhere safe. When you sit down and start on the next milestone, you’ll be feeling pretty good about yourself.

It may seem too much like work, but figure out how long you expect each milestone to take, it will help you recognize early on if you aren’t going to be able to complete a whole milestone by the end of the Jam. This could save you some time and give you the opportunity to polish things up or focus your energy on things you can accomplish easily.

Build Boring Things Ahead

The rules for TOJam state that you can build some things like menu screens ahead of time. Don’t waste your time at the jam on this stuff. Arrive on Friday ready to start on actual gameplay code. It’s a waste of precious time and energy to do it at the Jam.

Know Your Art Needs

Make sure the artists on your team have an explicit list of assets they need to create before the Jam starts. If you’ve planned your game out, you should be able to do this, and even be able to tell them what order you’ll want things in. This is doubly important if you are going to be relying on floaters. Your access to their time is limited, so make it count by being prepared.

At The Jam

Play Other People’s Games

Maintaining inspiration is important, so don’t waste the fact that you are surrounded by creative people. Don’t intrude on people who are obviously busy, but if someone is looking for help play testing or if they are taking a break you may want to strike up a conversation about their game or give it a try in its current state. It only costs you a few minutes of downtime, but sharing the creative energy and seeing what other people are doing can help keep you motivated.

Avoid Scouting

Before the Jam make sure you know the food options in the area and the nearest location of your favourite coffee shop and any convenience stores. Check their hours. There were no 24-hour Tim Horton’s anywhere near George Brown that we could find last year. It took far too long to figure this out. It’s easy to waste a lot of time. (Aside: If you know of a 24-hour Tim Horton’s near George Brown, please let me know)

Sleep

I didn’t sleep at all at the first TOJam. Don’t do that. Trust me. You are going to spend the final day primarily fixing bugs, polishing, and balancing. These tasks are detail-oriented and  much harder to do when you are tired. Personally, I pull an all-nighter from Friday until Saturday and get a full night’s sleep Saturday night so I can hit the ground running on Sunday morning. Everyone is different, so you’ll have to figure out what works for you. That’s a pretty popular model, though.

That being said, if you can go all night once, do it. The overnight is an essential part of the TOJam experience, in my opinion.

Roll With the Punches

Plan to make your game playable in some form as soon as you can. Do the bare minimum for each aspect of the game and get a complete picture. You might find out that one of your major design choices isn’t actually terribly fun. Don’t give up, though. If there’s one thing I would like to stress above all else, it’s do not give up if something goes wrong. Just do what you can.

Normally I’m a diehard Flex fan, but I know not everyone shares my views so I’ve used the Bit-101 Minimal Components for this. It could easily be retrofitted to use Flex as well (I will probably do this later). For this initial release, it is purely an Actionscript 3.0 library. I’ve set up a Git repository to share it with everyone. An explanation of how to use it, below the cut. You’ll need the Bit-101 components in order to use it at the moment. Currently hosted on Google Code, here

AScalpel Class

The main AScalpel class is a singleton which holds onto the root of the editor display. You have full control over where and how this is created, hidden, and shown. The AScalpel class is used to create and destroy LiveEditor instances, as well as for registering custom editors and setting global options. In the simplest case all that needs to be done is the following. Details on that first call are later in the post.

StandardBit101Editors.install();
addChild(AScalpel.instance.display);

There are two ways to create editor windows for objects. You can add objects to an internal list using AScalpel.instance.addObject and then select objects from the dropdown that appears to create editors for them. Alternatively, you can call AScalpel.instance.open directly and just create editor windows without clogging the screen with the main editor window.

[Editable]

The [Editable] tag is the core of the system. Any public variable or getter/setter pair tagged as [Editable] will have a matching field created in the editor. If the member is a basic Actionscript type, the bare [Editable] tag will likely be enough. AScalpel has default fields defined for all of the basic data types. There are additional parameters that are available to handle other situations or to enhance the editor that is created.

explicitCommit=true

By default, all editors will apply their updated values to the target object as you type. In many cases this may be undesirable due to unexpected or invalid values being set. If explicitCommit is set to “true”, a Commit button will be added next to the field and the updated value will only be passed into the target object when the button is clicked.

[Editable(explicitCommit="true")]
public function get x():Number
{
	return _x;
}
public function set x(in_value:Number):void
{
	_x = in_value;
}
private var _x:Number;

customEditor=”com.fully.qualified.ClassName”

You can specify a custom class to be used for the field for this particular member. A common case for this would be using a colour picker control for colour properties. AScalpel will try to figure out how to use any editor class, but is is always better to explicitly register it. That’s covered near the end of this post.

[Editable(editorClass="com.bit101.components.ColorChooser")]
public function get color():uint
{
	return _color;
}
public function set color(in_value:uint):void
{
	_color = in_value;
	redraw();
}
private var _color:uint = 0x000000;

Any Property Supported by the Editor

If a parameter of the editor field is not recognized by the ObjectEditor, it will check if a property of that name exists on the field editor itself and apply the value if so. For example:

[Editable(editorClass="com.bit101.components.NumericStepper", minimum="1", maximum="30", step="0.1")]
public function get radius():Number
{
	return _radius;
}
public function set radius(in_value:Number):void
{
	_radius = in_value;
	redraw();
}

Configuration

Assigning default editors

For types which are used in multiple places in the game, it’s much more convenient to define a default editor for that type than to specify it in every [Editable] tag. This is done using AScalpel.instance.setDefaultEditorClassForType method of the ASCalpel singleton.

Configuring custom editors

All custom editors should ideally be configured, even if they would work with the default values; It’s a convenient way to be sure that the custom editor is actually visible to the compiler. When registering an editor, you pass four things to AScalpel through AScalpel.instance.registerEditorClass

1. A reference to the editor class (not an instance of the class or the name of the class)
2. The name of the member variable which is used to set and retrieve the current value of the editor
3. The event which the component dispatches when it is initialized (or null if there is no such event)
4. The event which the component dispatches when the value changes

The first version of AScalpel has integration with the Bit-101 minimal components built in, through the StandardBit101Editors class, shown below. This provides a relatively simple example of how to configure AScalpel.

package com.andrewtraviss.ascalpel
{
	import com.bit101.components.CheckBox;
	import com.bit101.components.ColorChooser;
	import com.bit101.components.Component;
	import com.bit101.components.InputText;
	import com.bit101.components.Knob;
	import com.bit101.components.NumericStepper;
	import com.bit101.components.Slider;
	import com.bit101.components.TextArea;

	import flash.events.Event;
	import flash.events.MouseEvent;

	public class StandardBit101Editors
	{
		public static function install():void
		{
			AScalpel.instance.registerEditorClass(com.bit101.components.InputText, "text", Component.DRAW, Event.CHANGE);
			AScalpel.instance.registerEditorClass(com.bit101.components.NumericStepper, "value", Component.DRAW, Event.CHANGE);
			AScalpel.instance.registerEditorClass(com.bit101.components.ColorChooser, "value", Component.DRAW, Event.CHANGE);
			AScalpel.instance.registerEditorClass(com.bit101.components.CheckBox, "selected", Component.DRAW, MouseEvent.CLICK);
			AScalpel.instance.registerEditorClass(com.bit101.components.Knob, "value", Component.DRAW, Event.CHANGE);
			AScalpel.instance.registerEditorClass(com.bit101.components.Slider, "value", Component.DRAW, Event.CHANGE);
			AScalpel.instance.registerEditorClass(com.bit101.components.TextArea, "text", Component.DRAW, Event.CHANGE);

			AScalpel.instance.setDefaultEditorClassForType("com.bit101.components.InputText", String);
			AScalpel.instance.setDefaultEditorClassForType("com.bit101.components.InputText", Number, {restrict:"0-9.\\-"});
			AScalpel.instance.setDefaultEditorClassForType("com.bit101.components.InputText", int, {restrict:"0-9\\-"});
			AScalpel.instance.setDefaultEditorClassForType("com.bit101.components.InputText", uint, {restrict:"0-9"});
			AScalpel.instance.setDefaultEditorClassForType("com.bit101.components.CheckBox", Boolean);
		}
	}
}

In this first instalment, I explain my thoughts on the role of a game engine and the overall scope of what I intend to achieve.

The challenge facing a game engine is to help the developer express their game design concisely.

An engine for resolving the challenge of physics or rendering is great, but that isn’t a game engine at all.  It’s a graphics engine, or a physics engine, usually with a token entity system built on top of that. These types of technically-oriented solutions can simplify code that deals with their particular subsystem, but do little to assist the general process.

What then are the basic elements of a game design that an engine should treat as its basic units? Rules. Many of these rules are simple; “Mario is hurt if he touches the sides of a goomba”, and others take the form of simulation systems such as physics. Entities are defined in terms of how the game rules apply to them. This is rarely described in such a formal way by game designers, but during implementation the core task is to distil the design down to these types of basic ideas and then express them in code. The goal of the game engine is to allow each game rule to be specified with as little code as possible.

There are three key factors I will be focusing on in my own engine design:

1. Minimize code to define a rule.

2. Allow custom rules with minimal overhead.

3. Make gameplay code as readable as possible.

In the next Game Engine Design post, I’ll lay out the high-level component view of the engine and describe how I intend for the parts to work together.

A great deal has happened over the past year. Quit my job. Started a company. I’ve done some work for Manulife Financial and have been on contract for a social game developer for some time. I spent enough time migrating my blog tonight, however, so I’ll have to share more details in a future post.

Pro Tip:Talking to Jim McGinley for 30 minutes or so when you are exhausted to the point of passing out will generally restore your energy for the remainder of the day. Or at least long enough for the caffeine to take over

As always, I had an awesome time, even if I was more tired this year than previous years. That largely due to the fact that I was up until 3 am the night before the Jam trying to get SVN set up on my machine so that Alex and I could forego the USB time sync. Irrational Escalation at its finest.

Alex covered the event really well with some video blogs. Find them here.

There were some fantastic games out there, I sunk quite a bit of time into Michael Todd’s dogfighting game. Shawn McGrath’s game would probably conquer XBox Live Arcade if it were to appear there. Some screenshots and description of our game after the cut

Our game this year was “Reentry” a game about misplaced guidance systems and creepy starship pilots. This year had a lot of ups and down for us.

Good: Sound and music

This year’s game used more sound assets than all 4 of the previous games I’ve worked on put together.

Alex worked with a friend of his to record voice tracks for the main characters who I have dubbed Captain Helium and Lt. Commander Creeper McShady. The voices
add a lot to the experience. The game feels a little dull without them, but that’s in line with our plan. The characters are a big part of the design.

We also got a great music track from chiptune artist OxygenStar and editted it into 3 loops connected by transitions. It turned out great.

For sound effects, we used SFXR, which belongs in every indie developer’s toolbox. Thanks to Steven Hill for throwing that one our way. All of the sound effects in the game were generated by Alex using this tool. I’m excited to try out the music creation tool Musagi by the same developer

Bad: Source Control

If you ever think about trying to set up SVN the night before a 72-hour game development event, and further think about starting at 11 pm, with no prior experience doing so, do yourself a favour and don’t.

Our hackjob solution made me worry quite a bit but ended up working out. We set up the Flex project on Alex’s computer in a network share folder and both pointed our environments at that location directly. There were some hiccups where one of us would temporarily break the build for the other, but I don’t think we lost more than 30 mins over the course of the Jam. That’s much better than what we wasted with our USB juggling last year.

Next year I’ll try to get SVN set up again, but this time a month in advance at least.

Good: Scope Control

We wanted to aim for a smaller game idea this year. We have trended towards big ideas before, and felt that it didn’t leave us enough time to refine the gameplay for the actual fun factor. I think we pulled it off this time, despite ignoring a game breaking bug right until the end of the event.

Balancing ship movement to be challenging without killing you was very time consuming You have to click the appropriate thruster and hold the mouse down (not necessarily over the thruster) to keep it firing. There are two thrusters that push your ship side to side, and two more that control your rotation. Figuring out the right amount of force for each engine to apply, as well as turbulence and impacts took up a pretty significant chunk of my time at the event.

Next time I’m adding some mechanism to adjust these values in the game itself, to make tweaking less time consuming

Bad: Miscommunication

This mostly happened prior to the event, but apparently everyone had a different picture in their head of what the game would actually look and play like up until the week of the event.

It wasn’t until we actually started sketching out the game that everything became clear. Lesson learned. The storyboard comes before everything else. It’s much harder to have a misunderstanding based on visual information than written or spoken information.

Things To Change Next Year

Based on my experience this year, there are several things I want to keep in mind when TOJam 6 rolls around. Some good practices from previous years were not observed, and they proved their value in their absence.

1. Use an engine. Not using Flixel this time made sense, but the decision should have come earlier, and a more appropriate technology selected. The best games every year leverage existing technologies. Motor physics really gave us a leg up last year.
2. Simple gameplay. We went simpler this year, in terms of number of mechanics, but we didn’t actually choose a simpler mechanic for the core of the game.
3. Revive last year’s formal approach. Alex and I both work better against a well defined schedule. Not having one this year wasn’t a good change
4. Prove it’s fun ahead of time. We took a risk on this one with a small idea and really only one major mechanic that we hadn’t seen much of elsewhere. I liked doing this, but there should have been some pre-Jam prototyping just to be sure that the idea was actually a good one.
5. Consider abstract graphics. Every year so far I’ve worked with representative graphics, and it can be limiting in some ways even if it brings a lot of benefits along with it. Besides, if Miguel Sternberg can make a game without developers, we need to show him we can make a game without artists!