Hey all,
I'm writing a basic 2d isometric tile-based game engine, and trying to follow the entity component system design pattern. My understanding is that Entities are generic containers that contain Components. Components are the different types of data that you associate with that entity. Systems are the game logic, and loop through entities that have the correct combination of components that the system needs to process. So, my question is: How do these systems pick which entities have the correct combination of components? I can think of a few ways, that I'll suggest below in pseudocode, but I was wondering how other people do it.
#1: Each system loops through all of the entities in the game, and explicitly checks if they contain the correct components.
http://vasir.net/blog/game-development/how-to-build-entity-component-system-in-javascript ("System" section)
function RenderSystem.process(entityList) {
// Loops through all entities (maybe inefficient if there are a lot of entities in the world?)
foreach(entity in entityList) {
if (entity.componentList.contains('PositionComponent') && entity.componentList.contains('SpriteComponent') {
graphicsContext.render(
entity.componentList['PositionComponent'].x,
entity.componentList['PositionComponent'].y,
entity.componentList['SpriteComponent'].image
);
}
}
}#2: Have some sort of bitmap that represents the components an entity can have. Each bit position represents a component type.
function RenderSystem.process(entityList) {
// Loops through all entities (maybe inefficient if there are a lot of entities in the world?)
foreach(entity in entityList) {
// Let's say that position 1 and 3 represent the position and sprite components.
if ((entity.componentBitMap & '1010') == '1010') {
graphicsContext.render(
entity.componentList['PositionComponent'].x,
entity.componentList['PositionComponent'].y,
entity.componentList['SpriteComponent'].image
);
}
}
}#3: Have strongly typed "Nodes" that represent collections of components.
http://shaun.boyblack.co.za/blog/2012/08/04/games-and-entity-systems/ ("Nodes and Systems" section)
class RenderNode {
public PositionComponent position;
public SpriteComponent sprite;
}
function RenderSystem.process(renderNodeList) {
// Loops through all nodes that have been added to some linked list of nodes.
foreach(node in renderNodeList) {
graphicsContext.render(
node.position.x,
node.position.y,
node.sprite.image
);
}
}#4: Have separate hash maps of components where the entity that they belong to has it's id as the key. Do an intersection on the hash maps required by the system, and only process those entities whose id was in all required component hash maps.
I have seen some posts alluding to this sort of approach, but I haven't seen any articles or tutorials implementing it.
function RenderSystem.process(entityList, componentManager) {
// Get the set of entityIds that we want to process by intersecting the required component hash maps
entityIdList = componentManager['PositionComponent'].keys.intersect(componentManager['SpriteComponent'].keys);
foreach(entityId in entityIdList) {
graphicsContext.render(
componentManager['PositionComponent'][entityId].x,
componentManager['PositionComponent'][entityId].y,
componentManager['SpriteComponent'][entityId].image
);
}
}Some notes:
- #1 through #3 have components on the entity object itself, while #4 has components stored in a separate data structure.
- #3 would require some sort of registration with other data structures upon entity creation. This would have some overhead when attaching components dynamically at run time (for example, what happens if your character gets frozen by an ice monster and can no longer move, and you want to remove its "MovementComponent," you'll have to find all of the nodeLists that have movement components as one of their properties, and remove the entity from the list).
- #3 allows the system to just process the required components. No need for filtering entities, or performing intersections on lists of components. By increasing overhead in attaching components to entities at run time, you've decreased the overhead of filtering within the system processing.
-
#3 allows for strongly typed collections of components. My pseudocode above is for a system that is dynamically typed, but in a static language, I would have to explicitly cast the components before accessing their properties. For example...
entity.componentList['PositionComponent'].x...would become...(PositionComponent)(entity.componentList['PositionComponent']).x...because componentList would just contain IComponent or something like that. It wouldn't know about x.
