How often do players and game magazines compliment a recently released game by saying that it's "well balanced"? How often do they say this about products that have been out for years? In the real-time strategy (RTS) and role-playing game (RPG) genres, the answer to the first question is seldom, if ever. In the case of massively multiplayer online role-playing games (MMORPGs), the answer to the second question is not as often as they should.

Good game balance is, in many ways, the holy grail of game design. Companies invest significant time and resources in attempts to balance their games so that they're neither too hard nor too easy for players. These efforts can be a significant drain on a company's resources, since designers and engineers working to solve balancing problems aren't adding functionality. Instead, they're spending valuable time reviewing the same equations or lines of code in an attempt to determine why, for instance, one character class consistently outperforms another.

Unbalanced games hurt development companies in other ways, too. An unbalanced game frustrates players and generates negative publicity and reviews. Both of these situations negatively impact game sales and/or subscriber retention levels, which in turn decreases the cash flow to the publisher and developer, and restricts the capital and resources available to those firms. Without those resources, the ability to improve the functionality and features of existing games is limited. Additionally, the funding available for the development of new games is decreased.

Developing AAA games titles is a multi-million dollar expense and the costs continue to rise. On average it costs three million dollars to release a title, and MMORPG development costs easily exceed ten million dollars. This is all upfront cost and does not include the post-release expenses incurred as designers and engineers attempt to remove bugs and balance their games. In the case of some games, the post-release expenses can be quite significant. Much of the post-release costs stem from ineffective balancing during the initial design, alpha and beta phases. Fortunately, the proper application of risk analysis techniques can help you in two ways. It can reduce development time, and therefore costs, and also increase sales and subscriber levels due to positive word of mouth.

Probabilistic and Risk Analysis

At the most basic level, an RPG is simply a large collection of numbers and equations. As such, an entire game could be developed using only a spreadsheet program, such as Microsoft Excel, and a probability plugin, like Palisade's @Risk. @Risk is a commercial add-in designed to work with Microsoft Excel. The program allows a designer to exchange uncertain and variable values for @Risk functions. By doing so, an entire spectrum of results can be observed instead of a simple average value. The use of @Risk and Microsoft Excel allows one to model and analyze critical game systems.

Of course, a game created with only a spreadsheet and probability package would lack the meaning, context, and emotion that an RPG brings to players. However, such a game contains the same fundamental systems that allow players to advance and evolve within online games, with the benefit that meaning, context and emotion are stripped from the game. By focusing just on the underlying combat algorithms, systems can be developed and modeled rapidly and simulated thousands of times in order to determine the likely outcome of a situation. By analyzing these outcomes, truly balanced games can be created.

Risk analysis techniques work the same irrespective of the industry they're applied to, and the desired results are even quite similar. Just as the petroleum industry might try to predict future utilization of fixed assets, a game developer might attempt to predict future results of a given game situation. In the petroleum industry, data models supply executives with information so they may make cost/benefit decisions regarding the assets. Similarly, a combat model for a game helps a designer predict the outcome and see if adjustments need to be made to races, classes, and groups such that balance is achieved. In both cases, risk analysis techniques decrease uncertainties and allow the maximum potential to be reached.

While this article focuses primarily on RPG gaming systems, the application of risk analysis techniques can be used to play-balance games within most other genres. Real-time strategy games are excellent candidates in particular, due to the variety of combat scenarios that need to be tested. Where risk analysis modeling is not applicable are relatively simple games such as platformers and side-scrollers, since the systems that players interact with in these games do not generally contain systems that are worth modeling - they can be balanced by the designer through simple trial and error.

Origins Of This Article

(Editor's Note: This section amended at author's request on 6/16/03.)

The origins of this article began after making observations of Asheron's Call 2 (AC2) during its beta and retail stages. While reviewing the game's pseudo-class-based system and its associated skills, inconsistencies were observed in the balance of certain game systems. Through correspondence with AC2's program manager, Matthew Ford, it was discovered that while AC2's developers tuned game balance by using numerical analysis techniques common to MMORPG development, neither AC2 or any other MMORPG in Ford's knowledge used the deep risk analysis methods described in this article. I found this interesting; it explained the degree of specialization, class, and realm/faction imbalance found in many retail products.

