We had a truly horrible winter in Boston (the worst in recorded history, actually), mostly compacted into the month of February. It seemed like spring would never come, and when I went on vacation last week, the snow was gone but the world was bare.
But I came back from vacation and discovered that the grass had turned green, and all the bare branches had sprouted green buds, and crocuses were pushing up green and purple. I might not have noticed it if I’d been here every day, but since I was gone, the effect was glorious.
And I thought: this reminds me of game dev.
(Okay, everything does. But bear with me.)
For the purposes of this post, I’m thinking about traditional game dev rather than interactive fiction. Interactive fiction is great because (generally speaking) progress is extremely visible. When you can’t go west at the top of the day, and you have three new, fully implemented rooms in that direction at the end, then it’s easy to see what you’ve accomplished.
Traditional game dev is different. To paint with a very broad brush, the heart of traditional game dev is mechanical. There’s no game before the gameplay works, regardless of whether that gameplay revolves around jumping between platforms or dropping tetronimos.
In a situation like this, you can’t start from room one and just keep going. You need rooms – or the equivalent coding structures for your game mechanics. Without those structures, you have a pile of design notes and art and sound, but you don’t have anything that’s recognizable as a game.
Once that initial infrastructure exists, then you can build upward and outward. Once you have the concept of tetronimos, then you can give the player the ability to drop them. Once you have physics in place, then you can give the player the ability to jump.
initial infrastructure (physics engine) –> basic mechanics (player can jump) –> gameplay mechanics (player can jump on enemies to destroy them)
But in the trenches, it’s very hard to see progress – especially in those early gray days, when the snow’s barely melted and there’s no green in sight. You work all day, and at the end, you can maybe push a ball with the arrow keys, even though the final design calls for hundreds of bullets flying through the air as your protagonist avoids them by somersaulting off the walls.
In game dev, you’re both the gardener and the garden. The seeds sprout underground, and the branches put out buds, and little by little, green pushes its way to the surface. A single day’s progress might be invisible – but over time, all those invisible days add up.
This is why I keep a weekly dev log. It’s one of the most powerful motivational tools in my arsenal. No matter how slow my progress may seem on a day-to-day basis, it’s spectacular when viewed a week at a time. I can’t go away on vacation and expect the game to grow itself, but I can take a snapshot at the top of each week and watch the world bloom.
(There are a lot of other lessons you could take from this post, like “never code your own physics library” and “rapid prototyping makes the snow melt faster” and “game jams are like kudzu, in a good way”. But one post at a time!)