Great. You're suggesting that a GAME hasn't any reference to render code; instead, it might have a renderer subsystem that cares about it (which could be 2D or 3D, it won't affect the game logic). But then, how can I know how a entity could be rendered (or how can i bind it a sprite ) without have any "graphic" information on it?
Newly thanks to all
Beginners tend to mix all their game logic, rendering code, and input into one big mess.
A Game of course will have references to everything. But every component that a game is made up of only needs to know about itself. This is no different than a real machine.
I just made a cup of coffee in a single cup coffee maker. It is composed of a few subsystems that don't know about each other, but work together to solve the problem.
When I turn the unit on the main part asks the water tank if there is enough water. If it says yes, it turns on the heater for about 30 seconds. Then it says 'ready'.
This means I put my cup on the tray, and a coffee cartridge in the holder and close it. Then I press one of the brew buttons.
The machine sucks the water out of the tube and sends it to a little heater. Then it shoots it through the cartridge and out a hole. Then that drop of coffee lands in my cup.
All those little components do their job independently and don't know about each other. The tank heats on command and reports water level. The tube moves the water from point A to B. And finally the little nozzle thing heats that one drop to boiling point and shoots it through the cartridge and out of the machine.
The machine doesn't even know if there is a cup on the tray, or a cartridge in the slot! That's out of it's scope of responsibility. Just like any component in the machine, that's my single area of responsibility in the equation.
So, you can combine several types of things into a higher level thing.
class GameObject
{
Entity entity;
Sprite* sprite;
WhateverElse we;
}
Also, another example would be a resource loader. It just passes pointers to loaded objects, and doesn't know anything else about them.
When you create a gameobject you need to assign a sprite. You get it from the resource loader.
GameObject Paddle1;
Paddle1.sprite = ReourceLoader.GetSprite(".../Paddle.dds");
The GetSprite() will scan over it's list of loaded assets. If it finds ".../Paddle.dds" has already been loaded, it will simply return a pointer to it, and add 1 to the reference count. If it's not loaded, it will load the image, add it to the list of loaded images, add 1 to the reference count, and then return the pointer.
When you are done with your objects, you call ResourceLoader.KillSprite(".../Paddle.dds"), and that will simply decrease the reference count on ".../Paddle.dds". If the reference count reaches 0, it will be deleted from memory (or marked as free so another can be loaded on top of it).
The ResourceLoader knows nothing about the game or anything else outside of it's realm of responsibility. It just counts, loads, and passes out pointers to loaded assets on request.