First off, I acknowledge that this is the wrong question to ask. The better question is: “How can I determine how many mechanics my game should have?” This essay gives my own opinion on that question.
However, just so we’re all on the same page, this is the definition of “game mechanic” I’m thinking of. It’s a little bit ineffable, as game systems often have a fractal quality about them — you can go up or down in level of detail and think of features at that scale as game mechanics also. That complicates things a bit, but we’ll have to muddle through.
In my humble opinion, the answer to “how many mechanics should my game have?” is usually “less than half of the number you’re imagining right now.”
I think there are a lot of reasons people assume games need to have way more mechanics than they really do. The first is the pesky real world. IRL is awash with verbs and their consequences. The number of things a human being can do is enormous and keeps growing. If the player’s avatar is a human being, you might think that it will break player expectations to limit them too much. “If players see an apple and they can’t pick it up and eat it, it will break their immersion!” you might say to yourself. The truth is that players will start by exploring the limits of their capabilities, exposing those differences from the real world no matter what they are. (Also, at that point you might think about just removing the apple). If the game holds their attention long enough, the players will grow accustomed to the conventions of this virtual world, and immersion won’t truly be broken unless those conventions are.
The second reason people think they need a lot of game mechanics is because AAA games have tons of game mechanics. I just played “Deus Ex: Mankind Divided,” and that game included stealth, cover-based shooting, a huge tech tree, crafting, branching dialogue and narrative choices, money and merchants, exploration, and probably a few more huge systems I’m failing to recall.
Oh yeah, inventory management.
How can these games get away with having SO MANY mechanics? First of all, I’m not sure they do. I tend to find AAA games a bit bloated. That aside, there are a few reasons. First, they’re super long. Every good game mechanic must be taught to the player in isolation, then mastered, then used in combinations with the others, etc. All of that takes time that smaller games don’t have. But 40+ hours is a lot of time to get the player up to speed with a gaggle of mechanics and let them explore some of the consequences of them.
The second way they get away with having so much stuff is that so many things are already so familiar to their audience. To play these games at all, you have to have made a sizable investment in gaming, and thus have most likely played other games before. By making mechanics that are similar to ones players have already seen, designers can skip a certain level of player reeducation.
Let’s look at a game on the opposite end of the spectrum. Super Mario Brothers. The game is about Jumping. You can run, but jumping is what gets things done. You use it to get over gaps, to avoid enemies, to stomp enemies, to break blocks, to get power-ups…The game really explores the consequences of jumping, and as Steve Swink has often pointed out, they made jumping feel really good. What other mechanics are there? There’s mushrooms, which make Mario bigger and essentially give him an extra life. Mushrooms and Jumping both have multiple functions, and can even be undesirable in certain circumstances. And there’s the fire flower (which you can use while jumping). That’s all there is for the first two entire amazing Mario games. This should be proof enough that adding more mechanics is not the best way to add depth and complexity to your game.
How can they get away with having so few mechanics? The answer is dynamics. Each mechanic serves several functions depending on the circumstance, and all of them combine with one another for interesting effects. By crafting circumstances that call for different combinations of mechanics in different sequences, there is effectively no limit to the number of interesting situations you can create. The tricky part is creating mechanics that are open to that kind of combinatorial richness.
It’s my opinion that, process-wise, really the only way to proceed is to build up mechanics. It’s borderline impossible to pare away mechanics and rest assured that the ones that remain are the right ones. It’s better at that point to start from a single core mechanic and work back up from there. So, how to build up mechanics?
An idea for a game, at minimum, is a mechanic and a feeling. It’s an answer to the questions “What should the player do?” and “How should they feel while they’re doing it?” If the mechanic is new, that might be enough. If the feeling is unique, that might be enough. If there are constraints on the playtime and/or your development time, that might be enough. If, at any point in building a set of mechanics, you feel like it might be enough, stop there.
If the main mechanic is something the player might have seen before, or the playtime allows it, you could consider adding another supporting mechanic. This is your opportunity to add some combinatorial richness. The second mechanic you add should be consistent with the feeling you’re trying to create. It should serve more than one purpose. It should also combine with the first mechanic in an interesting way. If possible, set it up so the player can do both simultaneously, or at least trigger one before the effects of the other have worn off.
It’s difficult to speak in generalities like this, so let’s talk about a concrete example. One of my favorite mobile games, “Jetpack Joyride.” It’s a free-to-play one-button infinite scrolling game. The game includes some mechanics designed explicitly to support the free-to-play-ness, but I’ll just talk about the core gameplay for now.
Their first mechanic is to use the control scheme (hold the screen to generate a steady upward acceleration) to avoid obstacles and collect coins (two goals that are often at odds). The title of the game is “Jetpack Joyride,” so we can assume the designers were trying to achieve a feeling of exhilaration and fun (with a bit of transgression thrown in).
Periodically, the player encounters tiles which grant the player a random vehicle power-up. The power-ups, in Mario style, also afford the player an extra life; when the vehicle is destroyed, the player goes back to the jetpack. The placement of the powerups in the environment creates a risk/reward scenario — the tile might be too close to an obstacle, or it might distract the player from an incoming missile. Once captured, the powerup gives the player a new control scheme depending on which vehicle was chosen at random. For example, the Dragon reverses the control scheme entirely — now you must press and hold to accelerate downwards. So, powerups serve three additional functions: Extra Life, Risk/Reward, and Control Scheme Novelty.
The Dragon Powerup.
To this they added an achievement system. In most games I think of achievement systems as very superfluous to the main experience, but in Jetpack Joyride the achievements add another dimension. Early achievements act almost as tutorial — coaxing the player to a certain level of mastery. After a certain point, the achievements create new modes of play, prompting the player to perform dangerous maneuvers like flying close to missiles, or totally reversing the goal of the game by telling the player to intentionally die at a particular distance. The achievements refer back to every mechanic that was previously established (Avoiding Obstacles, Collecting Coins, Getting Vehicles) supporting and giving them extra motivation.
There’s a lot more I could say about “Jetpack Joyride” but you can already see how these mechanics each serve several functions on their own, and all combine together in interesting ways.
The designers could easily have failed to take advantage of the inherent opportunities of their mechanics by separating out the functions of each. For instance, they could have had hearts in the level which gave the player an extra life, and removed that functionality from the Vehicle powerups, but it was far more elegant and more intuitive to combine them. They also could have failed to create the combinatorial effects amongst mechanics, for instance by making the achievements relate only to distance or coins gathered, rather than using them to alter gameplay or to explicitly support the use of powerups.
I hope I’ve convinced you of a few things. First, and most important: If your game isn’t fun yet, adding more game mechanics is not the answer. Second, there is a definite method to how one adds game mechanics. Start from one (ideally you should actually implement and play it before designing any more) and work up, always keeping in mind a few things: 1. The feeling you’re trying to create. 2. How the new mechanic can serve several functions 3. How this new mechanic combines with the previous ones to create interesting consequences, and 4. Do you really need to add another mechanic at all? Not only does this methodology produce better, more coherent games, it also allows you as a developer to tightly control the scope.
The only resistance to following this advice might come from people in marketing. They might argue that a few interesting mechanics does not make for as many bullet points on the box as a lot of uninteresting ones. It’s hard to say they’re wrong, given Will Wright’s assertion that the game experience really begins when they see or hear about the game and start imagining in their mind what it will be like to play. Perhaps it’s a matter of better communicating dynamics. This is something I don’t yet have a good answer for, and would love to hear your opinion in the comments.
~~
Rob Lockhart is Creative Director of Important Little Games and a Senior Designer at Phosphor Game Studios. You can follow him on twitter.