AI Structure in a game

Hi all,

I was talking with paradigm yesterday when i noticed our structure of the AI system in a game:

Input → processing → output

This translates literally to:

MessagingSystem → FiniteStateMachine → AgentAction

As I can see the messaging system can be replaced with a “sensory” system like the suggested “eyes” and some hearing system with sound bounds using Arman’s sound system.

The FiniteStateMachine can be replaced or used in junction with a FuzzyStateMachine or a neural network.

However, the AgentAction seems the only “output” that doesn’t have an alternative. Simply because an AgentAction can do anything (load new zones, play an animation, play sounds, change direction, call reinforcments…etc)

So does anyone have any suggestions for the output stage of the AISystem? or is the AgentAction OK?


Well… if AgentAction can really do anything, I guess that will work. :slight_smile:

Is AgentAction an interface? If not, I’d probably make it one and have your class implement it. That way, people can make anything an AgentAction instead of having to extend a specific class.

The only thing I find myself wanting in situations like this is to have some kind of identifier with the ‘doAction’ (or whatever the method is). Ie: I tend to want to know where the request is coming from. I don’t remember what the API looks like, so maybe this is already there.

Other than that, I can’t think of any reasons not to just use AgentAction… particularly if it’s an interface.


the interface thing… well, that had me thinking about it for a while before I implmemented the AgentAction.

The thing is, the AbstractAgentAction class has two variables. The spatial to control and manipulate. And a controller that can manipulate the spatial.

So if its an interface, that wont be easily done. I guess I could create a SpatialControlledAgentAction class in the AISystem and make the actual AbstractAgentClass to an interface (renamed ofcourse).

As for the doAction identifier thing. No, it is not implemented. The thing is, the game/entity/input creates an action, and sets the action for an entity. So the entity is calling the doAction. But whats setting the action in the first place? I think that should be left to the developer to keep track of.

What do you think shmooh?


Does the AbstractAgentAction only have 2 class variables and that’s it?

If so… it probably won’t hurt to have a standard interface and use that in code… (although I’m not sure how those class variables are accessed?)

This has the feel of a standard callback (or listener, if you want to use a Java term)… Ie, something happens, and it notifies something else, and that’s it. If that’s the case, making it an interface sounds like a good idea to me. If the AI system doesn’t care what the ‘doAction’ method does or what object its talking to… then why not?

As for the other bit about identifiers… How is the agent action set in the AI system? I mean… at some point, something needs to register the ‘AgentAction’ object with the system so it can be called, yes? Would it be possible to pass in an identifier with that action when its registered so that when the callback happens, the identifier is given with it?

This allows for one ‘AgentAction’ object to handle different events. It’s not quite as OO, but it can help simplify code and keep object creation down. Of course, this only works if the system can support calling the same action object for different events.

It’s kind of like when using ActionListeners in Swing programming. Sure, you can do what the authors probably intended and create a listener for every widget… but most of the time, you can make do with one listener and do different things based on who sponsored the ActionEvent. It keeps the code cleaner, and reduces the memory footprint. Performance difference is insignificant.

Basically… My point is that the system is more flexible this way. All you’re doing is providing the developer with a way to handle events differently… not forcing them to. They could always ignore the identifier.

The identifier could be anything. For internally used code, I usually end up using an int because I can easily keep track of them and they’re faster and smaller… but a better (more robust) solution may be to use an Object. An alternative is to let the system assign a unique id and return it when the action is assigned, but you’re taking control away from the developer by doing that, and probably making things more complicated for him… so I wouldn’t suggest it.

But… I don’t know how simple it would be to add an identifier, or if you even like the idea. As the designer and author of the code, what do you think, DP?


Currently, the listeners have to be coded by the developer. So really, no listeners or their interfaces have been created. But thats a very good idea shmooh.

And yes, AbstractAgentAction only has 1 method and two "protected" variables ://

As for setting the AgentActions, the only current way of doing that is to send a message to an entity, and then do some if statements to see if that is the message to "run", then set the currentAction to an AgentAction that does the running.

Else if its to load a new map, then set the currentAction to an AgentAction that perhaps starts a new thread and loads all the stuff.

Btw, i really like your idea for firing events :smiley:

Il open a new thread to discuss this.