Ask a Game Dev

Scaling an encounter to support different numbers of players is generally a question of resource allocation. If we have a small number of these encounters in the project, we can do most of this by hand and spend more effort on each one. World of Warcraft's old raid system where raids supported only 10 or 25 players are examples of such where tuning and mechanics were modified to specific player numbers. However, doing this for one to eight players (or, as it stands now in WoW anywhere from 10 to 30) means eight balancing passes for every encounter. That's far too much work to do in any reasonable amount of time. This means we need to think about building a system of rules to do this for us quickly and easily.

Usually when we're talking about scaling an encounter, we have a number of dials we can adjust, as you said. Here are a few of those numbers

Some of these are more easily scaled, like health, damage, debuffs, etc. while others like specific attacks and cooldowns often require more careful balancing. For enemy health, we consider the amount of damage per second we expect per player and multiply by how long we want each enemy to live, then give a little extra buffer (e.g. additional time for players dodging enemy attacks). For damage per hit, we consider how much health and damage mitigation players should have and how many hits we want them to be able to take before death. For debuffs and cooldowns, we consider what percentage of the encounter time we want the players to have to deal with debuffs or cooldown abilities. It really helps to think of the players as a scalable percentage for the enemies to affect, rather than specific numbers.

If player healing is a role that needs to be handled, it makes tweaking the encounters more difficult since we cannot always expect there a healer to be present. In such situations, we can potentially provide an NPC healer or other environmental elements like interactables or consumables with cooldowns that provide enough healing for the fights. Our goal is usually to make healing and health management an additional task to be considered by the players during encounters, even while solo.

There's a lot more depth we can go into on this - tailoring action set piece raid boss fights in World of Warcraft is very different from doing a broad tuning pass for a squad with variable size in a game like Call of Duty Outbreak - but this should explain the broad strokes of how a system designer approaches this kind of thing. We have a set of different numbers we can adjust (and set up formulas for), and we have a holistic view of the players as a collective of effectiveness that we can modify on a percentage basis instead of an individual player basis. Then, if we have the time, we establish the kind of experience we want the players to have and tune toward that experience.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

MOBAs as a genre generally sustain themselves primarily because playing the game at lower skill levels allows players to feel ownership and powerful when they do well, but also provides them excuses from having to admit their own responsibility in their loss. This creates a powerful feedback mechanism where players get to feel significant early validation and offloads having to deal with their own inadequacies until they choose to become serious about the game.

In MOBAs players get to see the results of their own good plays immediately. Whether it's landing a skill shot, hitting with an ultimate, winning a team fight, gathering resources through laning or jungling, pushing a lane, taking down a tower, these are all immediate "wins" for the active player. It's easy to see the causal nature of the forward progress here - the player performs the action and gets to see the positive results of that action almost immediately.

On the other side, players get to blame their teammates when they're losing because their own mistakes are easy to dismiss. It's extremely difficult for a game loss to be attributed to a single mistake; game losses tend to result from accumulations of multiple bad decisions made over the course of the game. Most of the time, the bad decisions are fairly small and easy to miss. These mistakes only become backbreaking as they add up, resulting in gradual overall momentum change for the entire team. They're also often about proving a negative - that the player didn't do something they should have, rather than choosing to do something they shouldn't have.

This becomes a feedback loop for players - they see themselves improving by making better choices early on, but they don't really have to deal with their own mistakes and failings until they get serious about improving. This is why so many MOBA players get stuck in "ELO Hell" - they have hit their personal skill ceilings but haven't realized it yet.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

If keeping the beat is the most important thing in the game, then you build the game around keeping the beat. There are many different ways to approach the problem, but if I were building such a system myself, I would start with a system to handle a data-driven beat (e.g. this level/song sets the beat to X, that level/song sets the beat to Y) and then build all of my visuals and gameplay on top of that. The key component to making this work would likely be an animation system that could scale animations faster or slower in order to match the timing of the music.

