2D Game Programming Tricks - Beginning Android Games - page 377

You should now know how to construct a nicely fitted bounding shape for your 2D objects.
Define those bounding shape sizes manually when you create your graphical assets, and define
the units and sizes of your objects in the game world. You can then use these sizes in your code
to collide objects.

Game Object Attributes
Bob just got fatter. In addition to the mesh we use for rendering (the rectangle mapping to
Bob's image texture), we now have a second data structure holding his bounds in some form.
It is crucial to realize that, while we model the bounds after the mapped version of Bob in
model space, the actual bounds are independent of the texture region to which you map Bob's
rectangle. Of course, we try to have a close match to the outline of Bob's image in the texture
when we create the bounding shape. It does not matter, however, whether the texture image is
32×32 pixels or 128×128 pixels. An object in our world thus has three attribute groups:

ï?® Its position, orientation, scale, velocity, and acceleration : With these we can
apply our physics model from the previous section. Of course, some objects
might be static, and thus will only have position, orientation, and scale.
Often, we can even leave out orientation and scale. The position of the
object usually coincides with the origin in model space, as previously shown
in Figure 8-10 . This makes some calculations easier.

ï?® Its bounding shape (usually constructed in model space around the object's
center) : This coincides with its position and is aligned with its orientation and
scale, as shown in Figure 8-10 . This gives our object a boundary and defines
its size in the world. We can make this shape as complex as we want. We
could, for example, make it a composite of several bounding shapes.

ï?® Its graphical representation : As shown in Figure 8-12 , we still use two
triangles to form a rectangle for Bob and texture-map his image onto the
rectangle. The rectangle is defined in model space, but does not necessarily
equal the bounding shape, as shown in Figure 8-10 .
The graphical rectangle of Bob that we send to OpenGL ES is slightly larger
than Bob's bounding rectangle.

This separation of attributes allows us to apply our Model-View-Controller (MVC) pattern,
as follows:

ï?® On the model side, we have Bob's physical attributes, composed of his

position, scale, rotation, velocity, acceleration, and bounding shape. Bob's
position, scale, and orientation govern where his bounding shape is located
in world space.

ï?® The view simply takes Bob's graphical representation (that is, the two

texture-mapped triangles defined in model space) and renders it at its world
space position according to Bob's position, rotation, and scale. Here we can
use the OpenGL ES matrix operations as we did previously.

ï?® The controller is responsible for updating Bob's physical attributes

according to user input (for example, a left button press could move him to
the left), and according to physical forces, such as gravitational acceleration
(like we applied to the cannonball in the previous section).