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.
Uses Gosu::Song for moving sounds. That limits only one tank movement sound
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:
Search WWH ::




Custom Search