#caution: math

Not really, no. Indie games tend to be more exempt from the [80-20-5 rule] because their audiences are much, much tinier than AAA games that the randomness of distribution outweighs the statistical probabilities of large numbers. The larger an audience gets, the more the distribution will approach the normal [80-20-5 breakdown].

If you roll two six-sided dice and add the results together, you get a distribution like this:

There are more equally-likely combinations to get 7 (the average result) than there are to get 12 or 2 (the extreme results). This means 7 is a much more likely result. However if I only roll 3 times, it isn’t unreasonable that I get a 2, an 11, and a 12. It is only as the number of rolls grows that the overall distribution approaches the expected. Three rolls isn't enough to get a realistic distribution. A dozen rolls isn't enough. You'd probably need hundreds of rolls to approach the normal distribution with your results.

Think of each player in the audience as a roll of these dice. Many indie game audiences are so tiny that the randomness of the roll skews the outlier results. When your audience is literally dozens of people, single factors like a viral tweet or a single influencer mention can really skew the results. Compare this to the audience of a AAA game, which is typically in the millions. The millions of rolls smooth out those events and things approach the normal distribution where most players are in the middle. The large audiences of the wildly successful indie games also approach the normal [80-20-5 distribution].

Whether an audience follows the [80-20-5 distribution] doesn't have much to do with the actual content of the game. It's primarily a factor of the size of that audience and the way people tend to behave in large numbers. The smaller the audience, the more they can skew in odd ways.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Time to buckle up, because you’re going to learn some system design principles today. We’re talking about formulas and shape and effect of the curves that you get from graphing them out. This is probably the most important principle for system designers to internalize.

Instead of just picking numbers out of thin air, system designers create and work with formulas that take individual factors like character level, skill rating, stats from equipment, etc. and use them to calculate resulting values like damage, health, critical hit rate, etc. By tuning these formulae, we can establish baseline numbers for RPG content that will always generate reasonably correct numbers across all game levels. Then, because we have the formula to figure out the stats for us, we only need to tune and adjust the exceptions to the rule (e.g. a hard boss fight, an easy tutorial enemy, etc.) rather than all of the content. 

There are three basic curve shapes to consider when deciding what kind of growth formula we’re building: Linear, Quadratic, and Logarithmic. Each of these shapes causes a different feeling in the player for strength/power gain when plotted against time. We’ll briefly go over each of these curve shapes, the general formula for them, and examples of how they are used in games.

The first curve shape is Linear. Linear is the most simple - a constant relationship between stat and result. The basic linear formula is Y = aX + b where a is some multiplier and b is some constant baseline value. Linear curves gain power in lockstep with the input factors. This results in a feeling of constant power gain over time. It’s also kind of boring, because the experience will be similar (and predictable) every step of the way. This is the sort of growth you want for something to be reliable and safe. One simple example of a linear curve is hit points in Dungeons and Dragons. You get one die roll (or half of one plus the die maximum, rounded up) of HP per level plus whatever Constitution bonus your character has. You get the exact same boost going from level 1 to level 2 as you do from level 10 to level 11.

The second shape is Quadratic. Quadratic curves start off with small boosts initially, but grow rapidly later on. Their basic formula is Y = aX² + bX + c, where a and b are multipliers and c is some constant base value. Quadratic curves impart the feeling of starting off weak but growing rapidly - look at how much height was gained when going from 0 to 5 compared to 15 to 20. This can be good for things like enemy difficulty to make bad guys feel like they are rapidly gaining strength as they get stronger, or making the player feel like a demigod after leveling up from humble beginnings. This kind of curve for player power heavily encourages stacking this one thing. We also often see this sort of curve for experience points needed to level up - later levels usually require significantly more experience points than the early levels.

The third shape is Logarithmic. Logarithmic curves are effectively like a rotated quadratic curve - you start with large gains early on, but then they taper off over time until the curve approaches a constant (or linear growth). The basic formula for a logarithmic curve is Y = aX + b(log X) + c, where a is a linear multiple (the linear growth you want to approach), b is a logarithmic multiple (which affects the amount of early growth), and c is your baseline constant value. Logarithmic curves are great for things like diminishing returns on things - we start with big boosts, but additional stats don’t provide as big a boost as they did at first. This also lets you establish a limit that won’t be breached by the formula, so you know what kind of theoretical power maximum you can balance around.

These three curve shapes allow for a large amount of control over how things generally feel for a player. We designers can affect how experiences feel for the entire game by making small adjustments to these formulas. Then, if we have specific experiences we want players to feel, we can make individual adjustments and overrides to specific encounters to tune them up or down. But generally, we can use these curve formulas to establish the baseline growth for the entire game and everything that works within those formulas. That’s how we can balance an entire RPG - we have formulas that govern almost everything so we only have to make sure the formulas feel good and not each and every individual item.

