Actually I have redone my code many times. Sometimes I did it because I had a better data structure in mind, other times I did it because someone told me to. Its coming out nice.
Avoid this. Your code may be coming out nice, but if you keep rewriting sections of code as you finder better techniques then you'll never actually finish your game.
Write code. Once it works, leave it alone. If you don't like it, make a note of it, but move on.
Once you've finished your project, then you should go back and re-evaluate the code you noted earlier. Try to find more elegant or appropriate techniques. Then, use what you learn in your next project.
Otherwise, you may be improving your coding skills, but you won't have anything to show for it.
Well, the grunge/grime doesn't need to be heavy enough to actually be grungy and grimy ;) Unless you're specifically going for that look, just aim for a lived in and we'll used look. Few things are new in a nursing home. There might be scuff marks on the walls from the wheelchairs. Wear patterns in the carpet would follow high traffic paths. Maybe the back door has a discolored spot on it from where those staff who smoke tend to push on it with their nicotine stained hands.
Dawoodoz's suggestion of nearly transparent layered textures is a good one. You don't necessarily want the added layer(s) to stand out, Maybe they're so subtle you can't immediately notice them, but they still manage to provide some visual interest and break up large sections of flat color.
Both the Screen Manager and the Entity Manager are placed in a helper class called GameServices, which makes stuff available throughout the entire application, including e.g. the Content Manager and other things.
So instead of every Screen/State having it's own Entity Manager they can all access GameServices.EntityManager to do entity related stuff.
I used to do something like this, but it's risky and error prone. If GameServices is global, then you are exposing these systems to your entire program. It becomes easy to use that access point in places where one really shouldn't, tightly coupling disparate systems that really shouldn't know about each other at all. And tracking down a bug can become extremely difficult since function calls aren't localized to a well defined subset of code.
If your passing your GameServices object around, it's somewhat better, but then why not take the even more better approach of passing these Manager classes specifically to the objects and/or functions that need them?
Not that your approach doesn't work. It does and can be okay for small projects, but it allows the introduction of some nasty bugs, and can become a crutch. I couldn't see how to structure my code any other way until I finally scrapped my entire code base and vowed not to go down that path for my next project. And now I'm a better coder and my code has no hidden dependencies, and is easier to understand and maintain.
I've always been hesitant to jump into Factories because I met a Tech Director that told me they were "crap". Now, obviously, I'm always careful when I am not given any reason, but given I generally respect his opinions as far as tech stuff goes, I figured there might be a reason to avoid these?
No disrespect, but that advice itself is crap. Factory classes have their place, and are only crap when used poorly.
One reason to use a factory to construct bullets is to eliminate unnecessary dependencies. For such complex bullets as you are discussing, it's probable that you would need to pass arguments to the constructor that the calling code otherwise wouldn't need at all, and shouldn't really know about or care about. Pass that responsibility off to a factory and watch your code become simpler, more loosely coupled, and less spaghetti like.
Googling "when to use the factory design pattern" can prove informative. ;)
You call your render function from your game logic? That seems odd. It's usually done at or near the end of the game loop. Maybe you could keep a pActiveCamera that can be updated in your game logic to point to whichever camera you need, and then pass that pointer in to your render function.
An important question here is: does the global have a state that can be changed anywhere in the program? I suspect that a sound system would have state. Such globals are much more difficult to debug, because the problem can be anywhere in the code base, or even worse, the result of multiple lines of code that are widely separated.
It's much better to pass the object around where needed, and better still to have a sound rendering step as Alvaro mentioned, to restrict the scope of the object as much as possible.
There was a time (not too long ago) when I couldn't figure out how to design a game without every manager being a singleton. It severely hampered progress, because global access led to global use, and bugs became ridiculously difficult to track down.
Then I learned about the Single Responsibility Principle, and saw how managers violate it. What does it mean to "manage" resources or input? Take a notebook and a writing device and write down everything you expect your texture manager will need to do. Repeat for your other managers. Each action listed for a given manager is likely to be an atomic responsibility, and should strongly be considered a candidate for its own class.
So maybe you have a TextureFetcher class that you can instantiate to request a given texture. And TextureFetchers have a static TextureCache member so that you can instantiate a TextureFetcher wherever you need to (some rendering class or preload routine) and they will always have a handle to the same TextureCache where all the textures are stored. And if the TextureCache doesn't currently have the requested texture loaded, it can instantiate a TextureLoader, or use one instantiated in its constructor, to load the texture. No globals; the closest thing is a static member, which can be private and really only be called from a couple methods in the Fetcher. Nice and easily trackable code.
That's kinda off the top of my head and should be considered more an indication of how globals aren't necessary rather than an example of How To Structure Your Code.
Another couple of concepts to get familiar with are Inversion of Control and Dependency Injection. I used to think passing pointers and references all over the place made messy, ugly code. But it makes dependencies explicit rather than trying to keep track of everywhere a global singleton has been called. And in practice, with a bit of planning, they don't need to be passed around as much as you may fear.
There's probably a use for singletons somewhere, but in my experience, they're unnecessary in games, and end up being more trouble than they're worth.