Process - Designing Games - page 269

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 misunder-
standing. 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 thou-
sands 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 else to waste their
time on the wrong problem. I've called unnecessary meetings and missed
essential ones. I've argued when I should have acquiesced, and acquiesced
when I should have argued. I've overcommunicated, undercommunicated,
and miscommunicated.
269