PS. There’s even more work done when you see how these different formulas interact with each other. The difference in the rate of change between the formulas will affect how power level changes between the interacting systems. So, combining our linear hit point growth example above with quadratic experience points for level growth, it means that player hit point growth per experience can actually be derived with a (rough) logarithmic curve because you have more hit point growth per experience at the start than you do at the end. A good system designer is able to visualize how these formulas work with each other and how to translate one term into another by deriving formulas from each other.

[Join us on Discord]

The FANTa Project is currently on hiatus while I am crunching at work too busy.

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Distilling a few semesters of upper division university math into a single blog post is kind of hard, but I’ll give it my best shot. IK is short for Inverse Kinematics, so we’ll start with that.

Kinematics is the branch of mechanics that describes motion without considering force. It describes what happens when you hold your wrist and fingers still and then move your elbow. Your wrists, forearm, and fingers all move without any application of force on them directly, because they’re inheriting the motion from your elbow. Your elbow moves and all of the parts of your body that are attached to it move with it.

Inverse Kinematics is starting from the extremities and then working our way backward. If our foot gets placed on a solid object (like a stair step), it cannot go any further. This places a constraint on the bones further up in the hierarchy - our ankle can’t move because our foot can’t move, our knee can’t move because our ankle can’t move, and our hip can’t move because our knee can’t move. Each of these joints has an maximum range of motion, so by enforcing these ranges of motion as we go up the hierarchy, we end up with a legitimate pose for the skeleton where the foot cannot penetrate the stair step.

The math comes in when we’re figuring out the position and orientation for each of our bones. Our foot bone has a set transformation because we know it can’t move any farther than where it collided with the stair step. The ankle bone exists somewhere relative to the foot bone and has built constraints for how far and what angles it can move (e.g. a normal ankle can’t bend more than maybe 150 degrees in any direction), so we can figure out where the ankle should be relative to the foot bone. From there, we continue to go up the chain to the knee bone which has a position relative to the ankle bone that will inherit the new ankle bone position and take the knee bone’s set of constraints into account (e.g. knees can’t bend more than 180 degrees). The knee bone is connected to the hip bone, the hip bone is connected to the base of the spine, and so on up until the bone you’re supposed to move doesn’t need to move because everything under it is within the hierarchy constraints.

The IK math comes in when using these constraints and expected transformations relative to the child bone’s transform to calculate the transforms for bones further up in the hierarchy, until the displacement transformation from the foot not being able to step through the stair step is distributed among the bones constraints. In principle, we’re distributing the spatial difference between where we want the foot bone to be and where the foot bone has to be across all of the bones above it in the hierarchy - the ankle, knee, hip, etc.

[Join us on Discord]

The FANTa Project is currently on hiatus while I am crunching at work too busy.

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

That’s not usually because of IK. What you’re looking at is what’s known as ragdoll. Ragdoll is when we apply physics forces (like gravity) to bones in the animation rig (skeleton) and let the physics simulation take its course. Typically the rig’s bones are still constrained the same way as before - you rarely see bones bending the wrong way, but they often fall into positions that ends up looking unnatural when the skeleton is taken as a whole. This is usually a combination of things like rig bone constraints being much more simplistic than the actual bones and joints that we’ve all spent all of our lives becoming familiar with.

Here’s an example - the W-sit position (above) can be fairly uncomfortable for a lot of adults. This is primarily because of the way that our knees and hips are constrained by the muscles, tendons, and other physical bits. Our adult legs just don’t like bending this way as we get older. If our legs are folded and pointed in the same direction, we have fewer problems when sitting with our legs and feet pointing in the same direction:

This is generally a much more comfortable position for most people than the W-sit position. But it isn’t comfortable for everyone, and not everyone is as flexible with their hips and their knees. 

By contrast, In most animation rigs we don’t model the same subtle physical constraints on our hips or knees because we don’t need to. The hip bones in animation rigs tend to be ball-and-socket joints that are completely independent of each other. There aren’t any tendons or muscles or fat deposits to collide with in game animations. A character standing straight up on one leg while the other leg is in half of a W-sit position is a totally legitimate pose because the legs are usually independent of each other. It would look absolutely ridiculous, but it would be a legitimate pose within the rig’s constraints.

Normally, we use hand-authored or motion captured animations so the animators naturally avoid any weird movements or poses in order to make the motion believable. However, when we let gravity and physics take over, this can move the limbs into unnatural-looking combinations of positions, because these are the resulting positions that only take the rig’s simplified constraints into consideration.

Take a look at this memed example of ragdoll in action:

None of the character’s individual bones are actually moving in a way that breaks them. It’s more of a contextual thing - a human being with human muscles, bones, and tendons would not move this way, and we’re totally expecting him to behave like a human because he looks like one. But his shoulder doesn’t actually dislocate. His elbow doesn’t bend the wrong way. It’s just the aggregation of every little thing working together that makes it look weird. That’s probably what you’re remembering when you think about flailing limbs.

