Five Steps to Adding Physics-Based Realism to Your Gamesby David M. Bourg, author of Physics for Game Developers
As a game developer, and very likely as a gamer yourself, you've probably seen products being advertised as "ultrarealistic," or as "using real-world physics." At the same time you are wondering how you can spice up your own games with such realism. Or perhaps you want to try something completely new that requires you to explore real physics.
Say, for example, you're writing a baseball video game and you want to model the various pitches, such as curve balls, knuckle balls, and fast balls, based on real-world parameters such as release speed, spin, the altitude of the playing field, and so on. Considering all these factors would allow you to distinguish between different pitchers and even between different playing fields. This would offer greater challenges to your gamer, and perhaps more importantly, greater intrigue and variety.
Now, I can't explain how to write such a physics simulation in this short article; instead I've written a book, Physics for Game Developers, which explains the physical and computational principles you will need to know to write such a simulation. In this article, I'll give you a general overview of the five major steps you must take when developing physics-based simulations for your games.
Step 1: What to Model?
The first thing you have to do is decide what it is you'd like to model physically. This may seem obvious, but it's not trivial. You could decide that you'll just model everything in your game physically. While this makes your decision easy, you just significantly increased your development workload. Further, your game's performance will suffer unnecessarily. It's important to remember why you're adding physics to your games in the first place. Presumably, it's because you want to enhance the immersive experience for your players. You've already created a gaming environment that looks realistic, and now you want it to behave realistically as well. What you must do is determine which elements of your game will benefit the most from using real physics and which elements won't make a difference at all in terms of the overall gaming experience.
Generally, your game environment will be full of visual detail so as to create a visually immersive experience. However, it isn't necessary for every little visual element to be modeled physically to achieve this.
Consider this example: You're working on the next blockbuster hunting game complete with first-person 3-D, beautiful textures, and an awesome soundtrack to set the mood, but something is missing. That something is realism. Specifically, you want the game to "feel" more real by challenging the gamer's marksmanship, and you want to do this by adding considerations such as distance to target, wind speed and direction, and muzzle velocity. Moreover, you don't want to fake these elements, but rather you'd like to realistically model them based on the principles of physics.
So now you're faced with deciding what exactly to model physically. Well, for this example, you'd want to model the flight dynamics of the bullet fairly realistically. Do you have to model the gun, too? Probably not, unless you want to use a force-feedback mechanism to simulate the kick of the gun when it's fired. What about the target? Say your gamer is shooting at some tin cans for target practice. You could include the tin cans in your simulator and model the collision between the bullet and tin can so that when struck the can goes tumbling through the air. That would be neat.
On the other hand, what about the stand that the tin can is set upon? Do you really need to model that to yield an immersive shooting experience? Probably not. The point is that you should carefully select what game elements are most important for immersion and focus your attention on those. Leave everything else out of your physical model so you don't waste CPU time.
Step 2: Physical Models
Now that you've decided what it is you want to model, you have to decide how to actually model it. Recall from your physics lessons that rigid body motion is governed by Newton's second law of motion, which states that the acceleration of a body is proportional to the resultant force acting on the body and this acceleration is in the same direction as the resultant force.
In equation form this is simply the familiar equation,
F = ma; where "F" is the resultant force vector, "m" is the mass of the body, and "a" is its acceleration. You can write an analogous formula relating applied torque to a body's moment of inertia and angular acceleration. Don't worry if you've forgotten these fundamental principles of rigid body dynamics, I've devoted
several chapters in my book to this subject as a refresher course.
The formulas for Newton's second law form the equations of motion for the objects in your simulation. Given some externally applied forces and torques (moments), your objects of known mass and inertia will accelerate. While accelerating, their speeds and positions will change; for example, they'll move around under the influence of the external loads. This last statement is critical. It's true that you must solve the equations of motion in a manner such that your simulation is stable. It's also true that you must incorporate accurate collision detection and response in order to capture the interaction of the objects if they run into each other. I'll talk more about this in step 3 later in this article. What ultimately determines the behavior of your objects, however, are the forces and moments that act on them, so it is important to get them right.
While the concept put forth by Newton's second law is easy to grasp, the simplicity of the governing formulas are deceptive because these forces and moments acting on your object are not always easy to calculate. This presents you with a dilemma: It's crucial that you model the forces and moments accurately, but you must trade absolute accuracy with ease of implementation and computational speed. This requires a practical understanding of the object you are trying to model. For example, if you are writing a flight simulator and you want to accurately model the flight dynamics of your plane, then you need to understand how wings generate lift, how tail rudders cause a plane to yaw, how flaps cause a plane to bank, and so on. All these elements effectively apply forces and moments to your plane in order to get it to fly, yaw, bank, and so forth.
What ultimately determines the behavior of your objects are the forces and moments that act on them, so it is important to get them right.
Here's another example: if you want to model the flight of a baseball in your game, then you must consider aerodynamic drag, Magnus Lift forces, and gravity. If you don't get these right, your baseball won't behave like it should. If you leave out Magnus Lift forces, for example, you'll never get a curve ball in your simulation (unless you fake it, but that defeats the purpose of implementing accurate physics in the first place).
Many game physics references that I've come across spend little time discussing the physical nature of forces and moments. Instead, you often see simple, generalized formulas for forces such as viscous drag (commonly called damping in the literature) and spring forces. Generalized formulas are great for modeling generic objects, but they won't cut it if you're going to accurately distinguish the behavior between, say, airplanes and cars, baseballs and cricket balls, or hovercrafts and boats. That's why I've included several chapters in my book that discuss the nature of a variety of forces acting on common objects, including practical formulas and data.
While there are an infinite number of things you may try to simulate in your games, there are a handful of different types of forces that are common across a wide variety of situations. The first type is field forces. These are also known as forces-at-a-distance since the forces are generated between objects that are not in contact, but which are separated by some distance. The best example of this type of force is the force due to gravity. If you are simulating any sort of projectile in your game, then it's safe to assume that you'll have to include gravity in your force calculations.
Another common force is friction. Friction acts between objects in contact and always resists motion. If your hero has to push barrels or crates around in order to navigate a level, then you'll have to model the friction between the barrel or crate and the ground in order to simulate its motion as it is being pushed.
Any time you have an object moving through a fluid, which could be air, water, or any other gas or liquid, the object will experience drag forces opposing its motion. Whether your object is a plane, a bullet, or a person jumping through the air, fluid dynamic drag is a factor that you should consider. In addition to contributing to physical realism, drag, or damping, is always good to help stabilize your simulation.
Many objects moving through fluids also generate lift forces. The best example of this is an airplane wing that generates the lift that allows an airplane to fly. Most people normally associate lift with wing-like, or airfoil shapes; however, even completely round objects can generate lift, if they are spinning. This is the so-called Magnus Lift force that is created when an object rotates as it moves through a fluid. As I mentioned earlier, this is the physical mechanism behind a curve ball in baseball. It's also a significant factor governing the flight of golf balls as well as many other types of sports balls.
One means of connecting objects in a simulation is through the use of springs. A spring applies a force between two connection points, which is proportional to the elongation or compression of the spring. Springs are often used in particle-spring assemblies to simulate the motion of flexible objects, such as cloth. The last chapter of Physics for Game Developers goes through an example of how to use a spring-particle system to simulate a cloth flag waving in the wind while suspended from a flagpole.
Pages: 1, 2