I thought “What crap is this? I’m not going to install it!”. That was stupid, because Unity rocks as a game development tool!

Why Unity rocks (in my opinion)

In a matter of a few hours, I wrote a third person shooter prototype.

Of course, this was after I spent some days to get familiar with the environment.

The basic features my game had in about 8 or so hours:

• 3D 3rd person “over the shoulder” camera
• Enemies who moved around
• The enemies could smartly aim at your current location
• A spawner system where I could place a spawner object anywhere and it would automatically spawn more enemies
• A waypoint based movement system
• A simple user interface which displayed health and some other stuff

What is Unity?

Unity is basically a game engine with an IDE sort of editor tool. It can be used to develop games for multiple platforms and the web (which uses their browser plugin).

It has a fast 3D engine, a PhysX based physics engine and libraries to work with all sorts of things you might need when developing a game (GUI, collisions, even multiplayer is quite straightforward to do).

The editor itself is kind of like a level editor for a 3D game – think Valve Hammer or WorldCraft – but it also has an asset list, scenes, input management etc. quite easily straight from the UI.

Oh, and did I mention it also works on Macs and not just Windows, and that you can write scripts for your game in JavaScript, C# or Boo?

If you develop games, for fun or for profit, Unity is worth checking out

Now I’m not very familiar with other 3D game engines, but Unity is the best I’ve seen. It does require some getting used to, especially how the scripts are attached into the game, but I can’t really think of many bad things about it.

ps: I’m not going to attach a screenshot of my game because it’s basically just a bunch of boxes. I’m not a 3D modeller, sorry

Finnish games

• Slicks ‘n’ Slide – A great top-down racer with a track editor. I made a similar JavaScript based top down racer.
• Triplane Turmoil – Side-scrolling multiplayer shooting with triplanes
• Wings – Side-scrolling cave flying shooter with tons of weapons and maps etc. etc.
• Minebombers – Top-down shooter, a combination of bomberman and miner
• Tapan Kaikki – Top-down shooter
• Liero – Side-scrolling shooter where you are a worm and as usual the goal is to kill the other worms
• Koiratappelu – Couldn’t find anything in english about this. This game was a bit like Triplane Turmoil
• Areena 4 – As with Koiratappelu couldn’t find anything about this in english either. A great strategy game where you manage a team of gladiators in a fantasy world and fight in different leagues to be the best.
• Duck, Mr. Duck (in finnish, has a screenshot) – A very Worms-like turn-based shooter, except this time you are a duck.
• Alien Phobia – Top-down shooter, simple and fun: The only goal is to survive against an endless flood of aliens out to kill you. There is also Alien Phobia III.

Others

• Action Supercross – Possibly one of the first good physics based games? Side-scrolling motocross puzzle game
• Assault Trooper – Isometric shooter
• C-Dogs – Isometric shooter with two-player support and I think there also was a map editor

What’s your favorite?

I spent countless hours playing the above games, although there probably were others that I forgot about.

Share your favorite old games in the comments

• DHTML – In other words, using divs with images and moving them around
• Canvas
• A hybrid: Canvas with DHTML

I’ve considered each of these, and they all have some pros and cons which we’ll look at next.

DHTML

This is the most compatible of the three: Even Internet Explorer supports creating divs and moving them around on the fly.

This approach is quite simple too. The APIs used are well-known and usually quite problem-free when used correctly.

Moving divs etc. around tends to be pretty fast too, so even if you have a big huge animated explosion or something, the performance should still be relatively good. Compared to canvas this is DHTML’s biggest win.

One of the downsides with DHTML is sometimes jerky movements: You always need to draw and move things pixel-precise, as you can’t tell a div to be exactly 15.5 pixels from something. Canvas can draw “between” pixels, as it automatically aliases the graphics to look more like it.

With DHTML you also can’t draw shapes like you can with canvas, so you’ll need to come up with the graphics in an image editor beforehand.

With CSS transitions and other tricks, you can bend DHTML surprisingly far. However if using transitions or other advanced features, you sacrifice compatibility with more browsers than you would if you were just using canvas.

Canvas

Canvas is great. I wish I could leave it at that.

However, in addition to being generally easy to use after getting familiar with the basic API, there is one significant downside: Canvas is slow. Slow slow slow slow slow.

Unless you apply considerable amount of thought into the code, getting stuff drawn at reasonable speeds with canvas is difficult. It’s like going back to the times when computers had 66 mhz CPUs.

Canvas does have a lot of good things though: You can draw on it directly, with direct pixel manipulation, a vector-like API, or images.. or compose a new image using another canvas.. It is certainly very flexible, and it makes it very simple to do complex and dynamic shapes that would be much trickier otherwise.