[Join us on Discord]

The FANTa Project is currently on hiatus while I am crunching at work too busy.

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

They are specifically asking for understanding of vector and matrix mathematics, and the ability to apply those principles to solve real game problems. This primarily means matrix transformations and core principles of vector geometry. Here are a few examples of where this might come up.

Imagine that you’ve been tasked with writing the very basics of a shooter. There’s a target in the world somewhere. The player has an orientation and position, and the target has an orientation, position, and radius. The player equips a hitscan weapon and shoots. [Does the shot hit the target?] How can you tell?

Imagine that you’ve been tasked with adding a “doppler” sound effect to projectiles like rockets as they fly through the air. You want the rocket’s sound effect to build up to its maximum volume and pitch when it reaches the closest point to the listener and then scale down as it moves further away. The rocket can be flying in any potential direction. How do you tell when to scale the sound louder or softer? When should it be at its maximum?

Imagine that you’ve been tasked with writing code that determines whether an opponent can see the player. You’ve got the player’s position and orientation and the enemy’s position and orientation. The opponent has an field of view of 120 degrees and a maximum view distance of 100 meters. Can you come up with a formula to determine whether the enemy can see the player?

Imagine that you’ve been tasked with attaching various visual effects to guns - muzzle flash, barrel smoke, sparks, glowy lights, etc. You have the player’s world position and orientation, and have access to the weapon’s position relative to the player and where the vfx should go relative to the gun. Can you figure out where the effects should be placed in the world?

Imagine that you’ve been tasked with adding laser trip mines to the game. A trip mine sticks to a surface and displays a laser perpendicular to the surface it has attached to. If that laser is broken by a player or NPC, the mine explodes. It can also stick to practically anything, including players and enemies. How do you figure out whether the mine should explode?

As you may have guessed, there’s a lot of math that goes into placing things where they should be, pointing them in the directions they should face, and moving them to places where they want to go. Vectors and matrices are the best-understood ways of mathematically modeling those kinds of behaviors in 3 dimensions. This is why a lot of game programmer roles require knowledge of 3D math.

The FANTa Project is currently on hiatus while I am crunching at work too busy.

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

It’s because they’re all simulating physics and things can get weird due to numerical error tolerances. Out here in meatspace, objects cannot interpenetrate each other because of how matter works. My hand cannot occupy the exact same space as other matter. Even if I stick my hand into an area occupied by gas, that gas is displaced by the exact volume of my hand. The gas particles and my hand cannot be in the same place at the same time.

However, in 3D game world space [there is no inherent sense of collision]. Objects can clip into each other without any trouble - we have to artificially (and externally) check to see if they *should* collide, and then do something like stop them from moving. The problem typically comes from the fact games have to use numbers in order to represent object locations and orientations. When you’re talking about numbers (especially with regards to things like angles), the chances of sticking to whole numbers like 1, 2, 3 are pretty much zero. You’re looking at values that are closer to 1.0001123 or 121881.10181891. Those numbers are typically represented by a “floating point” numerical representation, since they can represent both very large numbers and very small fractions. The problem with floating point numbers is that they get less accurate for very small fractions - you might look at a number and get 1.000000000000000000000001 at one point and 0.999999999999999999999999 at another. This is really only a difference of 0.000000000000000000000002, but it means that the position of things can shift at any time a tiny bit. That means that it is entirely possible that some objects will slightly interpenetrate each other at any given time. 

We build our physics systems to ignore small stuff like this. If it isn’t a big interpenetration, we’re probably fine so we can ignore it. But sometimes that difference is over the minimum threshold, and that’s when the physics system says “Oh, these objects have collided with each other. Let’s run our physics simulation on them to see where they go”. Then, depending on the physics simulation formula, we typically take things like the mass of the objects, the time frame over which the motion takes place, and the resulting force applied to each object in a specific direction (typically away from each other because it’s an equal and opposite reaction). Most of the time, we use the normal physics force formula: Force = mass x acceleration. Acceleration is generally (distance moved / time² ). The thing that usually makes the objects go flying super far is because of that time factor. Typically, the objects only interpenetrate for a frame or so, which comes out to ~1/60th of a second, or 0.0166 seconds. So if you move 1 centimeter in 0.0166 seconds, you’re looking at an acceleration of about 3,628 cm per second squared applied to your objects.

Basically, a small push that happens super duper fast has a huge amount of kick because physics. It’s also the cause of [the corpse volcano that I built] a few years back. And, since physics is physics and math is math, it happens pretty much everywhere regardless of the engine because math and physics aren’t engine-specific.