On the data side, this would mean all animations would be built so they could be sped up by dropping frames, or slowed down by holding certain frames for additional length. All animations would also need to be the same length (or a multiple of a standard length), so that I can ensure the animations will fit into a standard musical measure. If I wanted to have a variety of attack animations and hit reactions, I would probably also establish a set of rules that each attacking and hit reaction animation must always be the same number of frames. I could further standardize each attack and hit reaction active frame happening on the same frame each time.

The code side would then play my animations to those musical measures along the beat. It would do so by scaling the animations longer or shorter based on the beat. The system could add or cut animation frames so that each animation can play in sync with the music. Once I've got the animation system integrated with the beat-keeping system, I can then ensure each animation should start playing on the appropriate frame to keep the beat. As long as the animations are scaled to the musical measure and the music keeps the same beat for its entire duration, the animations should always sync to the beat of the music.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Sure. The way to enforce the feeling that a faction is a real thing is that all units from that faction should feel like there's a common theme among them. I suggest that you establish a "faction ability" (or a pool of faction abilities) that all units from the same faction will share in addition to their "class" ability. This way you can create a handful of abilities that can be reused across many enemies and tie everything together at the same time.

Faction abilities should showcase what that faction "feels" like, both from a narrative sense and a gameplay sense. Starcraft, for example, had all Zerg units regenerate, all Protoss have a combination of shields and health, and Terrans have a mix of organic (healable) units and mechanical (repairable) units. Each faction's abilities in Starcraft helps reinforce what they are and how they work. Your faction abilities should be similar. Your Corp foes should have abilities that make evoke the feeling of Corp representatives. Your Cops should feel like cops, and your gangs should feel like gangs.

To do this, think about what makes a Corp and try to capture that in gameplay mechanics. Maybe the Corp units are ignored by Cops unless they directly harm the cops because they have legal immunity. Maybe they have better stats in general, because they have better gear than cops or gangsters. Whatever qualities they have, as Corporate representatives they should have commonalities that players should consider when engaging with them. When players start a fight with Corp enemies, they should have a good idea about what they should expect from Corp enemies.

A lot of work needs to go into differentiating the members of each faction - what is common to those enemies and how fighting them feels different from fighting enemies from other factions. Also, consider how the factions will interact with each other too - the way the factions behave and act will set the stage for how the game world works. The mechanics you create should, when the enemies engage with each other, play out in a way that makes sense within the world. Your game mechanics should help reinforce the narrative and the narrative should help reinforce the mechanics. This establishes a stronger, more cohesive world and experience to the player.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

It's generally easier to prototype and develop ranged combat that feels good than it is for melee.

Melee combat lives and dies by the animations and systems we build. If my character swings her sword in a horizontal arc, it creates very different expectation for a hit reaction than stabbing or chopping. A player will probably realize near-instantly if the reaction animation doesn't match the type of attack properly and it will make the combat feel cartoonish, breaking immersion. The melee animations are also performed extremely close to the camera, so the player gets full view of all of the details. We need many different attacks and many synchronized hit reactions in order for the melee combat to look right.

Ranged combat, on the other hand, does not usually carry this kind of action-reaction animation expectation. Shooting animations are generally simple and small motions. Playing a hit reaction can be as simple as a flinch or just falling over. Hit reactions are limited to hit location and typically don't need to take the motion of the weapon into account. Enemies that play hit reactions are also usually smaller on screen and further away, meaning less overall player scrutiny. We can sometimes just get away with turning on ragdoll and not even need a specific hit reaction.

Really, it comes down to the fact that animation and system requirements of making a good melee combat system work are more expensive than making a good ranged combat system work. Since the act of shooting and the act of getting hit are significantly distinct from each other, ranged combat is much easier to get working than melee combat where the hitting and the getting hit are inextricably linked. Combine this with the fact that melee combat is, by necessity, up close and immediately visible and you have a noticeably higher bar for acceptable quality from a melee combat system.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

The best way to get better at being a systems designer is to design game systems for games. This doesn't have to be designing systems for video games - a lot of system designers I know are extremely proficient card, board, and tabletop game designers too. Remember, the purpose of system design is to create an elegant set of game rules that convey a game experience to the player. The rules of play will direct how the player feels, so we must take care in crafting them.

