Designing Games

Part Three. Process

So far, we’ve looked at the craft of game design. We’ve examined mental models that help us understand how a design is working, and how to change it to make it better. But craft alone isn’t enough to make a good game.

What should a game designer do, day to day, hour by hour? When should we brainstorm, program, debate, or take a break? What should we plan, how far ahead should we plan, and how should we record those plans? What do we communicate, and to whom, and how? And how do we adjust as the team grows from a single person to more than a hundred developers?

If we can’t answer these questions well, all our craft will be worthless because it will be aimed at the wrong problems. We’ll attack problems that don’t exist, make delusional plans based on dreams, build technology we don’t need, and suffer catastrophic communication breakdowns. In the end, our game will be smothered by bureaucracy, anger, and misunderstanding. We will become busy idiots, working hard in the wrong places.

It’s surprisingly hard not to fall into busy idiocy. I’ve done it thousands of times. I’ve become obsessed with a programming challenge and spent days on it, even though the feature involved had almost no impact on the game experience. I’ve created art for something that was almost certain to be cut later. I’ve tested when I should have built, and built when I should have tested. And busy idiocy is also a group activity. I’ve asked for work without making my intent clear, leading someone ...