Or, let’s write kilosized games!
Just a few days ago I was reading about somebody writing games whose source code could fit on a business card. “Cool”, I though, “I can do that too!”. Well, maybe. I’m not a videogame programmer and I have little artistic abilities, so I set a somewhat easier target: write a small game whose source code fits in a 80x25 terminal screen (2000 charactes).
Since I wanted to output some graphics and not only characters on a console, I opted to use javscript running in a browser.
The bad news is that I couldn’t reach the target size, the good news is that I got close, 2046 bytes, which is still less than 2 KB. You can see the whole source code below here:
You can play with it here, or check the animation below: it’s responsive, mobile-ready and buzzword compliant!
More seriously, the gameplay is quite simple: missiles are pouring down, and you have to intercept them before they destroy the city. I’m calling the game “Missile defense”, but yes, it’s not original and you can guess where it took inspiration from :-).
While the game itself is nothing exceptional, writing it was an interesting detour from my usualy work-related programming activity. Having size as a major constraint in the program design was interesting (usually it is not an issue, only business requirements are), and playing with minification was an adventure by itself.
Structure of the game.
If source code size would not be an issue, the structure of such a simple game would not probably be worth of discussion. Having to keep the size low instead means often having to decide between a perfect (but “bloated”) implementation of a certain algorithm and a quick and dirty that almost get it right but fails in the corner cases.
The first issues I met was graphics, even more so since I’m not a designer and I didn’t really want sto start a graphics program to paint pixmaps. In any case they take space so I decided not to used them. All the “graphics” that you see in the screen are in fact Unicode characters. Among other things this means that the game may look differently in different browsers, depending on the font used; for example on my computer Chrome will render them in a single color while firefox will show the beautiful multi-color characters that you can see in the Gif above.
Moving the “images” around takes time and code. For this reason missile animations are implemented with a two-step animation and an appropriate animation duration (the exact duration will decrease while playing to make the game more and more difficult). The explosions are made bigger with a simple transform and its duration. This also let us have a perfectly fluid gameplay, since it all managed by the browser.
What is left is a loop that creates every so often a new missile, some code for keeping track of the score and another loop checking collisions between missiles and targets/defensive explosions.
Trimming the game.
After the initial implementation the unminified code was about 7KB, so I decided to remove a number of feature that were interesting but not essential for the gameplay. These include: ability to start a new game (sorry, you will have to reload the page), simple bounding box algorithm for collition detection (so don’t be surprised if from time to time a missile will excape an explosion), disabling text selection, and avoiding from time to time a spurious scrollbar appearing for an istant. After doing this, the game went down to about 5700KB.
Playing with the minification
The tweaks were mostly one of the following:
Using a local variable for globals used many times.
The minifier cannot rename global variables, so if their name is quite long it make sense to make a an extra local variable and reference that In this way we can replace
document.getElementById('x'); document.getElementById('y'); document.getElementById('z');
with something like
var getElementById = document.getElementById; getElementById('x'); getElementById('y'); getElementById('z');
which hopefully will get renamed to something like
var x = document.getElementById; x('x'); x('y'); x('z');
The more the more the function is called, the more we save bytes.
In a similar vein, object properties cannot be renamed, but can be accessed through a variable whose name we can decide. For example
element1.style.background = x; element2.style.background = y; element3.style.background = z;
can be changed to
var background = 'background'; var style = 'style'; element1[style] [background] = x; element2[style] [background] = y; element3[style] [background] = z;
which the minifier hopefully can shorten to as much as
var a = 'background'; element1[a][b] = x; element2[a][b] = y; element3[a][b] = z;
Again, the more an attribute is used, the more we can take advantage of this trick.
Those two trick were more than enough to reach a size below 2048 bytes. I think that an even smaller size could be achieved, but I didn’t want to pass my time tweaking a minifier, so I called it a day. I will try to take it further next time I will try something similar.
The game as some playability issues. Most of them are the result of trimming the code (for example text selection is not disabled, so you can select it by mistake while playing), others because I did not tune much parameters, expecially the collision detection loop that seem to run not often enough. I guess with some fiddling it can be improved but since it was my first try I’m satisfied with the result. Having already learned a few tricks, next time I can dedicate more time to polishing.