Once upon a time, I spent three months writing an IF game called Five Gods Exiled. It was a spectacular failure.
Five Gods Exiled was a Frankensteinian attempt to combine the core mechanics of Arkham Horror with the procedural generation of ZAngband and execute the whole thing in Inform 7, overlaid with an epic science fantasy narrative.
This is one of my favorite failures because I learned so much from working on it. I could probably write ten articles inspired by that game (everything from “Best Practices in Procedurally Generated Landscaping” to “Why I Love Lists And You Should Too”), but the primary reason it never saw daylight was that it wasn’t any fun to play.
It was a whole lot of fun to build. But it wasn’t any fun to play.
You need to know whether or not your vision for a game is fun. If it isn’t fun, then it’s not worth making. (Or, if the goal isn’t “fun” – engaging, or worthwhile, or effective, or whatever you’re aiming for. Not all games are “fun”, but every game design has some goal that equates to “the player will not regret having spent time playing this game.”)
This is not to say that every fun game has its Most Important Fun Part from the beginning. Experimentation is real and valuable. At a Boston Postmortem talk, Joe Mirabello (Tower of Guns developer) mentioned that his game changed dramatically because of a well-received bug in a playtesting build. It does happen!
…but it’s a risk. If you don’t have a plan for “here is what makes my game fun”, or you don’t prototype your Fun Element to make sure it really is fun – then you risk spending X months (or years!) on a game that is, in the end, Not Fun.
This is why formal game development cherishes rapid prototyping. The idea behind rapid prototyping is to create the smallest, fastest version of some element of your game, and then rebuild it and rebuild it until you have a good version. Such as the important element of Why Is This Fun.
When I started working on Five Gods Exiled, I knew about rapid prototyping. I knew about the importance of finding the fun. But what I didn’t know was how to break the game down into components. I saw the game as one complex melange, and I trusted that, if I built the whole thing, it would be fun.
I love making games, and I talk with my friends about my current projects. I wound up trying to explain this project repeatedly (at different stages of development) to one of my friends. It was a two-to-five minute spiel, and every time I finished, she frowned and shook her head. “I don’t understand what you’re trying to do.” “That sounds really confusing.” “What exactly is the player doing?”
Eventually, I would just wave my hands and say, “Look, it’ll be awesome when it’s done.” And that should have been a giant warning sign.
I didn’t have an elevator pitch because I didn’t know where the fun in the game was. I explained the game as a collection of features instead of a single clear vision. I thought that a bunch of good elements had to add up to a good game. And I polished the heck out of that turd.
Now, I should note that not everyone is good at elevator pitches. If you’re bad at elevator pitches, that doesn’t necessarily mean that you have a bad game idea. It may just mean that you’re bad at elevator pitches.
Fast forward to 2014, when I wrote the first draft of a fantasy novel. I knew it was good, but my ability to explain it was very, very bad. Just as bad as my explanation of Five Gods Exiled, in fact (though the overall reception was far more positive).
At Arisia 2015, I had the fortune of a practice pitch session with renowned author NK Jemisin. I had a ten-minute block to pitch my novel and hear her feedback.
I walked in the door. She leaned back in her chair, looked me straight in the eye, and said, “Pitch me your novel.”
I said, “Uh.” Then I rambled for five minutes or so about the main characters, the worldbuilding, the start of the plot, and the themes.
She listened patiently until I trailed off. She asked a few clarifying questions and I scrambled through my answers. She eventually said, “You’re going somewhere good, but you have no hook whatsoever.”
“I know,” I said sheepishly.
“Look. What do you think is the most interesting thing about your novel?”
I told her.
Jemisin said, “Here’s your hook: ‘Finch’s friends and family think she’s dead. They’re probably right.'”
I probably swore (and apologized), but I don’t remember for sure. I just remember how obvious it was once she said it, and how bewildered I was that I hadn’t seen in a year of telling people about my novel. I walked out of that room with my head reeling and two minutes to spare.
Back in the world of game design, Jemisin’s advice still holds true. “What is the most interesting thing about this novel?” equates to “What is the most fun thing about this game?” Having an answer to that question means that you can prune a vague design vision into something concrete, clean, and – most importantly – testable.
If you know which part of your game is supposed to be fun, then you can prototype that aspect without building the rest of the game around it. You can build the fastest possible version, show it to some players, and verify that, yes, This Was Fun. And if you’re wrong, and it isn’t fun, then you can back up and try something else.
Should your answer be “The environment is procedurally generated” – which was, inevitably, my answer for Five Gods Exiled – then you have a problem. That answer belongs to a tech demo, not a game. I don’t regret those three months (I still steal tech from it, after all!) but I wouldn’t choose to repeat them. Writing elevator pitches for my games, even just in my notes, ensures I won’t do so.
Thank you to everyone supporting Sibyl Moon through Patreon!
If this post was interesting, useful, or entertaining, please consider becoming a patron.