Attribute Weights

This section shows how to find attribute weights for the racing example from Chapter 11, “Attribute Numbers.” Table 12.1 shows how you would get a total score for each car, based on its attributes (refer to Table 11.1).

Now, you need to test these numbers in a game. For this example, you would race all three cars several times and find out which one wins most often and by what margin. Let’s say that in this testing, the muscle car wins every race by a significant margin. You are now seemingly stuck: The data is clearly not balanced if one car is winning every time. But if you lower either attribute value for the muscle car, its total won’t be as high as the totals for the other two cars, so you will no longer be able to compare them in the spreadsheet.

This kind of situation happens with game data all the time. It’s actually fairly rare for attributes to add up across balanced game objects to be the same. It often turns out that one attribute is simply more important in the context of the game than others are. In the case of our racing example, the more important attribute appears to be top speed.

If we add one more attribute to our cars, we can get an even better idea of how badly skewed raw attribute numbers can be. Table 12.2 shows an additional attribute, horn sound, and one more car.

If you simply look at the total raw scores for the car, it seems like the clunker is far and away the best vehicle. However, when you look at the attributes in the context of what they do in the game, you see a very different picture. This is a racing game, so the loudness of the horn is not important to the game, even if it is an attribute you can control. The problem is that attribute value is throwing off the total value of each car.

The solution to this problem is to use attribute weights. An attribute weight is a multiplier you apply to each attribute that compensates for some attributes being more important than others. When setting up the data at first, using 1.0 is a nice neutral starting point. It indicates that all attributes are equally important and lets you get through the data entry process more quickly. When you begin testing, you are likely to find that the attributes are not of equal value, and they need to be modified with weights. In the racing example, testing shows you that top speed is more important than acceleration, and horn loudness is not very important at all. You can use these observations to inform your first pass with weights, which might look something like this:

• Acceleration: 1.0 (Neutral. Not very important but not unimportant.)

• Top speed: 1.5 (Top speed is therefore 150% as important as acceleration.)

• Horn sound: 0.0 (This essentially removes horn sound from the total value equation since it is not an important factor for the game.)

You can now recalculate the weighted total for each car, as shown in Table 12.3.

With the new weights applied, the total value looks a lot more like the test results you see in the actual game. The muscle car always wins because it has a better total real value in game. The goal of the weights should be to represent the effect of each attribute in the game as realistically as possible.

The next step is to go back to the data and adjust it so that each car has the same total weighted value while retaining its own unique character. Given these goals, you can adjust the attributes on the other vehicles as shown in Table 12.4 to make them feel different from each other, hit your intended goals for the feel of the game, and use balance attribute weights.

With these new numbers, it appears as though you have reached all your goals—but there is only one way to find out. After doing a balancing pass with weights, you need to go back and test the feel of the game. If the game now feels more balanced, you can conduct some specific tests to find out how many times each car wins and by what margin. When you have that information, you can be more confident that your game is more balanced, and you will be able to add new objects to your spreadsheet and quickly get them into balance before ever actually placing them in the game.

One more factor we need to look at here is that the clunker is still way out of balance. This type of imbalance is not always a bad thing or something that needs to be fixed. This might be a joke car that was placed in the game, or it could be a punishment for a player who wrecks a car too often that will set up the player for almost certain failure. It could even be a challenge car that a very good player might pick to show that, even with the quantifiably worst vehicle in the game, they can still win. These are just some of the valid reasons to have data objects that are well out of balance. It is just as important that you know they are out of balance and by how much.

It is important to note that weighting can require some counterintuitive thought. In Table 12.4, you can see that speed is weighted 1.5 and acceleration is weighted 1.0, which means that speed is more important than acceleration in this game. It also means that the raw numbers for speed are likely to be smaller in total than the raw numbers for acceleration.

Let’s consider a more extreme example. Say that you are making an archery game where each archer has the attributes power and accuracy. Because a missed shot does no damage, you have determined that accuracy is twice as valuable as power. In this case, your attributes would get the following weights:

