Many sources of movement in an entity system

Question

I'm fairly new to the idea of entity systems, having read a bunch of stuff (most usefully, this great blog and this answer).

Though I'm having a little trouble understanding how something as simple as being able to manipualate the position of an object by an undefined number of sources.

That is, I have my entity, which has a position component. I then have some event in the game which tells this entity to move a given distance, in a given time.

These events can happen at any time, and will have different values for position and time. The result is that they'd be compounded together.

In a traditional OO solution, I'd have some sort of MoveBy class, that contains the distance/time, and an array of those inside my game object class. Each frame, I'd iterate through all the MoveBy, and apply it to the position. If a MoveBy has reached its finish time, remove it from the array.

With the entity system, I'm a little confused as how I should replicate this sort of behavior.

If there were just one of these at a time, instead of being able to compound them together, it'd be fairly straightforward (I believe) and look something like this:

PositionComponent containing x, y

MoveByComponent containing x, y, time

Entity which has both a PositionComponent and a MoveByComponent

MoveBySystem that looks for an entity with both these components, and adds the value of MoveByComponent to the PositionComponent. When the time is reached, it removes the component from that entity.

I'm a bit confused as to how I'd do the same thing with many move by's.

My initial thoughts are that I would have:

PositionComponent, MoveByComponent the same as above

MoveByCollectionComponent which contains an array of MoveByComponents

MoveByCollectionSystem that looks for an entity with a PositionComponent and a MoveByCollectionComponent, iterating through the MoveByComponents inside it, applying/removing as necessary.

I guess this is a more general problem, of having many of the same component, and wanting a corresponding system to act on each one. My entities contain their components inside a hash of component type -> component, so strictly have only 1 component of a particular type per entity.

1. Is this the right way to be looking at this?

2. Should an entity only ever have one component of a given type at all times?

Answer 1

For your scenario, we typically add three components to a game object:

1. TransformComponent (position, orientation, scale)
2. VelocityComponent (speed, direction)
3. ControllerComponent

When game objects need some type of AI functionality such as moving along a path as you described, we assign an AIController to it's list of components. AIControllers are really nothing more beyond a wrapper that steps a Behavioral Tree. The behavior tree is where we design the actual functionality we want to have the game object perform such as:

BehaviorTree* tree(new SequentialNode());
tree->addChild(new MoveToNode(x,y,z));
tree->addChild(new WaitNode(30));
tree->addChild(new MoveToNode(a,b,c));
tree->addChild(new WaitNode(30));
gameObject->addComponent(new AIController(tree));

The AI subsystem manages AIControllers and so that subsystem ticks the controller which in turn steps the Behavior Tree. The MoveToNode() looks at the present position/orientation, calculates a direction vector and speed to where you want to move to based on it's constructor arguments and sets the values on the velocity component. The movement system is responsible for reading movement components with values and applying physics thus updating the position/orientation accordingly.

The above code simply moves a game object from spawn location to x,y,z in world space, then waits a minimum of 30 seconds, then moves the game object to location a,b,c and then waits another 30 seconds. Once the wait is over, the behavior sequence has finished, so it repeats from the start.

This allows you to easily define whatever AI functionality you need all self contained in the AI subsystem with minimal impact to your Entity subsystem. It also allows you to keep your entity system component list lean without too much granularity too.

Answer 2

An option is to add controllers to your design. Entities own data to represent position (in the case of my engine they have data that remember the previous positions too, so I can know the velocity vector and if they are being moved or teleported), but they don't know nothing about physics or AI. Controllers move entities and you can have many controllers affecting the same entity or one controller affecting various entities.

For example: create a base Controller class with a run() method, or if you don't like the name call it think(), update() or tick(). Then you inherit from it and create a MoveController, NPCController, PlayerInputController (for the player entity), PhysicController; then you implement the run() method. I would put your MoveByComponent in the MoveController and not in Entity.

These Controllers can be instantiated by each Entity if they hold data specific of an Entity. They can be destroyed or reseted for reuse latter. Also you can use a Controller for move a group of entities, in a RTE game for example, if you need to move various units as a group, have a controller by each unit may hurt game performance, then you can simply assign all the units to a GroupController or LegionController and let it move the units as part of a organized group. When fighting, if the game allows individual unit behavior, and probably most games do, you will have to switch to a UnitController but it's better to do that only when needed than from the beginning.

In my developing game I have a MoveController that moves entities following a path, one MoveController exists for each NPC and the player character. Occasionally one is created for boxes or rock that the player can push. The PhysicController, only one instance, that will check positions of all entities assigned to it, if some entity is colliding another assigned entity the resulting position of both is calculated (it actually does more than that but you get the idea). The NPCController is the AI, one instance per NPC. It checks the situation of the NPC and decides where to move, then push the path to a MoveController, that actually moves the NPC. Controllers have a priority, so I can determine in advance their order, the PhysicController is the last to execute.

I advocate for controllers but is not the only "correct" option. For example I remember an Entity interface in Cafu engine that have the think() method in the Entity itself, the user of the class must inherit from Entity and implement think(), I remember a derived class called CompanyBot (that comes with the example game) that do some collision check in that method, as it is called "think" we can assume AI code is expected to be there too. While NeoAxis engine (last time I looked into it) have AI and physics separated from the entities.

There exists a Controller pattern that I have listened about. Maybe you should search for it, and that probably is not exactly what I'm talking about here but sounds like a good solution too.