If you’ve been following the TankWar 2.0 development, you may have noticed it does draw some okay looking graphics but it still is somewhat reasonable quick. It only uses canvas for rendering, so yes, it is indeed doable, but it requires tricks.

I’ll be discussing the finer details of how to make canvas rendering faster in another post.

Hybrid

A hybrid graphics engine is exactly what it sounds like: It combines both DHTML and canvas to overcome the downsides of both approaches.

While this may sound like the stone to drop two birds with, it may not be.

One of the good things about this approach is easily seen when you need to display large graphics that move. Canvas can be very slow in cases where you update larger areas of it, so in a case like this using a div for the big graphic is good. Then, you can use canvas for the rest, to create different shapes etc. which would be tricky with divs.

The main downside of this approach is complexity. Since you need to deal with both canvas and DOM, it’ll become twice as complex as using either of the approaches alone.

In closing

The approach I’ve chosen for TankWar 2.0 is pure canvas. I may need to resort to a hybrid approach if the performance drops too low, but right now it’s still tolerable at least on a moderately quick PC.

In the past, I’ve used canvas on most of my games: TankWar, Opera Command, WidgetRacer, Asteroids… but I’ve also used a DHTML-like approach in a Tetris game and in WidgetCity. In these cases the DHTML-based approach was simpler or had other reasons, such as being much faster in case of WidgetCity (My post about the table/CSS rendering in WidgetCity).

I’ll be discussing the details of how the new TankWar 2.0 canvas engine works in a later post. I’ve had to do a significant amount of performance trickery for it too.

This is the first one: Assessing the damage. In other words, take a look at the old code and see what can be salvaged. I’ll also list some issues with the current implementation, and how I plan on solving them in the new version.

Issues in the current implementation

I wrote the most of the code in the current version of TankWar somewhere in 2006. Let’s be frank: The codebase sucks.

It’s a mess.

I’m surprised some of it ever worked. At all.

My coworker Artem tells me recognizing your old code is crap is a good sign: It means you have improved – and I agree with him.

In addition to being pretty poor code, the current version does have some bugs too:

1. If your bullet moves very fast, it can go through the ground.
2. The graphics system is poorly implemented which can be seen especially when using the bomber weapon – it can get pretty glitchy
3. The bullet trajectories deviate wildly depending on the computer’s speed

While some of these issues could be patched into the current code, it would just make the code even more fragile.

Damage control

In most cases there’s some useful code even if most of the code is messy.

In the case of TankWar, the main implementation of the game engine, menus, etc. will be thrown away. They make most of the code, but they are also the worst parts of it.

The good parts of TankWar include the terrain generator, some vector math classes and some utility classes.

It seems we can apply the statistic that simpler code contain less problems here too.

Solutions to the current problems

First and foremost, the codebase will need to be organized better. Now it’s just a jumble of code and HTML, CSS and whatnot mixed together like magic hobo gravy.

The game engine itself will need to be more robust and be able to handle fast moving bullets properly, and the trajectories need to be correct.

Bullet collision solution

The solution to fast moving bullets going through stuff is improving the collision detection mechanism. Currently the implementation is quite simple: It simply moves the bullet each cycle and checks if the bullet intersects the ground or other objects. This is very easy to implement, as the canvas element has a function for it, but it’s not very accurate with fast moving objects.

A better approach with fast moving objects is using ray intersection detection. Put simply, this means we will check all the points in the trajectory, including the points between the positions the bullet actually is in. In the old implementation, depending on the speed, there could be tens of pixels of space which was never checked for hits.

Glitchy graphics

The solution to the issues with the graphics system is to make it separate from the other stuff. The current graphics engine was just quickly slapped on top of the physics engine to make it display pretty pictures. This is more of an architectural problem than an algorithmic issue as the collision detection.

Additionally, the graphics system may be a little problematic in general. While it works with the current simplistic graphics, I’m not sure whether it would function very well if I wanted to include more complex graphics.

Bullet trajectory problems

For the third problem – framerate dependent trajectories – the solution may be more problematic. The current version already attempts to fix this by using time-based movement. However, it does not quite work, meaning I’ve either implemented it wrong or the timer is not accurate enough.

If the timer turns out to be inaccurate, the solution may be to precalculate the trajectory using a predefined framerate. This means we would have to first calculate the trajectory, and only after it’s been calculated, we could render what happened. This might be difficult, because calculating the trajectory may take so long that the user would notice a significant delay between “shooting” and the game actually performing the shot.

Then again, the frame rate calculator was (as far as I can remember) also slapped on top of the existing stuff and never really properly planned. The timer itself works quite similar to the timer in my JavaScript bitmap sprite animations post.