In my correspondence with Ford, we discussed the concepts behind risk analysis and its practical application for MMOPRPGs. We also examined the predictive benefits gained by modeling and testing MMORPG systems. Ford agreed that any MMORPG would find this risk analysis a "valuable companion to traditional mathematical tuning methods"; he particularly saw it as a well-founded way to catch unexpected consequences created by seemingly unrelated changes to game balance values. Ford also agreed that this method could be a good way to rapidly iterate experimental game dynamics in the early stages of a game's design, as well as refine game balance in the later stages of development.

Significant Game Systems

When designing an RPG, numerous systems need to be developed and balanced. Many times what appears to be ideal on paper is found unacceptable when actually applied in game, as small differences in skills, spells, or other abilities become pronounced in the course of using them thousands of times. Some of the systems that need to be balanced in RPGs include:

This list is just a fraction of the systems that need to be designed and balanced in a successful RPG. And to make things even more complicated, someone trying to balance one game system may unwittingly unbalance another, since game systems are not always discrete elements. Most systems interrelate, and adjustments made to basic areas like player races and classes have the potential to affect every facet of a game.

Developing a Model

In order to apply risk-analysis techniques to game balancing, a base-case scenario is required. In the case of a combat system, a base case represents a typical player character of predetermined level/class/race/etc. For an existing game, care should be taken to gather data so that an average player character can be simulated. If balancing is attempted prior to the stage where the game is playable, then designers should use both personal experience and future expectations to develop a base case that accurately reflects what they want to see in the completed game.

Qualification of Input Parameters

Once the base case is determined, all of the constants, variables, and equations contained by the system need to be quantified:

When designing models, a caveat exists: a model is only as good as the data fed into it. When inaccurate data or equations are placed into a model, the results generated by that model will be inaccurate and irrelevant. "Garbage in, garbage out," is a frequent adage. It is therefore important to understand both the range of conditions available in the game system as well as a practical understanding of player tendencies and minimum/maximum potential.

If a model was being developed to tweak the success rate between a basic melee player character and a basic melee monster, it might require the following for each:

Model Requirements:

The above represent only a partial listing. If systems within a game are affected by features such as the time of day, or other outside factors, then the model will require inputs for those elements. Simple games require fewer inputs in order to generate meaningful results. The converse is also true - complex games require more effort and control when developing a model.

In order to create more accurate models, most of the above requirements should be inserted into the model in the form of variables. The use of variables, as opposed to constants, allows for a range of conditions to be observed. If, for example, players can vary their primary statistics between values X and Y, then the model should account for that. By factoring variations into a model, designers will not be limited to results provided by constant average values.

Once all the constants, variables and equations have been quantified and input into the spreadsheet, it is time to run the simulation. The number of trials performed is arbitrary and up to the modeler. The more trials conducted, the more even distribution you'll get, and therefore you'll get more accurate results. However, especially in the case of exceptionally complex models, conducting trials takes time. In general, a simulation containing five thousand iterations is adequate. This limits the effect of any given iteration to only 0.0002%. If unaccountable outliers are observed, the number of simulations performed can be increased in order to smooth the curves.

Comparing Results to Design Objectives and "What If" Scenarios

Once a simulation is complete, the results can be analyzed. One of the primary benefits of risk analysis software is the ability to observe cumulative probability graphs for specified outputs. Cumulative probability graphs illustrate the percentage chance that an outcome Y will occur at least X percent of the time. In the case of combat between a basic player character and a basic NPC monster, designers can observe the hit point variations each round for the duration of combat. Figure 1 shows a sample cumulative probability distribution for melee hit points, and illustrates the benefits.

Tabulating the chance of death each round allows designers to observe the likelihood of a combatant dying on a round-by-round basis (see Figure 2). Naturally, subtracting the chance of dying from the value 1.0 produces the chance of survival (e.g., 1.0-.6=.4, or 40% chance of survival). In a fight to the death (which most game battles are), survival of the player character indicates that the enemy was dispatched first. In the case of PC vs. NPC combat, plotting the chance of NPC death and one (1) minus the chance of PC death displays the likelihood of victory or loss each round. The point where these two lines intersect is the expected outcome of the fight. If, on a plot containing the chance of NPC death and one minus the chance of player character death, the lines intersect at sixty percent (60%) in round twenty-five (25), then the player character will have a sixty percent (60%) chance of victory in any single combat against that NPC. This intersection point can be compared to the desired outcome of the combat simulation. Desired outcomes might be:

· A 75% chance of beating an equal level monster using no special skills or styles
· A 95% chance of beating an equal level monster using optimum level skills and abilities
· An average of 60 hours spent crafting before a trade skill reaches its maximum
· A 40% chance that one class will beat another class using optimum skills/styles.

