Game Development Reference
In-Depth Information
float
scale
= 1.0f
end
We could also inherit from
RadarBlip
to create all sorts of different types of
blips for different enemies if we so desired. But that's more of an aesthetic de-
cision, and it's irrelevant to the calculations behind implementing the radar.
For the actual radar class, there are two main parameters to set: the maximum dis-
tanceanobjectcanbedetected inthegameworld,andtheradiusoftheradarthat's
displayed onscreen. With these two parameters, once we have a blip position it is
possible to convert it into the correct location on the screen.
Suppose a game has a radar that can detect objects 50 units away. Now imagine
there is an object 25 units straight in front of the player. Because the object pos-
itions are in 3D, we need to first convert both the position of the player and the
object in question into 2D coordinates for the purposes of the radar. If the world
is y-up, this means the radar's plane is the xz-plane. So to project onto the plane,
we can ignore the y-component because it represents the height. In other words,
we want to take a 3D point that's (
x, y, z
) and map it instead to a 2D point that's
essentially (
x, z
), though a 2D point's second component will always be referred
to as “y” in the actual code.
Once both the player and object's positions are converted into 2D coordinates pro-
jected onto the plane of the radar, we can construct a vector from the player to
the object, which for clarity we'll refer to as vector . Although can be used
to determine whether or not an object is within range of the radar (by computing
the length of ), there is one problem with this vector. Most game radars rotate as
the player rotates, such that the topmost point on the radar (90° on a unit circle)
always corresponds to the direction the player is facing. So in order to allow for
such functionality, must be rotated depending on the player's facing vector. This
issue is illustrated in
Figure 10.7
.
