Entity property system

Question

In lieu of a typical implementation of entity-component systems, I've gone the data-oriented route described by Jason Gregory in Game Engine Architecture. This works really well for common properties that need to be present in practically every entity, like position, model information, and health.

// Common properties
namespace Entity
{
    Vector position[MAX_ENTITIES];
    int health[MAX_ENTITIES];
    Model::ID model[MAX_ENTITIES];
}

But what about when it comes to specific information like character status, AI behavior modifiers, and NPC descriptions? Only a handful of entities need this kind of information: who would expect a barrel to give out quests? It needs to be discrete for each entity, so flyweighting is ruled out.

// Rare properties
namespace Entity
{
    // Character stats
    int strength[MAX_ENTITIES];
    int intelligence[MAX_ENTITIES];
    int charisma[MAX_ENTITIES];

    // AI behaviour
    int aggressiveness[MAX_ENTITIES];
    int recklessness[MAX_ENTITIES];
}

Should I just grit my teeth and make every entity a blob of the same data? Or is there something else I can do to create distinctions between entity types?

Edit:

Here's a method I'm now considering. Hopefully I can program the systems to make use of this layout while still avoiding memory problems.

// Common entity data
bool            Entity::active      [MAX_ENTITIES];
Vector          Entity::position    [MAX_ENTITIES];
Quaternion      Entity::orientation [MAX_ENTITIES];
Vector          Entity::scale       [MAX_ENTITIES];

// Entity handles
Model::ID       Entity::model       [MAX_ENTITIES]; // Index into the Model::X properties
NPC::ID         Entity::npc         [MAX_ENTITIES]; // Index into the NPC::X properties
Script::ID      Entity::script      [MAX_ENTITIES]; // Index into the Script::X properties
Status::ID      Entity::status      [MAX_ENTITIES]; // Index into the Status::X properties

// Models
Material::ID    Model::material     [MAX_MODELS];
Mesh::ID        Model::mesh         [MAX_MODELS];
Skeleton::ID    Model::skeleton     [MAX_MODELS];

// Materials
Texture::ID     Material::colorMap  [MAX_MATERIALS];
Color           Material::diffuse   [MAX_MATERIALS];
Texture::ID     Material::normalMap [MAX_MATERIALS];
Color           Material::specular  [MAX_MATERIALS];
Shader::ID      Material::shader    [MAX_MATERIALS];

// You can see where this is going...

The benefits of this are that you only need to specify the data for the components you need, and it works well with my resource systems (which operate via handles). It also allows me to process each mesh in the same way, each animation in the same way, etc.

I'll post more if I run into any issues.

Kind of getting away from the benefits of an entity system if you're just giving all the entities the same properties. Does the route described by Jason Gregory not cover this situation? — House
– House, Commented Dec 22, 2012 at 20:09
No, it doesn't. He skims over the actual implementation of the entity table and neglects entirely to comment on how to deal with potentially huge entities. — jmegaffin
– jmegaffin, Commented Dec 22, 2012 at 21:01
Bummer. I suppose then you just need to pick one of the standard ways of dealing with storing entity data for components that are not global. — House
– House, Commented Dec 22, 2012 at 21:11
Maybe split your entities into several groups using the same sort of data and use inheritance for this? This way your barrel won't give quests and your npc has AI modifiers, but they can inherit from a class like BaseEntity which has properties for position, model, texture etc. — Thomas
– Thomas, Commented Dec 23, 2012 at 14:46

miguel.martin · Accepted Answer · 2013-08-14 09:43:41Z

You could possibly use an entity system. I am not referring to your current implementation of an entity-component system. An entity system is designed to take away the use of inheritance of your entities (game objects), so that you may define complex ones.

If you don't already know... An entity system is a design that is split up into three major parts. The first part would be an entity, this defines an object in a scene/world, it is typically represented by an integer (as it's identifier), and nothing else*. The second part of an entity system is components, these are usually represented by a data structure. A component could store practically anything, such as mesh, transform (position, rotation, scale, etc.), collision information, etc. One thing to note is, that a component, as I said, only stores data and does not contain any logic. The last part of an entity system is the systems, a system defines logic for your game. For example, say you wanted to move all the entities with an InputComponent and a PositionComponent, you would create a MovementSystem, which defines methods to move the entities (via the PositionComponent, typically through a function called processEntities or update).

*entities do not store a list of their owned components

NOTE: An entity system is not an object oriented desgin, you could implement one in a procedural language, such as C. However, that doesn't mean you have to avoid classes all together, infact, they could benefit you.

ALTERNATE IMPLEMENATIONS:

There are various alternate implemenations you will find on the web, some examples are:

components don't only define data, they also define logic, this is used with the Unity3d game engine (I personally dislike this design, but it works)
entities store a list of their components (in my opinion, this is a very bad design, as you could benefit from storing it in one location)

EXAMPLES

A very famous Java implementation, the Artemis framework: http://gamadu.com/artemis/

A C++ implemenation (this library is mine): http://github.com/miguelishawt/anax

FURTHER READING

There are various links on entity systems (on the bottom of the page) here: http://gamadu.com/artemis/tutorial.html

Uhh, this is exactly what I'm already doing. I'm just asking about a small implementation detail. — jmegaffin
– jmegaffin, Commented Dec 24, 2012 at 8:02
No it's not? You're storing common variables for each Entity, assuming that they all have strength, vitality, etc. with the Entity System that I described, you add the data that you need for a specific Entity (the data isn't actually stored within the Entity). — miguel.martin
– miguel.martin, Commented Dec 24, 2012 at 14:57
@MaelmDev I agree with miguel. This is not what you are doing. Your entity should be nothing more than an ID (with perhaps transformations built-in). Your components can be attached to the entity by storing them directly in the entity using some container or using a manager that ties together the entity and the components it has. — Samaursa
– Samaursa, Commented Dec 26, 2012 at 13:59

Stack Exchange Network

Entity property system

1 Answer 1

You must log in to answer this question.

Hot Network Questions

Entity property system

1 Answer 1

You must log in to answer this question.

Related

Hot Network Questions