C++ game, class design and responsibilities

Question

I've just read some related questions that came up when I typed the subject, so I'll try not to repeat those.

I've recently started revisiting a learning project I started about two or three years ago - a C++ port of a Mega Man engine. Yes I used ripped sprites. I also am using a game engine library for drawing, music, and input.

My original code was atrocious. While it could (but barely) be called OO, it missed the point entirely. I've starting adding things like interfaces and cut out a lot of repetitive code. There are some things I'm not sure about, because game design gets very complex at times.

The object that represents my game library is currently global (I know globals are usually bad) because many objects may rely on it here and there for things like loading their art or music. What's the best way to go about pulling that object out of global scope, without having to pass fifty parameters to everything that would otherwise use it directly?

Next question: As we all know, Mega Man shoots lots of little white projectiles. Currently, the Player object is responsible for the Projectile objects he fires, updating their position and such (literally, calling the Projectile::Update() method once for each shot, inside the Player::Update() method). Is this the wrong way to do it? My first improvement was have all of these objects implement a DrawnObject interface, so that my game can just draw everything. Doing the same thing for Updates would mean I take control of the projectiles away from Player and give it to some broader Game object. The reason I'm hesitant about this is that it feels like the God object antipattern. Or am I misunderstanding said antipattern? There is still additional complexity involved - the projectiles die if they leave the visible screen, so any call to update the projectile would require the caller to have access to the screen object.

That's all for now, I'll come back with more problems when I reach them. End of first post!

Answer 1

As far as making a class global I would use a singleton, then just call Game::GetInstance() which would return a pointer to the global class.

As far as the particles, the way I've always handled games was to make a class that manages all the objects. In my games main loop I would call that classes UpdateObjects function which would go through a list of items it has stored and call each of there Update functions. Same thing with Render and Collision.

Answer 2

I've tinkered with game design in the past, but I can't claim to be an expert.

For accessing an object globally, I would suggest using a singleton

for moving objects, I would suggest making everything a parent class that understands screen location and has an update method. Whenever a new object is created, add it to a vector that contains all objects, once per frame, you step through the vector and run the update on all of the objects.

Answer 3

The object that represents my game library is currently global (I know globals are usually bad) because many objects may rely on it here and there for things like loading their art or music. What's the best way to go about pulling that object out of global scope, without having to pass fifty parameters to everything that would otherwise use it directly?

I agree with the aforementioned singleton solution.

Next question: As we all know, Mega Man shoots lots of little white projectiles. Currently, the Player object is responsible for the Projectile objects he fires, updating their position and such (literally, calling the Projectile::Update() method once for each shot, inside the Player::Update() method).

There is an agile design principle for code construction called: "The single responsibility principle". According to it "THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE." So I guess I would start with seperating the responsibilities of the Player class to seperate classes: eg one for positioning and one for firing.

See an example and more on the subject SRP