Everyone knows: Playtesting is important. And they are right: Playtesting is one of the most important steps in creating a polished game. Devs everywhere should praise their playtesting teams, but that is a subject for another day.

Today, we are talking about checking your math, both to fix issues before they get to playtesting AND to fix issues that playtesting would never catch. Don’t leave it all to your playtesters to fix your broken mechanics, they will not appreciate it. It turns out your math teacher was right when she said this stuff is important!

Math checking is a pretty simple thing to do. Think about white room examples of how the game should be played (which is a bit easier in video games than say, Tabletop RPGs where expected situations can vary widely) and crunch through the numbers. Let’s look at two examples of odd math quirks that could have been eliminated from popular games from big budget studios had they just run all the math:

# Example I: The Half-Inch skill from Dragon Quest IX

OK, for those of you who haven’t played this game (if you like RPGs, you should), the half-inch skill is this games version of stealing. Half-inch is cockney rhyming slang for pinching something, AKA Stealing. Anyway, that trivia aside, let’s examine how it works.

All monsters in Dragon Quest IX have two items that they drop. One is the common steal, and the other is the rare steal. The way the game checks it is at the end of the battle, first it checks the common drop rate. If that succeeds, it gives you the common item and the checks end. If it fails, it checks against the rare drop rate. If that succeeds, it gives you the rare drop. If it fails, you get nothing.

Now, the Half-Inch skill basically uses the same numbers, but it applies a bit of math to the drop rates. Each drop rate is multiplied by 2, and then modified by the users Deftness stat. The equation* is below:

**Steal Rate = (Drop Rate * 2)(1 + (Deftness – 51) / 474)
***Note: The actual equation is a bit more complicated, but is accurate for the situations presented below)

Once you have successfully stolen from an enemy, you can no longer steal from him again and will need to find another of that enemy to try again. As an example, if the common drop rate of an item was 1/16, the steal rate for a character with 209 Deftness would be calculated as follows:

**Steal Rate = (1/16 * 2)(1 + (209 – 51)/474)**

**Steal Rate = (1/8)(1 + 158/474)**

**Steal Rate = (1/8)(1 + 1/3)**

**Steal Rate = (1/8)(4/3)**

**Steal Rate = (4/24**)

**Steal Rate = 1/6**

Easy enough, even if its a weird formula. Now let’s say the rare drop rate on this one is 1/32. Plugging that into the same formula:

**Steal Rate = (1/32 * 2)(1 + (209 – 51)/474)**

**Steal Rate = (1/16)(1 + 158/474)**

**Steal Rate = (1/16)(1 + 1/3)**

**Steal Rate = (1/16)(4/3)**

**Steal Rate = (4/48**)

**Steal Rate = 1/12**

BUT, this isn’t the real chance of getting a Rare steal. Remember, it checks the common drop first, so the second equation only happens when the first fails, so multiply the 1/12 (chance of the rare check succeeding) by 5/6 (the chance of the common check failing) to get 5/72, which is the REAL chance that you will steal the rare item. So its easy to compare, let’s convert them both to percentages

**Common Steal Rate = ~16.66%**

**Rare Steal Rate = ~6.94%**

Nothing appears amiss so far, but let’s watch what happens when the skill users deftness increases. Say he has a Deftness of 999. Run through the calculations this would give us a Common Steal Rate of 3/8 and a Rare Steal Rate of 15/128. Converted to percentages that gives us:

**Common Steal Rate = 37.5%**

**Rare Steal Rate = ~11.72%**

Still looks good. Increasing Deftness made it more likely to get both. But let’s look at it from the perspective of someone playing the game. If you are trying to get a Rare Steal item, you are of course, going to find the enemy you want, then steal repeatedly until you get what you want from it (In fact, I tend to teach all my people Half-Inch to make this faster). So for each enemy you encounter, you want to know what the chances of getting each item are. The chance of getting the Common Steal if you steal until you get something for each enemy will be the Common Steal Rate / (Common Steal Rate + Rare Steal Rate). The chance of getting the Rare Steal is whatever percentage is left over. So let’s do this for both the 209 and 999 Deftness Rates:

**209 Deftness Common/Rare = ~70.59% / ~29.41%**

**999 Deftness Common/Rare = ~76.19% / ~23.81%**

So now isn’t that interesting. If you steal until you succeed, the lower your Deftness is, the more likely you are to receive the Rare item. Seems a bit counter-intuitive doesn’t it? So how could this have been fixed? Very easy, all they would have had to do, was make the Rare check happen first THEN move to the common check, rather than the other way around.

