Designing with Physics: Bend the Physics Engine to Your Will

Everybody. All right. So, I think one of the things that's changed a lot over the last few years in independent game development is physics engines used to just be this gimmick that was used for games like Stair Dismount. But, they're now used in a lot of indie action games. And I think maybe even most of them, right? So, so indie developers used to roll their own really simple arcade style physics from scratch. But, I think most people now, probably most of the people in this room, just use an engine like physics or Box2D cuz that's what comes rolled into Unity or Unreal or whatever it is that you might be using, Cocos2D. And the downside of that is it's hard to get a modern physics engine to behave just how you want it to, right? So, indie teams don't usually have a a physics expert. They probably don't even have a person who gets the basics of how the physics engine works under the hood.

Uh we're just a bunch of designers messing around with middleware. So, you know, we're starting to see a lot of games, I think, with physics that are glitchy or unreliable or, you know, much more often than that, uh the kind of dreaded word game games that are floaty. And floaty isn't a precise term, right? Like that's that's a vague term. It's just a vague feeling you get when you're playing a game. And I think there's a few different things that can make a game feel floaty. So, for example, a game can feel floaty because the gravity is too low, which means they take a long time after I jump in a platformer for me to land again. And the things really accelerate slowly in the air. This is This, of course, is uh is Limbo. It's one of my favorite indie games of all time, but I think also representative of a of a large crop of indie games with floaty platforming physics. Uh a game can feel floaty if objects have no mass, which makes them feel like cheap props made out of Styrofoam. They fly away when you touch them, and they don't push back on anything. And sometimes games feel floaty because

it just it just seems like objects have no mass even though they do because they skate along the ground without slowing down like empty boxes or because they travel through each other like like ghosts instead of colliding with things. And you know, I feel okay calling out floatiness in other people's games because I made Quop which I think is probably the worst floaty-est game of all time. He he's in moon gravity. His feet slide along the ground and his body is tremendously weak. His joints are kind of spongy like foam rubber and you know, so I I think I'm the world's premier expert in making a game floaty. But I've been getting a little bit better at not doing that too. So I thought I'd share some tips for other people who like me don't want to roll their own engines and just want to use a pre-built one. Action games generally feel best when they're fast and heavy. You want things to react quickly, hit hard. It makes a game feel more convincing. It tightens the sense of control. It makes the action cooler. It makes it more exciting.

But when you make things move fast and hit hard, you're you're adding a lot of energy to the scene. You're basically pushing the engine to its limits. And when you push a physics engine past its limits, you get glitches and instability, right? Joints explode. Things get stuck inside other things. Objects fly off into space. So we we dial our forces down. We slow things down. We reduce the mass and the energy in the scene and we get this kind of floaty result. That's how floatiness occurs. And in fact, it's for that reason that most game engines, including Unity, are set up with really floaty defaults, right? The default values for physics are there because it slows things down. It protects you from glitchiness, right? But it is possible to reduce floatiness in your game and still keep things stable and glitch-free. And generally, I think that falls into the category of things that are the designer's job. It's a designer's job because some of the ways we fix physics problems involve changing the game design, redesigning the levels or the game mechanics so the

problems don't arise. And all of the more technical ways we go about fixing physics problems are going to have an impact on how the game plays and how it feels. So it's I think of it as being a designer's job. So I'm going to try and give these tips with as little reference to code or or to maths as possible. I'm going to start with the basics and then I'm going to get more surprising and more complex. So there's one very basic step that you can take to improve floatiness in your game that most designers neglect to do, which is to check your gravity and units. So for total realism, you have an average human being character should be about 1.7 m tall and 5 ft tall. And gravity should be about 9.8 m/s squared and it would fall down something like that, right? That's sort of roughly how it would look. But gravity accelerates everything at the same rate, no matter how big it is and how heavy it is. So if you set your objects up to be too large, as in this case, they're going to look like they're falling incredibly slow.