• Accuracy: 2.0

• Power: 1.0

This means two equal archers would have raw attribute numbers where the power attribute is higher than accuracy in most cases. It’s only once the weight is applied to the raw values that you can see which of the players is the better archer. For example, look at Table 12.5.

At a glance, if you don’t know the weights, Archer 2, who would have a higher total attribute summed score, looks like the overall better archer. But when you apply the weights, you can see that the two archers are, in fact, balanced (see Table 12.6).

Be patient when searching for proper weights. It can take dozens of tests—or more—in varying circumstances with multiple playtesters to determine the proper final weights to apply to your attributes. While this process should start very early in the production of data objects, it’s likely that it will continue throughout production and almost up to the end.

DPS and Intertwined Attributes

Very often, a single attribute tells only part of the story of the in-game interaction. The most common example of this is damage per second (DPS), where a series of characters have both a damage attribute and an attack rate attribute. Each of these has its own scale, with a minimum and a maximum. However, looking at only one part of the pair—that is, looking at only damage or only attack rate—does not explain accurately how powerful the character is. For example, say that you have a pair of weapons—a dagger and a battle axe—which have the damage scores shown in Table 12.7.

Which one of these weapons does more damage? Without any other context, the answer is fairly clearly the battle axe, but let’s look a little deeper. Table 12.8 shows how often each weapon can attack in a minute.

Now which weapon do you think does more damage? While individual hit damage has not changed, the total accumulation of damage output has changed considerably. Instead of asking how much damage each weapon does, it would be more helpful to consider how much damage each weapon does in a single minute. When you take into consideration both the amount of damage done and the frequency at which damage is done, you can get a much clearer idea of which weapon does more damage in a practical setting in the game. Because video game combat goes fast—usually in seconds rather than in minutes—we commonly express this value as DPS (damage per second).

But how do you determine DPS for two weapons that can’t attack every second? To do this, you need to take an intermediate step and calculate using a scale at which both weapons can do damage multiple times. For this example, we can use minutes, but any amount of time will work, as long as it’s enough for both data objects to have multiple attacks. To get the value, you need to multiply the damage of each shot by the frequency:

Weapon damage × Attacks per minute = Damage per minute

Table 12.9 shows the results for the dagger and battle axe example.

You can now clearly see that the dagger does slightly more damage over time. To translate damage per minute to DPS, you divide the damage per minute value by 60, using this formula:

(Weapon damage × Attacks per minute = Damage per minute)/60

Table 12.10 shows the results for the dagger and battle axe example.

With this calculation, you can now compare two weapons meaningfully, and in Table 12.10, you can see that over time the dagger will do slightly more damage than the battle axe. Note that the final DPS value has a decimal portion, so it is likely going to be used only for internal evaluation. If you wanted to represent this to players, it might be better to leave it as damage per minute or show it graphically as a bar chart.

The calculation becomes slightly more complicated when the frequency is measured in delay, as opposed to attacks per time. For example, for the dagger and battle axe, you might have a cooldown delay between attacks. To convert a cooldown into a per time measurement, you divide 60 seconds by the cooldown to determine how many times the cooldown can trigger in a minute. For example, a 3-second cooldown would be 60/3 = 20 attacks per minute.

While DPS is the most common intertwined set of attributes used in games, it’s far from the only one. The good news is that any given set of intertwined attributes can be treated in the same way as DPS for the sake of comparison. Let’s look at one more example that at first seems to be quite different. Say that you have forklifts that can carry pallets. In this game, quickly moving pallets is advantageous, so you want a forklift that can carry a lot of pallets. The other part of the equation is how many trips the forklift can take in a minute. The more trips, the better. Table 12.11 summarizes the capabilities of two forklifts.

Which forklift is the better one in terms of this game mechanic? To compare the two, you need to first calculate how many trips per minute each can make:

