Making a game in Javascript
During my daily commute to and from work I have been writing a game to enter into the Js13k Games competition.
The competition runs for a month every year, at the end of which entrants must submit a complete game using only 13 kilobytes. The competition has been running since 2012, and this year 245 games were entered.
The standard of games in JS13kGames varies but is generally high, with some of the games being as good as commercial products. I don’t make that claim about my game — you need a fast computer just for it to be playable — but it was fun to make, and maybe one day I’ll improve it for slower machines.
This is the first time I’ve entered this competition. Earlier in the year I entered JS1k, which is a similar competition, but there the limit is just 1k, or1024 bytes. I came 7th overall. You can play that game here.
My 13k game is an homage to the platform games I played as a kid. Arcade adventure 2D platform games like this were very popular. These games generally involve finding and using objects to solve puzzles, in an environment of ladders and levels that can be navigated by jumping and climbing.
One such game, Citadel, was a particular favourite. It was published in 1985 for the Acorn Electron and BBC Micro computers. I’ve always wanted to write a game like it, and it inspired my entry into the competition.
Building the world
Another popular game at the time was Exile. It was one of the earliest games to use procedural generation to build its world, rather than the programmer having to hand-coding every single element. This is a technique that is still in use today, with Minecraft being probably the best known example.
Procedural generation makes it possible to create a virtually infinite playing area that uses only a small amount of code and data behind the scenes. It’s a technique that I use in my game to fit a large game world into a small amount of code.
My procedural generator creates a world consisting of a layer of grassy earth on top of rock, containing an intricate series of caves, some of which are flooded with water. You can read more about it in this article.
I decided that I wanted my game to have a mission and an ending rather than go on forever. This requires preventing the player from getting lost in an infinite world, which means the play area needs boundaries.
An obvious way to add boundaries is to put up walls, but this didn’t fit with the natural style of terrain I had created, so I decided that a sea would be the way to go. This is why the game is set on an island. The play area is still infinite — you can swim off in the sea for ever — but I hope that swimming away from the island would get so boring that the player would prefer to stay on the island.
Fitting it into 13k
As its name suggests the JS13k competition requires writing a game no larger than 13kB, which is 13,312 bytes. That’s small. A laptop or phone has its memory measured in gigabytes, which is thousands of millions of bytes. Even my favourite Citadel was written for a computer with 32kB available.
Writing a game to be so small requires some special techniques. My earlier 1k game involved writing some quite horrendous looking code, using a number of tricks (known as ‘golfing’) to squash as much functionality as possible into 1024 bytes. The habits of writing clean maintainable code that I use during my day job went on hold, as I worked to squeeze as much as possible into a small space.
I approached the 13k competition in the same way, but it wasn’t until a couple of days before the closing date that I noticed that the 13k size limit applied to a compressed (zipped) version of the code, rather than the executable code itself. This came as a relief. Time was running out and I hadn’t golfed the code as much as I wanted, but now I was able to submit an entry of 10kb without needing to work any harder to compress it.
The left over space means I could have fitted a fair bit more into the game. There was a lot of polish I wanted to add, as well as more items, baddies and puzzles. Designing graphics and gameplay takes as much time as coding, and time was the limiting factor for me, not program size. As the deadline arrived I had to leave the game as it was.
Alas my game is nowhere near the quality required of a winning entry, but given that I only worked on it for an hour a day I’m proud of what I’ve achieved. As the other entries demonstrate, a lot is possible in 13k.
About Alexander
I’m a software engineer based in London. I help companies to build web applications.