You need to make sure you're at least designing your objects so that they have a realistic size relative to the gravity you've set, right? That's the first most basic step to avoiding floatiness. But in fact, when you make an action game, you usually want to turn your gravity way up higher than a realistic level, right? Strong gravity is faster and more exciting. It makes everything feel better. And you know, in saying that, that shouldn't be news to any of you. In Super Mario Brothers, gravity is about nine times uh Earth's gravity. I mocked it up. This is how This is how Mario would look with realistic gravity, assuming Mario is 5 ft tall. I think that is pretty floaty. Uh all right, so what do you do, right? You You're going to You're going to turn up the gravity, turn it way up, make it more fun. Suddenly you get problems. So this is one of the most common problems that you see with physics engines, it's called jitter. So, an object that should fall down and come to rest on the ground sits there doing these little mini bounces forever. So, to understand why that kind of thing

happens and to avoid it, you kind of have to have a basic understanding of how collisions work in a physics engine. Now, objects in a physics engine don't collide like things in real life do. So, I'm just going to give you like the basics of this so you can understand it. The most important thing to know about a physics engine is that it works in two separate phases. So, the first thing that happens is the engine tries to work out where everything would go if nothing could interact, if nothing could collide, using Newton's equations of motion. So, it's a video game, we need to know what's going to happen every time we update the physics engine. So, we update the position of every object based on how fast it's going. And uh it's it's it's speed or it's it's uh velocity. And we update the velocity of every object according to its acceleration, including gravity. That's That's the kind of basic thing. That's the first step. At the end of that first step, uh you might have solid objects uh overlapping cuz they couldn't interact. And all the joints will have come out of their

sockets. So, the second phase is what's called constraint resolution. And constraints is just this umbrella term that refers to collisions and joints. For collisions, this is how it works. The engine takes the overlapping object and it moves it back out until it's no no longer overlapping. And if it's an object that ought to bounce when this kind of thing happens, we looked at how far we had to move it back to stop it from overlapping. And then we calculate how much it should bounce according to that. So, that's the basics of how collisions work in a in an engine. Same thing goes for joints. So, everything gets uh every every object in your scene that's connected with joints gets moved first as though they're not connected at all. This generally gets sucked down by gravity, and after that, the engine moves them back until they're in a place that's that's allowed by that joint, right? So, I'm I'm exaggerating the effect a little bit here so you can see it, but this is basically what happens. Now, since the movement phase and the collision phase are handled separately,

you get a bunch of unexpected behaviors that you wouldn't see in the real world. So, this is the most basic one. After every physics update, we move the objects according to their speed. If they're going fast, they may never over overlap an object that you would expect them to collide with, and you'll never you'll never see a collision. So, this is called tunneling. Uh by the way, I should say uh I captured all these animations from an actual Unity project, but I could have set them up just as easily in uh C++ Box2D or in Unreal or whatever. It would have been the same. The most simple way to solve that is to make it so that less time passes between each update. So, you set a smaller fixed time step. So, in Unity, you can see here the the they default the default value of your fixed time step is 0.02 seconds. So, what that means is it's updating the physics engine 50 times a second, which is good if you're running it on a Danish TV set, I guess, but totally insane on a computer or a console, especially in America, because your main update loop is probably running 60 times a second. So, here I've

set a much faster update rate, 120 physics updates per second, which cost me some physics as cost me some CPU, but it solves the problem. So, that's called the brute force solution. The other thing you can do is you can set fast-moving objects to use continuous collision detection, uh which prevents tunneling by looking for collisions all along the path of an object's motion. That costs quite a lot of CPU cycles. I should say uh Unity actually has this long-standing uh bug where you can't switch that off in the 2D physics mode, uh but they're fixing it for the next update, so you'll start to see these problems. Uh yeah, so continuous collision detection. Okay, so now we can understand jitter happens, right? So every frame the ball is accelerating down with gravity. It's entering and overlapping the ground and then the engine is pushing it back up until it's not overlapping the ground and the engine has to interpret that as a bounce. So most designers get frustrated with that and they wind up turning the gravity down and you get a a floating result. So what should you do about that? Well, there's a special setting for for jitter. It's both Box2D and

