Archived

This topic is now archived and is closed to further replies.

Logic of Entity List : I'm stuck.

This topic is 5015 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

Do you keep all your entities in a big global list? If so, how do you then keep track of players or do you keep a list of entities and a list of players? I''m stuck on how''d you allow the specific player to ''control themselves'' if they''re just in a huge entity list thats constantly being updated. I can half-ass guess in a multiplayer game with a client and a server, because the server is storing the list and doesn''t CARE that the player is being controlled, its just like any other entity as far as the server is concerned. Basically what I''m asking here is how do you keep a player in a list with all the other entities, but allow that entity to be controlled still?

Share this post


Link to post
Share on other sites
As I''m sure you can imagine, this varies wildly between different game types.

Typically, things may go in multiple containers. For example, your entity''s collision proxy will go in some hierarchical space container (like a loose octree) for collision purposes. Your entity''s graphical representation will go in some other container for rendering. If it''s on a client, and listening to user input, it may go in a list of "UI listeners". If it plays sounds, it may be in some container of "sound sources". If it''s waiting for some file to load, it may be in a list of "file system pending requestors". Etc.

If you need a list of players, make a list of players. If you need a list of entities, make a list of entities. However, I like it better when control structure is described using a more explicit relationship; i e, players are in the list of entities, but they also listen to control information by being in the list of UI event broadcasters.

Share this post


Link to post
Share on other sites
That''s the way I do it to.

The Player class (in fact all of the classes) that I use actually contains a client object that links to the control of the system, whether that is keyboard or network. When the cycle comes for working out how an entity moves, the class only needs to run one function and it will get the data from the current keyboard/network/ai state. This however ends up making it very transperant from the engine itself so keyboard controls that modify more than the player become a little harder to implement.

Share this post


Link to post
Share on other sites
Well, your entity list will most likely consist of *pointers* to objects derived from a generic entity class.

The level loader class might, for instance, create some number of enemies, derived from entity, initialize them, and add them to the entity list.

The player, on the other hand, might be created at game startup, or from data in a saved game file. It could then be added to the entity list.

The entity list would then contain a pointer to any entity that resides in your world, regardless of the type. Once each loop, it could test for collisions, check if an entity should be removed from the list (dead) and call functions common to ALL entities, nothing more. Then each type of entity could override these basic functions to do what they need. (Enemies could do basic AI when OnUpdate is called, and player could perform basic animation calculations or ignore the call altogether).

Then the game could be treated as a server/client application. The renderer and physics engine would only be concerned with what''s in the world, and the other subsystems, like input, or saved game loading, could have more specific pointers to the actual objects in their derived form, like CPlayer or CEnemy.

I hope that sheds some light on the topic.

Share this post


Link to post
Share on other sites
A player is in essence an entity with special functionality.
A monster with AI is also an entity with special functionality.
Both can use the same interface to your game.
For example, an AI could send keypresses, just like a human player. The game wouldn''t care...
Static entities are exactly the same... except they never send keypresses. Collision would go just the same for every entity.

So, you have one base Entity class, and you have derived entities with epcialised functionality (see: abstract factory pattern).

Collision meshes can be in a seperate container, because multiple entities can use the same mesh. A group of ogres would all use one and the same mesh, so it''d be silly to copy the mesh to every entity. So, what pi=3 said, you''d have pointers to a collision mesh.

Network players... the same... a network player is also an entity. Except it doesn''t receive key-presses from a keyboard, or an AI, but from the network.

parthon already said it, the actual implementation of your entity is transparant to the rest of the engine. Whether it be a human player ramming on a keyboard, and AI calculating keypresses or a network client receiving stuff from the network. It''s all the same to the engine.

How you build the interface between the engine and entities is a whole different story. A keypress or netreceive can be asynchronous to the engine. So, do you do the update asynchronous to the engine itself? That could make it hell for the synchronisation of the variables.
Or do you handle the synchronisation at the entities itself. Let the entity store the last keypress and let the engine do a "GetLastKey()". This could be nasty too as a keypress could be lost if the player presses two keys at a time.
Decisions decisions...

Share this post


Link to post
Share on other sites