Sign in to follow this  

A few questions regarding game entities

This topic is 2790 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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. I think it would work fine, but are there any more efficient ways of keeping and updating my objects? 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). Thanks in advance, Rob

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Ahhh, interesting, thanks.

I'm not sure I fully understand it completely though,

Basically there is a subsystem for each component type which holds a list of all the objects which use that component?
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)...

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?

I think I got lost somewhere :P

Share this post


Link to post
Share on other sites
If you inline the function, calling getXY will not induce a cost. It would be like accessing xy directly.

Store your entities in a single entity list. Some of those entities will be renderable entities. Those particular entities should register themselves with some sort of rendering container/manager. So basically another list for the renderables. You could have them unregister themselves from this container when they are marked invisible. Or you could have the renderer traverse the list every frame processing only the visible renderables.

The renderable list doesnt need to be updated per say, and it definitely should not affect game state. The entity list how ever, will be updated every frame. So everyone in the entity list gets an update call, and only entities in the renderable list get rendered.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Thanks a lot, that's cleared things up :)

I think I'll read around on the subject a bit more before I dive in, does anyone have a link to any useful articles or threads discussing it the component system other than Sneftel's topic?

Share this post


Link to post
Share on other sites

This topic is 2790 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this