Have you ever wondered how it feels to write a HTML5 game? Мy wife and I did, and we created the game Life of Blobb for the js13kgames competition. The participation has proved very educational, especially because of the constraints:
Limited size. 13 kilobytes means that you get to develop with limited raster graphics, relying more on code to create your game. Imagine how much minified canvas code can be extracted in one kilobyte, and the corresponding image.
Limited time. The time range was August 13th to September 13th, giving participants a month to go through writing, testing, and polishing the games. Since we started late and had to finish early, our development time was roughly cut in half, but still sufficient.
What went well
The object hierarchy and level structure turned out very well. Levels are scriptable (providing setup and tick events), which allowed flexibility like time limits and different setups.
The levels have been balanced to be challenging enough so that the game is not easily beaten the first time. Full credit of this goes to my wife; I had quite a bit of trouble of beating some levels after she was done balancing and I pulled her changes.
I particularly enjoy the ending. This year's theme was bad luck, and I think it is appropriate.
Since this is our first game, it was a good sign when @mozhacks published a game development tutorial and it matched the design that evolved on our side.
What went bad
My only regret is that the instructions were not written well. In particular, one of the main mechanics -- to keep the player blob in a given size range -- was described poorly, and frustrated many players. A lot of interactions could have been polished more, but given the time frame, they turned out well.
During development, the one of the biggest engineering hurdles was how one blob consumed another. At first, this was done by calculating the overlapping area of the two blobs, but that yielded the effect of very rapid blob growth and rendered the game unplayable. In the end, conserving the center distance proved more usable and allowed some mechanics like brushing off bigger blobs. Still, this problem consumed a lot of time that could have been used for polishing.
I am happy with the end result. Who knows, it may get a bit more polish sometime soon...
Interested in becoming a better front-end developer?
Subscribe to the occasional newsletter.