Game: Hiding GameObject Privates

09/11/14

All right, game dev stuff!

Yeah!

Today, I properly hid private functionality for the GameObject class code.

....

"That's not really very game dev-y."

Right you are, Stephan. This whole game dev setup is also an excuse to learn and develop C++ coding practices. I'm not saying the current setup is necessarily good, but it was something recommended in Code Complete and this seems like a good time to get a feel for it.

The header class definition for GameObject looked like this:

class GameObject {
    public:
        GameObject( int, int, std::string );
        ~GameObject();
        int getX( ) const { return x_; }
        int getY( ) const { return y_; }
        void setX( int x ) { x_ = x; }
        void setY( int y ) { y_ = y; }
        int getVx( ) const { return vx_; }
        int getVy( ) const { return vy_; }
        void setVx( int vx ) { vx_ = vx; }
        void setVy( int vy ) { vy_ = vy; }
        void handle( const SDL_Event & );
        void update( double dt );
        void render( SDL_Surface * );
    private:
        // TODO: private class defined in file (keep private stuff hidden)
        int x_, y_, vx_, vy_;
        SDL_Surface *sprite_;
        void jump_( int, int );
};

Now it looks like this:

class GameObject {
    public:
        GameObject( int, int, std::string );
        ~GameObject();
        int left( ) const;
        int centerX( ) const;
        int right( ) const;
        int bottom( ) const;
        int centerY( ) const;
        int top( ) const;
        void setX( int x );
        void setY( int y );
        int getVx( ) const;
        int getVy( ) const;
        void setVx( int vx );
        void setVy( int vy );
        void handle( const SDL_Event & );
        void update( double dt );
        void render( SDL_Surface * );
    private:
        GameObject_ *gameobject_;
};

I feel like it might make more sense to make the private gameobject_ object a reference instead of a pointer. But reading into it and everything is revealing to me that I'm trying to learn the metagame to a game I don't even know how to play. It's overloading my brain without much payoff. I'll try to stick with basics and fundamentals, adding new concepts piecemeal, and play with things accordingly.

Anyways, I'm doing this because I'm hoping to have things setup such that I can limit the amount of files I'm poking at once. When last I was making a game (gamejam_flowers), I got up to looking at 8 files at once. There was a lot of coupling between most of the files containing the python code.

I'd like to think that this game will end up much more complicated than a game made in a short weekend. I'm not sure how low I can keep my number of open files to be productive, but I figure if I can design such that less files will be open, I'll be more productive overall. So, I'm making it that when I'm altering how GameObject behaves, but not how other code interacts with it, the only code I change is in gameobject.cpp. Even gameobject.h can be a file I ignore.

I'm trying to build design skills such that I only need to understand and/or alter a tiny amount of code to get changes I desire. Lots of the coding books I read drill in the importance of it. Accomplishing it allows for easier reading, maleability, maintenance, and improvement of code in general.

I'm not good at it, but I've only been specifically working on this skill for a very short time. I'm a long way from the 10,000 hours mastery.