Jump to content

Welcome to Obsidian Forum Community
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. If you already have an account, login here - otherwise create an account for free today!




Photo
* * * * * 1 votes

tunin' tips and tricks

Posted by J.E. Sawyer , 09 November 2009 · 1722 views

politics of 14th century italian city-states
At work, I am often directly involved in an aspect of game design that not all designers really deal with: system and content tuning. This is the process by which system rules and content are adjusted to produce a specific effect for the player. E.g. you want the player to feel like he/she really gains a great advantage when he/she gets the raccoon tail in Super Mario Brothers 3, so you space out the frequency of raccoon tail powerups and you make sure that the raccoon tail's flight powers allow access to useful/valuable areas.

RPGs are often difficult to tune for a few reasons:

* There are a lot of statistics
* Many of the statics are derived/connected to other statistics
* There are subsystems that govern access to various abilities (e.g. class systems, racial abilities, etc.) that create a player desire for egalitarianism/balance between those subsystems

This won't all be coherent, but I'd like to write down a few basic rules that I have developed over time.

* Avoid allowing a base value to be modified by more than three inputs. That is, if you have a base damage value for something, you should ideally allow it to be affected by no more than three things. The fewer inputs you allow to modify a value, the more significant the effects of those inputs are. Additionally, the range is generally more constrained and predictable for a player. In turn, this makes tuning content easier.

E.g. how long you can hold your breath underwater. It's affected by your Constitution score, your Swim skill, and your Breathing Bonuses (a catch-all of non-stacking bonuses specifically for holding breath). As long as you know the max Constitution score, max Swim skill, and the highest Breathing Bonus, you know exactly how long a character can hold his or her breath underwater at any given point in the game. Because you only have three inputs to worry about, it's easy to track everything that goes into this system. Player attempts to min-max the system are limited to those three categories, which means that non-min-maxers can still be "competitive".

Now let's say you decide to expand this system. You allow all Breathing Bonuses to stack. A player can have a Breathing Bonus from up to three different perks and Breathing Bonuses on any/all equipment he or she can wear, up to eight "slots" worth. Even if the values used on these perks and pieces of equipment were relatively minor, the spectrum of minimum and maximum have increased dramatically. It becomes more difficult to predict where a character will be on this scale at any given point in the game, and the min-maxer has an extreme advantage over the casual player, making content tuning difficult.

* From a single value, avoid deriving multiple values in different subsystems. When you do this, you have created a complex balancing problem for yourself. The classic example of this is the ability score system in pretty much all editions of (Advanced) Dungeons & Dragons. Ability scores affect skills, the use of class abilities (e.g. a paladin's lay on hands), and various class-neutral statistics (hit point bonus from Con, AC bonus from Dex). Every time you adjust one of these skills, abilities, or statistics, you affect the value of the stat that has an input into them. Logically, any time you adjust inputs into the value from which these other values are derived, you affect the expected range of the derived values. The fewer things a single value affects, the easier balance will be for you.

* Do not create drawbacks that are "opt-out" for the player if it still gives some benefit to the player. I.e. do not allow the player to take what is ostensibly a "drawback" that gives them a bonus to a skill pool, or some other sort of gameplay bonus, unless that drawback is very difficult/impossible to avoid. When people want to specialize a character in something, they already know what they want to do. What they don't want to do is pretty much everything but that activity. "You gain +4 to damage with broadswords but -20 to damage with wooden dowels and light maces," contains an effectively worthless drawback. The only way the drawback would ever arise in gameplay would be through some asinine heavy-handedness on the part of the game designer -- for which the player will almost assuredly resent you. A more even-handed drawback would be, "You gain +4 to damage with broadswords but attack 20% more slowly when using them." The benefit and the drawback are both realized within the same activity. The player cannot reap the benefit without suffering the penalty.

* When making trade-offs between items/skills/abilities, those trade offs must actually feel different in application or the player's choice isn't very important. For example, in the above case of +4 to damage with a 20% lower attack rate, there should be situations in which more damage per hit = better and situations in which faster attack rate = better. For example, if an armor system is threshold based (subtracts a flat damage value), doing more damage per shot always means that damage has a greater chance of getting through armor. In this case, the +4 bonus is better when used against opponents with armor. Against opponents with high health and no armor, raw DPS matters more than damage per shot. In such cases, having a 20% faster attack rate may be better if it outweighs the DPS value of the +4 in the overall equation.

* Show the player what he or she is getting, even if they don't necessarily understand how the underlying math works out. When players invest in something, they have an expectation that what they are increasing is affecting something. Make sure that this is happening, and happening consistently. If you have some sort of weird logarithmic adjustments going on behind the scene without informing the player, the player does not know what he or she is getting. In a case where you have a system where all points on a scale cost a fixed value to buy, each point should advance the derived values by an equal amount (a linear increase) -- or the player should be informed about how things are actually being increased on your wacky scale.

Okay that's enough for now.




This post warmed my cynical old heart. It reminds me of the numerous times me and my best friend have gone out to the bar and brainstormed how we'd handle the games we'd like to see made. Lately Shadowrun has been on my mind the most (what with Smith & Tinker aquiring the electronic rights). It's strange that thinking about different business models can now excite me.
Photo
J.E. Sawyer
Nov 15 2009 05:30 PM
I'm glad anyone can take something away from this. Often discussion about mechanics revolve around specific examples in games. Over time a lot of these specific examples have fallen into patterns that I've found useful. Still, I find it hard to articulate the underlying principles without examples.
I thought it was unfortunate when D&D switched to a system where the base stats increase over time. It added another parameter to a complicated system that already seemed to have grown more organically than logically. Also, I never thought that system, created for tabletop gaming, ever translated well to computer games.

There are nine different Skill categories in my game, each of which hosts a variety of specific Traits. Some Skills give access to over a dozen Traits, while others only host a handful. Then again, some Traits are significantly more useful than others. In introducing dialogue skills, WotC tried to balance dialogue with combat with rogue-ish abilities with spellcasting and I think failed. Pretending dialogue is as important as combat in a computer game didn't work out, IMO. Trying to micromanage dialogue through stats was a mistake, IMO. If I tried to have an equal number of Traits for every Skill, I would end up making similar arbitrary and un-fun compromises. Instead, I will state up front that the typical effort to make everything numerically equal is not being made, and that the point cost for a Trait is directly related to both how powerful it is, and how frequently (depending on play style, of course) it will be of use.

November 2014

S M T W T F S
      1
2345678
9101112131415
16171819202122
23 242526272829
30      

Recent Entries

Recent Comments