Legend of Grimrock: Making of Rapid Programming

Almost Human’s Petri Häkkinen ratchets up the technical talk by posting a new “making of” blog post to the Legend of Grimrock website that covers the concerns, goals, and processes that were considered when coding the dungeon crawler. Long live C++:

A typical game development workflow when working with C++ is something like this:
1. Design and write code in IDE (IDE being basically a glorified text editor)
2. Compile code (compilation turns the source code into machine executable sequence of instructions)
3. Run the game and wait for it to load
4. Test your changes (play the game to the spot where you have made your changes or load a saved game if you’re lucky and the save game is still compatible with your code changes)
5. Go back to step 1

Steps 1 through 5 is usually collectively called the (iteration loop). Essentially step 1 is where all the innovation and fun happens, everything else is just lost time. The length of the iteration loop is usually somewhere between 30 secs to a couple of minutes (if it’s longer than that you’re pretty much screwed). On consoles and mobile devices the iteration loop is usually even longer because the code and/or data has to be transmitted to the device for testing.

In game development, especially when tuning game play, the code changes you make in step 1 are often very quick to make and development speed can become bottlenecked by redundant steps 2-5. There are two factors in this. First, the actual time lost to waiting due to compilation, waiting for the game to start up and getting the game state to where you want it to be in order to test the new feature. Second, and this is far more important in my opinion, with a long iteration loop your mind easily wanders off and you lose the trail of thought. For example, if you have to wait for a minute for the code to compile, there’s a pretty good chance that you check your mails, open a browser to check the news and suddenly you’re thinking about your girlfriend, wife, dog, whatever 🙂 . And it’s this context switch that really hurts because getting back into the flow of programming needs considerable amount of time.

So clearly we have now established that the iteration loop is critical, especially for us because we are so small, we have only one programmer and development times are short.

So the first thing we did when starting up the company was to look into ways to shorten the iteration loop. This is not something that can be fixed by doing small tweaks to the development process. For example, in the past I’ve tried creating gui systems for tweaking various gameplay and graphics parameters on the fly and it helps a bit but not significantly because it’s very limited what can be done. The root problem is the use of statically compiled programming languages, usually C++, which does not allow making changes to the code on the fly. Fortunately there are better options. One of them is Lua and particularly an optimized jit-compiled variant called LuaJIT (more about LuaJIT later). Lua is a very neat dynamic extendable language that is almost ideal for game development: it’s relatively fast, it has a small memory footprint, liberal license and compiles and runs on practically every device. It is a very expressive language with many higher level features such as first-class functions, garbage collection, closures and coroutines. Basically a single line of code can do much more in Lua than in C++ which on its own can increase productivity a lot.