ai - How to implement behavior in a component-based game architecture?

I am starting to implement player and enemy AI in a game, but I am confused about how to best implement this in a component-based game architecture.

Say I have a following player character that can be stationary, running and swinging a sword. A player can transit to the swing sword state from both the stationary and running state, but then the swing must be completed before the player can resume standing or running around. During the swing, the player cannot walk around.

As I see it, I have two implementation approaches:

• Create a single AI-component containing all player logic (either decoupled from the actual component or embedded as a PlayerAIComponent). I can easily how to enforce the state restrictions without creating coupling between individual components making up the player entity. However, the AI-component cannot be broken up. If I have, for example, an enemy that can only stand and walk around or only walks around and occasionally swing a sword, I have to create new AI-components.



• Break the behavior up in components, each identifying a specific state. I then get a StandComponent, WalkComponent and SwingComponent. To enforce the transition rules, I have to couple each component. SwingComponent must disable StandComponent and WalkComponent for the duration of the swing. When I have an enemy that only stands around, swinging a sword occasionally, I have to make sure SwingComponent only disables WalkComponent if it is present. Although this allows for better mix-and-matching components, it can lead to a maintainability nightmare as each time a dependency is added, the existing components must be updated to play nicely with the new requirements the dependency places on the character.

The ideal situation would be that a designer can build new enemies/players by dragging components into a container, without having to touch a single line of engine or script code. Although I am not sure script coding can be avoided, I want to keep it as simple as possible.

Summing it all up: Should I lob all AI logic into one component or break up each logic state into separate components to create entity variants more easily?

edit: I suspect there is some confusion about what I meant with the first and second situation. I have tried to explain it in the diagram below.

Note the relationship between the individual states and the entity. In the first situation, an AI component is pre-built before being put in the entity. A designer can only select from a distinct set of AIComponents made available by the programmer. The second situation has the different states on the same level as other components. A designer can now create an entity with unique AI without interference of a programmer.

The question is, are these the only two options for structuring AI in an component-based entity and, if so, what would give the maximum flexibility?

Answer

If you do intend to have more possible enemies or players that you can't imagine right now, then you should definitely break it up. What you're describing in your second point is basically the state pattern.

I think I agree with Gregory that you shouldn't have separate stand and walk state components. It's just a movement component with speed 0. On the other hand, if you have objects that can't move, you either have to split it up, or just put some kind of boolean restriction in the movement state that prevents having non zero velocity.

For the player I don't think it needs to be completely separate. It can still use all the other components, with the addition of an input component. This component drives the transitions between states, whereas in the enemy it's controlled by a default AI, or if you want, different AI subclasses that your enemy designers can choose from.

edit: actually, for your stationary enemies, rather than restricting the movement component, just give them a stationary AI component that never chooses to move them.