I need help because I don't really know how exactly the best way to build it would be. My current idea resolves around circular dependencies, which I want to avoid. Generally, I have a header, game.h
Circular dependencies are unavoidable at times, there is nothing inherently wrong with them as long as you make sure you tear them down correctly.
I generally wanted to have my textures stored in the core so that some textures could be preloaded during some levels and used in the next. One problem is the circular dependency that is being created. Another is that I have to be careful to know which textures are preloaded when. I'm just having trouble coming up with concepts.
I would personally have a texture manager, and have that passed between the entities that need it, rather than a root "Game" object that everything goes through for everything (I imagine you would do the same for audio and such?).
As for knowing what textures are preloaded, why not use texture "handles". When a texture is requested that's not loaded you just return a "default" texture, and spawn off a thread to load the new texture and replace the default one when its ready.
tbf through that's kind of unnecessary, what situations are you going to come into when you need to load textures at runtime (I assume most would be loaded when the map is loaded?)? If all else fails, loading textures at runtime is unlikely to take more than a few milliseconds, unnoticeable to the player.
Another thing I don't understand is memory management. How do I handle that? Should I try to allocate everything as soon as possible?
Number one rule of game developer, always avoid allocating at runtime when possible, memory allocation is one of the slowest things you'll find in any game. Especially on consoles. Try and load everything before hand, or better yet, stick em in the stack.
Personally what I do is write my own allocation routines (and then override new/delete to assert, to make sure people don't accidently use them). These allocation routines typically allocate in huge blocks of about 64mb each, and then portion them out and return them. Far faster than malloc'ing them at runtime.
Also, in case that the player has an error, how do I handle that? Should I make some functions boolean that return false so that my main function can end peacefully or should I just use a function like exit()?
If the game can continue from the error, ignore it. Better to allow the player to keep playing than drop out (obviously don't do this in debug mode tho).
If you want to find a nice way of showing fatal error messages to the user, checkout the use of SetUnhandledExceptionFilter on windows and setjmp/longjmp on any other platform.