PhysX have this thing where you can specify a minimum speed for bouncing. It's a threshold value. So if the object lands slowly, it just sticks to the ground. It gets glued to the ground. It's not realistic, but it does solve the problem. So you can turn that value up or or again, you can mitigate the problem by just reducing the fixed time step. Okay, the slightly weirder stuff. The next thing you need to know about the constraint resolution phase is it doesn't know anything about the free movement phase, right? So if an object uh winds up overlapping another object at the end of the movement phase, the engine doesn't know which direction the object came from, right? It just moves it back to whatever is the closest edge of the overlapping object. So you get situations like this where the ball bounces out the wrong way because the closest edge is the wrong edge. If you reduce your time step, you make it more likely the engine will find the correct edge or again, you can enable continuous collision so the ball doesn't go past the edge. The other main thing that you need to know about collisions in these engines

is that they get resolved one pair of bodies at a time. Each pair of bodies is only considered once every time the physics engine is updated. So the engine pushes apart the first pair of overlapping bodies that it finds and then the second uh and then so on, right? So so we don't come back to that first pair of objects until the next iteration of the engine. If you walk that through in your head, if you think about how that's going to work, you'll realize that you'll definitely have a bunch of bodies that are still overlapping at the end of the process. So because of that, when you have long chains of bodies, uh big stacks of bodies that are colliding or chains of joints, uh they take time to finish colliding with each other, right? So, they That's why you see this kind of sponginess, which is why the joints in Quop, for example, are really spongy. And you can use that to your advantage, right? So, the the pole in Super Pole Riders uses the same principle. The pole is made up of a whole bunch of pole segments that are connected by rigid weld joints. So, in So, in theory, really what I'm telling

the engine is the pole shouldn't bend at all. It's made up of a bunch of bricks that are welded together. But, because it can only correct the positions of these segments one pair at a time, you can never get the ball the pole back to perfectly straight in one pass. So, it takes time for the pole to get back to straight, and you you get this kind of bendy appearance. So, So, you know, I wanted that for this game, but if you want to minimize that kind of rubberiness rather than maximizing it, you should try to design the objects so they aren't made out of long chains of of connected objects or stacks of bodies. And I you know, I I keep coming back to this point about design because this really is a job for a designer, right? The mechanics of the the game depend deeply on how you construct your physics scene. You can't depend on programmers for you artists to do that for you, assuming you even have a separate programmer or an artist on your indie team. So, that kind of bendiness and sponginess, you can reduce the effect by turning up the number of iterations in the physics solver, which allows these pairs to be analyzed multiple times in each fixed update, or by reducing the fixed time step

again. But, the effect is always going to be there, no matter what. So, you need to design with it in mind. There's one other weird side effect of this pairwise approach to collision resolution, which is that things get stuck when you don't expect them to get stuck. So, I remember a few slides ago I showed you this case where the ball bounces out the wrong side of this object. What if we add another block? So, in a case like this, the ball is pushed away from the top block before it gets pushed away from the bottom one. And neither block knows about the other one. It's just pushing the ball out to the nearest edge and forgetting about it. So, the ball gets stuck. And that's the culprit, I think, a lot of the time when you see stuck bodies in physics games. And people really have a lot of trouble solving that. Uh so, adding more iterations here won't help. You need to make sure that the initial collision works and goes out to the correct side, either by reducing the time step or using continuous collisions. Or sometimes you can also it can help to add like a redundant collider there to fill in the gaps, to give the object a hint which way it should go to get out of being stuck. So, again, it's the job of the the designer,

not the programmer. So, one other note on this, when you're creating a polygonal mesh collider that's concave, the engine will break it up into convex shapes for you. So, here I'm building a collider for this cricket bat in Unity, and you can see it's breaking it up into triangular sub-colliders as I go. But each sub-collider is a separate shape. It's makes it a gets considered separately by the engine. So, objects can get stuck in between. And can be a bit bewildering. So, you just need to be aware that when you're using concave shapes for your colliders, you're going to see that kind of thing. You should probably try to avoid using concave shapes if you if you're able to. All right. So, as I said at the beginning, one of the major reasons why we say a game is floaty is that the objects appear too light. We want objects to look like they've got a realistic amount of mass. But it's not just a matter of turning up the mass on everything. When you've got two objects colliding, you expect the lighter object to be bounced away fast and the heavy object to keep on moving. So, here it's the behavior of the light body which makes the heavy body look heavy, right? The big block looks heavy