For beginners, try building a variant mode on a board, card, or tabletop game you already have. Maybe take your old Monopoly board and try some rules variants. What happens if you increase or decrease the number of houses you can build? How does the game experience change if you halve the price of every property? What happens if each player starts the game with a monopoly? How does it feel if you add new kinds of cards to the Community Chest and Chance decks? Then playtest your changes and see how things feel. Try to figure out how and why the changes you made affect the feelings the players feel.

Once you start getting a feel for how rule changes affect an existing game, take the next step - try building your own board or card game. Choose a theme or experience you want players to have, and then build a game to get them to feel it. Maybe you want to emulate the experience of surviving alone in a wilderness, climbing a mountain, opening a treasure chest, shooting at a bullseye, or getting your senpai to notice you. Whatever it is, try creating a set of rules to try to emulate that experience. Then gather some friends, playtest the game, and see if it feels good. Why or why not? How do you improve it?

By doing this over and over with different games, you will level up your system design skills. I know several designers who have crossed over between tabletop/board/card game and video game system design positions because design skill translates from platform to platform.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Most of the time, we start by setting a target time we think the game experience should take for a first-time player to feel what we want them to feel, and then add about 50% to that. A long fight should feel like a protracted fight and the time limit should reflect that. A short fight should feel like a sudden burst with a lot of pressure to finish it quickly. After we set our estimate, we playtest it to see how it feels. If we don't like it or we were off in our estimations, we adjust, playtest, and repeat. We can also ratchet that time limit up or down for various difficulty levels or challenges/achievements.

If we have to do this a lot of times, then yeah - we usually come up with a formula to generate it for us so encounters and similar timed events stay consistent and reasonable, and then tweak the important ones as needed. Consistency is really important for establishing player expectations, so having things become familiar and (to some extent) predictable helps players feel comfortable.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

We do it the same way we do any other seemingly-impossibly-large task - we break it down into smaller and smaller tasks until they are small enough to do. Cards in Master Duel are not atomic - they can be broken down into smaller components like card type, costs required to play that card, effects that happen that card is played, restrictions on when the card may be played, and so on.

It helps if you reframe what you think of as a "card" as, instead, a collection of individual costs, effects, and data. Everything first hinges on the card's type - monster, magic, trap, ritual, synchro, fusion, etc. For each card type, there's a batch of type-specific data - monsters have a star level, attack power, defense power, subtype(s), element type, and possible effects (e.g. flip effect, tribute effect, when dealing damage to a player effect, when attacking effect, etc.). The same sort of type-specific data exists for magic cards, traps, synchros, and so on.

Imagine I create an effect - special summon a monster from your graveyard in attack position. This same effect could be used to create more than one card, e.g. both Call of the Haunted and Premature Burial would use this effect. Each of these cards has additional effects and costs beyond this - Premature Burial has a cost of paying 800 life points and equipping the monster, and both require the monster to go back to the graveyard if the card with the effect is destroyed. With enough different costs and effects, I can then combine them in different variations to create a large number of different cards.

Cards are just combinations of attributes, costs, and effects. As long as we have enough of each of these, we can create as many cards as there are combinations. We can increase the pool of possible cards by adding new types of effects, new costs, and new card attributes. The things we build aren't just new cards, but also new design space for possible cards. That's how we get the cards functioning properly.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

There is more to it than that. When we build game systems, one common method of differentiating the work is "things we probably will change" (e.g. things we plan to tune based on feedback) and "things we probably won't change" (e.g. the way a story character or environment looks). We build the things we expect to change such that it is easy to make those changes. The things that we don't expect to change are typically not built with changes in mind, because we assume we will lock them in and they'll be completely finished.

As you might expect, numerical balance values like 10% higher stun duration, 8% less HP, or an extra 5% critical hit rate are often built to be easy to change because we expect to have a lot of things in the game that can change them. A magic blessing spell, a potion that provides a temporary boost, a passive racial ability, or a piece of gear all might provide different modifiers to a character's health total and we're probably going to want to tune most of those to make them feel right for their power level and the player experience. Since we expect designers to modify these values a lot, the engineers build the system to make it easy to set and modify those values.

