Closed qualiaa closed 11 years ago
There is really no reason for it not to be a singleton. It makes accessing it easier. And why would you want more than one game playing. You should be able to do that by having more than one state and more than one window.
Tell me if I've misunderstood what you mean.
I think you just skipped over the word static. If it's static then it's basically the same except: no ctor/dtor, all member variables get set at the start of the program, and access is Game::func() instead of Game::Instance()->func(), so it's even more convenient. The problem arises when it constructs member variables you don't want constructed before other things initialize - something that requires SDL, for example.
Ah ok that makes sense. I had skipped a word.
Do you have a specific reason for using a static class instead of a namespace? Namespaces have nicer semantics for this kind of thing, so usually static classes are not the done thing in C++ :-)
Private members.
Ah yeah. You could use an anonymous nested namespace but then static classes are beginning to look nicer... xD
Exactly :octocat:
HOW DID YOU DO OCTOCAT?!?!
:octocat: :octocat: :octocat: :octocat: :octocat:
This may rely on SDL being removed, I can't remember, but I can no longer see any reason for Game to be a singleton apart from the perhaps non-trivial amount of effort required to change it.