I thought such remarks were beneath you? No need to be so patronizing. You might miss my point? What I’m saying is that I like the functionality in the component, as opposed to the system. I already wrote quite some code around these Entities and Components (and Systems as of today) and it certainly feels like a database - in the current code, you can already simply grab all entities that have component X, without plowing through all the entities. Similairly, you can grab all components in an entity, without the entity having a list of children. The implementation can both be a DB, or a hacked alternative using lots of java.util.Maps to quarantee nearly instant access to ‘columns’.
Currently I have code like:
`
EntityContainer container = new MySQLContainer();
Entity entity1 = new Entity();
container.add(entity1);
container.register(entity1, HealthComponent.class); // creates HealthComponent
container.register(entity1, MovementComponent.class);
Entity entity2 = new Entity();
container.add(entity2);
container.register(entity2, HealthComponent.class); // creates HealthComponent
container.register(entity2, DecayComponent.class);
HealthSystem healthSystem = new HealthSystem()
{
public Class type()
{
return HealthComponent.class;
}
public void perform(Entity entity, HealthComponent health)
{
// there is a 1:1 relationship between the entity and health object.
// fields like health.min, health.max, health.current are ‘bound’ to this entity
if(health.isDying()) // this is code in the component - bad
if(this.isDying(health)) // this is code in the system - better?
// remove entity from the container
else
health.recover(); // this is code in the component - bad
this.recover(health); // this is code in the system - better?
}
// like this... ?
private boolean isDying(HealthComponent comp)
{
return comp.health < 10;
}
}
// and now we feed the Container a HealthSystem, which
// iterates over all Entities with a HealthComponent
// and invokes system.perform(entity, health)
container.execute(healthSystem);
`
Maybe this code clearly shows that I’m missing your point. (?) Maybe, but I’m fairly sure I’m going in the right direction.
What I assume, is that the Component classes/types are like different tables, as you have a fixed amount of columns/fields per {Health|Decay|Movement}Component. Components are like records in a these tables: they only contain data. To connect everything, you have a table like:
(entity_id INT, comp_type INT, comp_id INT UNIQUE)
So that you can instantly find all types that have the same comp_type, and JOIN one of the Component tables depending on what that comp_type actually is. the comp_id is the foreign key used to join the entities to the components.
Either that, or a foreign key (entity_id) in each Component type table.
(Is there a more efficient way that you worked out?)
The System behaves like a stored procedure for a specific component type (like Health).
It just takes a while to get used to, and my preference for the code-in-component might just as well change sooner or later.
) Does Scott Bilas have an article on this, other than his GDC slides? I went through his slides, but would like to read something in more detail if he has it.