Speedy: 60/20 = 3

Big Brutus: 60/30 = 2

These are now your trips per minute scores. Next, you need to multiply the capacity by the trips per minute to get a total pallets per minute score. This gives you a final comparison that looks like what is shown in Table 12.12.

In this case, Big Brutus is the better of the two forklifts over the long run.

When using intertwined attributes, you often use the final DPS comparison score to evaluate weight in the total comparison of data objects instead of the individual attributes.

Binary Searching

Binary searching is a mathematical method of searching that enables someone to find an exact unknown number in the fewest possible guesses. Why is this important to you as a game system designer? You are constantly trying to find the right numbers for your data objects. By using binary searching, you can home in on the number you need more quickly, saving valuable time when creating large amounts of data.

Naming Conventions

When making even moderately complex games, you will generate numerous game objects— and which could easily get into the hundreds and possibly into the thousands. One of the most basic requirements of any game object is that it needs a name. Coming up with hundreds or thousands of names for objects can be a tedious task if you don’t have a standardized convention. Even more complex is tracking down and then working with a specific object that you have previously created that is floating in the sea of game objects. Even more challenging than that is finding and working with a specific object that someone else on the team has made. Try to imagine sifting through hundreds of objects that are numbered or named gibberish to try to find the one you are working on. It sounds awful—and it is awful. Now imagine doing this dozens of times a day, every day, for several months or even years. If you don’t have a good naming convention, this task becomes miserable and dramatically slows down work on the game.

You know what the problem is, but what is the solution? In the end, the most important thing about naming is to have one naming convention—and only one—for the team. There are many ways to name game objects, and many conventions can work. The important fact is that the entire team needs to agree to the rules of the naming convention it uses.

Let’s look at a naming convention that is data designer centric. It is made to help a data designer, who is usually the person most often modifying the data objects, find what they need quickly and keep the entire group of objects organized. To understand the system, first let’s talk about the English language a bit. English is inherently ambiguous in the way it describes objects. Let’s start a sentence in English as an example:

My game object is a big…

This is the start of a description, but it is not enough to give someone an idea what the object is. Let’s add another more:

My game object is a big, fast…

This is still not enough for someone to know what the object is; it could be any of millions of different things. Let’s add another word:

My game object is a big, fast, blue…

We are now three words into the description of the game object, and although we’re narrowing down the range of possibilities, it’s still impossible to know what the object is. One final word clears it all up:

My game object is a big, fast, blue narwhal (see Figure 12.1).

Aha! Four words into the description, and we finally have it: We are talking about a narwhal. The English description “big, fast, blue narwhal” does allow someone to picture what the object is, but it would not work well as a name in data design. Given that files automatically sort alphabetically on a computer, and most databases sort alphabetically by default, this name would sort by the first adjective, instead of by what the object is. Therefore, a basic English description like this won’t work very well as a name in a game.

In a very large collection of game objects, you would usually want to start names with a parent category. For example, you might start with the category sea mammals or, if you were playing the game as a narwhal, character. It is common to shorten the category name to a few letters for the sake of brevity and easier reading. If all category names are three letters long, for instance, then everyone knows that the object name starts at the fourth character. For this example, say that you are going to be playing as a narwhal, and you want to use the category prefix Cha (for character).

The following are some of the game object categories that are commonly used in games:

• Cha: Character, for playable characters

• Npc: Nonplayer friendly characters

• Bad: Enemy characters

• Pow: Power-ups, or useful boost items

• Wep: Weapon items

• Amr: Armor item (Note that this category name is Amr, not Arm, because arm is already a real word with a meaning.)

• Vhc: Vehicles

One of the first jobs of a system designer to create game objects is to create and maintain the names and definitions of object categories. Any lengths or convention will work, but for ease of reading, try to keep names fairly short and easy to understand. In creating a naming system, you want to find a good balance between getting very specific (with too many categories) and being too vague (and lumping together too many objects).

