Browse by type
NOTE: The current stable release 1.0.0 breaks backwards compataibility with < 1.0.0. See the change log for details.
Entity Component Systems (ECS) are a form of decomposition that completely decouples entity logic and data from the entity "objects" themselves. The Evolve your Hierarchy article provides a solid overview of EC systems and why you should use them.
EntityX is an EC system that uses C++11 features to provide type-safe component management, event delivery, etc. It was built during the creation of a 2D space shooter.
You can acquire stable releases here.
Alternatively, you can check out the current development version with:
git clone https://github.com/alecthomas/entityx.git
See below for installation instructions.
EntityX now has a mailing list! Send a mail to entityx@librelist.com to subscribe. Instructions will follow.
You can also contact me directly via email or Twitter.
std::shared_ptr for components.boost::signal and switch to embedded Simple::Signal.See the ChangeLog for details.
DEPRECATED - 0.1.x ONLY
An SFML2 example application is available that shows most of EntityX's concepts. It spawns random circles on a 2D plane moving in random directions. If two circles collide they will explode and emit particles. All circles and particles are entities.
It illustrates:
Compile with:
c++ -O3 -std=c++11 -Wall -lsfml-system -lsfml-window -lsfml-graphics -lentityx example.cc -o example
In EntityX data associated with an entity is called a entityx::Component. Systems encapsulate logic and can use as many component types as necessary. An entityx::EventManager allows systems to interact without being tightly coupled. Finally, a Manager object ties all of the systems together for convenience.
As an example, a physics system might need position and mass data, while a collision system might only need position - the data would be logically separated into two components, but usable by any system. The physics system might emit collision events whenever two entities collide.
Following is some skeleton code that implements Position and Direction components, a MovementSystem using these data components, and a CollisionSystem that emits Collision events when two entities collide.
To start with, add the following line to your source file:
#include "entityx/entityx.h"
An entityx::Entity is a convenience class wrapping an opaque uint64_t value allocated by the entityx::EntityManager. Each entity has a set of components associated with it that can be added, queried or retrieved directly.
Creating an entity is as simple as:
#include <entityx/entityx.h>
EntityX entityx;
entityx::Entity entity = entityx.entities.create();
And destroying an entity is done with:
entity.destroy();
entityx::Entity is a convenience class wrapping an entityx::Entity::Id.entityx::Entity handle can be invalidated with invalidate(). This does not affect the underlying entity.entityx::Entity handle.entityx::Entity ID contains an index and a version. When an entity is destroyed, the version associated with the index is incremented, invalidating all previous entities referencing the previous ID.entityx::EntityManager::assign<C>(id, ...).The general idea with the EntityX interpretation of ECS is to have as little logic in components as possible. All logic should be contained in Systems.
To that end Components are typically POD types consisting of self-contained sets of related data. Components can be any user defined struct/class.
As an example, position and direction information might be represented as:
struct Position {
Position(float x = 0.0f, float y = 0.0f) : x(x), y(y) {}
float x, y;
};
struct Direction {
Direction(float x = 0.0f, float y = 0.0f) : x(x), y(y) {}
float x, y;
};
To associate a component with a previously created entity call entityx::Entity::assign<C>() with the component type, and any component constructor arguments:
// Assign a Position with x=1.0f and y=2.0f to "entity"
entity.assign<Position>(1.0f, 2.0f);
To query all entities with a set of components assigned, use entityx::EntityManager::entities_with_components(). This method will return only those entities that have all of the specified components associated with them, assigning each component pointer to the corresponding component instance:
ComponentHandle<Position> position;
ComponentHandle<Direction> direction;
for (Entity entity : entities.entities_with_components(position, direction)) {
// Do things with entity, position and direction.
}
To retrieve a component associated with an entity use entityx::Entity::component<C>():
ComponentHandle<Position> position = entity.component<Position>();
if (position) {
// Do stuff with position
}
In the case where a component has dependencies on other components, a helper class exists that will automatically create these dependencies.
eg. The following will also add Position and Direction components when a Physics component is added to an entity.
#include "entityx/deps/Dependencies.h"
system_manager->add<entityx::deps::Dependency<Physics, Position, Direction>>();
entityx::EntityManager::MAX_COMPONENTS constant.Systems implement behavior using one or more components. Implementations are subclasses of System<T> and must implement the update() method, as shown below.
A basic movement system might be implemented with something like the following:
struct MovementSystem : public System<MovementSystem> {
void update(entityx::EntityManager &es, entityx::EventManager &events, TimeDelta dt) override {
ComponentHandle<Position> position;
ComponentHandle<Direction> direction;
for (Entity entity : es.entities_with_components(position, direction)) {
position->x += direction->x * dt;
position->y += direction->y * dt;
}
};
};
Events are objects emitted by systems, typically when some condition is met. Listeners subscribe to an event type and will receive a callback for each event object emitted. An entityx::EventManager coordinates subscription and delivery of events between subscribers and emitters. Typically subscribers will be other systems, but need not be.
Events are not part of the original ECS pattern, but they are an efficient alternative to component flags for sending infrequent data.
As an example, we might want to implement a very basic collision system using our Position data from above.
First, we define the event type, which for our example is simply the two entities that collided:
struct Collision {
Collision(entityx::Entity left, entityx::Entity right) : left(left), right(right) {}
entityx::Entity left, right;
};
Next we implement our collision system, which emits Collision objects via an entityx::EventManager instance whenever two entities collide.
class CollisionSystem : public System<CollisionSystem> {
public:
void update(entityx::EntityManager &es, entityx::EventManager &events, TimeDelta dt) override {
ComponentHandle<Position> left_position, right_position;
for (Entity left_entity : es.entities_with_components(left_position)) {
for (Entity right_entity : es.entities_with_components(right_position)) {
if (collide(left_position, right_position)) {
events.emit<Collision>(left_entity, right_entity);
}
}
}
};
};
Objects interested in receiving collision information can subscribe to Collision events by first subclassing the CRTP class Receiver<T>:
struct DebugSystem : public System<DebugSystem>, Receiver<DebugSystem> {
void configure(entityx::EventManager &event_manager) {
event_manager.subscribe<Collision>(*this);
}
void update(entityx::EntityManager &entities, entityx::EventManager &events, TimeDelta dt) {}
void receive(const Collision &collision) {
LOG(DEBUG) << "entities collided: " << collision.left << " and " << collision.right << endl;
}
};
Several events are emitted by EntityX itself:
EntityCreatedEvent - emitted when a new entityx::Entity has been created.entityx::Entity entity - Newly created entityx::Entity.EntityDestroyedEvent - emitted when an entityx::Entity is about to be destroyed.entityx::Entity entity - entityx::Entity about to be destroyed.ComponentAddedEvent<C> - emitted when a new component is added to an entity.entityx::Entity entity - entityx::Entity that component was added to.ComponentHandle<C> component - The component added.ComponentRemovedEvent<C> - emitted when a component is removed from an entity.entityx::Entity entity - entityx::Entity that component was removed from.ComponentHandle<C> component - The component removed.receive(const EventType &) method for each event type.Receiver can receive events, but typical usage is to make Systems also be Receivers.Managing systems, components and entities can be streamlined by using the
"quick start" class EntityX. It simply provides pre-initialized
EventManager, EntityManager and SystemManager instances.
To use it, subclass EntityX:
class Level : public EntityX {
public:
explicit Level(filename string) {
systems.add<DebugSystem>();
systems.add<MovementSystem>();
systems.add<CollisionSystem>();
systems.configure();
level.load(filename);
for (auto e : level.entity_data()) {
entityx::Entity entity = entities.create();
entity.assign<Position>(rand() % 100, rand() % 100);
entity.assign<Direction>((rand() % 10) - 5, (rand() % 10) - 5);
}
}
void update(TimeDelta dt) {
systems.update<DebugSystem>(dt);
systems.update<MovementSystem>(dt);
systems.update<CollisionSystem>(dt);
}
Level level;
};
You can then step the entities explicitly inside your own game loop:
while (true) {
level.update(0.1);
}
EntityX has the following build and runtime requirements:
$ claude mcp add entityx \
-- python -m otcore.mcp_server <graph>