Seems like on a thing versus some other thing rampage with Application Design vs Game Design shortly followed by this post. I guess that’s a good thing, it means there are challenges and doubts and that we need to research.

This post is also inspired by some books I’ve been reading lately and that I highly recommend: The Productive Programmer that was influenced by The Pragmatic Programmer.

Problem #1

We are writing code and there’s not such thing as writing code without bugs. Sometimes our oldest, most used code, that code that we trust each of our games with gets into a specific spot where a hidden bug appears and we spend hours and hours figuring out what’s happening.

Solution #1 is Problem #2

There are several solutions to this. Writing code that includes testing is in my opinion the best. The problem with this, game development wise and specifically in scripted languages such as AS3, is that this makes the code much slower. The solution was checking for inconsistencies and not performing operations instead of throwing errors and exceptions.

I ended up creating conditions for use. For instance our blit package uses three different types: the core, the object and the texture. The core keeps the state of the whole system, the object keeps the state of what and where to render and the texture keeps the state of BitmapData. If the object did not have a texture it would simply not render. Sounds pretty cool, right?

To be honest… wrong…

Problem #2.1

First problem was the times where the position had NaN value instead of a Number. This rarely happened but every time it did it was a huge headache to identify why and then track the source of the bug down. While this seems unrelated, the fact was the it looked like the texture did not exist. So I had to check if the texture was created, if it was passed, if it was there at all and the worst part was that if the texture was there as it should, where the hell was the problem?

Problem #2.2

Performance wise checking if there is a texture is absolutely dumb! 99% of the times there is a texture present. More, the object class has a visible variable. If the object does not have a texture why is it visible in the first place?

So while apparently I solved a problem by checking if the texture was present and not performing any blit operation if it wasn’t, the truth is that both performance wise (not that serious by the way, it’s just a if statement) and the unwanted problems it induced in the code backfired from time to time.

I spread this type of behavior through the code. While one if statement does not have a large impact in performance, a lot of checking piles up and I had a lot!

Solution #2

A short story and a riddle both taken from those books that explain my thoughts on the ‘final’ (we’ll see about that!) solution for these problems.

The first one was when one of the authors was hired as a consultant for a development project where the coders sent broken code to the version control system. What he did was to create a routine where the version control server would compile the code that was pushed. Every time the compilation didn’t work the server would send an email with the error. With the amount of mail with errors constantly piling up on mailboxes, one of the coders asked if there was a way of not getting that much email. The consultant replied: “Sure, don’t push code with errors!”

The riddle is… what code takes not time to be executed? The one that is not compiled.

So the solution is to write code that allows zero error tolerance while not compiling it. The way to achieve this is with conditional compilation which can be used in several way but these are the ones I believe the most useful is to use code blocks, like this:

private function someFunction():void {
	CONFIG::debug {
		// Development code
	}

	CONFIG::release {
		// Final code
	}

	// Both dev and final code
}

Inside the same function, different code is compiled depending on the current configuration. We can have several checks with exceptions and errors being thrown and then have a ‘don’t check at all’ version in the release configuration.

This is a two stage solution really. On one hand every time I do something stupid, I get errors so my code has to be perfectly implemented at least when it comes to our framework. On the other hand the same code that make me code as best as I can is also the code that does not run in the final version.

That happened with Bold Pixel. At some point in time Bold Pixel became a monster to please developers instead of a tool to be more productive in my purpose to my audience: create games for players! People play games, not code!

I stopped over-engineering sometime ago and started reading about how to become a better programmer not by writing better code, but by writing the exact code to solve the exact problem. This brought a new problem: what to do with Bold Pixel and how to maintain and evolve it? First thing was to start a new package and only bring in classes that I needed but wire the classes up to be as slim and straight to the point as possible. I do that all the time to build up my code base right now, but that’s not all. Here’s the whole process I’m using right now.

Start simple

class BlitObject {

	// Position
	public var x:Number = 0;
	public var y:Number = 0;

	// Rendering
	public var visible:Boolean = true;

	public function BlitObject():void {
		// Constructor
	}

	internal function render():void {
		// Render stuff here
	}
}

The class above can be a stub for a simple blit object. From a OOP perspective it breaks encapsulation completely since x, y and visible variables should be private but seriously, do I really need those to be private or protected and have getters and setters? No I don’t so no need to over-engineer it. The only thing I want to have contained is the render method that should only be called by the blit engine that lives in the same package.

The blit object only responsibility is to copyPixels or draw on a given world position translating camera position on the fly.

Writing a simple class like this is fast, performs fast, case closed.

Evaluate new needs

Now I need a tile map class. This class is also a blit object so following the “is a” versus “has a” rule tile map should inherit blit object. Considering the blit engine has a camera, the tile map won’t move. This brings two new problem.

1. If the tile map doesn’t move, why do I have x and y publicly accessible?
2. I want my camera to follow blit objects so blit objects must have x and y variables (or properties). How can I make tile map be recognized as a blit object, have x and y and have none of those altered?

Sounds messy…