Animations are typically not built to be easy to modify because we don't need to do it all that often. Most of the time, the character performs the animation and we call it good. We might tweak and modify it leading up to launch, but they are generally locked in once we finalize them. Most games do not need to tune a particular animation beyond being able to scale the animation playback speed to fit within a certain number of frames. Tuning would generally require the animator to make a small change, the designer to play with it and decide if it is good enough, and then make changes if it isn't good enough. This cycle can take a significant amount of time, and we often have [huge numbers of animations] we need to complete. This kind of iteration often takes too long to do feasibly.

There are exceptions to this, of course. Fighting games, for example, tend to make animation changes regularly because of the way they are built. In addition to damage and health, fighting game strength are all about the character animation start-up, the active duration, and recovery period. A particular move can be buffed by shortening its recovery time or nerfed by increasing a move's startup duration. Because the designers need to make changes to these animations regularly, the engineers build the animation system to be tunable so that the designer doesn't need to keep calling on the animators, and the animators can instead focus their time on creating new animation suites for new characters.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

When we're calculating combat math, we usually just aggregate all of the different damage mods together and apply them at some step along the damage calculation. This might be a large list from a bunch of different sources like the attacker's talents, equipment, weapon, buffs, debuffs, character class, race/species, etc. but also the defender's talents, equipment, weapon, buffs, debuffs, character class, race/species, etc. These different factors oppose each other and get evaluated for the damage calculation. In your example (-15% damage from Aliens), the incoming damage modifiers from the attacker would be marked as "type: alien" and the defensive bonus would match the incoming damage type to reduce the damage as part of the damage calculation process.

I'll take the opportunity to point out that the data displayed in UI tooltips and combat math don't necessarily have to match (trivia - tooltip and combat math not matching for a particular effect is a very common bug). Combat math and tooltips go through different paths and there are usually damage modifiers we will occasionally apply that don't want players to see. The most common damage modifier we don't want players to see would be debug damage mods. This is often used for dealing very specific amounts of damage or instantly killing enemies for test purposes, which may include needing to bypass enemy properties like health gates and damage resistance. Similarly, we might want to put special effects on certain monsters that we don't want players to know about, like world boss damage reduction to combat item inflation. One game I worked on had to apply massive damage reduction to most of their elder game enemies because the damage inflation from gear and levels had eclipsed the engine's original 32-bit integer-based combat math (maximum of ~4 billion), so the damage reduction was necessary in order to keep the game working.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

It's important to remember that game design is about crafting an experience for a player. Good designers can elicit emotional reactions from players by tuning specific numbers. The number that a player is shown does not exist in a vacuum. By taking the context of that situation into account, the number conveys specific meaning to the player. Let's consider a practical example.

Let's say that you hit an enemy at full health with Attack A and this is what the enemy life bar looks like before and after the hit:

Now compare that with hitting the same enemy at full health with Attack B and seeing this result:

Assuming that all other attributes of these attacks are the same (startup time, recovery time, ammunition, cooldown, etc.), which of these attacks is more effective at defeating these enemies?

If you consider the number of these enemies you defeat over time using only attack A or attack B, both attacks are actually functionally identical. It still takes two attacks to defeat an enemy, no matter if you use A or B. That B deals more damage per hit doesn't matter - overkill doesn't count for anything. However, if you think about which of these attacks feels stronger, then clearly B wins because the number is bigger, even if that bigger number doesn't actually make a difference in the speed at which you defeat enemies. It is the context - that the attack deals more damage - that makes the number feel like it's stronger and more powerful.

This principle remains true if the amount of damage dealt is 5 or 5,000,000,000. Damage dealt is handled as a percentage of the enemy's health and the amount of time said enemy takes to defeat, the numbers are really only for the way it makes players feel. It feels like you've gotten a lot stronger when you started hitting for 5 damage per hit and now you hit for 50,000. The enemies feel tougher than ones from the start if they can take 50,000 damage without dropping. It's this noticeable difference when engaging enemies of various levels that set the context for players to feel like they've gotten stronger and can take on "harder" challenges.

