Game Development Reference
In-Depth Information
As mentioned, Box2D is written in C++ and not Objective C. This can be a little off-putting to a new
iOS developer, who is just getting the hang of Objective C. Also, there are also some hurdles that
must be jumped to make your Xcode project play nicely with combined Objective C and C++ code.
We will take a brief look at setting that up in a moment; for now, though, let's ignore this hurdle and
spend some time looking at what Box2D is really all about.
The World
The starting place for all Box2D applications is understanding that Box2D simulates the motion of
bodies and joints within a world. Bodies are what you would expect—blocks, balls, and other game
elements. Joints are constraints put on bodies in the world; this includes things like pulleys and
teeters. We are not going to use joints in our example. These bodies and joints are all in a world
that describes how they interact with each other. This is analogous to how we have Actors in a
GameController
, as in the other chapters in this topic.
In addition to being a collection of bodies and joints, a world also describes the force of gravity in
a simulation. The gravity can be set to any value and go in any direction. Since our example is in
space, gravity will be set to zero.
Note
Units in the world are assumed to be meters-kilogram-second (MKS). Because you probably don't
want one pixel to be one meter, you will want to scale Box2D coordinates to your display coordinate system.
A world is also responsible for advancing the simulation, similar to how
GameController
advances
the location and presentation of each Actor. There are some differences; for example, a Box2D world
advances the simulation a number of seconds (fractions of a second, really) into the future, while
GameController
simply advances the frame count by 1. This is a subtle distinction, but it means you
can adjust how much simulated time has passed within the scene. Let's consider an example to see
why this is useful. Say you are building a game that runs at 60 frames a second. If you are using the
GameController
class, and you adjust the frame rate to 30 frames a second, the game will appear to
be running in slow motion on the device (half speed). If you are using the Box2D world, and you drop
your frame rate from 60 to 30 frames a second, you can double the amount of simulated time that
passes in each frame; this would cause the game to appear to be running at full speed—just with
lower fidelity in the animations.
This advantage comes with a price, however. With the
GameController
(and other engines that
work in the same way), each Actor knows that it has been exactly one frame in the animation since
the last time it was updated. This makes some aspects of game logic very simple; if a particle is
supposed to be on the screen for 15 frames, you can just count them off and remove the particle.
In a Box2D world, if you want to be able to change the amount of time for a given frame, you have
to specify the life span of a particle in simulated seconds. Additionally, in order to know when to
remove the particle, you have to calculate how much time has passed since the last time it was
checked. This may not seem like a big deal; you just have to do a little subtraction. However, if
the duration of your particle's life is not evenly divisible by the duration between each frame, your
particle may exist longer than you intended and can cause some unexpected interactions that may
be hard to debug.
