I'm making a small-medium 2d game right now(on android) and I just wrote up a singleton to handle loading/caching assets as I always do. I just have it set up so I can call loadAsset(name), unloadAsset(name), and getAsset(name) on the singleton to load and use assets and whatnot. the implementation is an ObjectMap(LibGDX's version of hashmap, it's the same as a java hashmap on the surface but allegedly is better with handling memory under the hood to cater to android's limited memory/nasty GC) that just maps the name to the textureregion. the texture regions come from a textureatlas storing many images that is also loaded and cached but libgdx suggests you cache the region itself because it has to relookup the region everytime and apparently it is costly.

I've just been doing it this way forever because it's be good enough for my needs but I see a lot of people hating on singletons and want to check to make sure I'm not making a bad decision by doing it this way, or if anyone has a better suggestion. I use a similar technique for all my games but right now I'd like the question to be answered in the context of a 2d libgdx game that will target android and probably ios.

Thanks for any help, I'd appreciate any solutions you guys can give me but most of all I'd like to have a good explanation so I can understand why this is or isn't a good idea and why something else may be a good idea, basically I want to advance my understanding as much as I can and any help in that regard would be appreciated.

Frankly, if it works for you, I wouldn't worry about it. I've used singleton resource managers for most products I've worked on and it hasn't been an issue design-wise. I'd be more concerned about hashing. Make sure your hashing calls are low and keep your hashing methods fast.

I hate on singletons, but there's nothing really wrong with them in small doses. If you just do this for assets, it's not a big problem. The way around the singleton would be storing the asset table in something like your Activity and assigning / passing it to the other things that need it. I don't know how much this would actually help you.

I mostly hate on singletons for the hidden state they represent. If there are a bunch of singletons that lots of functions regularly access, then it becomes a tangle of dependencies, and you lose track of the state of your program. I like to know what changes what and when, which is easier to track without the singletons. For example, if you run into problems with which assets are loaded or unloaded all the time, you might want to consider a different design. In general, I would only really consider changing a design if I have a concrete problem that I expect the change to help solve.

There's another rule-of-thumb you're going against: I do a lot of profiling at work, and I'd rather not see any string processing of any kind in the profile. Hashing strings counts. I'd try to keep calling getAsset down to a minimum.

Yah I see what you guys are saying about all the string processing for every getAsset() call, usually what I do though is just use it once for each gameobject i create so I can get a reference to the object and then store it in the gameobject class. I'm going to try out a more component based design on this one though and I don't plan on having a gameobject class so I don't know how that will work. I'll just have an id for each gameobject and my manager classes/components will just operate on everything based on id. I guess that means I'll have to have some kind of graphics component that has an array in which the index matches the entity/gameobject id and stores a reference to that entities sprite, does that sound right? Still reading about the whole component thing and I know it may be overkill for my project but I want to learn and am interested in it. If I'm on the right track, do you think I should store the textureregion references in the same component i use for rendering? Or just have a seperate graphics component that talks to my rendering component?

Thanks, sorry for the double question I just thought of that and didn't wanna start a new thread for it