The FANTa Project is currently on hiatus while I am crunching at work too busy.

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Yes, there is a need, but perhaps not in the way you think. Most engineers and system designers need some math knowledge for their day-to-day (I occasionally use vector math and matrices as well as the equations that generate specifically shaped curves), but that sort of thing does not require a mathematician’s expertise. It’s pretty run-of-the-mill ordinary stuff.

No, the mathematician game developer usually stays in the fields of probability and expected value. Many games with randomized elements (especially those that involve monetary transactions, like loot boxes) need mathematical models constructed to produce results within a specific range. If you’ve ever looked at gacha game math, their systems tend to be quite complex under the hood! Let’s take a look at the gacha I’m currently playing, Fire Emblem Heroes.

The way their gacha system works is that there’s usually a base 3% chance to roll a featured gold hero for each banner, and then a base 3% chance on top of that for a random gold hero from the same pool. There’s a 58% chance for a silver hero, and a 36% chance for a bronze hero, summing to 100% total (36 + 58 + 3 + 3 = 100). Calculating expected value from this is introductory probability math. However, there are a number of other confounding factors that get thrown into the mix too. After every 5 non-rare rolls, both the focus and the rare rate increase by 0.25% while the silver and bronze are reduced proportionately. Thus, the more rolls the player fails, the higher the chance of obtaining a rare hero. After 120 non-rare rolls, the next roll is a guaranteed rare hero. How often does this occur? In a game with millions of players rolling dozens of time each, it is bound to occur sometimes.

This is just one way that the math is involved. One feature of the game is that, as new banners arrive, old characters who were exclusive to the rare tier can get demoted to the silver tier, making them much more likely to be summoned (since the chance of silver is a base 58%). Which hero should they demote? What are the chances of obtaining that hero in the silver pool? How much currency should it cost? Suddenly, these sort of additional maths become a lot more complicated. That’s just one probabilistic distribution. What about other ones to keep the players from getting bored?

This is just one system for one game. What should the distribution be for Overwatch skins be if we want players to open roughly X loot boxes to obtain them? How do we build player choice into this distribution such that they can obtain a slight edge by making informed choices, but still remain within the revenue target band? When giving out randomized rewards, how about a currency system to melt down duplicates and use them to obtain what you want? What about “foil” versions of cards like Hearthstone’s, and how do they factor in?

If you think that this sort of work veers very close to gambling, you’d be correct. This is also why slot machine developers hire mathematicians to calculate probabilities and math for features like bonus games, payout tables, etc. If you want to be a mathematician and work on games, that’s the sort of thing you can expect. Not every game needs a mathematician since most games don’t need complicated mathematical models, but this is the sort of feature we hire them for. If this sounds like something you’d be interested in, by all means go for it. If you feel like you’d be more interested in other sorts of tasks, perhaps you would be better served doing something else.

The FANTa Project is currently on hiatus while I am crunching at work too busy.

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Before we begin, I suggest reading this post I made a while ago about [screen resolution and just how much data we need to process for each frame] if you haven’t yet. There’s a little bit of math involved, but I think it should be easily understandable. You need a bit of understanding about how resolution informs the amount of data we need to process each frame. Got it? Cool.

The amount of data that we need to process as resolution increases at a quadratic rate, because we must increase resolution in two dimensions at the same time. We can’t just widen what we display, we have to lengthen it at the same time or it won’t fit right on the screen. Doubling the resolution results in 4x the number of pixels to process because the total number of pixels is length times width. This works in reverse too - halving the resolution means only ¼ the pixels to process. As you might imagine, because there are so many fewer pixels to process, downgrading the resolution results in huge savings in terms of calculations.

One of the things that we track in most computer programs is the time. We know what real time it was (down to the fraction of a millisecond) the game started, and we can track how much time has passed since then. Because we have absolute time markers, we can use it to find relative time markers like how long it took for each of the last X frames to render. If we know how long the frame rate took to render, we can calculate our frame rate: 1000 milliseconds divided by (X milliseconds to render the frame) = current frame rate. For 60 frames per second, X has to be around 16.66 milliseconds because 1000ms / 16.66ms = 60.02. For 30 fps, X must be around 33.3 milliseconds. If X suddenly jumps to 50 or 60 milliseconds (16-20 fps) and stays there, that’s an unacceptable frame rate. We have to intervene somehow.

When the game detects this situation (by checking a running average of the last X frame times each time it finishes a frame), it can ratchet down the resolution to decrease the total amount of data it needs to process. Then it runs as normal. The resolution change should affect the average frame time, which then gets worked into the running average. If the average frame time is calculated too fast, the extra time is spent idling and waiting until the next frame. The game would consider the spike to be over and can decide to return to a better resolution. The goal here is to keep the frame time in the sweet spot for the best resolution at the target frame rate. If the frame time is too fast, we increase resolution. If it’s too slow, we decrease it. 

This week we step into the Design Phase of the FANTa Project!

[What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr