3
\$\begingroup\$

So I've gone with a somewhat singleton approach to my game class:

#include "myGame.h"

int main () {
    myGame game;
    return game.Execute();
}

But now I need to define a class that accesses variables in the instance of myGame.

class MotionState {
    public:
    virtual void setWorldTransform (...) {
        VariableFromMyGameClass++;            //<-- !?
        ...}
};

I'm trying to integrate this class into my project from an example that just uses globals. How can I access variables of myGame class in the definition of new classes? Should I give up on my singleton approach?

\$\endgroup\$
  • \$\begingroup\$ What variable in your game class do you need to access in MotionState? \$\endgroup\$ – kevintodisco Oct 29 '12 at 1:48
  • \$\begingroup\$ numOfUpdatedBodies++; and physicsWorldScaling \$\endgroup\$ – oringe Oct 29 '12 at 1:51
6
\$\begingroup\$

If you want to continue using the singleton approach, you could benefit from a proper implementation of the singleton design pattern in C++.

Essentially, you define your class as follows:

class myGame {
private:
    static myGame* _instance;
    // Other private members.

public:
    static myGame* Instance();
    // Other public members.
};

And then the Instance function looks like this:

myGame* myGame::Instance() {
    if (!_instance)
        _instance = new myGame();

    return _instance;
}

This way, you can call myGame::Instance() to get your singleton class, and invoke whatever modifier or function you need, from anywhere in your code.

You might also be interested in: https://stackoverflow.com/questions/1008019/c-singleton-design-pattern

\$\endgroup\$
  • \$\begingroup\$ Although looking at those articles, it appears that a game is not an ideal situation to use a singleton? or is this a barrel of monkeys? \$\endgroup\$ – oringe Oct 29 '12 at 2:16
  • \$\begingroup\$ It's a long standing debate in software development, and really comes down to a personal preference. If it works for you, then I say go ahead and use it! If you try to design the perfect object-oriented structure for your game, you might end up spending more time on that than actually making your game :) \$\endgroup\$ – kevintodisco Oct 29 '12 at 2:21
  • \$\begingroup\$ Position A: Some concepts really are singular. Like, if you have a class representing your game, there really can only be one instance of that class in your program. Singletons are therefore appropriate in that sort of situation, because they model the concepts accurately and explicitly. Position B: Singletons are really just complicated globals. If you think that using globals is bad for any reason, then using singletons must be bad for precisely the same reasons. \$\endgroup\$ – Trevor Powell Nov 4 '12 at 9:59
2
\$\begingroup\$

My thoughts-

A singleton implementation is a great way to just have one instance. But if your interested, another way, which I use ALL the time is a completely static class. By declaring all your functions and variables in your "MyGame" class as static you can just use the '::' operator (ex: MyGame::VariableFromMyGameClass++;) Also, as an added benefit, you can force no object creation of the class by declaring the default constructor 'private'.

Just thought I'd contribute :)

-MasterBaldwin

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.