About Chris M (twitter: @chrismcmath)

Game developer based in Beijing.


Ludum Dare 35
Ludum Dare 33
Ludum Dare 32
Ludum Dare 31
Ludum Dare 30

Chris M's Trophies

Chris M's Archive

The Three Knows of GameDev – A LD33 Post-Mortem

Posted by (twitter: @chrismcmath)
Thursday, September 3rd, 2015 5:06 am

I’ve come to revere Ludum Dare as a tri-annual marathon of determination, time management and polymathy. Even so I was not prepared for the turbulence this particular jam would bring. Having just come off work on various side projects I’d entered the weekend brimming with a great sense of energy and ability. How soon those two allies deserted me!

Were I to invent a time machine before I die, I would want to waste no time planning what to do with the technology. So here’s what I’d say to my pre-LD33 self.

I’d say…

‘Know the Three Knows!’

Know One: Know What You’re Making

Design is fun. Especially the bit without the design. Just saying stuff in a stream of ‘What If’-ism; one’s creativity taking flight and pirouetting across the warm canvas of possibility. Down below is cool reality, a series of etched hills and smudgy troughs. Mountains of design so well detailed they seem to implement themselves, but the troughs…

Oh the troughs are all too easy to overlook. In the troughs are shadows, those areas of design the free flight of creativity is blind to. They seem so innocent now, but come the 12th hour, perhaps the 24th, or maybe even 36th and they’ll prove to be your undoing.

‘Beware the design shadows, my son!
The work unseen, the flaws that forsake!’

Here, courtesy of Robin D. Laws, is a shadow we’d all do well to avoid.

So simple, yet it was only on Day II I realised I hadn’t done this, having allowed myself to be transfixed by the procedural features of my game. Now you wouldn’t know it, but there is a conceptually infinite number of planets in The Last Little Monster. Most people who play only see two or three of these. That leaves infinity minus three planets unexplored.

Did I need to spend the majority of the first day working on this? And if I did, the question of how to integrate it better into the core gameplay loop should have out-prioritised the implementation of it.

Know Two: Know Your Tools

As a Unity developer of a few years I often assume capability in systems I have little working knowledge of. Complex systems such as the PhysX engine may be conceptually simple, but then so is cooking and I still get food poisoned on a monthly basis. I had a humbling half hour near the deadline with the Unity UI system; where was the box that took CSS?

Music and art are notorious time sinks, and one should assume that anything one makes will end up in the final game. Had I truly grokked that notion earlier, perhaps I would have spend five more minutes on this guy.

Know Three: Know Thyself

As a test of polymathy, LD jammers wear many hats over the course of a weekend, and knowing which hat you’re wearing is crucial to fulfilling the related subtasks.

Careful now, I’m going to get all De Bono on you.

The Blue Sky Hat (What Could You Do?)

This is the hat that can get you in trouble, but can also light a fire that will keep you motivated through the weekend. This is the mindset that makes you want this feature, and that one, and how about this? And what if this does this, like in that game and that movie?

This hat really doesn’t care about what any of the other hats think. It’s the T-Rex of the park; it pulls in the punters but can also eat them.

The Design Hat (What Should You Do?)

The design hat is the electric fence to the T-Rex. It is measured and analytical. It is cool and conservative. It is not what is popularly thought of as ‘game design’. It is about reducing complexity, not increasing it. Gawd it sounds like a drag doesn’t it? Well it’s the ying to the Blue Sky’s yang, and without it you end up working on a procedural planet generation system for a day. So heed it well!

The Implementation Hat (What You Actually Do)

The Design Hat may be a downer, but at least it talks to you. The Implementation Hat doesn’t want to be interrupted so no thank-you I wouldn’t like to see whatever thing you were just laughing at. It’s the hat that gives Software Engineers a bad name. It’s the hat the reveals all and every flaw, and is the hat that bears the brunt of that disappointment. It is also the hat that requires the most concentration to wear, and will start to disintegrate as your brain gets tired.

You may have noticed using all of these hats yourself, but perhaps without consciously thinking about it. They are used at both high and low levels; each subtask will contain their own cycle of the hats. Due to the short time limit of Ludum Dare it’ll be difficult to get more than a couple of iterations in for any subtask, but making sure they happen in the correct order can save you from, well, this:

Due to the repeating nature of this process, the implementation of any design needs to be flexible enough so that it can support as many iterations as possible. This could include, or example, exposing your variables so that they’re modifiable in game, or encapsulating your behaviour in such a way so that it can be switched out without having to rewrite any other code.

My greatest error in LD33 was not realising this, which gave birth to a monster. It’s a monster which I’ve heard mentioned and even praised in rapid game development. It is The Prototyping Mindset.

The Prototyping Mindset says that there is no need to even try writing clean, maintainable code, because Hey this is just a prototype and we’re going to throw it away anyway. It is an attempt to avoid ever wearing the Implementation Hat, instead just running with whatever the Design Hat wrote on a napkin.

But design is an iterative process, no matter so irrelevant or hastily made the product. The Implementation Hat already has a rough deal; it doesn’t need The Prototyping Mindset undermining it further. The symptoms of this will slap you when you’re at your lowest. It must have been 2am when I found myself writing this piece of code, possible the worst I’ve ever written.

Remember this is the symptom of a poor implementation, a symptom of The Prototyping Mindset. A greater reverence for the Implementation Hat creates a platform for iteration allowing the hats to be greater than the sum of their parts. It also paves the way for code reuse; no more fear of a repository stopping you from turning that Kitten Meow-generator into its own library.

One last note- it’s OK to go crazy. It’s just one weekend. Better to go full throttle and reflect than to phone it in, or even worse quit, and have nothing to learn. It’s a weekend to disregard your emotions and give it your all.

After all, it’s not like you have a time machine to do it again.

If you’d like to play the game that inspired this write-up,¬†click here!

This article has been cross-posted on DevPact.

[cache: storing page]