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?
-
-
Show this thread
-
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.
Show this thread -
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.
Show this thread -
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.
Show this thread -
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.
Show this thread -
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.
Show this thread -
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*.
Show this thread -
Imagine having to paint a picture blind and wait a year before you can look at it and see if you painted it correctly.
Show this thread -
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'.
Show this thread -
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.
Show this thread -
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.
Show this thread -
I don't know of a perfect fix for any of this, but we have some tools.
Show this thread -
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.
Show this thread -
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.
Show this thread -
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.
Show this thread -
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.
Show this thread -
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.
Show this thread -
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.
Show this thread -
So unlike writing or painting, the meta of game design is painstakingly building a process where you can iterate as quickly as possible, while making as few changes as possible, while still enabling big change to be feasible late in the process.
Show this thread
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
