I'm trying to implement a simple turn-based space combat game, my first attempt at game programming. After some research, i thought that an entity system may be a good way of implementing this (primarily inspired by http://t-machine.org/index.php/category/entity-systems/ But i couldn't figure out how to implement some things using this architecture. For example, I understand how a movement system gets entities with velocity and position components, and updates the position each frame. But how would i let entities with a sensor component perform a sensor scan? If components only contain data and an entity is just a unique id, then its behaviour would go into a system. I could either create a separate system for it, or duplicate this functionality only in the systems that require it. If i make a separate system, My understanding is a scan would be performed on all entities with sensors, but not every entity may require information about what's around them every tick, then there's also the requirement of giving this info to other systems like AI. The second would result in some code duplication. Am I applying the entity system wrongly in this case? I'm having similar problems with figuring out how to implement special game events such as entering a specific sector playing a cut scene, or having gates bringing players to a completely new sector; should these 2 things be represented as an entity?

I'm having similar problems with figuring out how to implement special game events such as entering a specific sector playing a cut scene, or having gates bringing players to a completely new sector; should these 2 things be represented as an entity?

If your sector has a collider component, when new entities collide with it (aka enters the sector), the collision system informs other systems of said event. Your CutSceneSystem may be interested in collisions between Sectors and Entities and if such a collision event is raised, it gets the current sector id/name, locates the cutscene files and begins their playback for the user experience. In this case, its a combination of the Physics System and a Game System interacting by way of events/messages/callbacks.

As for gates taking players to new sectors, this again is basically a collider component in the ECS that raises a collision event that causes your SectorTeleportSystem to fire. It begins by playing a wormhole warp cutscene sequence while the new sector is loaded from disk. After loading is complete the cutscene sequence ends and you find yourself in the new sector.

As phil_t said, some systems can respond to game world events/triggers but are not necessarily manipulating entities. The events/triggers they do react to however can very much be something that the entity component system triggered based on some component system that manages a particular game aspect.

… then there's also the requirement of giving this info to other systems like AI. ...

Notice please that systems need not to be active. Sensors are a good example for a passive system. Reasons are (a) that the AI state determines whether and which sensor data is needed in the current run, and (b) that computing sensor data is often a relatively costly process. So instead of letting the sensor system run on its own, implement it as interface where other systems can send queries to.

Example: Attaching a VisualSensor component to an entity defines that the entity is able "to look". The component's data specify the view volume (e.g. a cone with diameter at its base, its heigh, and a direction). Another component, say the VisualStimulus component, specifies the volume and visibility (in the meaning of cloaking and such) of an entity if attached. These data are managed by a VisualSense system. The interface of the system allows to query for all entities belonging to a VisualStimulus that intersects the VisualSensor volume of a given entity.

Thanks all for the informative responses; that did clear up my questions :)