Hi everyone,

I've recently in the last year been working on my own practice ECS-based engine and have been making good progress, although limited to very simple game implementations like Pong! Actually enjoying sticking with it believe it or not; my mega-fantasy game can wait a bit longer :-). Now I'm getting into more and more detailed (and more confusing) implementation issues, I'll probably be pestering this board more and more for your insight.

Basically, I'm now stuck on how to properly implement how to control the player character and also AI characters. A few issues or possible resolutions have come to light.

1. Since I'm using an ECS architecture, then why not simply add an Input Controller Component for the player characters and an AI Controller Component for the AI characters; The Input Components get handled by the input system (which read from the keyboard and game controllers) and then send commands/messages/events to other components to make the player move or do stuff. On the other hand, in most games only one Entity (i.e. the player) will have an Input Component so is this overkill?

2. I've seen in some places (most notably in Unreal Engine) about Actors or GameActors. Although it's rarely stated explicitly, I'm assuming an Actor in this context is an Entity that can be controlled (either player or AI)? The reason for my confusion is in Unreal, it almost seems like an Actor is the same as an Entity, just a different name (although maybe I am wrong about this). Or is there a fundamental difference? (Does Unreal have both Actors and Entities?) In that case, are Actors in a pure ECS-model simply Entities with either an input or AI component?

3. The third final source of confusion is that there is the 'Actor Model' of programming which I have some understanding about. Is it just an unfortunate coincidence that they have the same name, or do they share something in common? Some people have talked about implementing an Actor System with ECS just to confuse me more.

Apologies if this has been answered before. I did look on the forums but could not find any answer that was satisfying. Thanks for your help in advance.

Thanks for you reply Hodgman. Just to clarify, I assume your answer to 1) is in favour of having an Input component? I can see the situation where you want to transmit commands over a network and these can simply be piped to the input component of the networked player's local entity rather than faffing around with other things. I'll probably go with this unless someone points out any fundamental problems with it.

Yes, I was familiar with the Actor Model, enough that I will probably use it (or some variation) to implement multi-threading at some stage (although not for Pong which I'm sure can survive without it!). Just worried there was something more to it, but thanks for clarifying again.

I would advise against having an input component that reads straight off the input hardware. It makes it unnecessaily difficult to switch the object that is controlled by the player. For example, lets say you have a character that walks over to a car, gets in it, and drives off. At some point you want to switch the controlled character to the car, possibly removing the character object at the same time. While this is certainly possible to with an input component you have to be very careful that the car and the character dont exist both for a frame or two and happen to both read a key press that causes them both to do something only ever a single object should do at any point in time.

Another example is having the capability to control an enemy character during development. Being able to switch to another character by clicking on them is priceless when testing certain gameplay features.

The solution to this is to have an additional layer between the input hardware and the objects, called a controller. In my engine each controller can have zero or one objects called their "avatar" which is the object that controller controls at the moment. I believe Unreal calls this "possessing". Each human player that joins a game gets their own controller (which can also handle things like key-remapping etc that game objects really should not care about).

Communication between the controller and the object is done through messages. This means that you can make a common movement interface for both your player character and enemies and simply switch the avatar object of the controller. The movement will work the same for both. If the player character can jump but the enemies cant they just wont react to the jump message.

Regarding AI characters, I am not really sure having their behavior be driven through a controller is necessary. In networked games it makes sense, but for single player games I usually have a component that drives their internal AI logic. If the object becomes the avatar of a player controller, the AI component simply switches off.

Yes, my plan was definitely NOT to have the hardware to talk to the InputComponents but have an intermediate 'InputManager' to receive input from the hardware and then convert them to commands/messages to be sent to the InputComponents. I guess the only thing I'm wondering is how much of the 'translation' of the input to commands should be in the manager and how much in the components. Thinking more about this does bring up an interesting point. There are 3 main ways entities can get input, one from the player controllers, one from networked input and the third from the AI. Should these 3 systems all be able to talk to the InputComponent, or is there really a need for a separate AI component?

The case with the car is interesting indeed and I didn't really think about those cases so thanks for pointing it out. I'm not planning on making the next GTA any time soon but still you never know :-) But the ability to switch an input controller to different entities for different reasons is certainly worth having indeed. Thanks!

Unreal's "Actor" is a "thing that can be placed in a level" - it then has "Pawn", which is a "controllable actor". It also has the concept of a "Controller" class on an Actor - the purpose of the controller is manipulate the Pawn. This ends up in essentially "PlayerController" and "AIController", with the former taking input from humans and the latter taking input from the AI subsystems. The idea is that characters (pawns) can be controlled by either Players or AI by swapping out the controller.

In UE, Player input is handled by an input system translating the raw platform input into a series of 'actions' (eg: space maps to jump, w maps to move forward, etc). These actions are handled by an InputComponent that lives on the PlayerController. This is what says "take the move forward action and actually do something with it". There's a good description on UE's InputComponent system here.

Thanks for that explanation evolutional. That at least is partly aligned with what I was thinking (although understanding the idea and implementing it are two different things entirely)! I still haven't figured a neat way of mapping raw hardware input into player controls yet (without hard-wiring it at least) but hopefully that'll come to me soon!

2. I've seen in some places (most notably in Unreal Engine) about Actors or GameActors. Although it's rarely stated explicitly, I'm assuming an Actor in this context is an Entity that can be controlled (either player or AI)? The reason for my confusion is in Unreal, it almost seems like an Actor is the same as an Entity, just a different name (although maybe I am wrong about this). Or is there a fundamental difference? (Does Unreal have both Actors and Entities?) In that case, are Actors in a pure ECS-model simply Entities with either an input or AI component?

Bear in mind that Unreal (and its terminology) dates back to the mid 90s, whereas the whole entity-component thing is a recent trend*. I would argue that Unreal have just added the concept of components to their Actors to try and make them more like the GameObjects in Unity, as part of their drive to convert indies and hobbyists over.

Most engines I've worked with still use a system much like Unreal's basic hierarchy, where there is a basic 'Actor' type - often under a different name - that represents "a thing that exists in the game world and which moves around and does stuff", and there might be a few subclasses that specialize the behavior. In that sense, an Actor is basically an Entity, but may not necessarily have interchangeable components.

(*Thief, System Shock 2, and Dungeon Siege had similar systems in the late 90s, but it's only the last few years that they've suddenly become popular, largely due to a large degree of evangelism from certain quarters.)