Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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.

share|improve this question
    
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? –  Byte56 Dec 22 '12 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. –  Boreal Dec 22 '12 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. –  Byte56 Dec 22 '12 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 Dec 23 '12 at 14:46
    
Inheritance is the last thing I want to do here. –  Boreal Dec 23 '12 at 15:16
show 1 more comment

1 Answer

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

share|improve this answer
    
Uhh, this is exactly what I'm already doing. I'm just asking about a small implementation detail. –  Boreal Dec 24 '12 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 Dec 24 '12 at 14:57
1  
@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 Dec 26 '12 at 13:59
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.