Encounter Design Topics: RNG in Encounter Design
RNG (random-number generation, a shorthand for randomness) always feels like a topic that inspires holy wars, both among and between developers and players. I feel like discourse on it tends to frequently be non-specific in a way that hurts the exchange of ideas, so I wanted to write up my thoughts on 1) what RNG is 2) how RNG can be useful as a tool and 3) my personal point of view on using RNG, specifically in encounter design.
A few provisos:
While you can tell from my About Me page that I did a substantial amount of work at both Blizzard and Obsidian, my point of view is not “the Obsidian Way” or “the Blizzard way”. If I use examples from a Blizzard or Obsidian game, they will be examples of content that I worked on and specifically from my point of view. I will not share “blizzard/obsidian rules” for NDA reasons and I also don’t want to misrepresent my opinions as the opinions of those companies. As such, these should purely be taken as one designer’s thoughts.
Randomness as a tool in game design is a huge topic, easily enough to write a book about. I am not doing that! The scope of this post is purely on player-vs-computer, single-player or multiplayer, “encounter design” aka the design of challenges that a player is expected to overcome. Though, if I’ve done my job, the applications outside of encounter design should make themselves apparent.
What is RNG?
With any technical game design topic, but particularly with RNG, it’s extremely important to define our terms. Arguing over the meaning of words isn’t fun (for me).
From my point of view, RNG in the context of encounter design is any aspect of an encounter which players cannot predict on repeated playthroughs of an encounter, or between different players’ playthroughs. Broadly speaking, I consider all of the following “RNG” to a lesser or greater extent:
Attack Selection - For example, a boss might use ability A, B and C in any of the following orders, randomly selected at the start of a phase:
ABC
ACB
BAC
BCA
CAB
CBA
This can be even broader, for instance, a boss might have 3 phases and do those entire phases in a random order.Positional Randomness - For instance, a boss might target different parts of the play space with an ability from run to run. Generally speaking, if that positioning is not influenced by external factors under the player’s control (e.g., where the player is standing, or where the player has lured the boss) I would consider these RNG.
Technical Run-to-Run Variance - Often, for purely technical reasons, a boss may vary their behavior slightly between runs. Maybe the pathing does something weird, maybe a timer syncs up (or doesn’t sync up), maybe the game lags - this is the randomness that a designer does not intend to include.
Emergent Behavior - For example, the interactions of AI in a Hitman level. This one is tricky, because everything within an emergent system may be effectively rule-based. But, because often the results of an emergent system lie outside the designer’s control, emergent situations often share aspects of RNG so they’re useful to think about in this context.
Additionally, while it’s typical to think of RNG as a dice roll, or rand()%100>X, there is more richness to random systems that is worth considering:
Deck of Cards/Bag of Tokens - This is a randomness system where it is either guaranteed, or would be guaranteed given enough time, that you would receive each permutation once before any repeat. If you’re drawing cards off of the top of a single deck, once you’ve drawn the 2 of Hearts you know you can’t draw it again unless it gets shuffled back in the deck.
Bad-luck Protection - This is a catch-all term for systems that have random elements but that introduce balancing aspects to deal with the feel-bad nature of outliers. For instance, a system that increases the probability of an event whenever the random chance to trigger that event fails.
Why do anything?
I think before talking about how to use RNG as a tool, you first have to think about the reasoning behind any choice you make when designing an encounter. Whenever I talk about encounter design, my point of reference is going to be what I consider a successful design. To that end, I broadly see a successful encounter as doing the following:
Contributing to the holistic experience/narrative - To me, all designers are “narrative” designers - in that a narrative to me is a crafted emotional and informational experience and all aspects of a game, including encounters, should fill that role. For instance, your encounter might serve as the apotheosis of a character’s arc, or provide a release of tension, or build the atmosphere of a spooky dungeon. Your design should serve the larger experiential goals of the game at that point.
While some games aren’t really based around an authored narrative, all games rely on taking the player on an emotional or intellectual journey. You can still think of this goal as serving the story the player would tell of their encounter. Even if you aren’t really serving a larger authored narrative, you should be asking yourself the following questions:
What do I want the player to feel during my encounter?
What kinds of stories do I want players to tell about their experience in the encounter?
Serving as a point in the game’s larger arc of mechanical teaching or testing. In general, encounters in games serve to either teach players about the game’s mechanics, or to test their knowledge/ability to execute them. This can also be part of a larger design, for instance, you might design encounters leading up to a boss to teach the player a mechanic which will then be tested in the boss encounter.
In general, as I discuss ways that RNG can be used, or dangers with it, these are the criteria I’ll be using.
Randomness as a tool
Given these criteria, we have to ask - what experience does randomness serve, or how does it meaningfully affect learning the game’s mechanics? Here are some examples from my experience:
Randomness encourages active response vs. muscle memory - As players who have done tens or hundreds of pulls on an MMO boss will say, if a boss follows a completely set pattern, players begin to be able to do the encounter without thinking - they begin to follow steps, like a dance. Adding random elements breaks up this pattern and forces active reaction. In that sense, it can help alleviate the boredom involved in repeating a section of an encounter where players are practicing a later stage but are forced to repeat the earlier stage to get there.
Randomness replaces planning with active reaction - As a corollary to the above, some types of randomness force players to respond to situations on the fly vs. strategizing ahead of time what they will do. For instance, WoW/FFXIV allow players to place markers on the playing field. If a mechanic targets non-randomized locations, or if players have control over those locations, players use these markers to determine where to move in response to mechanics. If positioning is sufficiently random, or there are other elements outside of players control, they will instead have to evaluate on the fly. Or, if a game has cooldown-based strategic resources, players cannot fully plan out every cooldown usage when abilities occur in a random order, especially if random ordering can cause them to recur at different points with respect to a cooldown cycle.
Randomness can distribute responsibility - In a multiplayer environment, when players have control of who an ability targets, they often tend to make a single player cover the work of doing the mechanic just to reduce the potential for error. Or, even if it uses consistent targeting outside of a player’s control, then certain players are forced to hold the burden of responsibility. If, instead, you want all of the players to have to learn to handle a mechanic, random targeting can accomplish that. Of course, another option would be to separately target each player - but generally speaking that can both be fairly boring and you often don’t have the space and time within an encounter to have that many repetitions of an ability.
…or, limit usage of individual powerful counters - In many MMOs, certain classes have powerful abilities that let them avoid certain effects - for isntance, in FFXIV tanks have invlunerabilities, and in WoW characters have abilities like Feign Death, Divine Shield, and Ice Block. When players can control who an ability targets, it often lets them always solve the problem with one of those abilities. This has a couple of knock-on effects - it ends up making the mechanic feel like every other mechanic you just invuln to solve, and it also pushes group composition in a way that can be unhealthy for social cohesion in groups.
Randomness serves to “blur” breakpoints - I’ll explain this by way of an example - when I was working on World of Warcraft, we would support between 10-30 players in Normal and Heroic raids, with mechanics, damage, and health “smoothly” scaling to account for the difference. However, some mechanics do not scale smoothly.
For instance, imagine an encounter where you require a number of players to complete a task. You might want 2 players to complete the task in a group of 10, and 6 in a group of 30. If you simply round up the fractional part when interpolating between those numbers, then adding, say, an 11th player would suddenly cause the number of tasks to increase by 50% while only increasing group size by 10%, increasing the difficulty for the entire group. Rounding down shifts where this breakpoint happens but doesn’t fundamentally change the problem. A simple solution for most groups would be to not invite additional players, and we saw that social dynamic replicated in earlier encounters.
To help deal with this, one solution I used was to establish an “expected value” of tasks per player. So, for instance, let’s say at 10 players there should be 4 and at 30 players there should be 12. This gives us a “tasks per player” value of .4.
Let’s say a group had 18 players. This put their “tasks per player” at 7.2. I guaranteed 7 tasks and used the fractional portion as a random chance of an additional task (.2 being 20%, in this case). So players had an 80% chance of 7 tasks, and a 20% chance of 8 tasks. I then logged the amount of tasks I’d given in total over the encounter (7 or 8 at this point). At each subsequent recurrence of the ability, I’d then compare the expected tasks at that recurrence to the actual tasks, and get the difference.
For instance, on the second recurrence, their Actual Tasks value would either be 7, or 8, and their Expected Tasks for the next case would be 14.4 (7.2 times 2, since this was the second cast). I’d then subtract the Actual from the Expected, giving me a new “tasks per player” value for this recurrence. In this case:
If the players saw 7 on the first task, their tasks per player would now be 7.4.If the players saw 8 on the first task, their tasks per player would now be 6.4.
This means, if the players saw 7 the first time, they would be more likely to see 8 the second. If they saw 8, they would see either 6 or 7 the second. Over the course of an encounter, players would see between 6 and 8, and adding a single player would never suddenly and repeatedly cause more to show up.
In this way, adding additional players to the encounter would subtly shift the average number of players who would have to complete the task over the length of the encounter, but in a way that adding a single player would only make a visible difference if players were carefully tracking the total number of tasks over an entire encounter and dividing them by party size. In this way, the breakpoint was “blurred”, reducing the sense that adding a single player was punishing.
Weaknesses of RNG in Encounters
Randomness, especially low-frequency randomness, can reduce the player’s agency over their success or failure, particularly in strictly tuned encounters - Often, it is unavoidable that one random outcome is marginally preferable from the point of view of players, and will result in higher or lower damage being done. For instance, often targeting a melee player with an ability that forces them to move away from the group will reduce their damage output more than a ranged player in the same situation.
Depending on the length of the ability, this can cause a substantial reduction in damage output for the group. If you have enough casts of the ability (and if the game in general or other abilities are tuned such that melee has advantages that balance out the inherent weakness of low range), then the law of large numbers can essentially smooth out the impact of these abilities overall - the variance from the randomness starts to diverge toward the average.
However, if an ability is very tightly tuned, even that variance can be enough to make the difference between success and failure in an encounter. Or, if it isn’t, in can create the perception that the random effects are what determine success or failure. This creates a situation where, in repeated attempts on a very difficult encounter, players are essentially “fishing” for good RNG rather than feeling like they need to perform better to complete an encounter. This is often a frustrating and undesirable experience.
In general, the best strategy here is often to try to minimize these random elements as the difficulty of encounters increases - or, to try to ensure that randomness is mitigated through a large number of casts. And, of course, outside of the scope of encounter design, characters classes who are disproportionately affected by things like movement should have other aspects that help to counteract those weaknesses.“Bad RNG” situations and forced restarts - Also, outside of the impact on tight tuning, if you have some variations of an ability that are particularly difficult to deal with, and that players can randomly end up receiving, AND the frequency is low enough that players may reasonably get through an entire encounter without seeing the “bad” situation, then players may just choose to intentionally fail the mechanic rather than learning the bad case. This is usually not desirable.
There are three ways to mitigate this that I’ve tried:First, just eliminating the “bad RNG” case from the possible list of option.
Second, increasing the frequency of the ability usage such that it becomes impractical to not learn how to solve the bad RNG case. This is especially effective if the ability happens near the start of an encounter, such that not learning the bad case becomes an impediment to later progression in the fight.
Finally, force the bad case at least once. On one mechanic I designed, testers felt that one random case was substantially harder than others and that this might be a problem. I just ALWAYS made the one of the casts the worst case, and then randomized from then on. Players were then forced to learn the worst case in order to progress the fight, but I still had the benefits of randomness in other sections of the encounter.
Final Thoughts/Comments and Questions, please!
RNG is a touchy subject between players and designers, and hopefully this helps explain some of the reasoning behind RNG use in encounter design. However, this is a subject that a whole book could be written about, and I’m sure there are many angles I haven’t covered. Please feel free to ask questions in the comments and if there’s any particularly interesting ones I’ll put the answers in the blog or write a new blog response post for them!