Game Development Reference
In-Depth Information
public float Bottom
{
get { return position.Y + barrelOrigin.Y; }
}
As you can see, this property uses the position and barrelOrigin member variables
to calculate the float value. Of course, another option would be to add an extra
member variable to the Cannon class called bottom and compute it only once, in
the constructor. The advantage of calculating the bottom of the game object in the
property itself instead of doing it in the constructor of the class is that it makes for
less redundant data in our class. We only store the position of the object and the
height of the cannon barrel sprite once, in the cannonBarrel object and the position
variable. The counter side of this argument is that recomputing the bottom ev-
ery time the property is accessed will make our code less efficient. This is a de-
sign choice that you have to make as a developer. There are many ways to design
classes and their member variables, methods and properties, and it is important
to realize what your goals are and who is going to use the class. Unfortunately,
there is no 'perfect' design that caters for all possible needs. Make your design
choices carefully, be aware of them, and make sure that everyone who uses your
classes knows which design choices you made and how they impact the use of your
class.
7.5 Reorganizing the Class Structure
7.5.1 A Class for Handling Input
Now that we have seen how to create our own class, let us think about the class
structure of our program. In the Painter3 project, we have two classes: the Painter
class that handles initializing the graphics device, loading sprites, and so on, and the
Cannon class for representing the cannon game object. Not only game objects are
suitable to put in a separate class. Also, other parts of the program could be grouped
together in a class, making the total program easier to read. In the Painter4 example,
we have added two classes to the program: the GameWorld class and the InputHelper
class. We have added the GameWorld class to make a clear separation between things
that need to be done for running an XNA game (initializing the graphics device,
creating the sprite batch, running the game, and so on) and the structure and behavior
of the actual game world (consisting of a number of game objects such as a cannon,
a ball and three paint cans).
The goal of the InputHelper class is to make dealing with input somewhat easier.
Up until now, if we wanted to check if a player pressed a key, we needed to store
the previous and current keyboard state and use a fairly complicated if -instruction.
For example:
Search WWH ::




Custom Search