 As a developer, you probably heard about design patterns, right, such as the single top pattern or the commit pattern. But as a game designer, had you ever heard about arms race or dynamic engines? When we design games, we face very common problems, even between genres, such as how can we limit players' actions or how can we keep the game challenging players as they progress? Well, it turns out that Ernest Adams, a game designer, has collected some solutions that other game designers usually use to solve these problems and created a diagram language called machinations to visually express these solutions. The idea behind machinations is that we can abstract game mechanisms as the flow of resources, so as an economy. So we have sources that inject resources into the economy or into a system, we have drains that take out or remove resources from this economy, we have pools that hold these resources, and we have connections that show the flow of these resources. Machinations are a very powerful tool to analyze how game systems interact with each other, so it requires a bit of practice so you can abstract and understand game systems as machinations diagrams. So leave a comment below if you want a series or more content about machinations diagrams, so I know that there are demands for that kind of content. But with what I showed you already, you'll be able to understand the four game design patterns that you are going to see in this video. An engine is a type of mechanism that creates resources for other mechanisms to use. For instance, players may use mana to cast spells, so there might have an engine that will produce this engine for the players to cast a spell. Now, we have some variations of engines. The most common one is the static engine. This pattern is built up by an automatic source that will inject resources into this mechanism, and some kind of interactive node that players can use these resources to perform an action. We often use a static engine when we want to limit players' actions using a simple mechanism. For instance, let's take Hearthstone as an example. In Hearthstone, players spend mana to cast spells or summon minions, so at the beginning of each turn, players earn one mana, stacking up to 10. If they spend this mana on one turn, they will be replenished on the next turn. So this mechanism of earning one mana per turn is what we call a static engine. Note that these mechanisms, and so the patterns, don't need to be active during the whole game. For instance, on firm parallax, I added a static engine that only replenishes the spaceship energy when the energy depletes. When the energy is replenished, players can only move, they can't shoot, they can't dodge. This makes so that players need to be mindful about how they manage this resource, because for instance, at the end of the first level, there is a rain of asterisks that go in the direction of the player. If they don't use this resource well, they will end up being hit by these asterisks, because they will spend all their energy shooting on asterisks or dodging some asterisks, and at some point, they won't have enough energy to shoot the asterisks that are really needed to be destroyed. A friction is a mechanism that drains resources from the system or from the economy. It is different from a simple static drain mechanism, because players must be able to invest some resources or develop some strategy or skill to overcome this friction, to overcome this draining. We usually apply the friction pattern when we want to counter a production mechanism, to prevent some game breaking strategy. That's why at the friction pattern, we have the output of a production mechanism at one side, and then we apply the friction pattern on the output of this mechanism. For instance, in Reciteer, a shop simulator game, players have to pay a loan installment at the end of each chapter. Each chapter has a fixed value for this installment, so players must think about creative ways to make enough money to pay the loan while still investing into the shop and paying the employees. Players can overcome this friction by investing into farming skills and showcasing rare items and also by negotiating better with their customers. As another example, on some MMORPGs designers add a durability mechanism to players' equipment. This makes so that players will try to grind on stronger enemies so that their loot will pay off for the cost of repairing their equipment. At the same time, these enemies should be weak enough that they don't cause enough damage to players' equipment that their farming won't pay off. This durability friction balances out the game economy because players will be more willing to make quests and engage with other players on raids to split the cost of this durability repair. Now, this one is especially useful for multiplayer games. Attrition is a special kind of friction that intends to make players actively drain resources from each other. We usually add attrition when we want to make players have a direct and strategic interaction between each other. So it goes like that. There is a resource that players must keep above a minimum amount in order to stay in the game. Let's say they must keep above zero. And there is an action, let's say an attack action, that players can use to drain these resources from other players. We usually see attrition in competitive games, as one of the most common implementations of this design pattern is to represent players' health. So for instance, in fighting games, I'll use Naruto Storm Revolution as an example. Players should keep their health below zero. Whoever drops the opponent's health below zero means the match. Know that for attrition to work, players should spend the resources on this attack action that they could spend with something else. For instance, on Naruto, we can use chakra to cast Jutsu's own opponents and drain their health. But we can also use chakra to dodge some opponent's attacks. We can use this to improve our movement on the battlefield. We can use chakra to even recover some health as well. As another example, in Hearthstone, players should spend mana to summon minions and cast spells in order to drain the opponent's health. But they can also spend this mana to protect themselves, to cast some protective spells or even to recover their own health. Escalating mechanisms put pressure on players to deal with ever-growing challenges. In escalating challenge, as players make progressions towards the game's goal, we make it more difficult for them to make further progressions. We apply escalating challenge when we want the game to dynamically adapt to players' skill level or strategies. This usually prevents players from barred them, as they will feel that they should still have to improve their strategies or develop some skills and improve their performance. Typically, in these mechanisms, we have some way to complete a task. Completing this task increases the player's progression in the game. At some point, at some progression amount, players will finish the game. The escalating pattern adds a feedback loop, closing the circuit between completing the task and making progressions. So, the more progression players make, the less progression they will make by completing this same task. This is a common mechanism we can use to make level design. So, on Final Fantasy XII, we have the Clone Primaries hunt system. There, players receive marks to hunt ever-stronger enemies. And as they defeat these enemies, they raise their ranks in the clan's interior. Ultimately, players have to defeat Yasma, a foe that has over 50 million health points. Note that the damage cap on Final Fantasy XII is about 10,000 points. So, this fight against Yasma may take over 3 hours of just dealing damage continuously. Another escalating mechanism that designers usually use to make the game match the player's skill is the escalating complexity. The idea is that, as players progress through the game, the game's complexity increases. Players fight against this complexity, trying to keep the game under control. But the positive feedback loop grows so strong that the accumulating complexity makes the players lose. In this type of mechanism, complexity grows exponentially. So, if players lose the control, the game ends very quickly. The overall structure of this escalating complexity is made out of a given task that players can complete in order to drain complexity out of the system based on their skills. Then, a progress mechanism adds complexity to the system. The more progression the players make, the more complexity this mechanism creates. If the game reaches a given amount of complexity, there is no turning point, so we trigger the game over a condition. A good example of escalating complexity is Tetris. In Tetris, players should fill a line with tetra minos, those tetris pieces that fall on the screen. If players manage to fill this line, they score. But by scoring, players also increase the speed in which these tetra minos fall on the screen. By increasing this speed and by having more and more pieces on the screen, players also increase the complexity of the game. So, at some point, there are so many pieces on the screen that there is no way to score anymore, so we trigger the game over a condition. These are just a few design patterns that we use on game design, but this is a very broad topic. And even learning the very modeling language can be quite a task. But I really hope you enjoyed it. Oh, I don't know if you noticed, but it did reach the goal on Patreon, so I will start a series here on YouTube on how to make a platforming game. You don't want to miss this series because it will be a series about how you can design, develop, produce and release a platforming game. So, turn on the notification bell, subscribe to the channel so you don't lose any of the videos I release on this series. That's it, thank you so much for watching, keep developing, and until the next time.