TL;DR: Should I have distinct components such as PlayerController and CameraController that would act as a “brain” this would tie/couple systems to an entity. Or make systems that update components and systems that act on the updated components this way systems aren't (or shouldn't) be tied to a specific entity.

So I'm a little confused on how to make systems in ECS it feels like I'm trying to make systems based on the entity rather than the components which leaves me with some systems being niche I guess? In my game engine project when it comes to input I have a global input manager (a singleton?) which is not part of the ECS then I created a PlayerController and CameraController which uses the input manager like this:

class  CameraController : public ISystem {
public:
	void Update(float timestep) override {
		// Mouse Input
		if (gInputManager.IsMouseButtonDown(SDL_BUTTON_RIGHT)) {

		}

		// Keyboard Input
		if (gInputManager.IsKeyDown(SDLK_w)) {
		}

		if (gInputManager.IsKeyDown(SDLK_s)) {
		}
	}
};

class  PlayerController : public ISystem {
public:
	void Update(float timestep) override {
		

		// Keyboard Input
		if (gInputManager.IsKeyDown(SDLK_w)) {
		}

		if (gInputManager.IsKeyDown(SDLK_s)) {
		}

		// Jump
		if (gInputManager.IsKeyDown(SDLK_SPACE)) {
		}

		// Some ability
		if (gInputManager.IsKeyDown(SDLK_e)) {
		}
	}
};

So, these systems are only useful to a single type of entity, and I feel like that might be the opposite of what ECS is trying to accomplish? Something I've seen frequently is to have some sort of input component I don't actually know how this would work, but if I had to take a stab the idea seems to be you'd have one system that updates your input component and then any entity that needs input uses that component and then I'd have like a mover system that uses the input component to move the entity so now instead of having a system targeting a specific entity like the camera or player I have two general purpose systems that can handle movement for any entity that uses input. This raises a few questions though like being able to look around with the camera or the player being able to activate abilities these are specific or handled differently by some entities which I think is why I went with my original code.

So, I'm curious of both methods mentioned are valid or if one is more typical than the other?

I would also add that it's essential not to get pulled down into the weeds about whether it's related to one entity, as that can easily change.

In my game, I have a CameraSystem and it is responsible for managing multiple camera controller types. We have controllers that render sub-viewport / sub-scenes for minimaps and animated character portraits for health frames. We have a combination of orbital controllers for the player when they're out in the main world and then a series of different types of camera controllers that are swapped in and out based on certain world actions, such as interacting with a specific mini-game or quest in the world. We also have camera controllers for handling cinematic camera tracks for when we play world-based cinematics, and the list continues.

For the PlayerController, we have a system designed to manage a variety of “EntityControllers” that support AI movement, player movement, and various physics bodies like elevators. We even have a specialized controller for when the player casts “Mind Control” on a target, and this controller is limited in that the player can do a subset of actions with the controlled character, but not everything as they can with their actual character.

You may not need all this fancy stuff at the outset, typically most early games don't, but that's the beauty of a framework like ECS is that it makes it tremendously easy to add, augment, and replace prior iterations as long as you design entities, components, and systems with well-defined contracts and boundaries.

Konjointed said:
So I'm a little confused on how to make systems in ECS it feels like I'm trying to make systems based on the entity rather than the components which leaves me with some systems being niche I guess? In my game engine project when it comes to input I have a global input manager (a singleton?) which is not part of the ECS then I created a PlayerController and CameraController which uses the input manager like this:

IMHO, what you have shown in your code should not, in an of itself, be part of the ECS. My engine uses ECS as the primary “glue” between low-level system and high-level logic; but I've come to the conclusion that coding specific gameplay-logic in ECS is not the best use of the pattern.

What you have shown are, as the name suggests, “controllers”. They are not systems. Trying to make them ECS-systems is forcing something unto a pattern that doesn't naturally fit. Your both scripts should be “controllers”, or “behaviours”, that you can attach to an entity, or component, to control them. Your ECS should only model what a “camera” intrinsically represents (that is, a view into the world with specific properties, but also reusing the transform that an entity might have). It doesn't care what happens when “W” is pressed. Your behaviour/controller dictates that. That way, the ECS/system itself is actually not coupled to a single thing - the camera-system only processes specific camera-properties, like view-matrices. That's the design I use for my 2d engine/game. There is a “Transform2D”-component, and a “Camera” component. CameraSystem uses transform+camera to calculate the view. Then, the actual player-controller (which is a regular, non-ecs script) implements the behaviour of the camera in regards to the player-movement. There can be many different ways to control these camera-entities/components; for cutscenes I can create external camera-entities and activate them/transition to them, to show camera-transitions…

That, IMHO, is the proper way to use ECS for your case. You get both the flexibility of the ECS, but don't have to misuse the pattern to fit what is essentially scripted behaviours.

@undefined If I'm understanding this correctly instead of the camera system controlling the camera I'd have a controller class that's not part of the ECS (or a script) to do that for me? I assume this updates the component and then the system just uses that updated information? Is this what hybrid ecs is?

Konjointed said:
@undefined If I'm understanding this correctly instead of the camera system controlling the camera I'd have a controller class that's not part of the ECS (or a script) to do that for me? I assume this updates the component and then the system just uses that updated information? Is this what hybrid ecs is?

Pretty much. The controller can be implement via ECS - in my case, I have a “script” compoment that is treated like a regular ECS component, that allows me to attach scripted interactions to entities.

I guess you could call it hybrid ECS, but I would call it “practical” ECS 🙂 For context, I develop a 2d oldschool action-RPG, which ATM has probably ~30 hours of story-driven gameplay/content. In such a case, using “systems" for behaviour is entirely unpractical. I don't want to make a different system every time I have a scripted NPC/Cutscene, for (hopefully) obvious reasons. In such a game, there are many scripted sequences that are entirely unique, and a regular behaviour-type script is much better suited for those. As you said, those behaviours use the ECS components and modifier their state, which then makes the systems process it accordingly.

In a smaller, less content-driven game, you might get away with using an ECS to implement behaviours like you shown. But I do firmly belive that it's suboptimal, and will not scale well.