Physics engines in games have been around for quite a while. Games from large to small that are worth their metal have some type of physics implemented within their gameplay—all the way from AAA games such as Gears of War to casual games such as Angry Birds. Just want to give a shout out to Angry Birds Space, “that ish is bananas.” Also, another space mechanic game that was a predecessor to Angry Birds Space that is worth checking out is No, Human. The term physics can cover a broad range of topics such as the way light works or how nuclear fission is created in the core of stars. When it comes to game development, we are dealing with classic mechanics, which are based on the laws laid down by Isaac Newton. This describes the motion of macroscopic objects such as birds being shot from a sling to astronomical objects such as the effect of a planetoid’s gravity on pigs flying through space.

When a game requires real world simulations of objects interacting with one another, programmers turn to a physics engine. These engines are just large calculators that help determine the position, rotation, velocity and acceleration of game entities. But, when it comes to the internal structure of how these engines work, most game developers are at a loss. We tend to think of physics engines as black boxes that perform some magic and rarely care about the deeper implementation. Although the output of these engines are amazing to behold, it can be quite advantageous to understand its underlying mechanics. So, when one comes across anomalies caused by physics, we can dissect the causality of what is going wrong.

The underlying characteristics that determine how to deal with objects in an engine are either Mass-aggregate or Rigid-body. Some other types of physics engines that are outside the scope of this article are soft body dynamics and fluid dynamics.

Mass-Aggregate Engines: These types of engines treat entities as a collection of smaller masses. These masses are connected with a network of rigid poles. A box can be constructed with eight separate masses that link in a web to form a solid. Mass-Aggregate engines are generally easier to program, due to each mass being expressed in only linear motion. But there is a drawback to these engines: truly solid objects become hard to simulate. There is always going to be some amount of spring in your mass, so extra code is required to correct these imperfections.

Rigid-Body Engines: With rigid body dynamics, objects are based on movement in three degrees of freedom. These objects occupy space and have properties such as a center of mass, moments of inertia, and are characterized as being non-deformable. Central characteristics of these properties are motion that is defined in six degrees of freedom, which are defined by translation in three directions plus rotation in three directions. What sets this type of engine apart is their level of realism, but this comes at the cost of being harder to program.

When boiled down, a physics engine processes how and when two objects are to touch which is denoted as contact resolution. This is delegated to objects that are sitting on the floor, objects connected together and collision of objects. There are three major avenues to go about handling these contacts.

Iterative Approach: Usually the easiest approach to implement, each contact is processed one by one. This works well with a limited number of contacts and can be resolved quickly. But it can run into problems with multiple objects colliding creating a large chain of collisions.

Jacobian Approach: In this method, each contact between objects is calculated as an overall set of effects and are applied to all objects at the same time. The down side is the calculations involved are processer intensive, but this can result in a more physically accurate simulation. Another pitfall to this approach is some collisions are just not accounted for and extra code must be written to deal with these conditions.

Reduced Coordinate Approach: These engines throw the laws of Newton out the window. Instead, sets of calculations are created to deal with every type of contact and constraints between objects. Most engineering software take this approach due to it’s high level of accuracy but it is an unrealistic solution for real time simulations where speed is key.

The last part of the puzzle is how these engines resolve contacts, or what happens after objects collide. This is when force comes into play. In physics, force is what changes a state of rest or motion in an object. Forces cause objects to accelerate, change direction or change shape. A crate sitting on the ground receives the force pushing up from the ground while at the same rate of gravity pushing down. In turn, no change of motion is experienced. In the case of a bouncing angry bird, the force acting on the bird is greater than gravity in turn causing a change in velocity. But this force is acting in such a small interval of time it can be considered just an impulse.

Force Based: Some engines use force to rest objects and impulses for colliding objects. A more frequent approach is to just treat everything as a force. This approach proves to be quite tricky to implement being that the equations behind forces are complex and are harder to implement.

Impulse Based: An alternative is to treat every collision as impulses, which are just, forces acting over a short period of time. A stationary object is kept still by calculating multiple collisions. The draw back is at lower frame rates; stationary objects can appear to jitter. But, being that the implementation is simpler, it is a good route to take.

When creating a physics engine from scratch, it is advisable to create it in stages. First, taking simple steps to create projectiles and eventually working your way up to cars and ragdolls. A wonderful book on the subject on physics engines is Game Physics Engine Development by Ian Millington. Also, currently we are developing an open-source JavaScript physics engine Bounce.js.