I could write a Blittable interface that would define a render function and getter and setter methods for x and y. The problem is that if there’s something I want to keep in the package scope is the render function and interfaces define public interfaces.

The solution is to convert blit object in an abstract class and have its original functionality moved to a new graphic class.

class BlitObject {

	// Rendering
	public var visible:Boolean = true;

	internal function render():void {
		throw new Error("Abstract function called. Override render()!");
	}

	public function get x():Number {
		return NaN;
	}

	public function set x(v:Number):void {
		throw new Error("Abstract function called or property x not available.");
	}

	public function get y():Number {
		return NaN;
	}

	public function set y(v:Number):void {
		throw new Error("Abstract function called or property y not available.");
	}	
}

class Graphic extends BlitObject {

	// Position
	private var _x:Number = 0;
	private var _y:Number = 0;

	override internal function render():void {
		// Render stuff here
	}

	// Position
	override public function get x():Number { return _x }
	override public function set x(v:Number):void { _x = v }
	override public function get y():Number { return _y }
	override public function set y(v:Number):void { _y = v }
}

class TileMap extends BlitObject {

	override internal function render():void {
		// Render the tile map
	}
}

Problem solved. The class responsibilities are much better defined.

1. A blit object renders and has x and y coordinates. Since it is an abstract class everything we try to do with it directly will result in an error.
2. A graphic is a world movable blit object that renders by copyPixel or draw.
3. A tile map is a world static blit object that renders very large objects by copyPixel or draw  based on a predefined xml specification.

Conclusion

What’s the conclusion here? Well for starters by this time I’d have a couple of interfaces and probably a helpers. I’m not saying it is wrong to have interfaces and helpers, actually it is preferable, but it would be coding for the sake of coding instead of coding for the sake of making a game. It took me 10 minutes to do this and while I was at it the BlitObject class also extends a ListObject class that really speed up the iteration, addition and removal of objects from the blit engine.

Still… I did repeat my self and the code has suffered another refactoring since then. I’ll leave that for another post but I wonder if you know what’s repeated…

URL

I don’t know about you, but I really hate those little bits of code that you will use in every single game but not during the actual development of it. As far as I’m concerned, even if not the most noble usage of the “reuse your code” rule, getting rid of these pesky little pieces of code is the single most useful usage of object oriented programming, not because I read it somewhere but because I’ll never have to worry about it again!

Opening files and URLs are two examples those pesky bits of code and to me both are perfect candidates to our framework Toolkit class! So here’s the code of the two static functions that were created to deal with it.

/*Opens an external file. Upon completing the task, callbacks to the
 *given function.*/
public static function OpenFile(filename:String, callback:Function)
{
	var ldr:URLLoader = new URLLoader();

	ldr.load(new URLRequest(filename));
	ldr.addEventListener(Event.COMPLETE, callback);
}

/*Opens a URL on a new window.*/
public static function OpenURL(url:String)
{
	var urlReq:URLRequest = new URLRequest(url);
	navigateToURL(urlReq, "_blank");
}

if(this.root.loaderInfo.url.indexOf("domain.com") != -1)
    trace("Good!"); // It's in the right domain
else
    trace("Bad!"); // It's in the wrong domain

What this does is to get the index (aka position) of the string “domain.com” from the string that is returned by the loaderInfo.url. If it returns -1 then the string “domain.com” is not present in the loaderInfo.url.

This solution is fine, but it presentes two problems.

First, if someone really wants to use your site-locked game, they can! They just have to find a way of putting the “domain.com” string somewhere in the path to your swf since this code does not compare the domain name but rather the presence of a string on another string.

The second problem is that you don’t know the domain where the game is present. I need that information for other evil schemes of mine, so this was the perfect reason to write a small tool that would fetch me the domain name.

So I wrote this simple static function that lies inside a class Toolkit -name I shamelessly stolen from a chat with Andrew from Epic Shadow- and that simply returns the root domain and the top level domain, separated by a dot from the loaderInfo.url.

/*Returns the name of the domain without subdomain, e.g. vortixgames.com
 * instead of www.vortixgames.com.*/
public static function Domain(root:MovieClip):String
{
	/* Splits the full path into an array of strings separated by "/"
	 * and gets the index 2 value which is the full domain name.*/
	var currentDomain:String = root.loaderInfo.url.split("/")[2];

	/* Splits the result into an array of strings separated by "." and
	 * checks the length of the array. If the array has a length of 3
	 * the domain contains a subdomain, for instance "www" and it must
	 * be discarded. If the length is 2 then, there's no subdomain
	 * present. */

	var fqdn:Array = currentDomain.split("."); // FQDN in array form

	var rdi:int = 1; // Root Domain Index defaults to 1
	var tli:int = 2; // Top Level Index defaults to 2

	if (fqdn.length == 2)
	{
		rdi--;
		tli--;
	}

	return fqdn[rdi] + "." + fqdn[tli];
}

The only issue I have with this function is that I have to pass the root as a parameter to the function. Any idea on how I could solve this otherwise is most welcome.