If the desired outcome and the simulation results are equal, the system is balanced and a designer can move on the next simulation. If the simulation result and the desired outcome are unequal, then adjustments need to be made to some part of the system.

When attempting to balance a combat system in this fashion, the process is reminiscent of supply-and-demand graphs used by economists. On a supply-and-demand graph, certain factors shift the curves in various directions. The same holds true for the victory and defeat curves. By varying constants or equations, such as weapon damage and "to hit" rolls, it is possible to horizontally translate one or both of the curves. By adjusting inputs until the point of intersection occurs at the desired outcome, the game system can be balanced.

The benefit of an effective model is that it not only lets you balance specific classes and encounters, it also lets you explore limitless "what if" scenarios. For example, suppose that player dexterity affects the "to hit" roll, damage roll, and blocking chance. If a designer wants to increase player damage by increasing a class's dexterity, he has to worry about the effects on the "to hit" roll and blocking percent. If a designer wants to increase a race's base dexterity, he needs to consider the effects of this change on every other class in the game. However, if a model was already developed, it would be a simple endeavor to increase the dexterity of the class or race in question, re-run the simulation, and determine whether the dexterity increase threw off the balance in relation to other classes, races or NPCs.

Model Use from the Design through Retail Phases

In each stage of development, the benefits of models change. In the design, or pre-alpha phase, the use of models accomplishes two goals:

In the alpha and beta phases of development, the theoretical results produced by models can be compared to actual player data. Variable distributions such as player's primary statistics, skill points allocations by level, and randomly generated loot distributions can be refined so that a model's input factors are appropriate. Additionally, during this phase of development, assumptions within the model regarding player tendencies will be validated or invalidated. By comparing the model to actual in game results, a model can be refined and made much more accurate.

When testing a retail candidate, results generated by models can be compared to in-game logs. The greatest benefit is in regards to the ever-present player complaints regarding overpowered classes. By comparing in-game logs with simulated model results, designers can definitively state whether a character class is functioning as intended. When in-game results differ from simulated results, models can help find bugs within the code.

Who Designs the Models?

There are two logical ways for a team to assign the task of modeling game interactions. The first option is to have the various system designers on the game development team create their own models. The second option is to have one team member responsible for developing a comprehensive model for the entire game. In the latter case, the model will be based on information that the various system designers provide. Both options have their pros and cons:

Benefits/Drawbacks To System Designers Creating Their Own Models:
+ The modeler has a comprehensive understanding of the system modeled
+ The ability to change and adjust inputs at will in order to observe the outcome
+ Greater understanding of how input variables shift the curves
- Designer may be less familiar with Excel and probability distributions
- Parallel and interrelated systems may not be contained within the same model
- Design leads are required to review the output from numerous sources

Benefits/Drawbacks To Assigning One Person To Model All Systems:
+ It generates a cohesive model containing all the game systems
+ The ability for systems designers to view the outputs for all systems at once
+ The ability for changes affecting the entire game to be analyzed from one place
+ Designers need only speak to one person to review parallel systems designs
- Necessity for full and open communication between the modeler and the designer
- Modeler may end up with more input on balance than a system designer can accept
- Only one person intimately understands how game systems are modeled

It's up to the lead designer to decide how the team should be structured. As both setups have their positive and negative aspects, the design lead should choose the one that will best fit the team's leadership style and corporate culture.

Limitations of Computer Models

Unfortunately, the use of spreadsheet models and the @Risk add-in does not guarantee balance in a game. Player interaction models are simply a method by which real game results can be predicted. It's up to the designer to analyze the simulation results and determine whether they are acceptable. As previously mentioned, a simulation's results are only as good as the model that produced it. The two main drawbacks of spreadsheet models are:

In the case of the first drawback, it is imperative that the person designing a model be very familiar with not only the systems being designed, but also the ways in which players utilize their character's skills and abilities. Models attempt to predict the outcome of a given scenario. If a player, or group of players, approaches that situation in a completely different fashion than the developer originally anticipated, the model would be invalid.

A good example of this exists in Mythic's Dark Age of Camelot. The traditional Player vs. Environment (PvE) leveling group was composed of tanks, mages and healers. (A "leveling group" is a term applied to any number of players who actively play together with the objective of killing monsters in order to gain experience and thereby increase their character's levels.) Advancement rates for a traditional group could easily be modeled and determined if one expected players to utilize groups similar to this in PvE combat. However, the rise in popularity of the enchanter class, and their pet pulling techniques changed the leveling dynamic significantly.

