Basically, in any game source I've found, and even in game dev books, all code is written with tons of these manager classes: ResourceManager, DisplayManager, KeyboardManager, EnemyManager, ManagerManager, etc. I feel like this MUST be bad design; it just goes against every principle you learn as you're learning programming. Hell, most of the time these classes are just wrappers around global variables; the only difference being you need to add the overhead of function calls to use them. And if you look into it, people always tell you, in what I imagine as a snooty rich person's voice, "There's no need that I can think of for singletons~" but never give a fuckin' alternative.
Take ResourceManager for example. This one is probably the best example of this pattern working. Pseudocode would look like
- Code: Select all
Texture* LoadTexture( std::string path );
I'm not sure there is a good alternative for this type of thing, because it serves one very important purpose: it makes sure resources are only loaded once. If I were to give every renderable object it's own texture member, say for bullets in a bullet hell game, I could be loading the same resource thousands of times.
Keeping on the bullet hell example, in order to continually redraw bullets, I believe I would need some kind of BulletManager. Example:
- Code: Select all
BulletManager( ResourceManager& rm );
Basically, I would need to iterate through every bullet on the screen and render it every frame. I can't think of an alternative, but I can at least take away the global access by giving each "shootable" class it's own BulletManager member, that only keeps track of bullets created by that class.
Also note that I passed in the resource manager via reference, which is basically how people recommend getting rid of global access. I can't imagine tossing these pointers around all over the place is very cache safe.
My question is basically: does anyone else have a different solution to keeping track of your entities or do you use manager classes?