Daniel Cook

Sometimes they are wrong by a little. Sometimes by a lot. Is it poor planning? Are they morons? An expert painter does not produce a completely broken picture 80% of the time. Why is this so hard?

I lay a lot of blame on the much larger gap between authoring a thing, experiencing the thing and revising. - Many types of media (like drawing or painting) allow for real-time 'self-playtesting' with the author as the playtester. - Game design does not.

When I draw, I am constantly engaged in a tight real-time iteration loop of authoring marks, viewing the marks, reacting to the experience as a viewer and adjusting the next steps. There are 1000s (often tens of 1000s) of feedback iterations.

Same goes for writing. There are larger editing passes that occur at lower frequencies, but even within those passes, I'm in a real-time create-experience-revise loop. The first draft is really the 5000th draft of the 'self-playtesting' process.

Now, when writing and drawing, I can't predict *exactly* how someone-who-is-not-me will react. Death of the Author and all that. But an experienced artist and writer can often get within the ballpark for a familiar target audience. Sad scenes are sad. Happy pictures are happy.

Contrast that with games. :) Some issues where the create-experience-revise loop breaks down. 1. Much longer iteration times. If I'm lucky it takes minutes to make localized changes and test them out. More typically it takes longer.

2. Due to interdependencies some changes can't be fully experienced by the player until months later when all systems are fully in place. I just worked on a game where it took 1.5 years before we were able to test the basic flow and balance. This is *common*.

Imagine having to paint a picture blind and wait a year before you can look at it and see if you painted it correctly.

3. Game developers often are corrupted playtesters. Many games involve mastery and knowledge. The designer, due to knowing what they know, becomes blind to issues new players will face. Empathy only goes so far, even when designers roleplay the 'new player'.

4. Other systems (social systems, emergent complexity, proc gen, randomness, exponentials) are just hard to mentally visualize. We can plan them out, but the experience of playing them is often (deliberately) a surprise.

There is no accurate 'self-playtesting' for these systems. A game designer's has limited ability 'play the game in their head' and so real (slow) playtesting is required.

I don't know of a perfect fix for any of this, but we have some tools.

A. Sketches: Movie makers (who also have extended pipelines) create low fidelity animatics that get to viewing the experience faster and cheaper. Game developers create prototypes that serve a similar role. It doesn't work perfectly for all systems, but better is than nothing.

B. Genre expertise: Teams keep rebuilding games in the same genre over and over again. It might take years, but eventually you get to those 10,000 iterations. In large part, this is how expert designers even get up to that not-so-respectable 20% rate.

C. Community playtests: A large population of players + live development (early access, games-as-service) maximizes playtest feedback. Richer feedback can help counterbalance the slow iteration.

D. Content systems friendly to late-stage fixes: If you know that you are almost always going to be making big changes due to late feedback, you can build flexible pipelines that are easy to refactor.

A proc gen system that creates 1000 levels constructed from modular components and centralized formulas is easier to tweak than 1000 handmade levels. Neither change is safe right before release, but at least the former is feasible.

E. Planning up front. There's room for more waterfall style approaches. Particularly if you are reusing code, tools and have an experienced team. It works for things you know that you know. But this is surprisingly limited in other areas that comprise the bulk of game design.