In closing

The rewrite will probably take a while, depending on how much time I’ll have to work on it. I will probably put together some more posts on the topic as I have some progress. Let me know if there’s anything specific about it you’d like to hear.

Naturally the new version will generally be more awesome than the old version – it would be rather pointless to just rewrite it and add nothing else than better code.

Further reading:
Rendering graphics in JavaScript games

Now, I have rewritten the online mode – this time that part is also all JavaScript – continue reading to find out what makes it tick.

The original server

I wrote the original server for TankWar using Python and the Twisted library. Now, since I had nothing left, I had to reverse-engineer how the server used to work from the client’s code.

It proved to be a bit tricky, but eventually I succeeded

The new 100% JavaScript implementation

I decided I wanted to write the server as an Opera Unite application, and Opera was conveniently running a competition for Unite apps too.

The latest version of the application uses Bayeux as the protocol. It’s a straightforward JSON-based protocol for Comet, supported by the Dojo Foundation, and with client libraries available for both Dojo and jQuery.

I decided to put the Bayeux protocol related server code on GitHub under project JavaScript bayeux server. The code doesn’t support all of the Bayeux protocol yet, but it can be used to implement applications already as I have done. I plan to continue working on some new features for the library, but if you want to contribute, feel free.

I call the application itself TankWar on Unite. As mentioned, it uses Opera Unite as its base. I hadn’t developed Unite applications before, but it turned out to be a relatively simple job, thanks to the fact that Unite uses JavaScript with few custom APIs.

Unite applications also have the ability to keep persistent state, so it was perfect for a game where I needed to keep things together over multiple requests.

In closing

I’m planning on doing some more stuff for the game, such as improving the engine itself as it’s a little bit glitchy. Perhaps also improving the graphics, maybe by using bitmap sprites with canvas.

If you want to check out the Unite application’s source code, simply download it from the mentioned site and rename the file to .zip. It should at least serve as a good example on how to use the Bayeux server for writing your own Comet-based Unite apps.

The Bayeux server itself might also work with other JavaScript runtimes like Rhino. You would most likely need to implement a custom RhinoConnection object though, as I have only used it with Unite so far.

What is “time-based” animation?

We all know what animation means, but what does time-based add?

Let’s imagine we have a game. Our game runs at 60 frames per second (fps) on a powerful PC, and 20 fps on a slow PC.

Animation that isn’t time-based is frame-based. In this case, a frame means a “cycle” in the game: In each frame you typically calculate things like movement or AI, and draw things on the screen.

Let’s say we have a walk animation which changes every frame. This means that on the fast PC the animation is much faster than on the slow PC, since the framerate is much higher.

Time-based animation calculates how long each frame in your game takes, and uses this to calculate how long an animation should take. By using time instead of frames, we can achieve exactly the same speed on both the fast and slow PCs.

There is also a term “time-based movement”. This applies the same principle to movement of characters and other things on the screen so that everything moves at the same speed no matter what frame rate.

The infrastructure

There is some infrastructure we need before we can actually start animating things.

• We need a timer which can calculate how long each frame takes
• We need a sprite sheet object, which we can use to keep track of different sprites in a big bitmap
• Lastly, we need an animation object which handles choosing the correct sprite from a spritesheet and such.

In addition to these, in a game you would also have things like animation and spritesheet loaders that load spritesheet and animation definitions from files so you won’t have to modify your code to change an animation. However, these are outside the scope of this post – if you’d like to see a post about loading this kind of things from files, leave a comment.

First, let’s look at making the class which will take care of timing the frames.

Creating a frame timer

The basic idea of a frame timer is that it should be called once every frame, usually after the processing is complete. At that point, it compares how much time has passed since the previous call. We can then use this value on the next frame to make a good guess of how long it’ll take this time.

To determine the time on each frame, we’ll use the Date object.

var FrameTimer = function() {
    this._lastTick = (new Date()).getTime();
};
 
FrameTimer.prototype = {
    getSeconds: function() {
        var seconds = this._frameSpacing / 1000;
        if(isNaN(seconds)) {
            return 0;
        }
 
        return seconds;
    },
 
    tick: function() {
        var currentTick = (new Date()).getTime();
        this._frameSpacing = currentTick - this._lastTick;
        this._lastTick = currentTick;
    }
};

This simple looking class simply tracks time spent during two “ticks”. With this we track the actual time spent between two frames, so that we can keep the animation’s speed constant in real time instead of application speed.

Using this object is simple:

var timer = new FrameTimer();
//Tick once to initialize the time
timer.tick();
 
