Pag on Games

I recently had an idea that could really increase the usefulness of the design docs I write. The problem with design docs is that they become outdated — a few months into a project and the game has already evolved enough to make the design unreliable in parts, no matter how hard you try to keep it up to date.

If the team doesn’t think the design doc is reliable, they’ll stop relying on it and instead do what they think is right. Problem is, everybody has a different idea of what the game should be like. Soon, the project falls into chaos as everybody goes in a different direction. How can we avoid that problem and make the design doc a useful tool in making sure everybody’s pulling in the same direction?

The American army faces the same kind of problem at a much larger scale. Before a battle, detailed plans are carefully laid out. They go from the top of the command chain to the bottom, gaining details along the way. A marvel of large scale communications.

Then the battle starts and the plans fly out the window because the enemy didn’t react as expected, some critical piece of machinery broke down or the weather changed. No plan survives the first encounter with the enemy.

How does the army keep soldiers moving in the same direction in the face of changing conditions? How do soldiers know what they should be doing for the good of the overall battle, even after the detailed plan becomes useless?

The army solves this problem with what is called Commander’s Intent. The plan starts with a short, simple and concrete description of what the core of the plan is for that level of command. It answers in a simple way this question: if only one thing was achieved with this plan, what would it be?

At the highest level, it may read something like this: “To invade this country, take control of its major cities and break the will of the enemies.” At a strategic level, it may be: “To push the opposing army away from this plain and assume control of it.” At the tactical level, it may become: “To remove the enemy from this hill and place our forces on it to protect the western flank of our advancing main force.”

The detailed plan is still needed to make sure everybody is ready of course. But if the shit hits the fan and a single soldier is left from that division, he knows he’d better get on that hill and do something to protect the western flank. Because he knows the commander’s intent, the individual soldier is able to act autonomously in a way that’s useful to the rest of the army.

If that approach works for plans to lead thousands of soldiers against an enemy that’s actively trying to disrupt those plans, it should work when making plans to create a videogame. I figured that to improve my design docs, I should make my Designer’s Intent clear at the beginning of each section by writing a short, simple and concrete goal for that part of the game.

For example, the overall intent for the whole game could read: “A realistic third-person stealth game in which the player controls an individual commando disrupting Nazi operations during World War 2.” The section about the enemies could have the following intent: “To have human enemies that behave as much as possible like real persons, including realistic strengths and limitations.” For the first level it could be broken down to: “To have weak enemies with limited perception to serve as an introduction for the player.” And the description for an individual drunken guard could read: “A drunken guard who’s very inattentive to his environment and who fights very poorly.”

Of course, detailed information is also given at each level of description. But if there’s some problem with that information — the stats given to the drunken guard don’t make sense anymore because of a gameplay change, for example — the person implementing that part can make an appropriate correction autonomously. Everybody can pull in the same direction because everybody knows what direction to pull in.

It’s important that this Designer’s Intent section be short, simple and concrete. A high level intent like “To create the most awesome game ever” may well fit the intentions of the designer, but it doesn’t say anything useful to the team. Likewise for an enemy section reading “To have enemies that are interesting and challenging to the player.” They lack concreteness. The intent should explain the core of that section of the design doc, the one single thing that’s needed to make this part of the design successful.

In hindsight, this seems obvious, but I’ve seen many design docs that give a lot of details but never explain what the intention behind those details is. Those projects often get into trouble as the chaos inherent in games development makes those careful plans fall down. By systematically explaining the intent behind every part of the design doc, I think I can make the design docs I write more efficient at getting the whole team to work together toward a unified goal.