In this tutorial, we’ll examine the use of physics to simulate projectile effects in games like Angry Birds. We’ll look at the basics of using 2D physics in game world space, such as creating bodies and applying impulses and forces.
Physics Engines
Why use a physics engine? What does it actually do?
A physics engine helps us do two very important things for our game:
- Detect collisions between our in-game objects.
- Simulate the forces and resulting motion of our objects from those collisions..
Collision detection: Games wouldn’t much much fun if your character fell through the floor before you could jump, or if, when you hit an enemy with your foot, you fell right through. Collision detection using a physics engine allows for very precise contact listening, and allow interactions between objects to be simulated using forces.
Force simulation: After a collision, what should happen? Game logic could be called, you could bounce, the other game object could bounce, or you could simply move no further. This is all handled behind the scenes, using the calculated forces of the engine. But forces aren’t limited to contact; other forces, such as gravity and impulses, can occur, without objects actually touching. Forces affect in-game actions and the movement of objects, characters, and even the world-space itself.
We’ll look at how physics engines work shortly, but first lets look at what engines you may want to use, and why you may decide to use them, based on your particular needs.
Choosing Your Engine
When you first start to think about using physics in your game, you will need to decide how you want to approach the problem, and what your game will require in terms of simulation. You have two options for using physics:
- Use an existing physics engine.
- Create a custom physics simulation
Using an Existing Physics Engine
Several excellent options exist for predefined and ready-to-use physics engines. One of the most popular choices for 2D games is Box2D; it’s a native C++ written engine, but has wrappers, ports, and extensions that allow it to be used in nearly any 2D platform. Another popular choice is Chipmunk 2D, which is used in several mainstream game engines, like Cocos2D.
Creating a Custom Engine
In some games, using a predefined engine isn’t necessarily the optimal choice. Using a physics engine can cause some unnecessary overhead when its full function isn’t required. In cases like simple platformers or brick-breaker type games—where you don’t need pixel-perfect collision detection or some of the other capabilities of an engine—it may unnecessarily use up resources that could be better spent elsewhere.
Building your own engine can give you more flexibility over the final product, but it can also make things more complicated if you are dealing with more than a few instances of characters and objects.
The Game Loop
Before discussing the properties and details of a physics simulation, let’s look at how it is called within the loop of your game scene.
The typical game loop will run through the following for each frame, in order:
- Input
- Update/Game Logic
- Simulate Game Physics
- Render Screen/Scene
This means that calculating the resulting physics is the last task performed in the loop before the screen is updated. This makes sense, as the point of the simulation is to react to what has happened within the game’s world-space.
Note that this image shows that physics are simulated during every frame of your game loop. This can result in some large overhead if your simulation gets overly large or complicated. For this reason, it is best to keep game management and calls to the simulation and its listeners limited.
Fixed Rate vs. Frame Dependent Physics
It makes sense now to discuss two different methods of polling the physics simulation: fixed vs. frame dependent rates. Consider the (void)update: method consistent within most game loops. This loop is called once per frame of the game scene. If your “simulate physics” method is called from (void)update:, your game world physics is going to depend on your frame-rate, and this can lead to some choppy and unrealistic simulations. In iOS, this effect is mitigated by the use of the usesPreciseCollisionDetection Boolean property, but what about in other engines?
Consider the following code segment:
CFTimeInterval timeSinceLast = currentTime - self.lastUpdateTimeInterval;
self.lastUpdateTimeInterval = currentTime;
if (timeSinceLast > 1) {
timeSinceLast = 1.0/60.0;
}
This code is designed to compensate for issues with the delta value for time. Consider a situation where you were playing the game on your phone and got a call: it would help your game for you to reset your delta back to the expected 1/60 (for a 60 fps game).
This is actually the first step into a discussion on decoupling the physics simulation from the time-step of the (void)update: method. While a modified time interval would certainly aid in a more stable physics simulation call, it doesn’t correct for all situations. To do this, we would need to actually remove the physics simulation call from the game rendering loop, and create a fixed cycle within which it could run. For instance; if your game is meant to run at 60 fps, you set the physics to simulate 60 times per second. This decoupling removes any concerns of rendering issues causing choppy feedback in your physics simulation.
In short, be conscientious in your implementation of physics. If you find yourself using an engine in an environment where you are taxing system resources, consider a fixed step physics simulation to maintain fairness and fidelity.
From Sprite to Physics Body
A sprite is an image rendered to the screen of your game. A sprite has no properties by default within a physics simulation. You can “fake” some of the behaviours of a physical world by using properties of a sprite such as a bounding box and an intersection call, but then you have to write all of the resulting logic yourself. Wouldn’t it be better if the game could handle all of this for us?
In these snippets, we create a sprite:
SKSpriteNode *sprite = [SKSpriteNode spriteNodeWithImageNamed:@"image"];
sprite.position = location;
[self addChild:sprite];
…and call a collision between two sprites:
-(void)update:(CFTimeInterval)currentTime {
/* Called before each frame is rendered */
if (CGRectIntersectsRect(sprite1.frame, sprite2.frame)) {
//do something
}
}
Body Shapes
Physics bodies are “simple” shapes that define the rough size and shape of your sprite, or perhaps define an active area of your sprite. Consider the following:
A physics body is not predefined by the image of your sprite, and is typically invisible within the game. You create the shape dynamically, often by calling a method to either draw the shape that will make up the body, or by using a program to help you draw out and define the body. You then attach the body to the sprite, and gain access to the simulated effects and properties assigned to that body.
You can have multiple physics bodies tied to a single sprite. Take, as an example, a sprite of a hero carrying a sword. It would make sense to create one body for the hero character, and another one for the sword he carries. This would allow you to create game logic based on collisions between different bodies.
In pseudocode, the logic would look something like this:
//physics logic
-(void)physicsCollisionDidOccur{
switch (collision bitmask) {
case (Player||Sword): //do nothing;
break;
case (Player||Enemy): //ouch!!;
break;
case (Sword||Enemy): //do damage!!;
break;
default: //do nothing;
break;
}
Relating the Physics Body to the Sprite
Consider the situation of a of a space game, where you have a hero ship and an enemy ship:
You would likely want to make the physics body of the player a little smaller than the base sprite image for two reasons:
Enhanced Visual Collision: When a player collides with an object in your game, by creating this smaller physics body, the sprite images will overlap temporarily at the point of contact, which looks good visually. (Further to this point: when drawing z-values, keep your player’s character at the front of the scene hierarchy.)
User-Perceived Fairness: To try to make your game feel “fair” to the player, keep the collide-able body limited to the bulk of the object, and away from extraneous protrusions like the back fin of the image above. This way, there won’t be any “cheap hits” to annoy the players of your game. Conversely, you usually want the enemy physics body to be at least the size of the base image; if we give our space hero a laser to shoot his enemy, a slightly-too-large enemy body makes it more reasonable for our player to obtain a hit. Also consider this same approach for tiles in a platformer or puzzle game that requires your player to jump from platform to platform. Players are used to a little “grace” in these types of games; extending the physics body a tad will help keep your game reasonably “fair”.
Typical 2D Engine Constraints
There are two main types of physics bodies:
- Edge-based bodies
- Volume-based bodies
An edge-based body is a static, immovable line that creates a boundary for other bodies to collide with. It has a negative space within it that has no effect on any bodies. A great application of this would be to create a boundary around your screen to contain any bodies within.
A volume-based body has volume and mass, and can be either dynamic or static. Because these bodies have mass, objects bounce off them and they can be affected by force contacts. Volume based bodies can be any of four main shapes:
- Circle
- Rectangle
- Chain
- Complex Polygon
There are some constraints to using bodies within your typical 2D physics engine. Here are the two main limitations:
Convex Physics Bodies
If a shape is convex, it means that no interior angle is less than 180 degrees.
To be clear, it can be possible to run physics simulations on concave shapes, but the processing cost is so high that it is simply not realistic for 2D, especially when running on a handheld or less powerful device. Concave-like shapes can be constructed by linking together two convex shapes using something called a Static Joint. Joints are another great feature available with 2D engines, but are outside of the scope of this discussion.
Rigid Physics Bodies
When a ball hits a wall, in the “real” world something like this will occur:
Your character’s sprite can undergo this type of transformation, but its physics body cannot. You can control certain properties of the body to affect its “bounciness”, but it cannot actually have a mutable shape. This is known as a Rigid Body, meaning that the body itself cannot be deformed or squished.
Properties of a Physics Body
Let’s have a quick look at what some of the some of the most useful properties available on a typical physics body are:
- Restitution is a measure of how “bouncy” an object is. More formally, it’s the measure of how much energy an object retains after it collides with another object.
- Density is the measure of how “heavy” an object is. It is used as a relative quality—for instance, a rock would be more dense than a ball, so when the ball hits the rock, it will be affected more heavily.
- Friction is the measure of how “slippery” an object is. This is used when one object is sliding along another, and determines how long will it take for it to stop.
- If a body is dynamic, then forces imposed upon it by the world and other objects will have an effect; if it is a static body, then they will not.
- Rotation is typically a Boolean variable that can be set on a physics body. In certain cases you may want to limit a body and not allow it to rotate, but you want forces to still be applied to that object.
Most engines have more properties available than this, but for the purposes of this discussion, these will be sufficient to get started.
Motion and Momentum
In a simulated physics world, bodies are moved by the application of forces and impulses.
Forces: General forces typically affect bodies more gradually than impulses They are a constant force that is applied over a unit time (like gravity or an engine).
Impulses (Impulse Forces): Impulses are immediately-applied adjustments to a body’s momentum. Impulses are usually applied to a simulation based on user input.
What Next?
Now that you understand the theory, the best way to cement your understanding of projectile physics engines is to build one yourself. Tomorrow, I’ll break down the code for a simple physics-based game that I’ve written, so you can see exactly how it works!
