What is the proper design for containers/managers?
I read somewhere that if you're using singletons for managers you're doing it wrong. Is this true? For example, in a simple 2d application, there will be a system for drawing that retains the sprite for per frame rendering. Then let each sprite decide whether or not it should or shouldn't be drawn (to be added or removed from the draw system). Many different systems would generate sprites, in a non-singleton draw system, it would require passing that draw system through several layers. In a singleton draw system, it would be trivial.
I'm oversimplifying this however, as there are other systems closely bound to sprites, for example, audio, networking, physics, etc (other managers) that would be used within a single sprite. Using singletons would make this trivial, while using class instances would make long parameters for initializing each and every sprite.
What is the proper way of handling this issue?
I'm oversimplifying this however, as there are other systems closely bound to sprites, for example, audio, networking, physics, etc (other managers) that would be used within a single sprite. Using singletons would make this trivial, while using class instances would make long parameters for initializing each and every sprite.
What is the proper way of handling this issue?
Many class instances can share the same sprite without it being a singleton. In fact a singleton implies only one sprite. I think most games will want more than that... unless I misunderstood what you are trying to convey?
Last edited on
Singletons are good options where you will want to have one manager for the entire program.
Good applications of this would be for textures, sound effects, etc. It makes sense to have textures loaded once in one global manager that everything shares, that way memory is conserved and you don't have to waste time/resources loading something that's already loaded elsewhere.
Not-so-good applications of this would be for something that has all the sprites on a scene, as this limits you to one scene per instance. Even if it seems like 1 scene per instance is fine, it limits what you can do down the line (If you want a split screen / multiplayer effect, for example. Your players would need to be in the same scene at all times and would need to share the same manager)
Good applications of this would be for textures, sound effects, etc. It makes sense to have textures loaded once in one global manager that everything shares, that way memory is conserved and you don't have to waste time/resources loading something that's already loaded elsewhere.
Not-so-good applications of this would be for something that has all the sprites on a scene, as this limits you to one scene per instance. Even if it seems like 1 scene per instance is fine, it limits what you can do down the line (If you want a split screen / multiplayer effect, for example. Your players would need to be in the same scene at all times and would need to share the same manager)
Galik
Seems like I didn't make myself clear. The sprites aren't the singleton, it's the systems the sprite utilizes that may / may not be. Lets say there is a character sprite, and a particle sprite and different systems for each (character system, particle system)
Lets also say the sprites use audio and texture managers. Meaning that if the managers weren't singletons I would have to pass audio and texture through the systems and into each instance of sprite creation.
My main issue is that the parameter list would get very long very quickly. If this is the way it is supposed to be or if there is something I'm missing that is supposed to simplify things let me know.
Seems like I didn't make myself clear. The sprites aren't the singleton, it's the systems the sprite utilizes that may / may not be. Lets say there is a character sprite, and a particle sprite and different systems for each (character system, particle system)
Lets also say the sprites use audio and texture managers. Meaning that if the managers weren't singletons I would have to pass audio and texture through the systems and into each instance of sprite creation.
My main issue is that the parameter list would get very long very quickly. If this is the way it is supposed to be or if there is something I'm missing that is supposed to simplify things let me know.
What does your object interaction diagram for a sprite look like? It sounds much too complicated.
Topic archived. No new replies allowed.