If your naming convention is for a large game with thousands of objects, you might follow the category with the subcategory. In this case, let’s assume the game is smaller and follow the category abbreviation with a noun that describes the game object. If the object is a narwhal, its name might therefore look like this:

ChaNarwhal

or

Cha_Narwhal

These two naming methods—using CamelCase and using an underscore—are both valid. CamelCase tends to be a bit shorter, but underscores can be a bit easier to read. For a small game, you don’t really need to worry that your game object name lengths will get out of hand, so you can use underscores. Both CamelCase and underscores work well, so you can choose either one; the important thing is to stick with the convention you choose.

If you are making a rather simple game, the object name Cha_Narwhal might be good enough. If, for example, there is only one type of narwhal, you would not need to go any further. However, say that you are creating a game that has several narwhal objects to choose from. In this case, you need more information to distinguish them from each other. At this point, you need to decide exactly how much granularity you need in order to describe your set of data. For the sake of this example, say that you have more than a dozen narwhals, so you need a name that is quite detailed. In this case, the next part of the name should be one word that describes the most important attribute of the object. It’s important that it be a description, and not a value, because it’s very likely that attribute values will change multiple times. You would not want to rename all your objects each time an attribute value changes. Instead, you want to describe objects in a relative manner. For this example, say that you have two class sizes of narwhal: big and small. For an object in the larger class, the name might now look like this:

Cha_Narwhal_Big

Now you can add the next most important attribute in the game. For this example, you might determine that speed is the next most important attribute and split the group into two classes: fast and slow. For a big narwhal character in the fast group, the name would now look like this:

Cha_Narwhal_Big_Fast

The name is now very close to a full description, but in this game, the characters can come in a variety of colors, so you want to add a final descriptor to make each name unique. For a blue narwhal with all the preceding characteristics, the name looks like this:

Cha_Narwhal_Big_Fast_Blue

This name may not, and likely will not, reflect all the attributes associated with this object. For this naming convention, you are not trying to cram in each and every attribute; instead, you want to pick just enough of the most important attributes to distinguish the specific game objects from each other. Cha_Narwhal_Big_Fast_Blue is quite a different name than the original description “My game object is a big, fast, blue, narwhal,” but it contains the same information, presented in a way that is easier for computers and data designers to work with. The order that this naming convention makes possible becomes apparent when you look at a larger group of objects, all names using this naming convention:

Cha_Narwhal_Big_Fast_Blue

Cha_Narwhal_Big_Fast_Green

Cha_Narwhal_Big_Fast_Red

Cha_Narwhal_Big_Slow_Blue

Cha_Narwhal_Big_Slow_Green

Cha_Narwhal_Big_Slow_Red

Cha_Narwhal_Small_Fast_Blue

Cha_Narwhal_Small_Fast_Green

Cha_Narwhal_Small_Fast_Red

Cha_Narwhal_Small_Slow_Blue

Cha_Narwhal_Small_Slow_Green

Cha_Narwhal_Small_Slow_Red

Cha_Whale_Small_Fast_Red

Cha_Whale_Big_Fast_Blue

Cha_Whale_Big_Slow_Green

Cha_Whale_Small_Slow_Red

This naming convention groups together all the narwhal characters so they’re separate from the whales. The fast ones are separated from the slow ones, the big ones are separated from the small ones, and so forth. Having a strict naming convention like this makes it dramatically more efficient to find the information you need and then to pass that along to anyone else who might need it on the team.

This is just one example of many different ways to form a good naming convention, and it is a solid starting point from which you can create the right convention for your game. In the end, the most important thing about a naming convention is that your team has one and that all the team members stick to it strictly.

Naming Object Iterations

Static, single-use names are not the only names in a game. Many objects need to have new names as they are revised. To properly organize all those names, you need to include a system of naming specific iterations of objects. It might be tempting to label a new version of an object new, but doing so is highly problematic. The good news is that there are better ways to get the desired effect.

