I was thinking today about the design of my central App and Level objects, and about the recommendations of not using globals. In my existing game code, these objects have always been globally accessable so that the various other objects in my game can access the games state (e.g. get the size of the window, size of the map, add objects to the levels object trackers, find suitable targets, etc, etc).
In my most recent game project Ive done this in the form of some global functions like "getApp" and "getLevel", although I guess I could also do more like in the singleton examples with like App::getInstance and have pretty much the same effect.
However I was wondering if this is really a good design in general? Should my app/level (and indirectly, window, object trackers, sound manger, etc, etc though methods like App::getAudio and Level::getProjectileTracker) be globally accessable like this? Or is there some prefered way to handle these objects?
Main App/Game/Level object design
If the App or Level truly needs to be global then that's probably fine, but I strongly doubt that they truly need to be global. You're usually better off passing pointers or references around to just the classes that need them. I know it sounds more complicated, but it doesn't really play out that way, and it encourages you to reconsider the game's design so that only those parts of your game that need access actually have it.
If you're anything like me, your skill in designing how your classes fit together will get better with experience, and you'll likely run into situations where you can't figure out a satisfactory way to do things. When that happened to me I posted here and got good advice on how to solve it. Turns out (surprise) that what seems like the intuitive approach sometimes isn't the best. But with some thought, and some forum-given advice on how to approach a given situation, my classes' interfaces improved and grew less tightly coupled with each other. And my code is better for it.
If you're anything like me, your skill in designing how your classes fit together will get better with experience, and you'll likely run into situations where you can't figure out a satisfactory way to do things. When that happened to me I posted here and got good advice on how to solve it. Turns out (surprise) that what seems like the intuitive approach sometimes isn't the best. But with some thought, and some forum-given advice on how to approach a given situation, my classes' interfaces improved and grew less tightly coupled with each other. And my code is better for it.
All the stuff about globals being evil is just rhetoric and has very little to do with reality. Now a variable that can be CHANGED globally is EVIL!!!!
Most people seem to confuse items that can be read globally with items that can be changed globally. Having an item that can be changed globally is a really really bad idea. Makes it impossible to really find problems and will lead to the demise of many a poor kitten. But if you just have a bunch of items that are read and used globally then it really isn't a big deal.
Most people seem to confuse items that can be read globally with items that can be changed globally. Having an item that can be changed globally is a really really bad idea. Makes it impossible to really find problems and will lead to the demise of many a poor kitten. But if you just have a bunch of items that are read and used globally then it really isn't a big deal.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement