Game Development Reference
In-Depth Information
Refactoring The Prototype
At this point you may be thinking where to go next. We want to implement enemies,
collision detection and AI, but design of current prototype is already limiting. Code is
becoming tightly coupled, there is no clean separation between different domains.
If we were to continue building on top of our prototype, things would get ugly quickly. Thus
we will untangle the spaghetti and rewrite some parts from scratch to achieve elegance.
Game Programming Patterns
I would like to tip my hat to Robert Nystrom, who wrote this amazing topic called
Game
Programming Patterns
. The topic is available online for free, it is a relatively quick read -
I've devoured it with pleasure in roughly 4 hours. If you are guessing that this chapter is
inspired by that topic, you are absolutely right.
Component
pattern is especially noteworthy. We will be using it to do major housekeeping,
and it is great time to do so, because we haven't implemented much of the game yet.
What Is Wrong With Current Design
Until this point we have been building the code in monolithic fashion.
Tank
class holds the
code that:
1.
Loads all ground unit sprites. If some other class handled it, we could reuse the code
to load other units.
2.
Handles sound effects.
3.
per whole game. Basically, we abused Gosu here.
4.
Handles keyboard and mouse. If we were to create AI that controls the tank, we
would not be able to reuse
Tank
class because of this.
5.
Draws graphics on screen.
6.
Calculates physical properties, like speed, acceleration.
7.
Detects movement collisions.
Bullet
is not perfect either: