     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Applying Risk Analysis To Play-Balance RPGs 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 feralone@attbi.com or at feralone@bellsouth.net. Resources Palisade's @Risk: http://www.palisade.com
[back to] Introduction |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Features
|
|
|