The practice of game design is one creating a functioning system that players can explore. I don’t mean explore as in “reveal areas of a map”, but explore as in push the frontiers of their understanding. Players explore a game through the action of decision-making. When you first start to play a game, you understand a certain amount, and that continues outward.
While you are learning (which is hopefully, forever – the best games aren’t solved in a lifetime), you are making decisions; decisions about things which you do not fully understand. And actually, can you really even call something a decision if you do fully understand all the ins and outs of that system? If you already know the optimal move, there is no decision to make. You simply do the optimal thing.
Therefore, decisions – all decisions – really have to have some level of ambiguity (or uncertainty, if you prefer) to them. After a match is over, you can learn something about the system from those moves you made and start to form some rough guidelines for next time. This is what games are all about – it’s what makes them special from other forms of interactive systems.
However, not all ambiguity is equal. There is ambiguity that is carefully crafted and a holistic, natural emergent quality of some systems… and there are some systems that really aren’t all that interesting on their own. So we have quick-fix “sauces” that we can add to a system in a pinch.
The problem is, if you dump a can of sauce over a flavorless dish, you’re gonna taste nothing but sauce.
So let’s say we’re designing some kind of conquest game. A big map, with lots of countries. You and your opponent both have 10 little army men units, and we’re both trying to destroy the other forces. Maybe you simply move your men into a zone to attack units in that zone, and maybe when you attack, you push the enemy forces back and they lose 1 troop.
It’s pretty clear to anyone following along with this example that we do not have enough for a functional game. While it might seem as though we would, what we have now is easily solvable and will probably result in some kind of stalemate / draw. So we need something. Some kind of… sauce that will make this dry husk of a game go down smooth.
In videogames, that “something” has almost always been to place some totally unrelated obstacle between the player and agency itself. Those things are always one or more of the following: Execution, or Output Randomness, Labor, and/or Mass Content. Afterwards, I’ll talk about the dangers of all of these.
Execution: In my above example, you could have a thing where players have to literally flick the bits with their finger into the opposing zones. If they’re able to connect with an enemy piece and stay inside the territory, the enemy is killed. If not, they are killed. This is placing an execution requirement between you and agency. That is to say, the decisions have become ambiguous because you simply don’t know if you’ll be able to do what it is you choose to do.
Since videogames are so heavily influenced by the need to always be fantasy simulators, and thus are generally terrified of being turn-based, putting execution requirements into them is very natural. In fact, making a real time game – something about decisions, but that doesn’t have significant execution elements – is something difficult and must be really focused on on the part of the designer in order to work, otherwise execution can easily take over.
Output Randomness: Output randomness is dice rolls, card draws, or random-number-generations that determine whether or not a player’s action succeeds or fails. This is in contrast to input randomness, which is something like a randomly generated map or random spells that are available for all players or something. This is generally expressed by “to-hit” mechanisms, “critical % chances”, as well as random item finds in something like Super Mario Kart.
This also comes very natural to videogame designers, being that Dungeons & Dragons – a fantasy simulator, through and through – was a huge inspiration for much of the roots of digital gaming. A somewhat crappy, flat combat system can seem more interesting when there’s “to-hit” dice rolls (especially if you can increase them with lots of Labor!) and critical hits.
Labor: Many – if not most single-player videogames of the past 15 years have been very, very heavy on forcing the player to perform hours upon hours of “busy-work”. Grinding against hundreds of no-threat popcorn enemies, running down long corridors, fetch-quests, and collection schemes are just some of the ways that modern videogames stretch a system out, making it feel less like what they are: an application where you press A to win. Games with labor-sauce all over them need to have a great presentation and a massive hype train going, or else people will walk away.
In boardgames, the use of labor is less common (because it’s generally harder to hide), but there are examples of games where a lot of “fiddling” has to happen in between busy-work gameplay, to make it seem more like you’re doing something. Breaking bills in Monopoly has always seemed like that to me.
Mass Content: A lot of people are still under the impression that “a shit-ton of content” is something for a game to be proud of, not embarrassed by. The idea that “more moving parts” is a good thing in a design or plan of any kind is a point of view that only exists in the world of videogame design.
But it’s not just these poor misguided “more is more” people who find a use in massive amounts of content. Mass content, like the other sauces, can seem to make a totally dry, lifeless dish seem appealing. Basically, it’s dependent on trying something for the first time – the element of “surprise”, if you will. It helps even more if there’s a perpetual trickling of content into a system. Magic: The Gathering was built with this in mind, as well as something like World of Warcraft. One wonders how much play these systems would get with a small, tight amount of content.
What’s Wrong with A Little Sauce?
It’s not just that these things are completely expected to be in every new title released. Worse than that is the fact that they’re almost seen by many in the videogame world as “the only way” to create ambiguity. People don’t recognize the significance of utilizing these things.
For example, we were having a discussion recently here on my blog (in the comments), and I mentioned that if you were to make Starcraft turn-based, thus removing the execution element completely, you’d be left with a pretty boring, flat game (similar to, but not as bad as, my theoretical conquest game listed above).
A user by the name of Dasick wrote:
“But if you make SC turn based, it would loose a lot of SC flavour and tension. I think that to properly translate those elements into a turn-based board-game, you’d have to break out the dice.”
You’d have to, would you? What he’s saying there is basically, if you don’t have execution, then you require output randomness. In videogames, many believe that those are the only ways to create ambiguity.
“So what are the specific problems with these sauces?”, you might ask. Well, I’ll tell you!
Execution: execution has a way of swallowing up decision-making and creating needless barriers for players. On one hand, in a game such as an RTS that involves both decision-making (what units to get, where to put them, when to expand) and execution (microing individual units, managing an economy, remembering to press the “build SCV” button every 30 seconds and I mean EVERY 30 seconds), the execution part can often take the lead. I just wrote about this in my last article in detail.
But further, large execution requirements make it so that it’s much more difficult to get to a point of competence/understanding than it has to be. One of the worst offenders are games like Street Fighter or Mortal Kombat, which intentionally make inputs difficult to do as a balance measure. This is a ton of extra information and muscle memory that a player has to get down, just to take his normal actions!
Output Randomness: I talked a lot about this issue in Episode 4 of the Game Design Theory Podcast. Essentially, when you take an action in a game, and there is a dice roll to determine whether or not you’re successful, your agency is being reduced. A system that has this is simply less efficient at giving you feedback for your agency. When you win or lose an individual match, you can never be sure how much of a role you played, and how much of a role randomness played.
Further, it’s information that has nothing to do with the game itself. Whether this die comes up 1 or 6 or anything in between has nothing to do with my skill, nothing to do with the game state and there’s nothing I can do to influence it. It’s noise from outside the system and it can’t possibly be tied in well to the core mechanism of a game (which ideally, everything in a game should be tied into).
Labor: I shouldn’t need to go on at length about this. People don’t generally enjoy busy-work, no-brainers, etc. It’s sort of the definition – the icon of boring. Yes, you can achieve a sense of satisfaction for having done some busy-work – but you can achieve a sense of satisfaction for having done anything whether it’s interesting or not. This is a blatant, callous waste of the player’s time and anyone who employs this in their game designs has my open contempt.
Mass Content: Assuming both get the job done equally well, what’s better: a clock that has four moving parts or one that has 300 moving parts? Elegance/efficiency is a pretty universally agreed upon “good quality” for things to have, and intentionally adding content to a system way beyond the point where it’s necessary flies in the face of that. People need to start thinking of game designs as machines. One faulty, out-of-balance or simply sub-par rule or bit of content can throw an otherwise working machine into disrepair.
The Solution Is Food, Not Sauce
Everyone must become vividly aware that this sauce-method is not the way that we should be operating. You must never think that you’d ever “have” to break out the dice. What you must not do is what most videogame developers (and some boardgame developers, mostly Americans) do, which is:
1. Come up with a theme.
2. Apply it to a generic gameplay model (FPS, 3rd person action, RTS) (for boardgames, usually Roll & Move or Area Control)
3. Grease the wheels with one of the four above mentioned sauces
Instead, you need to make sure that your actual system, itself, is interesting.
Well shit, how do you do that? That’s the hard part. Game design is way, way harder than most people who have been operating under the sauce-method realize. Like I said at the top of the article, it involves creating a system that can be understood, that is coherent, that can be learned, but is near-impossible to solve. High levels of emergent complexity is the name of the game. “Easy to learn, difficult to master” – this is a sign of elegance.
As usual, there’s more to find in the world of boardgames than there is of videogames, but I’ll provide some examples from both.
Super Smash Bros. – Nintendo 64 revolutionary fighting game. Two major attack buttons, that are combined with the directions to make attacks in different directions. There are a decent number of unique attacks, but they’re all intuitive and natural. Everything in this game is tightly woven around the core mechanism of “positioning yourself and your opponent”. Everything emerges out of that concept, cleanly and clearly (at least, with items OFF).
Go – 4,000 year old abstract strategy game. Has a 19×19 grid (somewhat large, but nothing compared to the grid in Starcraft or Civilization!), and black and white stones. Incredibly simple rules that a, during play, expand out into one of the most complex game systems ever known to man. And it all comes out of a simple core mechanism: placing stones to capture territory.
Outwitters – An iOS wargame. Seven unit types, small grid (for videogames anyway), one resource type that’s used for both issuing commands and summoning units. A fog of war system, which is hidden information, provides ambiguity, but it’s not random. Good players can learn to predict where their opponents will be.
All of the above systems start with a core mechanism and then tightly weave supporting mechanisms, balancing them together carefully to create a kick-ass curve of emergent complexity that is interesting, difficult, and ambiguous. All without the use of any sauces.
Why aren’t these “sauce”? Because they’re the meat & potatoes. They are the game – the ambiguity and complexity and uncertainty all is coming directly from the system itself. In go, the great emergent complexity of the board is where the ambiguity comes from. In Outwitters, the hidden (although uncoverable) information of the fog of war does it. In Smash Brothers, it’s the moment-to-moment prediction and reaction of a real-time decision that does it. By the way – this is in contrast to raw execution, which is a matter of “can” rather than a matter of “should”.
This article isn’t a “how-to-design-games” article. It’s more of a how not to design games article, but I just wanted to quickly give a nod to the way that games should be designed. I can’t stand the idea that there’s anyone out there who’s still dumping crappy sauce all over a potential great game idea.
Related – I did a talk at NYU’s 2013 PRACTICE: Game Design in Detail conference where I detailed the matter of “sauces” versus “systems”. I also did a Q&A session afterwards. Watch it here: http://vimeo.com/83682678