Implementing a series of independent Actions that are disparate but with common accessibility

Question

I have a requirement to implement a type of AI for a project, the issue is that I am having trouble visualizing how the AI should actually be implemented.

Essentially, I want the AI to be as dynamic as possible. That is, if I decide in the future to add another type of AI Action (as we'll call it), I don't need to rewrite the class using the AI or AI Action.

What I have now, is a very rough idea, but it should help clarify.

public interface IAiAction
{
    List<IAiProperty> Properties { get; }

    DateTime LastUpdate { get; }

    bool Update(Entity e);
}

public interface IAiProperty
{

}

Then I have something like:

public class WanderAction : IAiAction
{
    private List<IAiProperty> _Properties = new List<IAiProperty>();
    public List<IAiProperty> Properties { get { return _Properties; } }

    private DateTime _LastUpdate;
    public DateTime LastUpdate { get { return _LastUpdate; } }

    private Point _WanderTo;

    public bool Update(Entity e)
    {
        // Do stuff here

        return true;
    }
}

public struct WanderDistance : IAiProperty
{
    private Point _Home;
    private float _MaxDistance;

    public Point Home { get { return _Home; } private set { _Home = value; } }
    public float MaxDistance { get { return _MaxDistance; } private set { _MaxDistance = value; } }

    public WanderDistance(Point h, float m)
    {
        _Home = h;
        _MaxDistance = m;
    }
}

Then, in the class with the actions:

private List<IAiAction> _AiActions = new List<IAiAction>();
public List<IAiAction> AiActions { get { return _AiActions; } }

public override void Update(Vector2F force)
{
    foreach (IAiAction action in AiActions)
        action.Update(this);

    base.Update(force);
}

The problem is that this does not extend well. I'm not even sure how I got to this stage, as I've never had to do something like this before.

This code is by no means a requirement. If anyone has any other ideas for how it can be done (even if they are far separate from what this indicates) I am up for it.

For example, if I had an IAiAction that was to determine what the Entity was going to say randomly, this leaves very poor room to do that. I also, for the WanderAction as an example, need to return a Vector2F to the calling class, to add it to the force parameter of the Update(Vector2F) method.

If any clarification beyond this is necessary, please let me know. This isn't holding up the project, but it is causing me issue.

The only other method I can think of is to implement a sort of state that is carried through the programme. This would technically satisfy my requirements, but I'm curious if there is a better way.

Answer 1

If I'm understanding correctly, you have an Entity, which can do things (like walk, talk, and so on), and want to use classes to be able to provide this entity with AI behaviours. These will be triggered in some loop (or by schedule, or whatever) and will then cause some behaviour in the entity (walking, talking, etc.).

There's a few you're going to need two things:

• An interface for AI actions, allowing them to be triggered
• A way for the AI action to actually effect the change in behaviour

---

For the first one, you have your interface IAiAction. Let's look at how it's used:

foreach (IAiAction action in AiActions)
    action.Update(this);

So from this, it seems like actually, the only member on IAiAction should be:

void Update(Entity entity);

This also relieves you of needing IAiProperty at all. WanderDistance, for example, can just be a normal, private member on WanderAction.

Looking at this interface, there also doesn't seem to be anything AI-specific about it. It could work just as well for user-controlled actions, or actions so dumb they can't really be called AI (like waiting in place forever). Why not just IAction, or IInstructor or something?

It may be that as you implement more of these AI classes, you do find common structure. You could pull that out into a dependency or base class. But there's no need to pre-emptively impose structure, and certainly no need to expose it publicly. Just expose what consumers actually need. As an example, maybe you were considering using LastUpdated so that the Entity could only call actions that have been updated more than a second ago, or whatever. But why not keep LastUpdated private, and let the actions can make that decision themselves?

---

As for the second bullet point, it'd be tough to try to have some general way for the AI action to return an instruction for the Entity to understand. Instead, Entity should expose what it can do through methods on an interface:

void SetDestination(Vector2D destination){ /*...*/ }
void Say(string utterance) { /*...*/ }

Now an AI action can call methods, instead of having to return something and assume the Entity will have the logic to handle it. You could, for example easily add a ReactToDangerAction which both yells and runs away from the danger, given the above two methods.

---

This is a starting point, but one design improvement which may go a long way is to not pass the Entity in to the Update method, but instead pass it in through the constructor. After all, it doesn't make sense for your example WanderAction to be shared by two different entities, as they'd probably have different homes. So it might as well be tied to one particular entity permanently, rather than accepting one each time the method is called and hoping it always gets the same one. This would probably require a little boilerplate (factory classes, possibly), but would enable some design improvements.

For example, you could adhere better to the Interface Segregation Principle by splitting the Entity's interface into several (IDirectable, IVocal, etc.). Or, if you don't like the idea of Entity exposing methods allowing it to be ordered around by all and sundry, you could even make the SetDestination and Say methods private and pass them into the actions' constructors as delegates. It would also give flexibility if in the future you found that some actions shouldn't be tied to particular entities, or should be tied to multiple.