Badly tuned physics can be a disaster: A vehicle can become impossible to control, objects can get in the way of the player, things just don’t feel right and what should have made the game fun just generates frustration. As a game designer, you are responsible for the fun of the game, so it is your role to make sure physics are tuned properly and not left solely to a programmer’s whim. If you don't play a role designing and tuning the physics, your game might ship with you unhappy with the tuning, wishing you had learned more sooner (also called regrets) and you will miss a lot of opportunities to discover fun things you might have done with the physics. You will have to get your hands dirty and tweak many variables many times before you get some good results.
January 21, 2003
Author: by Fred Marcus
During my years as game design director at Angel Studios, there wasn’t a day where I didn’t have to deal with physics in one or several of our products. Impressive physic demos have always been one of Angel Studios ticket to get contracts, so we had to have some in our games. And actually, we had a lot of physics in our games: from driving physics to ragdolls, to collisions with stacking and more, the entire spectrum was covered. They all helped make our games look and feel different from the rest of the crowd. That, and our ability to tame physics so our games stayed playable and fun.
In this article, I will try to explain how to tune physics from a designer’s point of view with some fundamentals you have to know and end with some classic traps to avoid. But first, do you approach physics as a game designer?
Physics can make a game look and feel different. They can bring shocking realism to impacts, to vehicle controls and really enhance the critical reactions a player’s action generate.
Physics can help pull a game into reality. The ultimate goal, however, is to enhance that reality. If you get it right, you will give unique sensations to players and show them things they have never experienced before. Unfortunately, there is a price to pay for that. Physics can take a lot of CPU time and it requires a lot of tuning to keep a game fun to play.
Badly tuned physics can be a disaster: A vehicle can become impossible to control, objects can get in the way of the player, things just don’t feel right and what should have made the game fun just generates frustration. As a game designer, you are responsible for the fun of the game, so it is your role to make sure physics are tuned properly and not left solely to a programmer’s whim.
If you don't play a role designing and tuning the physics, your game might ship with you unhappy with the tuning, wishing you had learned more sooner (also called regrets) and you will miss a lot of opportunities to discover fun things you might have done with the physics. You will have to get your hands dirty and tweak many variables many times before you get some good results. There are no other ways around that. Besides, if you are a game designer, you already have to tune a lot of variables for your controls and your cameras.
But before you get there though, you need to learn the theory behind physics.
As a game designer, it is also your role to sit down and talk to your team and create a communication flow between all team members. Usually, you do the talking. You listen, yes, but you also have to explain a lot of things to a lot of people.
Well, this time, it is your turn to listen and to listen well! It is essential for the designer to understand the language of physics, to understand its limitations in real case scenarios, to make sure you get a grasp of what is possible or not. Only then, after hours of questioning and drawings (Paper and pencil are your best friends when sitting with a physics programmer) you will start to grasp how you can control this beast and make it behave the way you want it to.
It is ok to ask questions, again and again. It’s time to take your game designer’s ego and throw it out the door. If you don’t understand something, just ask and ask again, until you get it right -- Everything has to be crystal clear. You might look dumb, that’s for sure, but you cannot leave anything unexplained.
Understanding what the physics guy means is crucial if you plan to start to tweak things around and understand what is happening in your game. It will also allow both of you to work on solutions that solve these “special cases” occurrences. You know, it’s a game and sometimes you don’t want physics to do this or that. If you don’t know what you are talking about, physics wise, you will not be able to convince your programmer to tweak the code to make things work. After all, he wants it to be real but you want it to be really FUN.
Before you start talking to your programmer (Yes, you have to!), here is a very simple to understand primer on game physics as well as some basic techniques to help you tune your game for fun.
The center of gravity is a crucial parameter in physics. It will determine how your object will react to forces applied to it. The center of gravity is at the center of mass of an object (center of mass is another name for center of gravity), where the object will likely be balanced. If you move the position of the center of gravity of an object, you will change it’s behavior dramatically: If a tall object has its center of gravity very low, it will be very stable and hard to roll. If it is placed way up there though, the object will roll very easily. If you want a car to make nice drifts, or roll a bit into turns, move your center of gravity around. You will get very different driving feelings when you do so.
Physics in games are about forces and impulsions (a force is a continuous impulse). You can’t just move a physically based object by giving it a position in 3D space. You have to push it or apply a torque to rotate it. Also, the heavier the object, the stronger the force or the impulsion you need to apply to move it (except if your object and the ones you are colliding with have a low friction…). Some physics engine allow you to specify x,y and z coordinates and will try to calculate the forces needed to bring your object there, but it will still be an approximation.
To control all these forces and to prevent things to get too crazy (like an object spinning all over the place, a car that falls on it’s side too easily in turns) you have a friend that can help you. And this friend is called dampening. This is your Tylenol, your savior -- the magic word. If in your game physics make things fly out of control, go to your programmer and say the magic word. He will know what you are talking about. You should also ask him about dampening when things feel too slow, sluggish, smooth, controlled. Then, he probably already has dampening coded in and he did the tuning himself. Get these tuning parameters exposed and play with them.
You can dampen things in translation and in rotation, for each axis. In translation, damping can make a box slow down progressively once pushed or it can slow down a car going too fast. Think of it as brakes. It’s up to you if you want the brakes to be very soft and progressive or if you want to bring objects to a brutal stop. Too much translation damping and the object won’t move at all though.
In rotation, you can prevent an object to roll too much. Think of a car taking a turn too fast. If you don’t want that car to roll over, you add damping on the z axis. If you put too much damping though, the car won’t rotate at all and look very unrealistic.
So, damping is great, it helps you control things. The problem is, sometimes, you want an object to behave differently at different velocities.
Maybe you want a vehicle to roll a lot at low speeds but if you keep it like that, it will definitely roll over at high speeds and that’s a no no! Well, you can ask your programmer to give you speed relative damping! Quadratics are great for that. You get a constant damping value C, valid even if the object is static. On top of that, you have a damping value B for when the object speeds up. And then, at really high speed, a third damping A value kicks in for these special cases. The thing is, damping values can be updated every frame so it’s up to you to see what your game needs and design a system that fits these needs.
Of course, too much damping and your game doesn’t need physics anymore! That’s where the difficulty in balancing all this comes from. If your physics is too controlled by damping in order to make the game playable, you can get rid of it when you need to! For example, during a car crash, remove damping on all axis at once or progressively to see the vehicle spin all over the place in the most spectacular way. The difficulty for the designer and the programmer is to determine and recognize when a vehicle is really crashing.
Once you've learned a bit about how the physics in your game works, you'll soon encounter a number of common problems that you previously lacked the tools to tackle. This section offers a list of traps you have to avoid at all cost. They are classic problems, I see them every single time physics are implemented in a game. Make sure you read this before you start to tune.
A key element in tuning physics is the possibility to tweak each value in real time while the game plays. You have to ‘feel’ physics, just like you need to feel the controls and the cameras in your game. Being able to tweak physics values in real time will allow you to increase your iteration rate dramatically. Ask for this feature. Better: BEG for it!
Variable frame rate will change your physically based behaviors. Even if you are told that they will stay the same once the code has been optimized, don’t trust believe it! It will not happen, it will change and you will have to re-tune things (hopefully you will be trained by then and it won’t take you that long).
Sloppy physics code can take a lot of CPU cycles. It can take so much time that your frame rate will drop from 60 to 30 frames per seconds or worst. Variable frame rate disturbs a physic simulation and usually, oversampling is used to solve the problem.
Oversampling physics means that the physics code is updated independently from the display. If the game is displayed every other frame (30 fps), physics are still updated 60 times per second. It means that the game runs through the physics code two times before an image is displayed. It helps keep the physics stable.
But wait, if the game has to run the physics code two times before it displays something, then, it eats even more CPU time. And the game can get even slower! And then you might drop to 20 fps and need to update physics three times before you display anything! This chain reaction is a classic problem and trying to get a good, fast 60fps with no oversampling is the best you can ask for. Beware of oversampling and low frame rates.
Not everything needs to be physically based in your game. Especially when these things are far from the player’s point of view. No need to compute suspensions if the vehicle is four pixels on screen! Make sure your coder has physics LOD built in.
Another crucial thing to remember is that AI does not need to be physically based either. If you want to have tight control over what the AI does in your game, then don’t make it physically based. Physics will prevent programmers to move an object by specifying x, y and z coordinates. They will need to move objects through impulsions and forces, a more ‘analogue’ and approximated way to do it.
Not everyone is convinced that good physics are essential to a game -- "games don’t need it to be fun” I hear every so often. It is true, absolutely.
But, each new platform brings us closer to realism graphically. Hardcore gamers complain when the art is average, the AI dumb… and sooner or later they will reach a point where they will not accept object behaviors that don’t look right. As for game designers, we have the opportunity to make sure that game physics not only look and feel right, but that they play right -- balancing realism with effective and fun tuning.
Read more about:
FeaturesYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