(In Dark Age of Camelot, the enchanter class within the realm of Hibernia is a pet class. The player character is able to summon an NPC pet that can be loosely controlled by the player. Enchanters possess a spell line called "Damage Shield (Focus)." The "focus shield" can be cast and maintained on the enchanter's pet provided that the enchanter does not move, take damage, or attempt to cast any other spells. While the focus shield is active on the enchanter's pet, any PCs or NPCs damaging the pet will receive damage from the focus shield. Additionally, the focus shield generates massive amounts of "agro" as it damages NPC monsters. "Agro" is term used to describe the relative aggression that NPC monsters feel towards different players. In general, agro values are created and increased as damage is dealt to the NPC as well as when healing spells are cast upon PCs. The game's AI generally compels NPCs to attack the player character with the greatest agro value. In the case of enchanters and their "pet pulls" and focus shields, the enchanter's NPC pet constantly maintains agro.)

Instead of a traditional group composed of several melee characters that could absorb damage and generate agro (thereby maintaining the NPC monster's focus upon the melee characters), the typical group composition changed to include a greater number of mages. Given that mages generate the majority of the damage dealt in PvE combat, monsters were dying significantly faster than expected, and the rate of player level advancement increased. It would have been unlikely for the original model to include a simulation such as this. Therefore any encounters that were designed based on "traditional" group models were invalidated, as the enchanter method of leveling is completely different.

When player tendencies change like this, models should be revised to account for the new play patterns. In this way, adjustments can be made to game systems to ensure that the original design objectives are maintained.

In the case of incorrect inputs, this can occur in several situations. When inserting variables into a model, the modeler attempts to generate results for an average player. If the modeler's notions of "average" are inaccurate, then the results generated by the model will be invalid. It is therefore important to obtain real player character data in the alpha and beta phases and compare that data to a model's input distributions. If the real data differs from the model's inputs, then those inputs should be revised and the simulation rerun to check for any changes in the expected outcome.

Practical Model Design

When developing RPG systems, the models should be as complex as the game systems themselves. Irrespective of a system's complexity, the fundamentals of developing and balancing a game system remain the same. In order to demonstrate the methodology by which risk analysis principles can be used in games, I've devised an example. It's an extremely simplistic combat system, which will be modeled and then balanced. Two example scenarios will be reviewed with the first scenario serving as the model's base case.

The base case for this system is a one-handed sword/shield melee versus a two-handed sword-wielding melee. The objective is to model the system and determine how to adjust the system such that when this kind of duel occurs, either character has an equal chance of winning. The second scenario pits each of the two melee types (from scenario one) against an NPC monster of the same level. The objective is to balance each of the two player characters in relation to the monster without changing either of their design templates. The overall goal is to design the characters such that they possess a 75% chance of winning the fight against the NPC monster.

The sample combat system is exceptionally simple due to the spatial constraints of this article. Nevertheless, a more complex system using multiple factors affecting "to hit" rolls, positional attacks, variable speed weapons, and critical strikes would be no more difficult to balance.

Design Parameters

In this basic system, the following constants, variables and equations were used.

Constants:

Variables:

Equations

Character level was arbitrarily defined as 50 in the model. The skills assigned to each of the two characters were limited to their primary weapon type and primary defense mechanism. Armor factor was set to 200. Initially the weapon damage and variance were set to 24.3 and 1.5, respectively, for the one handed melee. For the two-handed melee weapon, damage and variance were set to 31.3 and 1.5, respectively.

In the basic character template, the only variables defined were primary character statistics. A system was adopted where each of the four primary statistics had a base value of 90 points. Players could allocate an additional 60 points between the four stats with a maximum of 25 to any one statistic. In order to simulate player choice, a truncated chi squared function was used. The mean value was set at 15 points per skill, with a median of 14.86 and a mode of 14.04. The distribution was truncated on the low side at 1 point per statistic, and on the high side at 25 points per statistic. In order to ensure that exactly 60 points were distributed among the four primary statistics, distributions were applied to only three. Quickness was left as a simple summation function that equalized the overall statistic point expenditure at 60.

The equations used in the simulation were mainly related to the character's primary statistics and skills. Hit points were based on a function of character level and constitution. Damage absorption was directly related to armor factor (a constant) plus the character's variable constitution amount.

The "to hit" roll was calculated as follows. Dodge was directly related to a character's quickness, such that an average of 10.5% chance to dodge existed. The blocking chance related to 80% of shield skill, while parry was set to 60% of the base skill level. The dodge, blocking and parry chances were added together and then subtracted from 1.0 in order to determine the percentage chance of each character taking damage.

The last two equations deal with weapon damage and damage variance. A primary statistic modifier was developed that would affect both weapon damage and variance. The modifier was based on the root-mean-square of strength and dexterity. In turn, the actual weapon damage was a function of the primary statistic modifier, the weapon's base damage, and also the character's weapon skill. Weapon variance was related to only base variance and the primary statistic modifier.

When modeling the combat rounds, a uniform distribution between 0-1 was used. This provided the information needed to determine if a hit was successful. A uniform distribution was also used to determine the damage dealt each round. This distribution ranged between the weapon average variance subtracted from average weapon damage, and the weapon average variance added to the average weapon damage. IF statements were used to track the hit/no-hit rates in each round and therefore determine whether damage was taken. Finally, the hit points of each character were tracked on a per-round basis.

As weapon damage and variance were the only factors adjusted when balancing this model, their initial values were determined by multiplying weapon damage by evasion chance and absorption factor, and then dividing into the character's hit points. The average number of combat rounds desired for combat resolution was 30.

Analyzing the Results

Initially, 2,000 iterations of the model were performed, but limiting the samples to a range this small displayed unacceptable variances in the simulation results. The variations observed in the low iteration trials are shown in Figure 3. In order generate more consistent and natural results with Monte Carlo sampling, 5,000-10,000 iterations were required. Consequently, all further simulations were run with 10,000 iterations.

By increasing the number of iterations performed for each simulation, variations in the probability curves disappeared and simulation results returned consistent values. The results of the one-handed vs. two-handed melee trials are shown in Figure 4a and in Figure 4b. Information presented in these two figures represents the percentage chance of either melee winning the combat in any given round. As Figure 4a shows, prior to round 22, there is almost no chance of that either character will die. In the twenty-third round, the one-handed melee has a 5% chance of death while the two-handed melee's remains at 0%. During round 24, the chance of death for the one-handed melee has increased to 10% and the two-handed melee is observed to have a 5% chance of dying. In the 30th round, the fifty percent 50% mark is reached. The point where the two lines cross is the balance point. From this point, the expected outcome of any given fight is obtained. If the junction of the two lines occurred at 60%, then the two-handed melee would have a 60% chance of winning and given battle, while the one-handed melee's chance of success would be 40%.

It is important to observe the similarities exhibited between the two curves. In the base case involving the melee combat between a one-handed weapon and a two-handed weapon, the general slope of the two curves is the negative value of the other. This trend is not always the case. By adjusting the inputs into the model, it is possible to change the slope. An example of this is shown in Figure 5. In that graph, the junction of the two lines continues to occur at 50% in round 30. However, the slope of the two curves is no longer the negative value of the other. The two-handed melee weapon has a 100% chance of killing the one-handed melee weapon by the 40th round. However, the one-handed melee weapon only attains a 75% maximum before death. On the low end of the scale, the one-handed melee weapon is observed to have a chance of killing the two-handed melee weapon earlier. However, these two do not balance out. Calculating the area under each of the two curves between rounds 15 and 40, the areas add up to 9.4 and 8.5 for the one-handed and two-handed melee weapons, respectively. This indicates that the one-handed melee weapon is more likely to win in single combat.

The ability to modify the slopes, and therefore the overall probability of winning, is an advantage when designing skills and abilities for classes of different types. When comparing a melee character to a mage, archer or other ranged character, variables and equations can be adjusted to balance range versus damage and differing absorption.

Scenario 2: 1H and 2H Melee vs. NPC Monster

Now 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.

The 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.

In 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.

The 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.

The 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.

More Complex Scenarios

These 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.

Variable Combat Speeds

In 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.

The 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.)

The 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.

The 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.

Ranged Combat

In 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.

Styles, Spells and Special Attacks

The 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.

Persons 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.

Group Combat

Devising 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.

When 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.

Table 2: Character definitions

The 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 article.

Tornado Charts and Sensitivities

A 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.

Additional Excel Features

Both 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.

Overall Benefit of System Models

The 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.

In 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 new games.

Author's 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 [email protected] or at [email protected].

Resources

Palisade's @Risk: http://www.palisade.com