Using the Handshake Formula

After you start creating game objects, you need a method of comparing them. For very simple games with few objects, this is simple: You take each variation of an object and compare it to every other variation. For example, if you were making a fighting game, you would have the characters fight against each other to ensure that they are all balanced in a fair way. If you were making a car racing game, you would race each car against all the other cars. If you were making an action game, you would want to compare each enemy AI type against every other enemy. This method of “brute force” testing and balancing works fine for very small games with a small number of variations. However, problems start cropping up when the number of game objects you create increases. Doing a full round of testing and balancing between two objects can take an hour or more for even a simple pairing—and that’s just for one round of testing. Making a full game often involves dozens of rounds of testing, tweaking, balancing, and rebalancing.

The first step in knowing how to deal with testing, tweaking, balancing, and rebalancing is knowing just how big the problem is. This is where the handshake formula comes in. The name handshake formula is based on an old mathematical riddle that goes like this: “A group of doctors are in a room together. To say hello, each doctor needs to shake the hand of every other doctor. How many handshakes does it take for any given number of doctors to shake every hand needed?”

You might wonder what this riddle has to do with balancing game objects. If you think of the handshakes in the riddle as a metaphor for how you test and balance objects against each other, it might start to make sense how useful this formula is to game designers. We can rephrase the riddle into language that is closer to home for game system designers: “A group of combatants are in a fighting game. Each combatant must fight every other combatant in the game to determine who is the best.” or “A group of cars need to race against each other to determine which is the best car. How many races would it take for all cars to race against each other?” While the outcome of the handshake formula might, on the surface, seem like nothing more than a bit of trivia or a curiosity, it is something system designers do constantly.

The handshake formula can be extended to larger examples (three-way races, group combat, and so on), but for now, we will focus on just two parties at a time. You need to think about how you will use the formula not for a single specific number but as a formula that you can apply to any number.

Any time you need to compare a number of objects to a group, you need to start with the size of the group. For the current example, let’s start with four. To compare any two of the group of four, how many combinations would you need? The very simple way to find the answer would be to combine each of the four with all four. This, mathematically means, squaring the number. You can also do this graphically in a spreadsheet, as shown in Figure 12.2; this is called a possibility grid.

Here you can see that if you list all objects in a row and also in a column, you can check off how many combinations there will be; this is the same as multiplying the number times itself, or finding the square. In this case, 4 squared is 16, so there are 16 combinations. This seems like a lot of combinations needed to do a comparison with just 4 objects, and indeed it is. There are several redundancies in the simplistic view of squaring the number that you can immediately eliminate. The first of which is a game object compared to itself. You don’t need to compare identical cars to know that they are the same, for example. If you look at every point where you would compare an object to itself, you find the clear pattern illustrated in Figure 12.3.

Object 1 is compared to itself in cell B2, Object 2 is compared to itself in cell C3, and so on in a diagonal pattern through the chart. In a fighting game, you know that Combatant 1 will be equal to Combatant 1, so you can eliminate the need to test that combination. Therefore, you can eliminate every point on the graph where an object would be compared directly to itself. In the case shown in Figure 12.3, this is 4 combinations. In fact, for any comparison, the number of eliminations will equal the number of objects you are comparing. So, if you were to compare 6 objects, you could eliminate 6 combinations, and if you were to compare 1,000 objects, we could eliminate 1,000 combinations. With this in mind, you need to update your formula to get rid of those unneeded combinations. This is the update formula:

(Number of game objects)² – (Number of game objects) = Unique comparisons

or:

G² – G = Unique comparisons

or, in this example:

4² – 4 = 16 – 4 = 12 unique comparisons

While this formula removes the redundancy of comparing objects to themselves, there is one more step you can take to make your comparisons fully efficient. In a fighting game, if you compare Combatant 1 with Combatant 2, do you then need to compare Combatant 2 with Combatant 1? No. You already did that comparison, but in the opposite order, and because order doesn’t matter in the comparison, you can eliminate any combinations that you have already done in the opposite order. Figure 12.4 shows this graphically in a spreadsheet.

