99.9% of the time, the first version of anything is usually shit. Did da Vinci’s ‘Mona Lisa’ spring complete from his brush in one breezy afternoon? Umm, yeah, no. Success comes from trying something, assessing what you’ve done, measuring the distance between what you have and what you want, and making the right choices to move you closer to your goal. The challenge is that this process can take a while. Depending on what you’re making, it can take a really long time. So much so, it’s easy to give up before you’re done. Seth Godin calls this “The Dip”. Creating something great takes tenacity more than brilliance. It’s just a lot of work.
Coming from a tech development background, one tool I’ve found that translates well to other arenas of life is Iterative Development. Iterative development states that it’s critical to get your product to a workable state, and from that state, start progressively improving it over time. This is particularly helpful when it’s difficult to know how your product functions without user input. People have a hard time giving feedback on an idea instead of a thing.
This working method is incredibly useful in game development. It’s hard to know if mechanics work, if emotional engagement is there, if the game is even fun… if you can’t actually play it. The key here is to find the minimal viable product (MVP) – how little effort can you expend before you can start testing your ideas? The less you build before you test saves time; you’re not building things that will eventually go in the trash. It’s been said many times before, but I’ll repeat it here: the key to success is failing quickly. Get all the bad ideas out of the way. Or as I like to call it, getting on the fast train outta Shitsville.
Get all the bad ideas out of the way. Or as I like to call it, getting on the fast train outta Shitsville.
You can increase your chances of success by failing faster. By lowering the investment to get bad ideas out of the way, it’s easier to surface the good ones. You’re less likely to waste time following tangents and pursuing useless features. You’ll more quickly learn which bits are actually important and which don’t make the game better. Or even worse, which bits make the game unnecessarily long, more complicated, or less accessible.
Back in the early days of my career I frequently said the phrase “Don’t kill my babies!” By this I meant, don’t judge an initial design as a final product; recognize that it is the foundation upon which the final product will be built and give feedback accordingly. Now I realize that I shouldn’t have shared products before they were minimally viable; once they were, the feedback I received would be useful. It’s important to share your project as soon as they’re viable, and protect them until then.
Ok, what’s minimally viable?
Different creative ventures have different standards upon what is deemed minimally viable. And you should keep in mind the specific questions you’re trying to answer. A certain stage of development can viable to answer one type of question but unsuitable for another. For example, while making Masterwork, a very early prototype was sufficient to validate that the game mechanics would work. But that same prototype was unable to answer questions like, “Does the pacing feel right? Is the turn length sufficiently short that I don’t have to give non-active player something to do? Is the deck size balanced for the correct card probability?” Those questions got answered in later versions… when the game got to the MVP state necessary to answer those questions.
The process is to playtest, take in feedback, make changes, and produce another prototype as quickly as possible and test again. Masterwork had eight versions before final. That’s seven structural and visual prototypes that were produced, tested, and ultimately discarded. Certainly a lot, but probably not as many as there could have been if I hadn’t iterated quickly and early.
In a future post, I’ll describe some of the tricks I learned to help makes prototypes quickly. I am by no means an expert at this but I’m getting better and I feel these are important tools for every game maker to learn. You can’t just create it whole in your brain – you have to put it in front of players as much as possible and measure feedback and iterate. That’s how you take the fast train out of Shitsville.