//Now do processing
while(true) {
  //do things based on time
  work(timer.getSeconds());
 
  timer.tick();
}

Sprite sheet and animation objects

To make our life a bit easier in the code, let’s abstract the code which calculates the exact location of a specific sprite on a spritesheet. Let’s also write a class which abstracts the animation and handling which frame should be displayed.

Since we’ll need the spritesheet class for the animation class, let’s look at that one first.

The idea is that we can create a spritesheet object that helps us in drawing sprites from a big sheet. As you know, to draw a specific sprite from a sheet, we need to know the location of it on the sheet – locating a specific sprite will be the main job of the spritesheet object, so that we won’t have to think of it all the time.

var SpriteSheet = function(data) {
    this.load(data);
};
 
SpriteSheet.prototype = {
    _sprites: [],
    _width: 0,
    _height: 0,
 
    load: function(data) {
        this._height = data.height;
        this._width = data.width;
        this._sprites = data.sprites;
    },
 
    getOffset: function(spriteName) {
        //Go through all sprites to find the required one
        for(var i = 0, len = this._sprites.length; i < len; i++) {
            var sprite = this._sprites[i];
 
            if(sprite.name == spriteName) {
                //To get the offset, multiply by sprite width
                //Sprite-specific x and y offset is then added into it.
                return {
                    x: (i * this._width) + (sprite.x||0),
                    y: (sprite.y||0),
                    width: this._width,
                    height: this._height
                };
            }
        }
 
        return null;
    }
};

The basic usage of this class is you create a data-structure which contains the spritesheet definition, and pass it to the object, such as this:

var sprites = new SpriteSheet({
    width: 32,
    height: 32,
    sprites: [
        { name: 'stand' },
        { name: 'walk_1', x: 0, y: 1 },
        { name: 'walk_2', x: 0, y: 1 },
    ]
});

The definition is simple: First, we define the width and height of a sprite, and then we define a name and x/y offsets for each sprite in the sheet.

When we apply this with an image which has three sprites, each 32×32 in size, we can simply tell the spritesheet that we want the sprite called ‘walk_1′, and we get a nice object with the X and Y positions to draw it from the sheet. We’ll see this in action soon!

The animation class

Now that we have the spritesheet stuff done, we can do the last in the line: The animation class.

The animation class takes a definition, similar to how the spritesheet took, and then handles various things based on that. For example, as each animation comprises of specific frames, it calculates how long a frame has been visible, and changes to the next frame when it has been visible long enough.

On with the code:

var Animation = function(data, sprites) {
    this.load(data);
    this._sprites = sprites;
};
 
Animation.prototype = {
    _frames: [],
    _frame: null,
    _frameDuration: 0,
 
    load: function(data) {
        this._frames = data;
 
        //Initialize the first frame
        this._frameIndex = 0;
        this._frameDuration = data[0].time;
    },
 
    animate: function(deltaTime) {
        //Reduce time passed from the duration to show a frame        
        this._frameDuration -= deltaTime;
 
        //When the display duration has passed
        if(this._frameDuration <= 0) {
            //Change to next frame, or the first if ran out of frames
            this._frameIndex++;
            if(this._frameIndex == this._frames.length) {
                this._frameIndex = 0;
            }
 
            //Change duration to duration of new frame
            this._frameDuration = this._frames[this._frameIndex].time;
        }
    },
 
    getSprite: function() {
        //Return the sprite for the current frame
        return this._sprites.getOffset(this._frames[this._frameIndex].sprite);
    }
}

The comments should explain most of this class. The main point is that with this, we are done!

Now we only need to look at the animation definition format, and then we can combine these three into the most amazing animation machine the internet has ever seen… or something like that anyway.

var walk = new Animation([
    { sprite: 'walk_1', time: 0.2 },
    { sprite: 'stand', time: 0.2 },
    { sprite: 'walk_2', time: 0.2 },
    { sprite: 'stand', time: 0.2 }
], sprites);

Here we define a walk animation. The animation is defined by simply giving the object an array, which contains objects for each frame, defining the name of the sprite and the duration of the frame. The variable sprites in the end is the spritesheet we defined in the previous example.

Putting it all together

Now, let’s put all this together!

I have a spritesheet lying around from some old projects: kunio.gif. Let’s animate this.

You may be familiar with this character – He is Kunio from an old NES game known as Downtown Nekketsu Monogatari, released in english as River City Ransom, and he’s been featured on various flash-animations as well.

I’ve used this sprite in a few other projects:

• In this Flex-based game test (use arrow keys to move, space to punch, doubletap arrows to run)
• In my Palm Pre Accelerometer demo application, which actually uses this same code shown here.