Both highlighted cells in Figure 12.4 are making the same comparison because they are both comparing object 1 with object 2, and you need only one of these comparisons. You need to know mathematically how many of these redundant comparisons are left in the chart. Because you are comparing every object with every other object, and all the objects are listed in both dimensions of the chart, you will get twice as many matchups of each object as needed. For every time Object 1 is compared to Object 2, Object 2 will be compared to Object 1. The same goes for each other pairing. This means you can eliminate half of the pairings because they are comparing the same two objects but in the opposite order. Figure 12.5 shows the redundant comparisons that you can eliminate.

Because all the highlighted cells in Figure 12.5 are redundant, you can remove them from your count of combinations that you need to test and balance. Mathematically, this means you can divide your total combinations by 2. This leads to the final formula:

(G² – G)/2 = Total combinations to test

or, in this case:

(4² – 4)/2 = 6

To validate that the formula is working, you can count the number of Xs in your chart after eliminating all redundant combinations (see Figure 12.6).

As you can see, 6 is indeed the number of valid combinations remaining. Now that you have the needed formula, you can input any number into it and find out exactly the number of combinations you need to compare your entire set of objects. As one more example, Figure 12.7 shows 20 objects and the combinations you need to test.

You can see that no matter how large or small the number of objects, the pattern repeats. If you plug in the new number to the formula, you get the following:

(20² – 20)/2 = 190 combinations

If you wanted, you could count the number of Xs in the chart and arrive at the same answer to verify, but doing so would take more time than using the combination formula. There is another way to do this formula that takes a little longer but that shows a very interesting pattern. To illustrate, let’s solve for the numbers 1 through 20 (see Table 12.14).

Notice that if you add the number of objects with the number of combinations, you get the number of combinations for the next greater count of objects. This means that if you know the formula for any number, you can quickly figure out the result for the next larger number by adding the number of objects to the number of combinations. If you wanted to extend this chart up to 21, therefore, you would add 20 to 190, for a result of 210 combinations.

When you know the number of combinations you are dealing with, you can use this information to more accurately calculate how much effort will be needed to check and balance these combinations. For example, if you know that it takes an hour to properly test and tune a single combination, you can figure out how many hours you need to account for in total.

In addition to using the combinations formula for testing and balancing, you can use it in the following ways:

• To make a round-robin tournament where every player plays every other player

• In a fighting game, to create a special victory animation for each combination of combatants

• In a racing game where a voiceover announcer says a unique line for each pairing of cars before the cars start the race

• In a superhero game where two of heroes combine their powers to form a special power that is unique to that combination of characters

• In a fantasy RPG, where each combination of character classes has a unique bonus when played as a team

• In a combat game, to create a special animation for each combination of attack and defense

In addition to using the combinations formula to manually figure out how many combinations you need to test, you can use a spreadsheet shortcut function that does this math for you. This function, COMBIN, takes two arguments: the number of objects in the dataset and the number of objects in a combination. For all of the examples in this section, that second argument has been 2 because we have been combining only two objects at a time. However you can combine more than two objects with one another to get a significantly larger number of total combinations. Using a spreadsheet formula makes it possible to easily calculate these larger numbers of combinations.

Further Steps

After completing this chapter, you should take some time to practice in the real world with the concepts covered here. Try these exercises to further explore concepts covered in this chapter:

• For some real-world examples of game objects, list their attributes and try to assign weights to those attributes. Try to do this for a variety of different objects and use the objects that you have created from previous chapters.

• Create a naming convention for game objects—either objects you have made or preexisting games objects. Take the time to figure out how many attributes need to be contained in a name and in what order they should appear.

• Use the handshake formula to determine the number of combinations in several actual scenarios (for example, your favorite upcoming sport or a game tournament you follow).