2: 1H and 2H Melee vs. NPC Monster
that the base case scenario has been defined and the two classes
are acceptably balanced, the two melee types can be compared to
a NPC monster of equal level. The design goal here is to develop
a scenario where each melee will beat the NPC approximately 75%
of the time, or conversely, a 25% chance of death. The intent is
to demonstrate that such results are possible without having to
adjust either character templates.
NPC monster's design is made up mostly of constant values, with
only one equation and zero variables. The relevant and adjustable
statistics for the monster are hit points, armor level, dodge, average
damage and average damage variance. The only equation is for damage
absorption, and that is a ratio of the monster's armor factor.
order to approximate basic results, the data in Table 1 was generated.
Table 1 displays the average number of rounds required to defeat
the monster. It includes both the one and two-handed weapons' chances
of killing the monster, and the monster's chance of killing each
type of fighter. By adjusting the input values to this table, initial
values for the monster were generated. @Risk simulations were then
run in order to determine the expected combat outcome.
goal of this exercise was to have both pairs of line junctions centered
on or near the 25% mark. In this way, both characters would possess
an equal chance of killing the NPC monster. As can be seen in Figure
6, the third trial displayed the best results. From Figure 6 one
can also observe the difference between expected kill times for
each of two scenarios. On average, the one-handed weapon would defeat
the monster five rounds after the two-handed weapon was victorious.
This poses a design issue.
question that is raised in this case is whether it is acceptable
for one class to take marginally longer to kill a monster than another
class. If the answer is yes, then the design can be considered complete.
If the answer is no, then one must consider what, if any, is an
acceptable divergence between kill times. Once that has been determined,
inputs to the model can be revised in order to attain the desired
results. In some cases, adjusting only the monster's model will
decrease the difference in kill times. However, it will usually
require adjusting all of the characters and monsters.
two models are extremely basic in both their design and application.
More realistic and practical RPG models are required to consider
factors like variable weapon speeds, ranged combat, styles, special
attacks, buffed vs. unbuffed states, and group combat situations.
It is possible to develop models that account for all of these game
features. Some of the methods by which they can be simulated will
now be qualitatively discussed.
most RPG games, weapon types are designed to fight at different
speeds. Additionally, factors such as melee haste buffs (skills/spells/items
that pump up character stats and increase the player's speed) and
casting time reduction abilities can further adjust the rate in
which attacks are initiated and spells are cast. Consequently, the
simplistic approach to modeling combat rounds shown above is ineffective
for generating meaningful models and results. Thankfully, it's possible
to design functional models that account for these variances. There
are three main methods of accounting for these variable attack timers.
first method of accounting for the difference in melee attack times
is to develop an average damage-per-second for weapons wielded by
the character. If the average damage of a weapon is 200 points,
and the weapon is swung every 3.5 seconds, then simple math yields
an average damage-per-second of 57.14 points. In this way, the rate
of damage delivered remains accurate. The rounds used in the above
examples represent an average attack speed between the characters
and/or monsters. When designing combat systems that lack reactive
weapon styles, this method of accounting for the differences in
weapon speed is preferable. (Reactive weapon styles are weapon-specific
skills or abilities that a player may use in response to the action
of their enemy. Examples include the use of "style a"
if an enemy blocks a player's attack, or "style b" if
the enemy dodges the attack.) However, when reactive combat styles
exist, their functionality and damage need to be scaled in order
to be modeled correctly. In the case of weapon styles that link
off of each other the results returned will require analysis in
order to ensure than styles are not being performed more often than
the game's mechanics allow. (Linked styles are those styles that
are chained together in a series: "Style a" must be performed
first, then "style c, and finally "style d" ends
the chain. If one style fails, then the succeeding style in the
chain cannot be performed. Models are required to check for the
success or failure of prerequisite styles to ensure that "style
d" is not performed, for example, 100% of the time, if "style
c" possesses only a 35% chance of success.)
second method of handling variable combat speeds involves exchanging
the combat-round scenario for a calculation based upon the duration
of combat and the average weapon speed, and relies on nested IF
statements. Combat is structured such that the model checks to see
if the current combat time is evenly divisible by the speed of the
weapon. When an integer result is returned, the applicable character
will attack. If the returned value is a non-integer, you can assume
that not enough time has passed and that no action will be performed.
This method is desirable when model accuracy is paramount. However,
this method of accounting for variable weapon speeds can potentially
be limited by the size of the model. In the case of long duration
combat, the number of combat rounds within the model can be quite
significant. This would both increase simulation run times and require
more effort to analyze the results.
third method of accounting for variable times is preferable due
to its relative simplicity and its degree of accuracy. Like the
base case example illustrated earlier, combat rounds are the unit
of measurement used by this system. The main difference is that
while the results are displayed as combat rounds, the rounds need
to be converted to time values before being compared to other models.
On the down side, a limitation to this system is when a weapon's
speed can vary. When weapon speed varies, for example between 3.5
and 4.2 seconds per attack, then one of two conditions need to be
in place: Either an average weapon speed must be assumed when combat
rounds are transformed to a time basis, or a variable for time distribution
needs to be included as a line in the combat results of the model.
order to properly account for ranged combat, the movement speed
of the attacked character or NPC is required. The model will then
need to keep track of the distance between the PC and NPC at the
beginning of each round. Through the use of IF statements, you can
structure it so that ranged abilities will be used as long as the
range between the PC and NPC is greater than the minimum range that
is specified in the model. In the case of an archer attacking an
NPC monster, three additional combat lines will be required in the
simulation. The first line will keep track of the NPC's position
in relation to the archer. The second and third lines will represent
the ranged and melee damage delivered by the archer. Both of the
damage lines will contain IF statements that check the position
of the NPC at the beginning of the round. If the NPC's position
is greater than the minimum ranged attack distance, then a ranged
attack will be performed. If the distance is less than the minimum
specified distance, then a melee attack will be performed.
and Special Attacks
increased use of fighting styles and special abilities in RPG games
implies that combat modeling systems should account for their damage
and effects. If special abilities are ignored when modeling combat
systems, the in-game results can be extreme. When applying special
attacks to a model, assume that the abilities are used perfectly
by the character -- that all styles are used at the most opportune
times. By designing a model in this fashion, the optimal scenario
is created. In turn, this provides an incentive for players to increase
their real-life skills. Players will have a specific goal to strive
for: the ideal use of their character's abilities.
who possess a significant understanding of player tendencies will
design the ideal special attack models. The reason is that if the
person designing the model is not intimately familiar with the play
styles of power gamers, then a perfect scenario will not be created.
IF statements can provide the necessary AI to determine when reactive
styles are to be used. When it is not possible to use a reactive
style, then the most effective styles should be used (i.e., the
greatest damage per endurance point). The idea here is to assume
that players are performing at a maximum level of skill and efficiency.
models that accurately simulate group combat requires careful planning
and a strong understanding of the way optimal groups function. Groups
with virtually any class composition or size can be modeled effectively.
The main constraints in modeling group combat are the time it takes
to develop the model and the modeler's familiarity with the play
patterns of gamers. If you don't find these two conditions insurmountable,
you should feel reasonably comfortable modeling an eight-versus-eight
confrontation, or an eight-versus-environment confrontation.
modeling group combat for player versus environment, one should
possess a strong understanding of how optimal player-versus-environment
groups work. In a traditional group, three main character types
exist: the tank, the healer and the nuker. (See Table 2 for definitions
of these terms.) Additional character types may exist, or even be
required, depending on a game's design. The additional roles may
enhance a group by adding player buffing, NPC debuffing, improved
regeneration rates, and pullers. Given the variety of roles within
groups, and the large number ways that the different classes can
be combined, it is important to perform numerous simulations such
that the comparable power differences between different group makeups
can be quantified.
2: Character definitions
A character that specializes in melee ranged armed combat. Examples
of tank classes are fighters, warriors, soldiers, rangers, and
paladins. Tanks generally have the highest armor class and hit
points in a group.
A character responsible for improving the health of other characters
via healing and resurrection spells. Examples include druids,
medics, and clerics.
The character that deals large amounts of direct damage via spells.
Examples include wizards, mages, spell-casters, magic users.
development of group combat models can be done by anyone with good
Microsoft Excel skills, good insight into player tendencies and
an understanding of how to apply risk analysis to create decision
trees. However, a discussion of the methodology by which one can
create group simulations would be too lengthy to include in this
key advantage to using models to design game systems is the ability
to determine how individual inputs affect a model's outcome. Variable
sensitivities can be determined using "tornado charts".
A tornado chart is a graphical breakdown that shows how key variables
affects a model's outcome. The effects shown in a tornado chart
are included for both the initial variable inputs (such as primary
statistics), and also for any equations that include a variable
in their calculations. Figure 7 illustrates a sample tornado chart
in which the effects of variables are shown on the outcome of the
1H vs. 2H simulation.
Microsoft's Excel and Palisade's @Risk possess additional features
that aid in balancing games. The features range from the simple
yet effective "Goal Seek" function, to the more complex
"Solver". Through iterative methods, these features can
automatically adjust key constants in order to obtain a desired
numerical result. "Goal Seek" will adjust the values in
one input cell until a specified output cell has reached a specified
desired value. "Solver" is a more complex version of Goal
Seek than can manipulate several input cells in order to minimize,
maximize or equalize a specified output cell. Both tools can be
of tremendous help to someone using models to play-balance a game.
of System Models
use of reliable models to simulate game systems can be an invaluable
tool. When a model is well designed, it can point out significant
flaws in a game's balance. Additionally, models can help to design
encounters so that they are appropriately challenging for a variety
of different groups. This article has focused primarily on the methods
by which one can simulate and balance classes in RPGs, yet the application
of risk analysis techniques is in no way limited to just classes.
Every game system that is composed of any form of numbers and equations
can be simulated with a spreadsheet and a probability package.
the long run, the use of models and simulations will make games
more successful and therefore more profitable. In the end, profitability
is the main goal. Improved revenues will increase the resources
available to game design companies. This in turn will allow for
both enhancements to existing games and the funds required to produce
Note: All Excel models and figures used in this article are available
for those wishing to view them. Additionally, I am always interested
in discussing both the practical and theoretical application of
mathematical models to the design and balancing of game systems.
If you are interested in receiving the Excel files or if there are
any comments about the application of the above techniques, feel
free to e-mail me at firstname.lastname@example.org
or at email@example.com.