But enough of that, let’s write a quick HTML page to put our code to work:

<!DOCTYPE html>
<html>
<head>
    <title>Canvas Spritesheet Animation</title>
    <script type="text/javascript" src="js/FrameTimer.js"></script>
    <script type="text/javascript" src="js/SpriteSheet.js"></script>
    <script type="text/javascript" src="js/Animation.js"></script>
    <script type="text/javascript">
        window.onload = function() {
            var timer = new FrameTimer();
            timer.tick();
 
            var sprites = new SpriteSheet({
                width: 32,
                height: 32,
                sprites: [
                    { name: 'stand' },
                    { name: 'walk_1', x: 0, y: 1 },
                    { name: 'walk_2', x: 0, y: 1 },
                ]
            });
            var ctx = document.getElementById('canvas').getContext('2d');
            var walk = new Animation([
                    { sprite: 'walk_1', time: 0.2 },
                    { sprite: 'stand', time: 0.2 },
                    { sprite: 'walk_2', time: 0.2 },
                    { sprite: 'stand', time: 0.2 }
            ], sprites);
            var kunioImage = new Image();
 
            kunioImage.onload = function() {
                setInterval(function(){
                    walk.animate(timer.getSeconds());
                    var frame = walk.getSprite();
                    ctx.clearRect(0, 0, 300, 300);
                    ctx.drawImage(kunioImage, frame.x, frame.y, 32, 32, 0, 0, 32, 32);
                    timer.tick();
                }, 5);
            };
 
            kunioImage.src = 'img/kunio.gif';
        };
    </script>
</head>
<body>
<h1>Canvas sprite animation demo</h1>
<canvas id="canvas" width="300" height="300"></canvas>
</body>
</html>

Here it is. Our great animation system!

A live example and source code

You can see this code in action by clicking here

As usual, don’t expect it to work in Internet Explorer. It has been tested to work in Opera 10 and Firefox 3, probably works in other canvas-supporting browsers as well.

Source:

• FrameTimer
• SpriteSheet
• Animation

Conclusion

Animating a spritesheet with canvas is quite simple. This is why JavaScript is quickly becoming a powerful platform for small games in my opinion – very easy to use, and quite ubiquitous.

You can use this same approach to animation in other languages too – For example, the Flex example I linked uses a very similar approach.

As for packageizer and few other things not working, that’s because I’m setting them up on a new server. They should be up soon’ish.

Now for the actual post!

Today I’ll talk a bit about my other popular JavaScript widget game, Opera Command. As you may have guessed, it’s a clone of Missile Command and I originally wrote it to run as an Opera Widget.

I recently modified it to run in other browsers, so you can try it out even if you don’t have Opera. There may be some issues regarding the Z, X and C keys being taken by the browser for other purproses but other than that it should work quite fine.

This game is technically less interesting and impressive than TankWar Online, but it bears a few things of note.

Opera Command is possibly the only one of my games with a small “story” – The little snippet about Redmondians attacking Norway you get when you open the game. Also, it had an online high score table, which no longer functions due to same reasons as TankWar’s online play. Some people had also figured out what the game does to post your score and had “hacked” it and posted fake scores…

As usual, the graphics are done using the canvas element and the menus are plain old HTML divs and stuff. Despite quite simple I like how the graphics turned out, as they kind of look “old school” and the game runs pretty well even on a bit slower PCs despite canvas being quite expensive speed-wise.

Some of the graphics are simple images drawn on the canvas, like the city graphics. Rest are drawn using the canvas methods. The explosions particularily are something that turned out surprisingly nice after a random try: They are simply circles that get larger and are filled with a gradient.

I still have one or two JavaScript games that might be worth a post. Perhaps we’ll see some in the future

Originally the game was made for an older version of Opera 9, and only worked in it. However, I have now modified the game so it should work in most browsers (tested Firefox, Opera 9, 10).

Click here to play cross-browser version of the game. The game should work for other parts than the online game mode, as the server is no longer functional.

Interested in hearing how the game works, such as terrain, physics and the computer AI? Keep reading!

A disclaimer regarding the code

If you want to go look into the code, feel free, but keep in mind I wrote this in late 2006 and the code is not really very good. It probably makes sense after you’re totally familiar with it, but even I who wrote the thing had problems finding the places I needed to modify to make it work once again.

Main features of the game

Let’s look at how some of the main features of the game work.

Terrain

The terrain in TankWar is generated randomly, based on a bunch of parameters. If you go into the map settings from the main menu, you can see and adjust these parameters.