The issue with this one is that with all the percentages already being so low, the chances that a human playing the game could have realized this pattern is nonexistent. The only way this can be caught is by checking your math.

# Example 2: Back-dashing in Castlevania: Symphony of the Night

Have you ever watched a speed run of Castlevania: Symphony of the Night? Here I’ll link you to one. Skip forward to the parts where he is playing as Alucard. Notice anything weird? He backdashes EVERYWHERE. In Symphony of the Night, Alucard has a backdash move where he quickly moves backwards and has a slight pause at the end. It is useful for dodging things, but also, because of how fast it is, even with the pause at the end, it is actually faster than he can go running forward.

This one doesn’t need any math for me to explain. I mean, I could break down the number of pixels he moves backwards with a backdash combined with the total time for the dash and pause, and then calculate his rate of speed running forward, but there is nothing for us, after the fact, to learn from this. But the programmers originally creating it could have found this with the math. They had access to all the data needed before the game was even running. Playtesting could have caught this one technically, but it apparently didn’t (or maybe they didn’t think it was an issue!).

How could this have been fixed? Speed up his run going forward. Create a larger pause after a backdash. Have the backdash happen a bit slower. Any of these things would have made it so the fastest mode of travel wasn’t propelling yourself butt first at the enemy.

Now, am I saying that all quirks can be found by checking the math and playtesting? No, a few weird things can always slip through on every game. For that matter, I consider Dragon Quest IX and Castlevania: SotN two of the better games I’ve ever played. I’m sure they did a ton of math checking to make them as good as they are, and these small quirks slipped through. Playtesting can catch a lot, a LOT of the bigger issues. But true polish comes from stringent playtesting and meticulously checking your own math. You have the advantage that the playtesters don’t, you have access to how everything in your game works. Don’t ignore it.

Do you check your math enough? Ever caught anything in one of your games that came off a bit backwards that you didn’t expect? Or maybe you know of another game that had a funny math mistake in it? Join us in the comments section below!

5 comments… add one

Yes, math is one thing, but fixing it or not could be part of the greater game design.

The way I see it, for instance on the Castlevania example, it uses an amusing principle of increased risk-reward:

You can go faster by backsliding, but at the same time, have a loss of control of that short burst of sliding, i.e. you can’t jump while you slide. Mastering it is a challenge on its own.

Then again, these techniques are used on lots of games in speedruns. Think of Super Mario 64′s long jumps across the levels, snaking on F-Zero and Mario Kart. I don’t think developers aren’t busy trying to counter speedrun techniques, as they are usually found by the community, long after the game is released. And using them – trying to master them – while not intended by the developer, can be amusing and fun on its own for players into such things.

The Mario Kart series had Rubber Banding AI, especially Mario Kart 64, a technique to help bad players and challenge good players, by cheating. One of the clearest examples would be the racing minigame in Chrono Trigger, where two cars constantly cross each other, creating an intense race from start to finish.

This is true for Mario Kart too, where the first kart generally drives the slowest, the second one slightly faster, the third one even faster, etc. And if they switch places, they also switch speeds.

My point is, some players don’t like this mechanic and are going to the extreme to break this mechanic. It is not intended as the developers wanted, but the most important is, players should have fun. Game creators can create an environment where players can have fun, but they shouldn’t dictate how they should do so, even if this corrects their math.

For more information and examples:

http://tvtropes.org/pmwiki/pmwiki.php/Main/RubberBandAI

Oh, and for the Dragon Quest example, yeah, I agree there.

Yeah, I mentioned that they may have thought it wasn’t an issue. I will say it makes SotN speedruns practically unwatchable unless you mute them :P.

Interesting post! Although I know this isn’t the point of the article, I do have one DQIX-specific question: you mentioned that for the steal rate equation [Steal Rate = (Drop Rate * 2)(1 + (Deftness – 51) / 474)], “the actual equation is a bit more complicated”. Would you mind posting the complete actual equation? Thanks!

There is a x2 chance equipment item that is factored in if you have it equipped, and if you get over a 50% chance of drop for the common or rare it just stays at 50%. Without the x2 chance equipment item though, only the most common of drops hits 50%+

Right, “Honor Among Thieves” being that equipment item; I didn’t know about the 50% cap, though. Anyway, thanks a lot for the reply!