Quote:Original post by mistercrabb
Hi, I'm learning c++, and I think I'm ready to make a simple game.

But, I'm not sure how to go about tracking and updating all the entities: player, enemies etc

Should I keep 2 lists of pointers, 'entities' and 'visible entities'?
I could then call the update function for each object in 'entities' and the draw function for 'visible entities'.
Edit: Objects could be pointed to by both lists, IE an alien would be in both while an invisible particle emitter would only be in the first one.

You seem to be thinking about a component entity system, although you might not realize it. Encapsulate your 'lists' inside classes and call these classes subsystems, and you've got something like Sneftel's outboard component entity system. I've used this design and it works well.

Quote:
Also my second question is regarding data encapsulation. I may have missed something here, but if I want to do a ton of collision tests, surely it would be faster to access an object's x/y directly rather than through a getxy(); function? Or is there a way of keeping track of the position of everything? Accessing data directly is bad, so I guess I need something (Visitor pattern? I've heard that phrase mentioned and it sounded vaguely relevant XD)

This just isn't going to matter. The difference between Get/Set functions and direct access is negligible in this context. Concentrate on efficiency at a much higher level: algorithmically and systematically. Make sure your overall design is efficient before thinking about micro-optimizations like the ones you mention here. Then, if you find it's too slow, profile your code to find the bottleneck and concentrate on alleviating it.

Quote:Original post by mistercrabb
Basically there is a subsystem for each component type which holds a list of all the objects which use that component?

Subsystems don't maintain lists of entities directly; rather, they maintain lists of subsystem-specific components that are linked (via member pointer) to the entities in the master list. So Graphics might manage a list of Renderables, each of which contains a pointer to (and enables graphical functionality for) an entity in the master list.

Think of components as discrete chunks of functionality that can be "attached" to any entity. So if you want to make a camera, you would create an entity and attach to it a Camera component. In this case, the component might do little more than manage a view/projection matrix; components of other subsystems, like Physics, will be much more complex.

Quote:
Then the game updater simply updates each subsystem which iterates through it's component list (Im assuming there should be one component instance per object that requires it)...

Exactly. I call the 'game updater' Engine. During a game update, the engine calls down to each subsystem's Update function. Each subsystem in turn does whatever is necessary to update its components. Generally this will be as simple as forwarding to a component-specific Update function, so components can take care of updating themselves.

Quote:
The one thing I didn't quite get from the description is how do I add class-specific functionality? Does the Updater component call the update function of the object it points to?

There is no Updater component. Updates are triggered by the engine itself, which in turn might be controlled by a script or some other user interface.