The input fields in the map settings screen are actually Web Forms 2 (now a part of HTML5 forms) elements, which still don’t seem to be supported by any other browser than Opera, even after many years. If you don’t have Opera handy, the main difference between the fields in other browsers and Opera is that in Opera, the fields get little arrows for increasing and decreasing the value.

The terrain generation algorithm itself is pretty simple. It takes the base height value, and then adds a number of points based on the height points value. The points’ heights is randomized between the min height and max height values. Ta-dah, simple terrain generation.

Destruction of terrain

Another feature of the terrain is that it’s desctructible. If you fire a weapon at it, it’ll make a hole. You could even destroy the whole map if you destroyed all the ground.

To understand how the desctruction of the terrain works, we have to look at how the terrain itself is stored and rendered.

The terrain is stored as an array of points, which are converted into a canvas path. The path actually consists of the sky, and not the ground – the sky and ground are rendered by first filling the whole image with the ground color, and then using the terrain path to fill in the sky.

When some of the ground is destroyed, the game creates a circular path, which is then added to the terrain path. This way the destroyed areas of the ground get filled with the sky color as well, making it seem like the ground was destroyed, even though the terrain path itself remains unmodified.

Terrain hit testing

This is also used for testing hits on the ground: as long as a projectile (or a tank) is inside the terrain path, or inside one of the circular explosion paths, the projectile keeps moving. The hit check was performed by an Opera-specific method and a custom polygon hit checking function in the old code, as when I wrote it, there was no reliable way to detect whether a point was inside a path or not. In the new version, the hit is detected with the canvas method isPointInPath, which should work in all browsers with a modern canvas implementation.

The physics engine

The game features a simple physics engine, which simulates falling tanks and moving projectiles such as cannon shells. It also allows for wind.

It functions relatively simply: each “physics object” – tanks and shells – have some vectors which define their position and velocity. The engine has a constant gravity, and an optional wind (which is kind of like horizontal gravity), which affect objects when they move. The physics engine is not active until someone actually fires their cannon – it has no need to run when you take aim, so the engine was designed so it could be given a set of objects to simulate (tanks and the newly fired shell) and then it could run until all the objects are considered “dead”. Being dead simply means that each object has hit the ground, or for shells, hit a tank.

Weapons

Currently the game has eight weapons. Originally there were less, but I had wanted to add more interesting weapons, so the weapon system was designed to accomodate various kinds of weapons, as can be seen in the current selection.

The weapon system is based on the concept of a cannon and a shell (which is what cannons fire). The cannon acts as a kind of a factory for shells, defining how much damage they make, how large is their blast radius etc.

The system is also wired with some events such as an event for the time when a shell hits the ground. This enables the engine to have weapons like the teleport or the arty drop, which both have a special handler for the hit ground event, which moves the player’s tank and fires three more shells at the location from the sky, respectively.

The bomber weapon is a bit special. The weapon’s behavior is actually not intended – it’s a bug. It probably seems crazily overpowered sometimes, and I never meant it to drop an infinite stream of “bombs”, just five of them, but because of a bug it just turned out like that. I liked the unintended behavior and left it in, so it became a feature instead.

Some of the weapons were inspired by Worms 2, like the arty drop and teleport.

Computer opponent

This was one of the most interesting parts of writing the game. As I wanted to give players the possibility to play the game by themselves, I wanted it to have an AI player.

The game’s “player system” is quite flexible. It had to be, so that implementing a “local” player, a “network” player for online games and an “computer” player would be possible. Simply put, the players each implement a specific set of functions that are called in specific points during the game – the game itself doesn’t care much what the type of the player is, except in some special cases, and the player object itself handles things differently.

The computer AI is not very complex. To not give it a completely unfair advantage (and so that my head wouldn’t hurt too much because of the math involved), I didn’t give it a 100% precise aim – which would have been possible by computing where the shell will land, given the gravity, wind and required power and shooting angle.

Instead, the computer follows this graph (click to see a bigger image)

The diagram is not 100% accurate, but that is the general idea of how the AI works. It does some small additional things, such as figuring if wind has changed.

Currently defunct: Online play

The coolest thing in the game no longer works: The online multiplay mode.

The online multiplayer mode was similar to what you can see in many PC games nowadays. It had a lobby where players could talk with each other, and a list of games which were active and joinable. It was also possible to protect your game with a password and choose a maximum amount of players.

There were some additional hidden features in the online lobby, such as the ability to join a custom room, a bit similar to joining channels on IRC. It also implemented some swearword filtering (schoolkids seemed to enojy abusing the chatroom during school hours) and an admin interface for getting rid of unwanted elements (which was implemented on the server and only worked for me)

