Game Development Reference
In-Depth Information
If you are a long-time coder, you've probably heard about design patterns. They are, more or
less, strategies to design your code, given a scenario. Some of them are academic, and some
have uses in the real world. For game development, we can borrow some ideas from the
Model-
View-Controller (MVC)
design pattern. It's often used by the database and web community to
separate the data model from the presentation layer and the data manipulation layer. We won't
strictly follow this design pattern, but rather adapt it in a simpler form.
So what does this mean for Mr. Nom? First of all, we need an abstract representation of our
world that is independent of any bitmaps, sounds, framebuffers, or input events. Instead, we'll
model Mr. Nom's world with a few simple classes in an object-oriented manner. We'll have a
class for the stains in the world, and a class for Mr. Nom himself. Mr. Nom is composed of a
head and tail parts, which we'll also represent by separate classes. To tie everything together,
we'll have an all-knowing class representing the complete world of Mr. Nom, including the stains
and Mr. Nom himself. All of this represents the
model
part of MVC.
The
view
in MVC will be the code that is responsible for rendering the world of Mr. Nom. We'll
have a class or a method that takes the class for the world, reads its current state, and renders
it to the screen.
How
it is rendered does not concern the model classes, which is the most
important lesson to take away from MVC. The model classes are independent of everything, but
the view classes and methods depend on the model classes.
Finally, we have the
controller
in MVC. It tells the model classes to change their state based
on things like user input or the time ticking away. The model classes provide methods to the
controller (for example, with instructions like “turn Mr. Nom to the left�), which the controller can
then use to modify the state of the model. We don't have any code in the model classes that
directly accesses things like the touchscreen or the accelerometer. This way, we can keep the
model classes clear of any external dependencies.
This may sound complicated, and you may be wondering why we do things this way. However,
there are a lot of benefits to this approach. We can implement all of our game logic without
having to know about graphics, audio, or input devices. We can modify the rendering of the
game world without having to change the model classes themselves. We could even go so
far as to exchange a 2D world renderer with a 3D world renderer. We can easily add support
for new input devices by using a controller. All it does is translate input events to method calls
of the model classes. Want to turn Mr. Nom via the accelerometer? No problem—read the
accelerometer values in the controller and translate them to a “turn Mr. Nom left� or a “turn
Mr. Nom right� method call on the model of Mr. Nom. Want to add support for the Zeemote?
No problem, just do the same as in the case of the accelerometer! The best thing about using
controllers is that we don't have to touch a single line of Mr. Nom's code to make all of this
happen.
Let's start by defining Mr. Nom's world. To do this, we'll break away from the strict MVC pattern
a little and use our graphic assets to illustrate the basic ideas. This will also help us to implement
the view component later on (rendering Mr. Nom's abstract world in pixels).
Figure
6-5
shows the game screen upon which the world of Mr. Nom is superimposed, in the
form of a grid.
