Emergent gameplay is a hot topic for game designers. It is the dream-like concept of every mechanic compounding on the next, in new ways that we don't intend. At least that's one of the definitions of it.
One of the reasons this topic is borderline controversial, is because people have various interpretations of what makes emergent gameplay. Some believe it's a way to use mechanics that you didn't intend of, others see it as mechanics compounding on each other, and others just see it as general creativity within the sandbox of video games.
To simplify this blog, we're going to be looking at numerous types of emergent gameplay in video games, and then we'll discuss how to design for it.
MINECRAFT
Minecraft's emergent gameplay has it's own caveats. It's technically a sandbox game, and players are always placing and removing blocks. It could be argued that since the shapes players construct is simply one additional dimension to the mechanic, it doesn't add anything too unexpected. The game thrived as a creative medium in which players could design games within it. This is something I enjoyed doing too, and you can see it within the content of thousands of YouTube Minecraft players. Things like Skybox, Hunger Games maps and the plethora of modded communities means Minecraft has a range of fabricated context.
If you're looking to create a game with the scaling potential of Minecraft, you need to ask what the evolution of this potential is. What would it take for players to get so infinitely engrossed. Alas, that question has spawned many voxel-based survival games in various settings, but I don't think changing the context is the answer. Players are now looking for a different type of freedom.
Minecraft has it's visually creative cubes. But it also has redstone. And alas, here is where you can easily create an element of emergence. Once Minecraft's cube logic was established, adding a programmatic language like redstone meant that with just a few sets of rules, players can create contraptions that play on the core mechanic. This is why we see people building basic computers and calculators and all that. I almost wouldn't count this as emergent, personally. If you wanted to make something like that, you're creating an interface for basic computing logic. There's not really a genre-defining innovation going on here.
SUPER SMASH BROS. MELEE
Nintendo at one point I'm sure hated the Melee fan base. An entire culture of gamers who clung to their game because glitches gave the game a competitive edge. Melee is a fighting game, where the objective is to knock opponents out of the level. What was meant to be a casual family game, became a twitch-reflex, hardware and game region specific entanglement of fingers around the Gamecube controller.
This fits into the category of game mechanics that the developers didn't anticipate, but their system allowed for it. It rose from a glitch, but I count it because of its mythos. Players figured out if you jumped, air-dodged back into the ground immediately and flicked the joystick you could slide backwards and forwards (wave-dashing). AND, during this sliding motion you could still input attacks. This completely changed the play-style of the game. It's like watching Muhammad Ali turned up to 11, characters were sliding, doing frame-perfect attacks and made the game look like it was playing at 2x speed.
How do you design for this? You don't really. But you get the choice of whether to embrace it when it happens, or to fight it. Nintendo had an intended audience and made their choice with future titles.
ABSOLVER
Open-world martial arts fighting game by Slocap. The game has you enter a world with other players, and you fight enemies, complete quests, learn moves by fighting others who know the move, and go on with your experience.
This game features an amazing potential to bank in on what we'll call viral emergence. Since you can't just learn a move, and the developers control how rare a move begins, you can create some really interesting social structures. As an example, the game had a degrading slap you could perform. To begin with, only a rare NPC could teach it to players, but since you can learn moves from other players, the move could spread. This spawned a school of martial arts experts who would perma-slap, or finish you off disgracefully. The key part of this is the social interaction that happened. Those who know rare moves are sought after. Naturally this wanes when everybody learns it, but it's a fascinating example of a social structure spreading virally throughout a game's community.
This example fits perfectly within the realm of the game, and I'm sure was the developer's intention with having players organically interact with each other. As a developer, you can control supply, gauge demand and let players do the rest in these multiplayer scenarios. This is something you CAN design for.
THE LEGEND OF ZELDA: BREATH OF THE WILD
One of this year's hottest titles for Nintendo Switch, the game takes our hero of time into an open-world. Much can be said about this game and it's approach to design, but we're only going to focus on how it treats emergence. Mechanics, features and properties that affect each other. BotW builds its world with various elements, including weather, temperature, wind, fire, water, ice and many more.
These mechanics are very hard-coded into the game. And when as a player you create a fire, that you then use to lift your glider into the sky, it's debatable as to whether or not that was an emergent feature. I like to believe that it is, because if we keep saying things aren't emergent there's never a point in talking about it. Again, as with many other features it's all about the player's experience. As designers, when players encounter compounding mechanics like this, we should make them feel smart. Because you've essentially presented the player with a puzzle, they've figured out what ultimately needs to be done to solve it, but then they build the answer themselves. That's a huge feat. That's something we should always celebrate, because it's almost like a free win for us as developers.
Nintendo does this with Breath of the Wild, though they treat it a bit more casually than the dream scenario would have. For example, the game gives you obvious clues about using large fires to lift yourself. The dream emergent design would have the game's stasis ability, freeze an area, you use a Korok leaf to build up massive wind power in that stasis zone. Then you dash into the zone whilst pulling your glider out, and getting ejected forward through the air.
If I described this to the team on BotW, it'd probably be a fair bit of work, because their system may not work quite so conveniently. If you're designing for this type of emergence, though, that's something you may need to think about when creating these foundation features.
A TOWNSHIP TALE
This is the quick self-plug moment. I'm not going to go into all of it, but I'll describe the nature of my design on the game and emergence. Simply put, as we build a persistent, physical world, the natural emergent thinking of players comes straight through. Kids in a play-ground will find things to do, give them enough time, and they might decide on a larger goal. So on and so forth. I'm currently exploring emergent development, where essentially I push the bounds on our game's systems to see if I can create fun outcomes.
At some point we'll do an actual blog post on the game's emergent features an approach to design, but I get the feeling the team will want to save that for the website.
HOW TO DESIGN FOR IT
Hopefully you can figure out what I think are some of the more distinct ways games try to be emergent. When you're laying out your feature set, mash them together to see if that can work. And then make it work, it'll take a combination of the types shown by the examples above because different features accommodate different forms. Being able to classify which type you want to target, means you can better know when you've succeeded. Although all of this brings about the question of balance, if I can combine everything, does that make it OP? Like all balance things, test and keep testing. Don't get bogged down thinking about how it's going to get balanced, just make it, and then solve the balance problem later.