FEEDBACK LOOPS

When connections form feedback loops there are two patterns that can emerge: Balancing feedback loops and Reinforcing feedback loops. Balancing feedback loops tend to take the system to a balance point. The classic example is to look at the operation of an air-conditioner machine. You set the number matching the temperature that you want in the room and the air-conditioner will throw hot or cold air depending on the current temperature of the room. In games, balancing feedback loops are used to varied objectives. They’re used to adjust the balance of the game to keep the player in the state of “flow” or to create a “rubber-banding” effect between players or player against AI, closing the gap between them to keep the game interesting.

Reinforcing loops are the opposite, so they keep the Stock constantly increasing or decreasing. A classic example from everyday life (if you are a musician at least) is the painful high pitch note when the microphone is placed in front of the speakers, which creates a reinforcing feedback loop of the same sound getting out of the speakers and entering again through the microphone. Most games are based on several reinforcing loops working at once. Progression systems are a kind of reinforcing loop, because they consist on acquire certain resources to invest them on earn more power, therefore acquiring even more of that resource. Training workers on a RTS like SCVs in Starcraft is a reinforcing loop, because it allows the player to obtain resources to train more SCVs, therefore obtaining more resources.

On the left, a reinforcing loop: when the player get hero power, he will advance more stages and therefore earn more money, that will help to upgrade the hero power and the loop starts again. On the right, a balancing loop: The more hero power (and stages and gold), the more enemy power, but powerful enemies will work against hero power, also reducing staged advance and money earned. Both systems are connected, and can be represented in many ways.

THE IMPORTANCE OF LOOPS IN GAME SYSTEMS

Games are essentially a mix of many loops, interacting with each other generating complex behaviors. Loops interact with each other only when they are in the same layer. As it’s noted in “Rules of Play”, we can analyze games in the logic, social and cultural layer, as well as human-computer interaction. In all of these layers we will find a set of complex loops that interact with the player in order to generate the intended experience set up by the designer. Remember that Game Design is a second-order design, so we didn’t create the experience directly, rather we set the system that will hopefully create that experience. One way to be closer to deliver the intended experience is through practice, the good ol’ trial-and-error. Another (complementary) way is to analyze feedback loops at different layers, from the logic, social and cultural side, the player decisions loop and how the system reacts and communicate that decisions.

USING FEEDBACK LOOPS IN IDLE GAMES

Idle games are focused on short and long-term decisions. There’s no need to break the APM world record or to have a mouse with 14 buttons. The main concern of the player is trying to predict how the different curves of power and resources will develop, to find the best combination of elements possible. When the player receives the feedback from the game, he/she must compare the outcome of the decision with the initial intention. It sounds easy to make and analyze, but there is a catch. Almost a Hero and most idle games are composed of many, MANY interconnected systems on top of a basic and very stable system, so there are a lot of things to take into consideration.

Having said that, feedback loops are clearly identifiable in idle games, because there is no “APM” related mechanics. Besides, loops work fiercely in a game like “Almost a Hero”, so it’s important to analyze the whole set of feedback loops so as don’t unbalance the game systems. Most systems of the game are interconnected, and at the same time are composed of many subsystems.

CRAFTING MECHANICS

Games have many loops working in tandem. You’ve probably heard terms like “core” or “main” gameplay loop. There is also the Mental and System models loop (similar to the MVC loop). There are loops going on when players make decisions. And feedback loops governing the logic inside the game, as well as the permeable social and cultural decisions. I will briefly talk of other types of loops and then I will explain more thoroughly how feedback loops on the logic-side of the game shape engines, what ultimately allow us to craft experiences for the players based on the rules of the game.

MAIN GAMEPLAY LOOP

To define the different types of loops we will start with the most commonly used term, the Main Gameplay Loop. This kind of loop is useful to define the 3 or 4 more common actions with which the player will engage in the game. This is very useful from the point of view of the designer, in order to pitch the idea and to don’t lose sight of the main gameplay that he/she wants to achieve. In Almost a Hero, we could identify a gameplay loop as follows: kill enemies → earn resources → upgrade heroes → wait → kill enemies → earn resources … a loop with which the player will interact repeatedly and that define the game and the genre of the game. The main gameplay loop is the most high-level description of the game systems, so it’s just an initial point to start exploring the systems of the game.

The Feedback loop of “Almost a Hero” consist in killing enemies to earn resources, that can be invested to kill more enemies and star again. Once the resources get depleted and is not possible to upgrade more, the player must wait while the loop keep killing enemies and earning resources, so when the player plays again, it will have enough resources to upgrade heroes and repeat the loop again.

PLAYER’S DECISION LOOP

On the other side, we have the Player’s Decision Loop, that is useful for the designer to analyze how players are making decisions and how these decisions feedback information to the player, generating different kind of emotional responses. I will not explain more here, because it’s a very vast topic, but you could read a full article HERE.

MENTAL AND SYSTEM MODEL LOOP

We also have the Mental and System models loop. If you are into UI/UX, you are probably familiar with this kind of loop, because it’s a very important tool to communicate the system’s purpose to the player. This loop is made up of two parts: the mental model of the game in the mind of the player and the system model of the game. The mental model is formed on the mind of the player based on previous knowledge of the game genre, what the player knew about the game before playing it and the constant interaction with the game that feds-up new information to the player. The system model of the game interprets the input of the player and reacts according to the rules that were previously set by the Game Designer. Then, the player receives the response of the game through the feedback and adjust the mental model of the game. This loop allows the player to better understand the system through constant interaction, thus generating more meaningful interactions with the game. These moment-to-moment, action/reaction loops are a very effective tool, because the Game Designer can analyze and enhance the feedback that the player receives, in order to constantly adapt the experience.

The Player and the System interacts through the Input and the Feedback. The player learns the game system and updates her mental model, to interact more knowledgeably with the game system.

LOGIC RULE-BASED LOOPS

Systems are a combination of Sources, Stocks, Sinks and many other components, usually working through feedback loops. Many of these combinations form repetitive patterns, forming what is usually called a mechanic. Mechanics could be combined into subsystems to shape larger systems, what we know as game genres. Game genres therefore are formed by a combination of certain mechanics that form a pattern, then we label them with names.

As Michael Sellers points out in his book, systems could be observed forming three basic main patterns:

Economies are a result of the work of Reinforcing feedback loops. Augmenting a resource in an economy and invest it will feedback and increase even more the amount of that resource. Many Strategy or RPG games are based on the premise of gathering resources and invest them to gather even more resources to keep investing the resources, for example, in training more units or buy upgrades. For example, in Civilization games you could increase the Culture resource, which allows to influence other societies and through those interactions, earn more Culture. Or in Almost a Hero, that you kill enemies and earn Gold, that can be used to upgrade Heroes in order to kill more enemies, thus earning more gold.

In a real economy, you can put your money on the bank to receive an interest, while you work to increase you inflow of money. In “Almost a Hero”, you can increase your Hero Power investing Gold, increasing Artifacts’ level and upgrading Items, all working to increase even more the Hero Power.

Ecologies are formed by Balancing feedback loops. Ecosystems are a great example of ecologies, because they keep balancing themselves to maintain the basic conditions to keep working. Inside that working range, ecologies are called “resilient”. When ecologies got outside the working range they get unbalanced, what’s called a “brittle” ecology. When ecologies become brittle, the designer must nudge them to balance again, because there is the threat of the ecology never coming back to the working range again, hence breaking the game. Hunter/prey ecologies are a good example. An increase in prey animal will provide more food for hunters, so there will be less prey animals and therefore less food for hunters, resulting in an increase in prey that will start the cycle all over again. Take the hunters or the prey away and the ecology will get unbalanced beyond (immediate at least) repair. In games, ecologies come from challenging the player, either from the game systems or other players.

Multiplayers and especially Social games tend to create balance, because players will join forces against the leading player, while sometimes help players that are too far back so they enter the competition. In Almost a Hero, the systems itself generate an ecology loop, adjusting Heroes and enemies Damage, HP and the Gold delivered by enemies against the Gold needed to upgrade Heroes to make the levels increasingly difficult to advance. You can find more about how to balance Idle games in THIS ARTICLE. The designer must balance the Balancing feedback loop (no pun intended!) to maintain the player in the state of “flow” and deliver a compelling experience.

In a normal ecology, a hunter animal will eat the prey, thus increasing their population. It will get a point when the prey animal will be too scarce to all the hunters (an outside slower feedback loop), so they hunter population will decrease and the prey population will increase. In “Almost a Hero”, the more stages the player advances, the enemy power will increase slowing the rate of advance.

Engines are a mixture of different components. They are complex systems that use Reinforcing and Balancing feedback loops working in tandem. Engines also have traders and converters, like cars’ engines that convert one type of energy into another, mixing different resources. Games are essentially formed by many engines, because for every Economy, there is usually an Ecology trying to stop indiscriminately advance of that economy, forming an Engine. At this point of the description, you should probably noticed that Engines and Mechanics are interchangeable terms. Games, in its wholeness are “engines of emotions” as called by Tynan Sylvester. For example, the main engine of Almost a Hero is formed by the player constantly increasing the power of Heroes and the number of resources, while enemies increase their power, making increasingly difficult for the player to kill them.

This is a simplification of some systems of “Almost a Hero”. The player strives to get more Hero Power, advancing stages to get the required resources to increase the Hero Power (Economies). While the player advances through the levels, Enemy Power will increase exponentially to impede player advance and upgrade of Hero Power (Ecology). The player can invest real money using the Game Store (Trader) to buy Gems. The player can convert the Gems in Clothes or Chests, these one used to get more power and advance more stages using Scraps and Tokens(Economy). The Real Money invested by the players is used by the Developer to increase player’s satisfaction, updating the game or creating new games (Ecology: the player decrease his money to increase his satisfaction with the game, getting to a point of balance where he want to keep playing). The combination of all the depicted systems conform various Engines, for example one Engine regarding the increase on Hero Power, advancement on Stages and increasing Enemy Power, another of the use of gems to increase Hero Power through Scraps, Items and Tokens and another of the player using the Game Store.

CONCLUSION

All this analysis will be pointless if it’s not put into practice. That’s why I encourage you to analyze games that you are using for reference to your own games or even your own games. Using systems thinking to analyze games will result in more meaningful discoveries about the working of the game system and the resulting experience in the mind of the player. If you’re a fan of Strategy and RPG games (as a designer and gamer) like me, you will find in Idle games many good systems that can be replicated in both genres. More important, Idle games are very logic-based games, so you can create a prototype to simulate almost the whole system on your own. Happy designing!

Resources:

Sellers, Michael (2018). Advanced Game Design.

Sylvester, Tynan (2013). Designing Games.

Upton, Brian (2015). The Aesthetic of Play.

Lehdonvirta and Castronova (2014). Virtual Economies

Pecorella, Anthony (2016). The Math of Idle Games

Almost a Hero – Crafting experiences using Feedback Loops Pt.2