Game Planning/Design – Pt. 4: GAME-BALANCING
Upon searching for resources on the subject of video game production and game project management I came across a little blog, by the name of “Game Design Concepts“.
Continuing on, I will be moving on to the final section in regards to creating a new game project: Taking the systems, characters, and content which you have created and play-testing in order to tweak and optimize the content.
Examples of tasks which play-testing accomplishes can be:
- Finding that game systems, contents, other main areas are lacking in power or balance given their placement within the game.
- Finding that the current characters and their interactions with the game-world as well as with eachother are less monumental/moving than originally intended.
- Finding critical bugs which allow for exploits of contents within the game resulting in unfair advantage (quick XP, quick resource accumulation, unintended quick progression/accumulation of other important game systems and areas of importance (ex. job/skill level-ups).
- Finding critical bugs which result in the player not being able to advance due to flaws in the game creation, or at worst, the game becoming completely unplayable due to scripting errors (memory leaks causing lag, infinite loops in code, system instability, etc.)
Anyhow, let’s continue!!
The Three Thoughts of Game Balance
- Transitive: aka. Using Mathematical Approaches
- Intransitive: aka. Using Your Designer Gut
- Fruity: aka. Using Uniqueness To Justify Unbalanced-ness
1. Transitive Approach
Summarizing all unique abilities, status points, and unique effects into a master list and assigning each a power level, “placing them on a cost curve”, is one of the fundamental and most basic ways to sort and attempt to balance various components of a game.
These assigned power values can then be used to create a total for a character, overall team rating, item, mission, monster, etc, and then can give an overall feel for the object’s total power.
For example, when looking at raw stat values, such as Strength (STR), in a system where 1 point in STR also gives other sub bonuses such as Physical Damage (P.Dmg) +2, Weight Limit +3, and can also help with meeting new weapon requirements (ex. Req. xx STR to wield), it can be agreed upon that raw stat values (STR, VIT, DEX, etc.) are more desirable than their bonus counterparts (+P.Dmg, +HP, +P.Def, etc.).
Using this example, we could assign the following, starting from the smaller portions:
+P.Dmg = 2 cost : 1dmg
+Weight Limit = 1:1 cost
Additionally helps towards weapon req’s = 1 cost
We could value 1 raw STR point with 4 overall cost.
Taking this example further, if we wanted to make an item with an overall cost value of 15, one example could be:
ITEM NAME: Broadsword
- STR +2 (8)
- P.Dmg + 7 (7)
or another example, for a Blacksmith/Merchant class who uses raw damage for their skills and also carries lots of heavy items…
ITEM NAME: Leather Rucksack
- P.Dmg +20 (10)
- Weight Limit +5 (5)
This method has resulted in two completed different items which without introducing other components (skills, characteristics, actual game systems, etc.) are completely balanced in terms of raw “associated power” levels.
2. Instrasitive Approach
Gamedesignconcepts’ WordPress blog outlines this as the following…
“The second method is an intransitive relationship between game objects, better known as a rock-paper-scissors relationship. In this case, there may not be a direct relationship between costs and benefits, but there is a relationship between the game objects themselves: some objects are inherently superior to others and inferior to still others. The game Rock-Paper-Scissors is the canonical example; none of the three throws is dominant, because each throw will draw with itself, beat one of the other throws and lose to the third one.
Note that transitive and intransitive relationships can be combined, as in the previous example. In typical real-time strategy games, units also have different costs, so a weak (but cheap) archer may still be defeated by a strong (and expensive) flying unit. Within a single class of units, there may be transitive relationships, but the different classes have intransitive relationships with one another.
Intransitive relationships can actually be solved, using matrices and some basic linear algebra. For example, the solution to rock-paper-scissors is that you expect the proportion of each throw to be equal to the others: there should be a 1:1:1 ratio. Now, suppose you modify the game slightly, so that each win with Rock scores 3 points, a win with Paper scores 2 points, and a win with Scissors scores 1 point. What is the expected ratio now? (It turns out the ratio is not what you’d expect; with optimal play on both sides, you would see 1 Rock for every 3 Paper and every 2 Scissors. The math required to do this is outside the scope of this course.) If you are looking for players to use objects in a certain proportion (with some being more commonly used than others), a well-balanced intransitive relationship is a good way to guarantee this.”
Good old fruity… in other-words, creating concepts (abilities, items, etc.) which are so unique that they are unable to be mathematically unbalanced, and do not fall in a “rock paper scissors” type of relationship such as the Intransitive examples.
Examples of this usually include skill effects which are completely unique to different characters’ own unique abilities.
A character with a unique power-up which affects the natural gold-increasing rate per minute, or one with changes the speed at which all units move by a factor of 1.25x. These effects operate completely independently, and while a general “power value” could be assigned, that value would be personally-derived, and not agreed upon.
“Since formal and numerical comparisons between objects cannot work, the only way to balance this is through excessive playtesting.”
“There are challenges associated with all three of these methods. For transitive relationships, everything relies on the designer finding the correct cost curve. If your math is wrong, it will be wrong for every object in the game; if you find one thing that is unbalanced, you’ll probably have to change everything. Transitive relationships are much easier to develop in retrospect after playtesting, than developing them ahead of time. Since so much relies on getting the math right, it also tends to take a lot of trial-and-error and therefore a lot of time.”