Game Development Reference
In-Depth Information
However, this is a very bad idea. A color indicator is certainly not a kind of cannon,
and designing your classes in this way makes it very unclear what the supposed use
is of your classes. Every time you write a class that inherits from another class, ask
yourself whether that class really is 'a kind of' the class that you inherit from. If it
is not, then you have to rethink your design.
10.5 The
Ball
Class
10.5.1 Outline of the Class
We can define the
Ball
class in a very similar fashion as the
Cannon
class. Just like the
Cannon
class, we inherit from the
ThreeColorGameObject
class. The only difference is
that we have to add an extra member variable that indicates if the ball is currently
shooting.
class
Ball : GameObject
{
bool
shooting;
...
}
When a
Ball
instance is created, we need to call the
ThreeColorGameObject
construc-
tor, just as we did with the
Cannon
class. Next to that, we need to give the
shooting
variable an initial value of
false
, and set the position. However, for now we are not
going to set these variables explicitly in the constructor. We will deal with this later
on. This means that the constructor is given as follows:
public
Ball(ContentManager Content)
:
base
(Content.Load<Texture2D>("spr_ball_red"),
Content.Load<Texture2D>("spr_ball_green"),
Content.Load<Texture2D>("spr_ball_blue"))
{
}
The ball should do a couple of things. First, it should handle input from the player,
so we have to override the
HandleInput
method. Also, the ball needs to be updated,
therefore the
Update
method also needs to be overridden. Finally, the
Reset
method
needs to be overridden, because the
shooting
member variable needs to be reset as
well when this method is called. Overriding the
HandleInput
and
Update
methods is
rather straightforward. Both the headers need the
override
keyword, and we can fill
them in with the right instructions. You can have a look at the complete
Ball
class
definition given in Listing
10.2
.
