Storing various game entities.
Author
How do you guys store/segregate your game entities?
The prototype I'm currently working on has multiple lists for things like enemies, inanimate objects, different bullet types, explosions, etc. This has served me well up until now, but having to constantly write template functions to run through a list (updates, collisions, recycling) and then make multiple calls to that function for lots of different lists seems a bit messy.
Is there a tidier way of doing this?
I just create one generic entity class/struct, and use that for all objects in the game, except for particles. I think I'd go nuts if I had to create a new one for each type of entity that was going to be in my game.
You didn't specify a language, but I use either interfaces or abstract base classes. For example, I might have an entity manager that holds a Collection<Entity>. An Entity interface (or class) might specify things like "tickUpdate", "move", "add", "remove" etc. The entity manager can iterate over all entities and call the appropriate method without caring how the specific entity implements those methods.
Author
Sorry for not being specific. I'm using C++.
At the minute my project has a generic Entity base class, followed by GUIEntity and GameEntity child classes (probably not necessary to split the two but it made sense at the time). From there I have derived classes for the various object types which are extended with functions/variables suitable for those particular entity types. These types are then broken up into varying lists, so I can check lists/objects with other lists/objects for things like collision.
I'd like to use a simpler system like the ones mentioned already, but how is using one entity list better? I would've thought that keeping a big list of different object types would make testing for interactions more expensive?
At the minute my project has a generic Entity base class, followed by GUIEntity and GameEntity child classes (probably not necessary to split the two but it made sense at the time). From there I have derived classes for the various object types which are extended with functions/variables suitable for those particular entity types. These types are then broken up into varying lists, so I can check lists/objects with other lists/objects for things like collision.
I'd like to use a simpler system like the ones mentioned already, but how is using one entity list better? I would've thought that keeping a big list of different object types would make testing for interactions more expensive?
well couldn't you do something like this
thats a basic concept on how it could be done so you don't have to make more then on struct or template for different objects that effect the game.
struct GameEntites //this will store any an all objects that effect the gamechar ObjName[30];ObjId *id;//pointer to a Object ID enum or array. bool ObjExplode = NULL;int ObjStatBonus = 0;//change an have more code to determine the statbouns on object.thats a basic concept on how it could be done so you don't have to make more then on struct or template for different objects that effect the game.
Author
Wouldn't that still require me to traverse the entire list of available objects to find all objects of a certain type? In my current project there's likely to be a 200+ objects on the screen at any one time, many of which will be bullets, so would having a single list be suitable?
The simplest solution is to use an interface or store all 'updateable' entities in their own list so that you only have to traverse this list and call update on them. Their update methods should automatically get/send the data required in order to update the game. Collisions should be a part of this update process.
And This may be slightly off topic, but you may want to consider approaching the idea of an entity differently. A component system solves this problem due to the loose definition of an entity.
And This may be slightly off topic, but you may want to consider approaching the idea of an entity differently. A component system solves this problem due to the loose definition of an entity.
It can be useful to maintain both an all-entities list and type-specific lists. The only mildly tricky part is object deletion, but it's not that hard with a little planning, and especially not with smart pointers.
Well with the struct style I should you; you can use a file system to handel all the objects so basicly you create a program that can make the object files. So then it would be like a Object Creater program where you can give it a ID, Name, Explosion Rate, Stat Bonus, Cost, Level Req, Gender Req, Stat Req, Chest Spawn Location, Drops from which monster, Sells from somewhere-cost an so on. Or you could do this all in a MySQL database so all the stuff is portable over to a Website easier so then you can do a WoW Armory style page on your site an so people can look up item stats an abunch of differnt stuff.
Hope I've helped.
Hope I've helped.
Looping through 200 entities is nothing, maybe if its 20,000 there might start to be problems. I'd say just use std::vector and loop through them all.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