This has all been a long and roundabout way of saying "designers use bigger numbers to make players feel like they've gotten stronger and are taking on tougher challenges".

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

In order to answer you question, I think it helps break down the way things work. Usually, any combat encounter in a game that has level differentials assumes certain underlying stats for the agents involved. All combat actors have some set amount of health, deals some amount of damage over time, has some specific abilities, perhaps has some defensive stats or mitigation abilities, etc. It is the difference between these values (or delta) that generally establish the relative ease or difficulty of a combat encounter. The greater the delta, the bigger the difference should feel to the player. It is by systemically adjusting these values that we can scale enemy encounters up and down as needed.

When we're considering difficulty scaling of enemies, there are a variety of things to consider - each resulting in a different kind of intended experience. It's important to recognize that scaling direction has vastly different effects on the game experience. Enemies at a significantly higher power level relative to the player can be unbeatable or they can just be challenging. That's a very different player experience than the opposite side of the spectrum, where we're considering how enemies that are often differing levels of easy or trivial. It is quite common for enemy scaling only to apply to those enemies deemed weaker than the player and not to enemies more powerful than the player.

If we don't scale anything at all, player power growth over time will naturally adjust power deltas. The natural consequence is that large power deltas will result in incredibly lopsided fights - both tougher enemies and weaker enemies. An enemy hitting for 5 damage is considered vastly different in terms of danger to a player with 10 health vs a player with 10,000 health.

In my experience, scaling enemies is primarily about keeping older content from being completely trivialized if we're still offering decent rewards there. This way, a higher level player can be incentivized to engage with the content (and obtain reasonable rewards at the same time), while those who don't want to are less aggravated while traveling through those areas. We usually do this by setting a maximum delta below the player - an enemy will never be weaker than this amount, relative to the player. That way, each enemy can present a lesser (though not completely trivial) challenge to the player, while still allowing players to traverse through that area without as much of a headache.

We sometimes set a maximum power delta above the player for higher level enemies as well. This way, players can recognize that they've entered a much more dangerous area and have an opportunity to reconsider and leave, rather than take any major penalties like death and any associated resources lost. This design choice makes the player experience a little more forgiving than an instant death might.

Some games actually do both at once by establishing a power band - enemies will never be weaker than X but will also never be stronger than Y. This way players who get significantly stronger than Y can feel like they've transcended and are now much more powerful than the older enemies. Similarly, the minimum power floor makes the area much more challenging for underleveled players, potentially leading to one-shots. Power bands are there to help establish a progression path for players. They can choose more challenging encounters if they desire, but it can help guide most players though a reasonable critical path.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

The answers to your questions come from extrapolating the principles in yesterday's post on power curves. Diminishing returns are logarithmic curves. Exponential increases are quadratic curves.

We generally want to have diminishing returns when we don't want players scaling off too far. We probably don't want players obtaining 100% chances on combat events - 100% damage reduction or dodge rate would, for example, likely break our combat math. This kind of thing typically starts to show up when players start approaching the peak of the power curve. We need to keep providing incentives to chase the new content and loot, so we use diminishing returns to make them stronger but not to the point that they scale off to infinity or get too far ahead of everyone else. This way, if we ever plan on raising that level cap through some kind of expansion pack or newer, more challenging elder game content, we have a top end of where they could be and we can set the next tier of progression at a reasonable place.

We typically use exponential power increases when we want players to feel like they've gained a lot of strength relative to where they used to be. This is especially visible when players return to the areas they've outgrown. Players feel like they've grown much stronger whenever they encounter an old foe who was once a grave threat but is now laughably easy.

You may have surmised already that these don't have to be mutually exclusive. We can support both exponential and logarithmic returns at the same time. Since power can scale in different dimensions (e.g. levels, gear, player skill, etc.), we can make logarithmic growth exist in some dimensions and exponential growth exist in others so that we can craft the overall experience that we want players to have by tuning those specific dimensions.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

