Where is 'game logic' implemented in component based design?

Question

I have been trying to get my head around using an entity component system for a game. But I am struggling to understand how I should do 'game-logic'.

What I have so far:

1. Components are essentially just dumb data holders, no logic beyond getters and setters.
2. Systems do processing on groups of components. E.g a PhysicsSystem might process all entities containing Transform and Velocity components.
3. Entities are just integers.

My question is, how do I add 'entity-specific' or 'game' logic? For example, I will have an entity which represents the player. How do I go about moving the player entity?

Couples ideas I had, not sure if any are good?

1. Create a 'MovementSystem' which uses a component (e.g PlayerMovementComponent). Then give just my player entity the PlayerMovementComponent. This is basically just a system which only ever processed the one entity... seems a big fudgey.
2. Create a Script or Behaviour component which holds a std::function (or maybe could reference a lua script), could then have lambdas which allow unique game logic to be given to entities. This seems to go against the data-orientated approach I’m trying to follow?
3. Create a Player class, have it reference the entity Id then give the player class an update method hooking into the game loop. This update method can edit its referenced entities components before the systems process. This is basically disconnecting myself entirely from the ECS for game-logic... not a fan of this idea (also will make my game loop bloat as more unique entities are required).

Hopefully, I can get some comments on the 3 ideas above and some new ideas or thoughts I can pursue.

Answer 1

Not everything in your game must be based on the ECS pattern you're using and the game logic might be a good candidate not to.

It could be a global script.
Or, as you mention, you can implement the logic as a system not to "pollute" your main loop with different classes: this game_logic_system, during its update phase, could callback on script(s) or implement the logic in a more hard-coded way, or via plugin, configuration file, etc...

Whichever way you implement the game logic, it has to be aware of the ECS: it has to identify (for instance) the player entity (by either a unique-id assigned to it, or by looking for entities with a dedicated Player component as you propose) and most of the logic will result in setting some component properties or calling ES methods to obtain the desired behavior.

Answer 2

All three of your suggestions are fine. Use all of them that fit your needs.

You don't have to (and should not) try to shove everything into the "entity component" model. That just creates the same basic shape of problem you have when you shove everything into the "inherit all the things" model: you've just swung the pendulum the other way.

I usually represent the player as a thing that gets a reference to some controlled entity, and recieves actions representing the (human) player's requests from the input system. It interprets those actions according to whatever logic the game needs and makes the appropriate changes to the referenced entity. It's not a "system." It's just what it is. There is one of them (usually), and it just sits in the main Game class the whole time.

You could just as well implement it as a component you attach to entities, owned by a "system" that collects player input and feeds it to every component. Letting the player drive multiple entities, if that's what you really want.

Your "script" component might be useful on its own, either to implement this player control or do handle other one-off or game-specific logic that doesn't deserve its own system or module or component or whatever you're using.