The gameplay itself was the same, but in addition to the interface elements seen in a local game, the game showed you a chat box and the list of others in the game so you could talk with them during the game. As with local games, you could have up to eight players in a single game, which was a limitation I had chosen based on the map size – the game could have had 10, 20 or more players, but the map would’ve gotten very crowded.

Online game server

The server for the online play was lost in a fatal hard disk failure in 2008 or so. It was implemented in Python, using a library called Twisted to provide HTTP functionality.

The server received communications from clients with XMLHttpRequests, and sent responses using a Server-Sent DOM Events channel, which each client was required to open. Most of the stuff was quite normal client-server type of things – the clients would get an ID, send messages, receive responses and parse them etc.

There was quite much game related things to do on the server as well. While testing the game, I noticed a worrying inconsistency of where the shells landed on one PC compared to a slower PC – sometimes on slow PCs, the shells would land on completely different locations than on the fast PC. I fixed this by making each network player get synced from the server. Basically it meant that whenever a player’s turn was finished, the player’s game told the server where the shots had landed. The server would then broadcast this to all players in the game, and this way each player’s game was kept in perfect sync.

Sadly I no longer have the code as said, and it would be a rather big undertaking to write a new one – certainly possible, but I don’t have the time for it.

Bottom line

TankWar was, and maybe still is, my greatest widget. WidgetCity was a large and complex project, but TankWar had a lot of special things in it and it was 100% written by me – WidgetCity shared a lot of algorithms with the original Sim City source code available online.

Here is the source code for TankWar, if you want to take a look at it.

The tile map is done purely using just CSS, and CSS classes. The map is also scrollable.

How is this all done?

Multiple approaches

As always, there is more than one approach to doing this type of a tile map.

The most obvious approach is to chop down each graphic in the game to one tile sized small images. Then, each of the small images is applied using a background image to each of the tiles. For example, an industrial zone is 3×3 tiles, so this would need 9 small images which each get applied to specific tiles to build the whole industrial zone.

This small image approach can be done in two ways: Using a CSS style to put the image as the background, or by inserting an img tag into the cell and changing its src.

There’s a lot of different graphics for just a single type of zone: Indstrial zones for example have different graphics for different land valued zones and different populations on the zone. The above approach would work, but it would require a lot of work to chop each big graphic into small ones and also each image would have to follow a specific naming scheme so it could be applied correctly.

Another approach is similar to what is used in CSS sprites: Each larger graphic is contained in a single file, and the image is then mapped into the small cells using CSS’ background-position.

The chosen approach

I decided to use the approach similar to CSS sprites. This is because it was simpler to work with the files, as I didn’t need to rename all the little images and define tons of CSS classes just to apply the specific backgrounds. This also somewhat simplified the JavaScript code applying the styles.

The game defines a set of CSS naming rules which are used in the stylesheets, so the code in the game can easily apply styles without having to use special cases all over the place. Each cell’s className attribute consists of several classes:

• An “offset class”, which is used to place the big image into the small cell: for example, “o31x1″ is the bottom right corner of a 3×3 tile – o for offset, 3 for 3×3, 1×1 for the X and Y offset from the center of the tile. The game knows which position of the tile it’s laying out, so it simply adds the respective offset class into the cell’s className.
• The main “graphic class”, such as “indbuilding” for an industrial building.
• A “land value/population class”. This is used to choose which graphic of the building to actually display, such as a small rowhouse, or a big skyscraper. These look like v0p1, where v0 means land value 0 and p1 means population 1

There are also some other special classes:

• nopower class is applied to zone center cells if the zone doesn’t have power. This shows the little no power indicator
• For roads and powerlines, there are classes called up, right, down and left, which are applied in following cases: if you have a road, and there’s a section of road above it, the class “up” is given to the bottom road cell, and the class “down” is given to the upper. If there’s also a road to the left of the upper cell, it gets “left”. In the stylesheet, there are combinations of these four classes, which apply the correct road and powerline graphics to the cells.

The scripting side of things

Of course all this won’t work without JavaScript. Behind the scenes, the game stores the map as a two dimensional array of objects. The objects in the array contain various data, which is used to determine which classes to apply to each cell when “rendering” the map.

The classes are also applied only when something changes – the game keeps track of what classes are in the cells, as re-applying the class incurs a performance penalty.

What about canvas?

Lastly, some words on an alternative to using a table: the HTML5 canvas element.

While it may seem “wrong” to use table to do something like this, I think it’s in certain ways better than canvas. Firstly, you get better performance, and second, you need less code.

Using canvas, you would need to write the code to draw the correct parts of the graphics, and if you wanted animations like the game has now, you would need to write timing code to run the animations. So in addition to the performance penalty of using canvas rendering, you would need additional JavaScript code running the animations and everything else.

