1
\$\begingroup\$

In order to wrap my head around component-based systems, I started making my own little framework. Unfortunately I am not completely sure how systems are supposed to be used in some specific cases.

For example I can understand the use of a RenderSystem or a CollisionSystem but how would one implement AI and how would the component look like? I am especially confused when it comes to actions. Could actions be stored in the components as objects?

\$\endgroup\$
  • \$\begingroup\$ Have a look at this similar question: Role of systems in entity systems architecture. The answer might help you out as well. \$\endgroup\$ – Miklas May 18 '14 at 14:44
  • \$\begingroup\$ @Miklas Oh I have read that. I am having troubles with entity actions and artificial intelligence for the most part. Do I make a system for each AI and hardcode the actions in them? \$\endgroup\$ – Veritas May 18 '14 at 15:48
  • \$\begingroup\$ It sounds to me like you are trying to shove your AI into a component system without really understanding what your AI is (or should be) and how it will work. Do you have an existing architecture for AI already? You should describe it, or you should solve that problem first. Not everything needs to be in a component, remember (and trying to do so is usually a horrible idea). \$\endgroup\$ – Josh May 19 '14 at 15:28
6
\$\begingroup\$

I am not completely sure how "systems" are supposed to be used in some specific cases.

However you need them to be used. There is no single correct way to build a component-based entity system (not all of them even include the concept of a "system"), and even among implementations that use similar terminology, not all the details are alike.

You need to focus on building the system that accomplishes the goals you have set for your project.

How would one implement AI and how would the component look like? I am especially confused when it comes to actions. Could actions be stored in the components as objects?

AI in games is about the modeling of behavior more than anything else. Interfaces that implement AI on a per-entity basis (entity system or not) are typically called "agents" or "actors," and typically contain code or data to control behavior of an individual creature/person/NPC/object/et cetera in the game. With that in mind, a common way to put AI into a component-based entity system is to have BehaviorComponent (or AgentComponent or ActorComponent, et cetera) which are associated with entities. Such a component implements an entire class of behavior for an entity and generally you don't attach multiple (although you could). For example, you might have an FollowPlayerBehavior component or an AttacksFromCover component.

In many games, "AI" typically just means executing behavior scripts, so often you won't even see dedicated AI systems or components since such behavior is normally just handled by more general scripting components that allow designers to attach arbitrary Lua (or whatnot) scripts to entities.

I would not recommend an approach where you implement individual actions an entity can take as components and shove a bunch of them on to an entity, as that is too fine-grained and doesn't afford you the ability to easily order the actions without enforcing an overly-rigid update order on your entity component system. It also makes branching decisions difficult, and implies you're going to do a lot of adding and removing of components at runtime which isn't always very common (and thus not always very efficient).

As always, the specifics of what goes into an "AI component" are going to depend heavily on your game itself: what it needs from AI, how your AI works in absence of the component system (the component system, remember, is a high-level object composition system and something like AI, rendering, physics should all be usable without also requiring the use of the component system; keeping that in mind will help you design better systems that work in isolation and help avoid the design paralysis that so often comes with building component systems for some reason).

\$\endgroup\$
  • \$\begingroup\$ Incredible answer! Thanks for taking your time to write this. \$\endgroup\$ – Veritas May 19 '14 at 16:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.