Recently I made a game and entered it into the Github Game Off 2019. The premise of the game is that there are a series of cows that run around following rules. The aim in the earlier levels is to get all of the cows into a green area. The aim in later levels is to use the cows to create and program a basic computer.
With these kinds of game jams, there is a restrictive time limit involved. In this case, 30 days. On day 0, you receive a theme in which to base your game upon: the theme was “Leaps And Bounds”. Generally there is not enough time to create a large, polished game given the limitations, and in my case, the game was largely unfinished. There was definitely enough gameplay for a few hours, but I had hopes for a bit more. Well, anyway, here’s how it went.
Brainstorming
For the first day or two, I tried to come up with ideas on how my game was going to work. I wanted to make a puzzle game of some description, and hopefully something that I would have fun playing as well. As the puzzle maker, it’s almost a given that you know the solution, but there are some problems which you can give yourself a blank palette, describe what you want, and then fill in the gaps. This gives the player (and me) a wide artistic license to solve the problems in their own way.
I had an idea for a tile based automation based on Befunge where the stack was part of the main memory. A basic language would need an instruction pointer and a stack pointer. In a game scenario, it would make sense that the instruction pointer and stack pointer would be physical entities. I ended up settling on cows, since I could reuse some assets from the last game jam I entered.
In addition, if I was going to create a computer, I needed to give it some limitations. If I made it too easy to write programs, then it would just be programming, however, if I add some artificial limitations, then it becomes a puzzle that needs to be solved.
Initial sprint
With only 30 days, I decided to try to remain with things that I already know, which would give me a predictable time limit to complete the game. I knew that I would not need a physics or collision engine, and decided to just create a game that works on a canvas in HTML with no framework. I thought that the game was minimal enough that learning additional frameworks or libraries would have simply wasted time, as the majority of the effort would be spent writing original code anyway.
In hindsight, this was a huge mistake, and I should’ve gone straight to Godot or a well established game engine. Just bundling the program at the end took almost half a day due to various reasons, but Godot would have instantly given me a cross platform binary, and a web version to boot!
For a few days, I used plain Javascript, but it became apparent that some things were going to eat up a lot of time. I would have spent too much time creating persistent data structures for the undo functionality for example. In addition, it became apparent that some of the data was not well suited to JavaScript’s weak typing. As much as JavaScript is quick to prototype, it is largely difficult to refactor.
Given my abilities as a programmer, I decided that it would be faster to switch to a language which has much stronger guarantees about the program at compile time, so that I can offload as much of my mental effort as possible onto the compiler. My personal experience with Rust is that it requires significantly less thinking while programming; the compiler just tells you what you’ve done wrong.
It took me a day and a half to rewrite what I had in Rust and compile to web assembly. I strongly believe that my productivity increased significantly after the change. In addition, the quality of my code was better than if I had written JavaScript. The reduced debugging ability of Rust on web assembly was largely offset by the fact that most bugs were caught before the program compiled. The bugs that did get past the compiler were easier to fix than JavaScript anyway.
The First Mistake
Theres a saying that if you only have a hammer, then everything starts looking like a nail. I’m no artist or sound designer. I write programs. The main mistake that I made was thinking that this game was going to be a technical exercise in programming. The reality of game design is far different.
Many modern game engines advertise that users can create significant portions of their game without writing any code at all. This is without a doubt a true statement. Unfortunately for me, I had (stupidly) decided not to use a game engine. I had vastly underestimated how much of a game was created by using the tools of an editor.
All of the luxuries that make your life easier with a fully featured game engine were not present. Every animation had to be coded by hand. Every graphic on the sprite sheet was manually selected. The level editor was hand coded. I even ended creating an ad-hoc component system and scene manager. All of this code was strictly unnecessary, and wasted time that I didn’t really have.
I suppose the other benefit to a game engine is having everything already set up for you. With Rust, I had to deal with the JavaScript foreign function interface. Using a foreign function interface is not great even at the best of times, so spending a lot of time getting trivial things to work was a bit stifling sometimes.
It’s not all a downside: some of the code I wrote would have been difficult to write correctly in a dynamic language (although I am of the opinion that all code is a little bit more difficult to write correctly in a dynamic language). However, in my opinion, 90% of code is usually “dumb” code, which just marshals around data from here to there, and 10% is “smart” code which does something interesting from a computer science standpoint. That means I’m only really worried about making 10% of my code more difficult to write. Godot has official support for many languages, so I’m sure that the benefits would have completely outweighed the downside.
In essence, I would have benefitted greatly by using an engine to create my game. Some of the smaller things that were easier in the past were more difficult. Therefore, some of the more important parts of the gameplay were missing; there simply wasn’t enough time to complete all of it.
The Second Mistake
Apart from not using an engine. My other error was to think of the game as a technical coding exercise rather than a piece of entertainment. Some of the greatest games are not technical masterpieces, and nobody gives wide acclaim to a game and attributes that exclusively to the quality of its code. In reality, if a game is programmed well, then nobody will know.
Unfortunately I’m not an artist or a musician. Therefore, these aspects were left on the back burner until the very end, an afterthought. In reality, I should have given these parts equal, or more attention than the code itself. If 90% of my code is just marshaling data, then maybe I could have eliminated some of it by using the built in engine capabilities, and spent the rest of my time creating assets that look and feel good.
If I could go back and do it again, I would probably create a series of assets which are more cohesive and atmospheric. Certainly making cows move around a paddock is not particularly dramatic, but I suspect that the graphics could have made a bit more sense.
That’s it!
That was exhausting! 30 days of game-making in your free time is hard work! For 30 days and no engine, I’m quite happy with the result (even if it is incomplete). I made myself a puzzle game that even I had trouble with solving. If nobody else enjoys it, I still had fun, and learned a few things about the relevant technologies.
More importantly, I learned some things that aren’t purely technical: Use the right tools for the right job; manage your time effectively; don’t reinvent the wheel; and if you’re making a game, make it fun to play!
I hope you enjoyed this article, if you want to try the game in all of it’s unfinished glory, you can play it here. The real puzzles start in the second world. Any feedback is welcome.
This post was originally posted on Andrew’s Notepad
Rust
Programming
Game Jam
Game Design
Github Game off