I couldn't think of a better title for this topic, but let me try to explain further here. I'm working (in C++) on a new version of my engine for a new game, and have the opportunity to try to architect things a bit more optimally. I'd like to get some ideas on what you guys think about a problem I have and the solution I chose. The problem I'm trying to solve is this (I use the example of textures but it applies generally to any component from a foreign subsystem): I've got various classes (representing entities of various sorts) that need to have textures assigned to them. At the same time, there needs to be a central repository of all textures that have been assigned, because I don't want to load the same texture twice. I currently deal with this (I'm simplifying for the sake of brevity) by having a TEXTUREMANAGER class that holds a bunch of TEXTURE objects (I use OpenGL so the TEXTURE object is little more than a texture ID) in a map <string,TEXTURE>, and has a public function to take a texture name string and return a reference to a TEXTURE. If it's not in the map already it'll add it and do the actual texture loading. So, the entity has a TEXTURE reference/pointer/smartpointer/whatever and gets it assigned it by calling TEXTUREMANAGER::LoadTexture(string texture_name); A similar problem comes up with my sounds. I've got my entities that need to have SOUND objects assigned to them, yet there needs to be a central repository of SOUNDs so they can be mixed together (yes, I do my own sound mixing, but don't let that throw you off). There's also the issue of not wanting to load sound buffers twice, but that's similar to the above so I'll ignore that problem for this example. My solution is similar: I have a SOUNDMANAGER class that holds a list <SOUND>, and has a public function to add a SOUND to the list and return a reference to a SOUND. It also has a public function to do the actual sound mixing, and for that it iterates through its SOUND list. This all result in my entities having to know about SOUNDMANAGERS and TEXTUREMANAGERS and having a lot of functions like ENTITY::LoadSounds(SOUNDMANAGER & use_this_soundmanager); and ENTITY::LoadTextures(TEXTUREMANAGER & use_this_texturemanager); A higher level system (which creates the actual entities) is responsible for passing in the managers to use. I like this architecture a lot better than using singletons or statics or globals, yet it still seems to have a fair amount of coupling. Anyway, that's a long explanation, but my real question is: what other architecture options are there that could solve these problems?

Resource managers are pretty standard so don't fix what isn't broken imho. Your system doesn't sound overly coupled at all. At some point eventually stuff in your engine is gonna have to know about other stuff. =)

Good question though. What are the alternatives? I agree that statics, globals, or singletons are not good solutions. Just about every project I have worked on uses some form of resource manager.

Quote:Original post by Telastyn
So you're making the design requirement that your entities need to have textures and sounds assigned to them, and then you're wondering why the implementation has entities which are coupled ( since you assign textures and sounds to them )?

Fair enough; I should have said the requirement is that entities need to be associated in some way with specific sounds and textures. As for my concern about coupling, I was worried that the entity has to know about the sound *and* the sound manager -- seems a little odd. Your suggestion is interesting and I'll have to look into it.

I'm also happy to hear that nothing I'm doing seems too backward -- I developed a lot of my general engine architecture in a vacuum, so to speak, using only trial and error from one project to the next (only discovered this great community recently).