The benefits of using canvas would be that you could provide smooth scrolling. With a table it would be very tricky if not completely unfeasible. Canvas would also allow zooming or other effects.

The game is called WidgetCity, and I’m participating with it in the Betavine Widget Competition 2009.

The game was designed to run in Opera Widgets mode, but it also works in Firefox – only downside is that you can’t save your city. Get the widget here, or if you don’t have Opera, you can play the game here. There is also a help file.

Continue reading to find out more details about the game’s inner workings and such!

The basic stuff

The game is quite similar to the original Sim City – it actually uses some graphics from it, thanks to the fact that the original Sim City source code has been released under GPL, which was a good thing because I’m not the world’s greatest graphics artist!

As per the requirements of the Betavine competition, the game had to run in a mobile phone. This is why the game is so small: It had the screen size limitations of a Nokia N95, which is something like 260×240 pixels.

The game was originally supposed to be based on the canvas tag, which I’ve used on my past widget projects like TankWar Online. However, this turned out to be a bit of a problem on the phone, and only one of the problems caused by the phone.

The N95 is actually a quite good device: It has the hardware to run games with 3D graphics, etc. etc., but it’s completely unable to run JavaScript code at a reasonable pace. Using canvas, the game ran absurdly slow!

In the end, I had to resort to using old-school DHTML style trickery: The game area is simply a table, with some CSS classes applied to each of the cells in JavaScript.

Under the surface

Under the relatively simple looking graphics of the game ticks a quite serious simulation engine.

The game engine simulates a lot of things, and it had quite serious performance implications which required a lot of JavaScript optimization. You can read more about the problems and optimizations encountered in development in Optimizing JavaScript for extreme performance and low memory consumption.

The sim engine calculates at least the following:

It keeps a track of what’s built in each tile in the game. This data is then used to calculate things like how much residential/commercial/industrial demand there is.

For some specific tile types like residential zones, the game calculates desirability and traffic: Is this area of the map “good enough” to build a large apartment block, and can the people living here drive to some destination?

The desirability calculations are based on a bunch of other large calculations: Pollution, crime rate, land value, population density. Each of these has to be calculated again and again during the progress of the game to keep the city developing.

Traffic itself uses a quite “dumb” algorithm: It just attempts to drive in a random direction along the roads until it reaches a destionation, which works okay for the simple calculations involved.

The large calculations like pollution and land value calculations require going over all the tiles in the map to determine what’s built where, and then based on those some values are calculated.

You can probably see why the performance wasn’t so great, as there is a lot of stuff going on in the background!

Issues during development

Most of the problems during the game’s development were caused by the really poor JavaScript performance on the target device.

For example, the original map size in the game was 300×300 tiles. This would cause the phone to immediately run out of memory when attempting to play, so I had to reduce the size to 128×128, which still quite good is nowhere near as large as the original.

Note that the original 300×300 map did run perfectly fine on my desktop and on my HTC Touch Diamond. It would probably have had major performance implications in the future, though…

Additionally, I originally planned to use canvas. However, I had to scrap that and use a table as the speed of canvas was just way too poor. You may be interested in reading how the WidgetCity map is rendered using a table and some CSS.

The JS performance in general seemed quite awful: Just looping over the 128×128 map was slow. If you did nothing else than just iterate over each of the 16 384 tiles, it would already have a small impact, which you wouldn’t have with most other languages, or even with a bit newer JavaScript engines.

Another memory related problem surfaced closer to finishing the development: The N95 would run out of memory when saving the game.

Saving and loading are a quite vital feature of the game, so this was a critical issue. However, Remco Lanting came up with a nice idea to possibly fix it: Save the map in smaller parts. The idea worked flawlessly. Remco also helped with testing the game and with some ideas, so a big thanks to him.

What’s missing?

While the game is quite ready and playable now, there are various things that I would’ve liked to add to it, but due to lack of time I couldn’t.

These include being able to lay rail, being able to get nice maps that display things like crime rate in different parts of the map, some user interface improvements, and of course disasters like nuclear plant meltdowns!

One particularily cool thing I would have liked to have was the ability to overlay data like crime rates on top of the city. I wrote a post earlier on how you can get Photoshop layer style stuff in JavaScript, which could have been a nice way to do this.

I don’t know if I will be adding all those, as I have various other things to do now that the game is released, like actually writing blogposts again.

However, if you’d like, you are free to modify the game. I’ve decided to release it under GPL, similar to the graphics from the Micropolis project used in it. If you would like to play with the source code, just download the widget, rename the file to .zip and unzip it like normal.