• 13
• 18
• 19
• 27
• 9

# Designing an Entity system

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

## Recommended Posts

Sorry for yet another Entity Design Thread, but i'm kind of stuck on how to do this. I've never implemented an entity system before, and now's pretty much the time to do it. I've got 3D models working and a stable codebase and rendering system. I know this sounds a bit silly, but i can't really figure out what should go on an entity class. Maybe it's because the term is a bit too abstract for me and that's why i'm not thinking straight. What i want to do is probably something similar to a game object. I merely want to add objects into my game. I'm simply puzzled and can't really figure out where to begin, other than adding position, rotation, scale, name and description. I also need my entites to possibly be made out of multiple models and such so i can create an instance of them without having to add multiple models for that. Writing code to do that wont be a problem, the problem is how to create an entity class/classes regarding what should be kept in those. Would anyone have some links to articles on this matter or something similar? Thank you very much for your help.

##### Share on other sites
As with most things you'll have to determine your requirements before you can determine the low level implementations details. Seems like you have a grasp upon the basic technology you will need but how to put it all together?

Let's say your making a FPS game. Let's see what you would need.

-Actor class  -has unique model    -models share animation sets for efficiency and reuse  -has unique logic or AI    -player logic    -AI logic    -item logic  -has active weapons     -weapons are complex objects        -weapons have properties         -weapons have unique animation and models  -has inventory? (maybe weapon is a type of item)     -items are unique objects etc...  -has physics     -has bounding box and associated physical properties

Actors should probably live in somewhere, lets call it the playfield.

-Playfield class  -holds all actors and items  -updates all actors and items  -handles physics  -handles logic (scripts?)

1/2 way there.. lets see we need a way to interact with the player, lets call that the controller.

-Controller class  -bridges UI and input elements into the playfield/actor class  -is stateful and can do unique logic?

Hmm anything else? Ah how about plugins for the playfield which handle custom functionality, which is just a catchall for ..

-Physics plugin
-Scripting plugin
-Serialization plugin for saving game state
-Networking plugin for handling network games?

-etc..

This gives u an idea, I hope :D

[EDIT: it seems tab are not preserved in normal posting, but in code brackets it is]

Enjoy!

-ddn

##### Share on other sites
I'd recommend looking into component-based designs. There's quite a bit of information on component-based entity systems in the forum archives and elsewhere on the internet, so you shouldn't have too much trouble finding references.

With a component-based design, the entity itself is basically just a container (or an association) of individual components; it's the components themselves that give the entity its behavior and appearance. There are various ways to implement such a system, some of which are fairly low-tech and don't take that much work to get off the ground.

If you're interested in seeing a working example of a component-based entity system, try downloading the free version of the Unity game engine and playing around with it a bit; by creating a few objects and writing a script or two, you should get a sense of how such a system can work. From there, it should be fairly straightforward to develop a similar system in whatever language you're programming in (if you're interested in going in that direction, that is).

##### Share on other sites
The way jyk explained it is the exact way I do it in my simple little game engine. Each entity has a vector of component pointers in it and that's all it is. Each system like graphics and physics would register a component creator with the factory. So in my engine, you would go CreateEntity() to get a blank object and its ID, then do things like AddComponent( ID, "logic" ) or AddComponent( ID, "renderable" ). For behavior, I just add a list of scripts to run for each object. So the logic ends up being someone component based ( can add scripts like "IsClickable" or something if you wanted to make a ui ). To further give you an idea, my full list of components at the moment is: Transform, Motion, Collision, Renderable, and Logic. Each system stores and handles its own list of components too. Hope that helps.