Game Development Reference
In-Depth Information
The Value of g
It is worth noting that, although the acceleration due to gravity on earth is about
10 m/s 2 , this doesn't look very convincing on screen. Games are intended to be more
exciting than the real world: things happen more quickly and at a higher intensity.
Creating simulations with a g value of 10 m/s 2 can look dull and insipid. Most
developers use higher values, from around 15 m/s 2 for shooters (to avoid projectiles
being accelerated into the ground too quickly) to 20 m/s 2 , which is typical of driving
games. Some developers go further and incorporate the facility to tune the g value on
an object-by-object basis. Our engine will include this facility.
Gravity typically acts in the down direction, unless you are going for a special
effect. In most games the Y axis represents up and down in the game world; and
almost exclusively the positive Y axis points up.
The acceleration due to gravity can therefore be represented as a vector with the
form
0
g
=
g
0
where g is the value we discussed before, and g is the acceleration vector we will use
to update the particle in the next section.
3.3
T HE I NTEGRATOR
We now have all the equations and background needed to finish the first implemen-
tation of the engine. At each frame, the engine needs to look at each object in turn,
work out its acceleration, and perform the integration step. The calculation of the
accelerationinthiscasewillbetrivial:wewillusetheaccelerationduetogravityonly.
The integrator consists of two parts: one to update the position of the object,
and the other to update its velocity. The position will depend on the velocity and
acceleration, while the velocity will depend only on the acceleration.
Integration requires a time interval over which to update the position and veloc-
ity: because we update every frame, we use the time interval between frames as the
update time. If your engine is running on a console that has a consistent frame rate,
then you can hard-code this value into your code (although it is wise not to because in
the same console different territories can have different frame rates). If you are run-
ning on a PC with a variable frame-rate, then you probably need to time the duration
of the frame.
Typically developers will time a frame and then use that value to update the next
frame. This can cause noticeable jolts if frame durations are dramatically inconsistent,
but the game is unlikely to feel smooth in this case anyway, so it is a common rule of
thumb.
In the code on the CD I use a central timing system that calculates the duration of
each frame. The physics code we will develop here simply takes in a time parameter
when it updates and doesn't care how this value was calculated.