Risk mitigation is important for game designers. When you have an idea for your game, you have to be able to look at it critically and call on your past experience and knowledge to answer: is this really going to be fun? Does it make sense as a part of the game we’re making? Is it going to be more frustrating than enjoyable? Do we have the resources to make it work well? It’s important for any designer to be able to do this.
However, there can come a point when the pendulum swings too far, and a theoretical problem with an idea might start eating up your time more than it should. Have you ever been in a meeting where you’re talking about, say, a weapon idea, and you start analyzing the potential problems with it and get caught up on a particular detail? You debate and debate and debate about if something will be fun or frustrating or overpowered or useless in the context of other weapons, etc. Then, maybe later on when the thing actually gets implemented and tested, you find out that the theoretical problem you were so worried about doesn’t actually ever come into play.
Symptoms of Theoretical Road Blocks
If you can recognize when risk mitigation starts to turn into a theoretical road block that might not even apply in practice, and take steps to circumvent spending too much time in debate, then you can save a lot of energy for everyone involved. Here are a few symptoms that let me know when I may have hit a theoretical road block:
- The debate starts to go in circles: 2 people have valid points that are counter to one another, and proposed “what if” situations seem to keep steering the discussion back and forth between the two
- People start worrying about really specific situations, as though looking at the idea in a clinical box and not in the context of how things really tend to play out in the game
- Most of the time, these road blocks show up early in the process, when ideas are still fresh and new and maybe things aren’t implemented in your game in such a way yet that you have a realistic feel for how it’s going to play out.
This is a tricky problem that shows up often but is difficult to grasp. I’m going to give a couple of examples of some theoretical problems that showed up for me in the production of Resistance 3, threatened to eat up a lot of mental time and energy, and which ended up not being problems at all.
Example 1 – Breaking the Ice
For my examples, let’s re-visit our old friend, the boat level of Resistance 3 (sorry guys, but until the game actually comes out, the boat level is all you get! Hooray for demos!). From the get-go, my lead gave me the goal of “selling the world” with the level, and one big story effect for the game is how the Chimera are cooling the entire planet. I thought, “Hmm, it’s colder than usual, and we’re on the water, so there’d probably be some ice. Hey, it’d be kinda cool if the boat got snagged on some ice and you could shoot it to break it up and free the boat more quickly.”
Since I was still pretty new as a designer, and had no deep understanding of how our destructible system worked, I went around to my team to see if the idea was even feasible. First I went to my pod’s environment artist, who had made breakable things in the past, and he seemed to think it was doable, so then we went to a programmer and asked him if he foresaw anything that could be tricky with the idea, and so on and so forth, until we got to the engine programmer who was responsible for wrangling the physics.
Now, he thought the idea was perfectly doable, but was concerned because it seemed very unrealistic. Afterall, if ice was thick enough that a boat could actually run aground on it and get stuck, then there’s no way that shooting at it with a gun would break it up into big pieces, the bullets would just chip off. My pod started coming up with counter-arguments, and the discussion went something like this:
“Well they’re alien weapons, so they’re more powerful and would break the ice,”
“What about the human weapons?”
“Maybe only certain weapons could break it”
“I just don’t think it’s realistic, players will think it’s dumb…”
etc.
At this point, I could see us falling into a rut. The theoretical problem was that the situation was unrealistic, thus players wouldn’t like it, and that’s what everyone was focused on. We could have spent the whole week arguing over how to make it realistic or whether the realism mattered, and never gotten around to trying it out to see if it was even fun to do. My gut instinct said that players probably wouldn’t care about the realism if it meant they got to break stuff, and I probably could have brandished my designer stick and said “just do it!” but it was important to me that the pod was on board with the idea before moving ahead with it, so this is what I did instead.
My personal fun filter is extremely broad. Here's how I spent my time in Ravenholm in Half-Life 2
I proposed that they give me two days to whip together a prototype and test it with people around the office to see if the majority really did think it was too unbelievable, and then we could resume the discussion to solve the realism problem if so. Otherwise, if that issue wasn’t really even a problem, we could move ahead with it. This did several helpful things:
- It let everyone else on the team detach themselves from the debate and focus on other things while the experiment was being run, freeing up brain cycles all around.
- It gave me a chance to see if the interaction would be something fun and worth adding (I have a very broad personal filter for things that are fun, so I can never assume “I think this is fun, everyone else will too!”)
- It gathered data about the “it’s-not-realistic” theoretical problem, which helped convince the person who was worried about it more than me just saying “trust me, it’ll be fine”
My prototype. At the time I didn't have a way to get a callback if the player shot the temp ice, so I used an enemy, and when they were killed, I "broke the ice" by having the pieces slide away along paths.
One hacktastic prototype later, I started grabbing random folks to test out the whole ice-shooting bit. I made sure to get a variety of brain types to test it, just in case (artists, programmers, HR folks, etc). After they played, I asked them a few questions, including “Did anything about that seem weird?” My first few players answered that it was weird that the boat driver just rammed into some ice in the middle of wide open water. Oft times a big confusing thing can hide a small confusing thing, so I adjusted the prototype to make it clear that the boat driver was trying to get through a very narrow space surrounded by ice, but mis-estimated and got stuck. That seemed to eliminate the big confusing thing.
As I suspected, most players didn’t think there was anything weird about it, and many thought it was fun to break up the ice and free the boat. When prodded specifically about whether shooting the ice with a gun would really break it, most players were like “sure!” and at least one was like “of course, that’s very realistic.”
At least one player did say “well, breaking that big piece of ice by shooting it isn’t very realistic, but it’s a game so I don’t really care. Plus, it’s fun to break stuff.”
In the end, I presented my findings to the group, and everyone agreed that the problem we’d been debating ended up not really being a big deal, and we forged ahead with making the breakable ice. Meanwhile, since I had the prototype made already, I was ready to immediately incorporate it into the design of the level that very day. So many birds were killed with a single stone!
The flat ice floes ended up being frustrating for players to see over the edge of the boat, so we changed it to a column of ice. This probably makes even less sense, realistically! Playtesters have yet to complain.
Example 2 – Boat
My next example is not a debate that came up among my team, but a road block that I ended up creating for myself.
Simplest gameplay space ever? Play felt best when the blue area was the front deck and not the back deck.
In pre-production, I was experimenting with the gameplay space of the boat itself. I was looking up lots of different boat references, mocking up rough models, and then getting them in game to run around on them and see how things felt. Early on, I discovered that when the cabin of the boat was up in the front, it felt in the way, like you couldn’t see where you were going. It felt much nicer when the cabin was in the back, making a pillar of cover and leaving the front deck pretty open so you could see out ahead what was coming next.
My little cabin-in-the-back boat felt very “right” and boatlike to me, but I ran into trouble when I started looking for real-life boats that were built that way. The long and short of it was, they don’t really make boats like that, at least not the sort of boat we were looking for, thematically. I was baffled, I felt like I was SURE I’d seen some image somewhere of a boat with an open front deck and the cabin in the back, but search after search was fruitless.
I started to get really worried. If that wasn’t a realistic way for a boat to look, then I couldn’t just force it. Would I have to figure out a way to make a gameplay space with the cabin up front? But no, it didn’t feel right. I wasted a lot of time fretting over the problem that the layout of the boat that I needed wasn’t realistic. I relayed my woes to my team, and I’m not sure who (possibly my lead) suggested that I go to the concept artists for help.
I presented the problem to one of the concept artists: I need a layout with the cabin in the back like this, but real boats don’t look like that, halp!! The artist assured me not to worry, took my little designer mock-up off, and within the DAY came back to me with an initial sketch of a cabin-in-the-back boat that, well, looked exactly like a real boat!
It was like sorcery!**
I probably could have saved myself a lot of time and energy if I’d gone straight to the artists upon realizing my predicament, and in the future I will know to do just that! In the end, all of the playtesters immediately recognized “this is a boat!” Although I’m sure that if Captain Boaty McBoatswain plays our game, he’ll say “there is no boat that exists that looks like this,” but for the majority of players, it looks enough like a real boat to satisfy their sense of place.
** My artist figured out the existence of the “fishing trawler,” which was probably what I was seeing in my brain at some point.
How my "giant coffin with a concession stand on top" was transformed into a boat by the artists (sans about a billion iterations in between)
Conclusion
Now, both of these examples had similar problems that were tripping us up. That being, “sometimes things don’t have to be as realistic as we think they do in a realistically rendered game.” But that’s not the real moral of this post! Road blocks don’t always have to do with realism, they can be about how something might be too over/underpowered, or whether players will be inclined to game the system using a particular feature, or if players will not be inclined to do something because of another game element.
The moral is, sometimes an idea can seem to have a big problem, in theory. But often when you look at the same idea in practice, the problem may end up being no problem at all. The trick is learning at what point trying something out will end up saving you more time than debating about it. Afterall, if you made a prototype for every point in every debate on every idea, it would definitely not be efficient.
Possibly some mathematical formula can be used to decide when you’re going to save time by forging ahead with a prototype over continuing the discussion, but if so, I do not know what it is. In the meantime, watch for the symptoms of theoretical road blocks and use your best judgement!