Emergent game design is one of the hardest, if not the hardest part of game design. Creating mechanics that can lead to new elements or systems is a Holy Grail concept. For today’s post, I want to talk about a very simple philosophy of design, and how it can lead to very big things.
Emergent game design is all about simple mechanics that interact and grow with each other. This kind of design requires a special way of thinking and building your game. You’re not creating explicit mechanics with only one purpose, but creating something with a variety of applications.
This is where the idea of “tools” vs. “keys” comes into play. A tool has a very specific purpose, but a wide set of applications. A key on the other hand has a specific purpose, but a limited application.
The AAA genre is full of games that give you a variety of mechanics, but they are simply keys. The modern Tomb Raider games are guilty of this. The abilities that you pick up for Lara can only be used at specified points in the world and have no other uses.
Games like Factorio, Infinifactory, Minecraft and so on, are built around tools. These games provide you with a variety of mechanics that can be combined in interesting ways. Thinking about what it means to design a tool is a prerequisite for emergent gameplay.
Emergent game design is usually seen in open-ended games due to the wide berth of systems at play. Creating a tool is about designing mechanics with applications and a world that can handle it. The idea is that a mechanic/item has a set function, but it can be applied to multiple elements in the game.
If I have a fire spell in a fantasy game, we can look at the difference of a tool vs. a key. If this was a key, then the fire spell could only be used in combat or to destroy specific things. As a tool, fire could cook food, destroy wooden structures, heat up water to create steam and so on.
In both examples, fire has a specific use, but the potential application is different. How mechanics interact with each other, whether or not explicitly designed, is a major part of designing tools. The evolution of the “rocket jump” in Quake was figured out by combining different elements of the design. ID Software had no idea that their mechanics worked like that, but it was quickly adopted as a part of the game.
Emergent game design is never about just one mechanic, but a collection interacting with each other. In some cases, the designer will integrate some of the possibilities into the game itself. However, in order for it to be seen as emergent by the player, they need to figure things out on their own.
Many AAA titles that try their hand at open world design still lead the player around and tell them what to do in any given situation. Linearity is the enemy of emergent game design, no matter how open the world is.
Emergent Game Design is not locked to real world elements. You can have a game with fantasy or sci-fi elements and still provide the groundwork for emergent design. How your mechanics interact with each other is the important part.
If you’re going to design your game around emergent game play, it’s going to be a part of your design from the very beginning. In some cases like the Quake example, you may not even realize that your game has those options.
Understanding how to treat your mechanics and systems as tools instead of keys is a vital part of creating a gamespace around emergent design.
As a question for you, can you think of other examples of emergent design in linear or non open-ended games; whether by accident or a part of the design?