because the small uh ball looks like it's going to be knocked away fast. Here the ball seems extremely heavy, right? So, the important thing is the the ratio of the ball's mass to the block's mass. It's called the mass ratio in physics terms. So, you set your masses so that objects that should be heavy are heavy, and objects that should be light are light. And it's it's good to have a few of each for contrast so that the heavy things can really look heavy. If you use straight box 2D in C++, it will calculate masses for all the objects based on their size. But Unity defaults everything to 1 kg. So this is using the default 1 kg mass. So the mass ratio of collisions is always 1:1. So you've got a 1 kg hammer sledgehammer colliding with a 1 kg balloon and I think that makes it look pretty floaty. You know, I should set the hammer to be far heavier than the balloon if I want it to look real. You might wonder why why would Unity do that? Why would they default everything to 1 kg? It's not crazy in this case.

The reason is it helps to avoid glitches. Like so much of the source of floatiness comes down to this. So remember that the engine resolves constraints in pairs, right? And remember that light objects are bounced off heavy ones really really fast. So what would you expect to happen here? I mean, what you want to happen is that the ball is going to sit still. It's going to be wedged between these two blocks. But because it's much lighter than those blocks, it's going to bounce away fast from the top one and it's going to bounce away fast from the bottom one. And you get this unstable situation, right? So you can fix this if you set the ball so that the the mass is closer to the mass of the blocks. But then it's going to seem floaty, right? Because it will make the blocks seem lighter by by comparison. So you need to strike a balance between floatiness and stability. Same thing goes for joints. So remember joints are resolved in the same way as collisions are in in pairs after the free movement phase. So so they've got these two springs here and they're taking turns to pull really hard on this small lightweight ball. So it gets moved a lot by each spring and that's very unstable as well. So

that's probably the number one reason why people have trouble with joints in games, especially with rag dolls. So if you try to set it so that the ball and the block have similar masses, then nothing's being pulled up too fast and you get a more stable simulation. Albeit much floatier and much less realistic. The same thing goes for the stack. So, you know, you you're always balancing floatiness against stability. All right. So, I've shown you some ways to keep things moving fast and looking heavy while avoiding glitches. But sometimes you have to give things an unrealistically heavy or a light mass for creative reasons. In fact, sometimes uh you just have to slow the whole thing down. Either just to reduce glitches or because you want to slow a game, it's just getting too hard, it's going too fast, or just for aesthetic reasons. You know, maybe you just you just want your game to look uh slower. And it matters a lot in terms of floatiness how you go about doing that. So, physics engines, including Unity,

uh include this drag feature that slows things down in direct proportion to how fast they're going. But it to me, anyway, looks super floaty. And it turns out the reason for that is that real objects hardly ever get slowed down by a force that's in linear proportion to how fast they're going. Only balloons and and feathers should be slowed down that way. You can uh apply your own custom drag force that's proportional to the square of the velocity. Then you'll get a more realistic way of slowing things down that doesn't look so floaty. It looks more like real air resistance, real water resistance. So, that's called quadratic drag. I know that probably looks subtle in that example. You trust me, it feels a lot better in the context of a real game. Sometimes when you set your mass values right, your objects look lightweight like in the Big Rigs game because they don't slow down fast enough when they're sliding around, right? So, the first thing that you do is you uh turn up the friction value on all your materials, right? So, Unity uh defaults to a

