Another great dissertation from Mark Brown of Game Maker’s Toolkit: “The Games that Designed Themselves”. It’s the radical idea that designers should ignore their preconceived notions and look to the game itself to find out where the development should lead. How does something design itself? Well… the answer is: Prototypes.
A lot of great indie game masterpieces are the result of experimentation and early gameplay demos that changed the course of game’s development. As Brown points out, there’s a whole history of groundbreaking games that were developed “almost by accident” where bugs and glitches were turned into features. Seth Coster, Co-founder of Butterscotch Shenanigans, explains:
We like to think about this process as the game discovering itself over time. Because as iterators, rather than designers, it’s our job to simply play the game, listen to it, feel it, and kind of feel out what it seems to want to become - and just follow the trails of what’s fun.
— Seth Coster, “Crashlands: Design by Chaos” (GDC 2018)
I love that phrase “as iterators”. Not as game designers or as game developers, though they very much are that role, they choose the moniker “iterators”. Accepting that any idea is rarely consumer ready and monetizable the first time around, they embrace the iterative nature of product design. They commit to building demo after demo of their idea, gathering feedback along the way. The process outlined by Brown works like this:
- Take an initial idea, however loose or fuzzy
- Build a working prototype
- Allow new ideas to spring up while coding and playing
Interestingly the designer’s role shifts a bit from creative overlord to active listener. They must be attentive to what the game (via play testers) is “saying”. They must be willing to explore those more interesting aspects, abandoning bad ideas and letting go of their initial ideas along the way. I love this methodology and it’s not dissimilar to how we build websites at Paravel, iterating and oversharing our works-in-progress in Slack.
The whole process hinges on the ability to do demos. Observing people in an attempt to identify friction points and gather candid feedback. You can fail dozens of times privately or semi-privately before exposing yourself or your company to public humiliation or condemnation. One idea that I find super fascinating from Creativity, Inc. (and is used by Pixar) was the idea of a “Brain Trust”; 12 or so experienced people who can give candid feedback on an idea. A “board” of proven creative problem solvers, but not made up of solely executives. Importantly, the Brain Trust doesn’t try to solve the problem, they leave that up to the director.
You can see this process emulated in a lot of other creative endeavors. A “Brain Trust” is maybe not a new idea, it’s maybe as old as time echoing historical forms of governance and wisdom-seeking like a tribal council. Your council maybe friends in a Discord or people you know from a meetup. I recently started experimenting with this on my side projects and got some great feedback. It requires a certain level of trust starting out, so don’t throw your pearls to swine by tweeting things to randos on Twitter.
Curiously, this demo-to-demo process is similar to the process found in Creative Selection by Ken Kocienda, which chronicles the creation of Webkit/Safari, the iPhone, and the iPad. These products have defined a generation, and getting a glimpse at how they were created is insightful. Apple were probably overly heavy on the secrecy element, but the process remains the same: Prototype, demo, repeat. Reduce the friction. Fail fast. Follow the fun.