This year, Yomi's Gate was nominated in the South by Southwest Gaming Awards. I'll be showcasing the game at the festival from March 13th through March 15th 2015. Between now and then, I'll be writing a series of articles discussing the game, where it came from, how it was made, and the kinds of challenges I've encountered along the way. This is one of those articles.
Week One: Why Yomi's Gate? - An article about why I'm making this game and not something else.
Week Two: The Shape of Things - Insights into how I go about creating pieces for Yomi's Gate.
Week Three: Making the Map - Words about how I made the map and the prototile, modular board for Yomi's Gate.
Everyone has ideas all the time for all kinds of stuff. Sometimes they're small ideas, like adjustments to things that already exist. Sometimes they're bigger ideas, like when you agree with some overarching concept but would personally execute it differently. They can be highly specific or incredibly vague. Ideas come in many shapes and sizes and it's tough to know the difference between a good idea and a bad idea, so I find it's best to pay attention to all of them and sort it out in retrospect. Sometimes an idea is terrible in one context but wonderful in another.
I talked a little bit about this in Week One, but the general ideas that would become Yomi's Gate came from playing other strategy games. I had a smattering of small ideas that each followed the form of, "I like X, but I would do Y differently." Sometimes that "differently" had a specific meaning, like wanting to resolve unit battles through static rules instead of probabilistic dice-rolling, and sometimes it was just a general feeling of, "not the way it currently is." The important takeaway is that most of my ideas arise from reflection on things I experienced and enjoyed. I think creative individuals are generally going to agree with that sentiment, that ideas are almost always a reflection of things that already exist.
One of the big weaknesses of ideas is that they tend to float away quickly if you don't do something to pin them down. To do this, I keep a file in Evernote called a "Spark File." In it, I write down every idea I can write down. Sometimes they're really short, like, "What if Feudal used a hex grid instead of a square grid?" and sometimes they're long, multi-paragraph concepts for entire games. They aren't even all game ideas. The point is simply to capture ideas quickly, knowing they're going to be forgotten if they're not recorded.
Doing this serves two major purposes:
1. It gives ideas a home, so they still exist when they leave your active thoughts.
Have you ever told yourself, "Oh, I don't need to write that down. I'll just remember it?" Of course you have, right? How many of those thoughts end up forgotten? How many times do you have a great thought in the shower, only to forget about it as soon as you left the bathroom? What about the thoughts you've had during long drives or train rides?
Our brains are efficient machines and they do the best they can to free up space and cognitive power for the things that matter. They're constantly clearing out clutter when we cross an event threshold, such as leaving a room or vehicle. For instance, we need to remember boiling water while we're in the kitchen because it's an immediate physical hazard, but when we leave the kitchen our brains are predisposed to discard that information because it's no longer an immediate threat. That's why timers are so useful: We can hear them from other rooms, allowing information to cross event thresholds for us.
The Spark File is your event threshold protection for ideas. You're going to forget your ideas if you don't write them down, so write them down as soon as possible whenever they happen. That's also why it's important to keep your idea log nearby, so you can write in it without crossing any event thresholds. Evernote works great for this because it syncs across devices.
2. It allows you to make connections between ideas that would have otherwise seemed unrelated.
Have you ever wondered why children come up with so many interesting, bizarre ideas? This is because when you're born, your brain has all kinds of possible connections ready to be tested. As you get older, your brain isn't withering away, but rather chiseling away at the connections that don't work and keeping the ones that do. We reinforce good connections and discard bad ones as we learn how the world works.
So really, the key to being creative is to actively foster interesting connections, isn't it?
When you're making this Spark File, it isn't a broadcast-only document. You need to go back and read through it every once in a while, beginning to end. This can take an hour or two, but an hour or two once a month is nothing for the new connections you're bound to draw. Re-reading a Spark File is a magical opportunity to listen to dozens or hundreds of versions of Past You and soak up all of the ideas they've had.
I am absolutely convinced that the most important aspect of creativity is the ability to connect ideas in interesting ways.
Beyond the Spark File and the connection of ideas, I had only one other guiding principle, which was asking myself, "How do I want the game to feel?" I take my cues on this from one of my favorite game designers, Jenova Chen. In this Polygon interview about Journey, he reveals that his design philosophy is about social games as an "emotional exchange."
In this regard, I wanted Yomi's Gate to be a demanding, brutal experience. I wanted to make a game where when you win, you feel like the ultimate tactician, that you barely wrested victory from an equally powerful opponent. When you lost, I wanted you to feel like you did so only because you missed a tactical opportunity somewhere, that your defeat was earned and that you could overcome it in the future.
I am admittedly not as elegant with my game design as Jenova Chen. Brutality is simple. Empathy is not.
With all of that in mind, Yomi's Gate is not some idea blossomed from the ether. It is the sum of many parts, all haphazardly assembled over time without any forethought as to what they would become. I never sat down and said, "I'm going to make a game and this is what's going to be in it." Instead, I built a growing compilation of small ideas and consistently started thinking, "These ideas go well together," more and more frequently.
Eventually I had enough small ideas that I was able to decide on a guiding principle of player emotion to unite them. I would center my game around combat and that combat would be decided with rules, not dice. I would use hexagons for a map because they simulate world space better than squares and I like hexagons. To keep setup short, players would start with their armies off the board and bring them in over time. To keep turns short, the map would be small and attrition would be high to keep units off the board. I would have to include enough units to give players meaningful choice about what to bring in, but not so many that memorizing them all would be a chore.
Much of this would be refined through lots and lots of playtesting and iteration, but the initial package was akin to a stew. You pick a bunch of stuff that sounds good, throw it together, and see how it turns out. When turning your ideas into reality, "a bunch of stuff that sounds good" is gathered over a long time and many different experiences, "throwing it together" happens when you actively revisit those experiences and observe new connections between them, and "seeing how it turns out" is what happens when you play with those glued-together concepts and see how they unfold with real people.
Next week I'll be talking about how I wrote the instructions for Yomi's Gate, which I'm sure will be an entertaining experience.