reasonably low value for friction. A lot of people don't change the defaults. But even then you may still see them sliding around. And the reason for that is that your physics engine only applies friction force at points of contact. And in a situation like this, it's a ball, so there's only one single point of contact on the ground. And where the circle touches the ground, that's where the friction is applied. It's a low force, so the object slides a a lot more than you expect it to, uh which makes it look as though it's light and doesn't have any mass pulling it towards the ground. So, if you can't get enough of a sense of of of weight with friction alone, you can use a custom quadratic drag force there as well, which does a pretty good job, I think, of looking like strong friction, even though it isn't. Makes the object look heavier and makes the whole thing less floaty. Don't use the inbuilt linear drag just to solve the sliding problem. Okay, so one final point. This is a situation you see a lot. There's like this this moving platform that's a kinematic body, which means I'm just telling it where it should be. And

since it's kinematic, it can't be pushed back by the ball. So, the ball has to bounce off the platform, uh as well as off the ground and the block, all of which are static and can't move. So, the ball glitches out cuz it's overlapping all these these three objects, and none of those objects can move, and the engine just doesn't know which way it should be pushing the ball. Even if you didn't get a glitch in this kind of situation, you'd get a really floaty result because the ball would be pushed away from the platform without pushing back, which would make it look like the platform had infinite mass and the ball had zero mass, like it was made out of air. So, like everything else I've mentioned, like that's more of a design problem than a technical problem. Um I've created a level design here, which is just asking the engine to do something it doesn't know how to do. So, you try to avoid moving bodies just by setting their position. You try to avoid making objects that have to move kinematic unless you are sure that they're never going to wind up pushing on a dynamic object and making it look really light. And now you know that that the how the engine is solving collisions, you know, in two steps and pair by pair, you can

do your best to design your game environments and your levels and so on so that these non-resolvable scenarios never occur. So, I've given you a lot of stuff to tune to get the physics working just right, right? You have a complex scene like this one with a lot of joints and a lot of different bodies, you need to tweak masses, joint strength, gravity, uh all these engine parameters for every single object. And the default values are almost never exactly what you want. And you you probably don't know beforehand what you want, so it's almost an impossible tuning problem. Uh you might have to change dozens of different different parameters just to get it to work something like how you want it. So, I was stuck for about a year with this game uh trying to tune it to the point where the the horse could just make it from the right of the screen to the left. And I only managed to get it working when I hooked up a a MIDI uh USB MIDI mixer controller with eight sliders and eight knobs to 16 of the physics variables at once, so I could tweak them all at once. And even now, I think it's sort of remains a little bit floaty. So, you know, I'm trying hard to work this

stuff out myself, but you know, what I'm finding is gradually you can almost always get the effect you want if you work hard enough on on redesign and on tuning. I made a little demo of how I how I would do that. This MIDI controller setup is really easy to do. Uh I made this example from scratch like with with nothing uh in about half an hour using the free program MIDI bridge and a Korg uh nanoKONTROL uh MIDI controller, which costs about $40 now on Amazon. If you don't have a MIDI controller, you could use a flight stick or a touch pad or anything that's giving you giving you this kind of fine multi-dimensional control. You can also just put uh mouse slider objects on the screen that you can move with the mouse. It's not quite as good, but it's it's better than nothing. I think if you try to tune your physics game one variable at a time, you're making life incredibly difficult for yourself. It's almost impossible. Okay. So, I know that was a lot to digest in 25 minutes. Um but I came up with a couple of goofy uh mnemonics to to help you out with this. Uh check check your gravity is as high

or higher than Earth's? Check your units are correct. Make sure the objects are not too large relative to the scale of your gravity. And reduce the fixed time step as much as you can without maxing out the CPU. So, you need to check your gut. I know this is stupid. I just I felt bad about how complex this was. So, you want to check that your objects have realistic contrast and mass, but that stacks of chains chains of objects have similar mass values, similar mass ratios. If you have stacks or chains of colliding objects, you want to increase the number of iterations. You want to avoid creating scenarios that the engine can't figure out how to resolve. And you want to replace the linear built-in drag with quadratic drag. So, change your mind. Check your gut, change your minds. I I hope that was useful for some of you. Next week or two, I'll try to put these slides on my website so you can go through more slowly. Thanks.