The hardcore theorycrafters can get pretty dang close to our internal formulas, but that's not necessarily going to stay the case. We will make adjustments to the formulas for various reasons (e.g. we want to tune crit up across the board, we want to tune this specific ability down, we're raising the level cap in an expansion, we want to change things up for this season, etc.) which can often invalidate previous assumptions.

In a lot of ways, the theorycrafters are actually the mirror opposites to designers. We designers start with the math and use it to try to craft the intended player experience. Our goal is to create a combat experience that is fun and engaging for the player. The theorycrafters start with the player experience and try to figure out all of the math that drives it. Their goal is usually to optimize their combat performance, even if it means sacrificing the engaging gameplay to do it. It's a pretty major distinction - lots of people can understand what it means to break down an experience into the component mathematical parts, but it is far rarer to find people who can use those math components to craft an interesting experience.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

The way we balance expected player level to power level is... We create a math formula. Levels are mostly arbitrary discrete markers of player power. Conceptually, they exist to provide a reference point for players to understand how strong things are relative to each other. Their very presence establishes that all combat encounters in the game will happen in one of five bands:

We start by establishing what kind of player experience we want these main types of combat encounters to feel like. How long should each of these encounters be? How many mistakes should we allow a player to make (e.g. getting hit) before getting killed in this kind of encounter? How long should enemies be expected to live? How many enemies at a time should the player be expected to deal with? How many enemies should there be before the player actually feels threatened? For the much higher level foe, we need to decide whether we want players to be able to defeat them at all. We need to figure out where the exact line is between a challenging-but-beatable Higher Level Foe and an impossible-to-beat Much Higher Level Foe.

Once we know what we want those experiences to feel like, we work our way backwards to define the variables we can modify for combat - damage, health, attack speed, defense, movement speed, and so on. We use these variables to construct a general combat formula that will satisfy all of our desired encounter band experiences for any set of input levels for player and foe. We use math to model how we want combat to go. The graph of the player's overall power against their level is called a "power curve".

Once we've established our formula, we can fill in the 'expected' stats for a bad guy of a given level. We will do similar passes for equipment, weapons, items, abilities, and so on and so forth. There should be a mathematical formula for the power of each thing so that we can always have a baseline expected experience. We can then fine-tune the individual attributes of any of these things if we want them to be weaker or stronger.

So yeah - system and combat designers are really a bunch of nerds who have to figure out how to turn cool imaginary combat into a bunch of math equations.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Here's the thing - most people who play Monopoly don't understand how to win at Monopoly. Most players play not to lose, which results in the most standard result - a game that goes on way too long and players get bored. It helps to look at Monopoly as a collection of systems focused around looking at the management of resources.

Let's consider the way a player loses at Monopoly - they completely run out of money and resources and go bankrupt. Think about where the money enters the system, and where the money leaves the system. New money enters the system only through a handful of methods - the money you start with, the $200 you get from passing Go, and the occasional chance or community chest card. Money leaves the system when players buy properties and improve properties by building houses or hotels. Occasionally, there will also be money leaving the system through chance and community chest cards, or paying to get out of jail. Money doesn't enter or leave the system when a player pays another player - it only circulates.

Removing money from the system forces players closer to bankruptcy overall. Adding money to the system makes it easier for players to survive overall. What happens if you have a pot of money on Free Parking? Well, it depends on the source of the money. If the pot comes from the bank, it introduces new money into the system and makes the game last longer. If the pot comes from other players, it keeps money within the system for longer. Neither helps end the game quicker, which should be one of the design goals.

I think that the main issue is that Free Parking isn't compelling to land on for gameplay purposes. Landing there feels bad, so making it a money pot makes it feel better. If our goal is to make it more interesting, I would suggest something that would either be more neutral, or even remove money from the system. I think that Monopoly would do better if there were more ways for players to interact with each other. Instead of calling it Free Parking, I might rename it as the Court House, where a player landing there can pay some fee (e.g. $25) to the bank to sue another player and compel the defendant to hand over some amount of money, e.g. $100, or a higher fee ($100) to take another player’s property. This way we remove a little money from the system whenever players land on it, as well as encourage interaction between players. The two important goals are to incentivize players landing on it and remove money from circulation to push all of the players to the endgame.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?