Question

I’m writing a simple 2D game centered around mazes with RPG elements. It is primarily for learning purposes to practice class design, graph theory algorithms, data structure use, and using 2D graphics.

Brief Overview of the Program:

The game itself is tile based. It currently generates and draws mazes to the screen, allows for player movement, and collision detection for walls; in addition it can handle screen scrolling for larger mazes.

Anyway, right now I’m working on building an object which handles placing objects around the map. First on the list is gold coins, then things like hearts and items. I thought this would be a good time to practice inheritance and polymorphism, but I haven’t had any formal training in this kind of design. Here is the header file:

#ifndef MAP_OBJECT_H
#define MAP_OBJECT_H

#include "Common.h"
#include "Utility Functions.h"

const int TILE_SIZE = 80;

class MapObject
{
public:


    MapObject(unsigned int nClips, unsigned int r, unsigned int c, unsigned int cSize)     :
         sheet(0), clips(0), row(r), col(c), numClips(nClips), clipSize(cSize)
    {
        //For those of you who aren't familiar with sprite sheet usage, basically this
        // handles which part of the sprite sheet your on, so it will draw the correct sprite to the screen
        if(numClips > 0) clips = new SDL_Rect[numClips];
        box.h = clipSize;
        box.w = clipSize;
    }

    virtual ~MapObject()  //NOt sure if this is right.  All the derived classes will
                          // behave the same upon deletion, since the only resource 
                          //  that got allocated was for the box SDL_rect
    {
        if(clips) delete[] clips;
    }


    void initBox(int modX, int modY);
    //I think each object will draw a little different, so I made it virtual
    virtual void draw() = 0;
    //Same with interaction--although I'm not sure how my player class is going to be able to handle this yet
    virtual void interact() = 0;

     SDL_Rect getBox() const;

 private:
    SDL_Surface*  sheet;
    SDL_Rect      box;
    SDL_Rect*     clips;
    unsigned int  row, col;
    unsigned int  numClips;
    unsigned int  clipSize;

     MapObject() {}  //Made this private because I want the memory to be allocated, and 
                     // numClips needs to be initialized for that to happen, so 
                     //basically I'm forcing the user to use the constructor with parameters
};


class Coin : public MapObject
{
    enum  CoinFace  //This represents all the different coin facings in the sprite 
                     //sheet, so that is can animate.  Used in the draw function.
    {
        FRONT,
        TURN1,
        TURN2,
        TURN3,
        USED
    };

    CoinFace  active;

public:
    virtual void draw(SDL_Surface* destination);
    virtual void interact();
};

#endif //MAP_OBJECTS

My biggest question is a general one: is this a good start to my design? Are their glaring problems? Misuses of OOD principles/conventions?

Will defining the virtual destructor like that allow for all the derived classes to use it? Or do I need to define it for each derived class?

I realize this is a lot, and I appreciate any help. I’m REALLY trying to understand OOD and how to use polymorphism, so help from some pros would be incredibly useful.

Thanks again.

EDIT: Big question I have also is the problem of begin able to modify private data members in the derived classes. I hear it’s bad class design if I need to do this, and I’m not sure how to write a good interface, I guess.

Answer 1

Part of the question relies on a matter of opinions. Nevertheless:

1. All I can say here is that your approach can work, and you’re well on your way to have that working. Just don’t forget to define the constructor of Coin.
2. The whole purpose of the virtual destructor is to call the appropriate destructor when we only have a pointer of a base class type. In addition, the derived destructor is performed before the base destructor is automatically called, without having to call it explicitly. In this case, a Coin pointed by a MapObject* will be destroyed correctly with delete, which performs ~Coin() and ~MapObject(), in this order.
3. That question can easily turn into a debate on proper interface construction, but here are a few solutions:
   • Define private members via the constructor, preventing them from being modified by other classes.
   • Make members in a base class protected instead of private. This might be the simpler solution to what you wish to do here.
   • Create setters for the private member types, like setActive(CoinFace). You can adapt these functions to your needs, like preventing invalid definitions for an attribute that would make the whole object inconsistent. Like the previous solution, you can make these setters protected, so that only derived classes can access them.
   • Make the class a friend of another class (calling it A). Instances of A can take objects of that class and access all its private members.