Game Development Without "Manager" Classes
Posted: Fri Aug 19, 2016 9:57 am
I thought about titling this "Game Development Without Singletons" but these manager classes are not always singletons.
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
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:
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?
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
class ResourceManager
{
public:
Texture* LoadTexture( std::string path );
private:
Texture* PlayerTexture;
};
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
class BulletManager
{
public:
BulletManager( ResourceManager& rm );
void RenderAllBullets();
private:
ResourceManager Resources;
};
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?