User Experience and Game Mechanics - AKA the Feedback Loop

[TheInternetIsForThis]

I am posting this guide largely because, honestly? This is potentially the most easily overlooked or misunderstood part of developing a game, and I figured a detailed explanation could help a few people.


What is a feedback loop?

At its most basic, a feedback loop is a recurring chain of player action to game reaction. There are plenty of charts and explanations you can find if you look it up, but I feel it's better to work with examples. Take Pong, a classic arcade game pretty much everyone has played in some form. The core feedback loop for Pong is the following:

1. A ball is approaching the player's paddle.
2. The player moves their paddle. If they don't block the ball, they lose a point and return to step 1. If they do block the ball, proceed to step 3.
3. The ball is now approaching the enemy paddle. If the enemy ddoesn't block the ball, the player earns a point. Return to step 1.

This simple loop of actions creates a cohesive, continuous chain of events that comprises the entirety of Pong's gameplay. It's absurdly simple, but also undeniably effective. What happens, however, if we want to add more content to the game? Obviously, you could add all sorts of things. Maybe allow the player to upgrade their paddle so it hits the ball faster or applies spin. Maybe add obstacles. Maybe allow the player to date the ball. Who knows? Your game, your rules.

However. The one thing you cannot do is break the core feedback loop. Or, more accurately, you cannot break it without encapsulating it within another loop. For example, a logical next step up from Pong to a more complex game would be Breakout. In Breakout games, you have two core feedback loops. The inner feedback loop is the following:

1. A ball is approaching the player's paddle.
2. The player moves their paddle. If they block the ball, it bounces upward and you proceed to step 3. If they don't block it, they lose the ball. If they have no more balls, end the game. If they have more, proceed to step 1 minus a ball.
3. The ball bounces up and breaks one or more blocks, which provide points to the player. Proceed to step 1.

Now, this is already more complex, but that's just the start, since that is just the feedback loop for a single level. That one is contained within another feedback loop:

1. Start a level, beginning with level 1.
2. If the player lost the level, return to step one at level 1. If the player won their level, display total points.
3. If there are no more levels, display the player's total score and return to step 1 at level 1. If there are more levels, return to step 1 at the next level.

This is also a simple feedback loop, but can easily be expanded. You could add a title screen before step 1, featuring attract mode and a scoreboard. You can add high score entry on relevant portions of steps 2 and 3. You could add upgrades to step 3, when another level is available to play. In fact, by breaking up the game into discrete levels and operating those levels as a core feedback loop, you've now created a major form of abstraction that can allow for significant gameplay changes between levels. As a specific example, the "levels" of VA-11 HALL-A: Cyberpunk Bartender Action are a recurring loop in the following order:

1. The morning shift of bartending.
2. The midday break.
3. The afternoon/evening shift of bartending.
4. Jill's bedroom, between shifts.

Now, while 1 and 3 are essentially the same level, they feature wildly different mechanics and feedback loops from 2 and 4, which also feature very different mechanics and loops from each other. I could go on from the example of Breakout games and Pong's mechanical evolution to every shooter genre currently in existence, but that's overkill when I have a more relevant point to get to.


Why does this matter?

Because far and away the most common cause for "bad gameplay" is a broken or improperly encapsulated feedback loop. If the feedback loop is broken, it must either be at the player's discretion (such as a pause menu), or via the use of a larger feedback loop encapsulating it (such as the days and seasons of farming games.) A good example of the overarching feedback loop and the effect it can have on a game is the phrase "Just one more..." where you finish the statement with a turn, or a day, or a level.

Which brings us back around to the original point: many games, especially homemade adult games, suffer from the fact that they're not games. They are, in actuality, a pile of game mechanics haphazardly dropped on top of some porn. There is a solid reason the overwhelming majority of popular games on this forum are visual novels, especially ren'py ones. Visual novels have a simple, easy to understand and mimic feedback loop that can be indefinitely expanded.

Now, on the subject of feedback loops and visual novels, there are two exceptionally common breakages I've seen. The first is map systems. These are fantastically useful tools, when implemented as part of the loop. Take Sweet Home ~H na Onee-san wa Suki Desu ka?~ as an example. The map in that game is absolutely part of the overarching feedback loop. Any time you're not actively in the game's menu or an interaction, you're on a map. And if you're on the map, you're never more than three clicks from an interaction. (Usually two, but if you leave the house you can be three clicks from an interaction inside the house.) That is a fantastic map implementation, because it improves the game flow and gives the player clear and direct access to any currently available content.

That is not now most people implement maps in visual novels. Frequently, you find visual novels here where you start in a player's bedroom, and click your way through the house to the interaction you want. Maybe there's a menu dropdown with a room shortcut, maybe there isn't. If there's a world map, it gets even worse. Click to the world map. Click the location you want to visit. Click your way through to the specific room you need.

This does not work. Well, no. That's not accurate. It does work. It even technically qualifies as a feedback loop. But unlike the example given with Sweet Home up above, it's an extremely short, repetitive feedback loop that rapidly devolves into undiluted tedium. A visual novel's core feedback loop is conversations and character development. You're literally presenting a text-based story with visual aids. Anything that actively hinders that should, at the minimum, contribute its own enjoyable feedback loop as a secondary type of level. (Again, see VA-11 HALL-A, above.)

The other common way visual novels break feedback loops is via minigames. Now, minigames are not inherently bad. They can, in fact, be integrated quite nicely. Stardew Valley has some arcade games that are absolutely above and beyond, in that category. But minigames, just like any other means of breaking a feedback loop, must be done so in a carefully handled manner. Why do people hate quicktime events? Because they're short, repetitive feedback loops that make no contribution to the loop they interrupted. So how do you interrupt the standard mechanics with a minigame? You do it in a clear manner that, as mentioned, contributes to the loop it's put inside. For example, the minigames in a game of Mario Party are short but varied, and contribute points and other rewards to the player who win (and sometimes to those who don't) that will affect continuing gameplay once the minigame is complete. As another example, take a look at the N64 games by Rare, such as Banjo Kazooie or Donkey Kong 64. These games are, in essence, a carefully planned series of minigames encapsulated by an overarching plot and adventure. Any minigame you complete makes a concrete contribution towards a current or future objective in the game, often one that is immediately visible and relevant. A better example of non-required minigame integration are the gambling games in Golden Sun, which are simple enough to learn on the fly and can directly contribute to the overall game via funds.


So how do I use feedback loops?

They're actually really easy to use! All you have to keep in mind are the following rules:

1. Don't break a loop. Broken loops feel clunky and irritating to players, and generally result in nonsensical complaints about bad gameplay or no gameplay.
2. Encapsulate or integrate. Loops can have definite endpoints, but only if that puts the player into a different loop that logically follows. (Level -> Results -> Level) Likewise, sometimes the best option is to simply integrate content directly rather than interrupting a loop. (You don't need to click to see the art in most visual novels, for example. It's just there, behind the text you're reading.)

Now, that definitely sounds easier than it really is, but it also isn't that hard. You can't just throw mechanics into a game and expect them to improve the experience. But you can increase the complexity of an existing loop, often to fantastic results. For example, the core farming loop of farmsims like Harvest Moon or Stardew Valley is the following:

1. Plant a crop.
2. Water the crop.
3. Harvest and sell the crop.

But even the very first Harvest Moon title varied that up, with adding variable number of days to mature, withering crops, seasons, and multi-harvest crops. Newer examples include things like permanent crops that continue to produce forever, and natural crops that require no player action beyond harvesting. Both of which are variations of the above loop. A good example of how not to make it more complex is the summer storm present in early Harvest Moon titles. That storm is unavoidable, breaks every loop but the calendar loop, and actively damages the player's prior work in the animal loop (they're unhappy from lack of food) and crop loop (damaged and destroyed crops from the storm) with no viable contribution aside from theoretically providing additional player immersion.

Speaking of which - immersion is never sufficient justification. A mechanic must contribute a potential positive to the loop it is implemented in. If a mechanic can only ever be an interruption, a negative, or both, it harms the gameplay experience.

But again, overall, everything should be some form of the following, potentially stacked inside itself several times in multiple variations:

1. The game provides the player with a concrete, reachable, and worthwhile goal.
2. The player attempts to accomplish the goal.
3. The game reacts to the player's attempt. Return to step 1.