AI Behaviour [Discuss]

Unity Engine
1

Hi

Following on from a different thread about AI I decided to have a little think about creating something that would be easy to implement and easy to manage regarding game characters.

I came up with this, I would very much appreciate comments/tips on this (apologies - this is fairly lengthy):

using UnityEngine;

///<summary>
/// Enum of the possible creature actions.
///</summary>
public enum CreatureAction { DoNothing, Sleeping, Eating, Sitting, Standing }

///<sumamry>
/// Interface which all creature behaviour scripts must implement.
///</summary>
public interface ICreatureBehaviour {
	CreatureAction ActionThisScriptImplements { get; }	
}

///<summary>
/// Sealed class to manage a creatures actions.
///</summary>
public sealed class Creature : MonoBehaviour {

	///<summary>
	/// Unity exposed creature behaviours - upto 10
	///</summary>
	public ICreatureBehaviour[] BehaviourScripts = new ICreatureBehaviour[10];

	private CreatureAction _currentAction = CreatureAction.DoNothing;

	///<summary>
	/// Gets or Sets the current creature behaviour.
	///</summary>
	public CreatureAction CurrentAction {
		set {
			_currentAction = value;
			ActivateScripts();
		}	
		get {
			return _currentAction;	
		}
	}
	
	// activate/deactivate a script based upon its creature action.
	private void ActivateScripts(){
		
		for(int i = 0; i < BehaviourScripts.Length; i++)
		{
			if(BehaviourScripts[i] != null)
			{
				if(BehaviourScripts[i].ActionThisScriptImplements == _currentAction)
					((GameObject)BehaviourScripts[i]).active = true;
				else
					((GameObject)BehaviourScripts[i]).active = false;	
			}
		}
	}
	
	// activate scripts on awake
	private void Awake() {
		ActivateScripts();	
	}
}

The idea is that the above script would be attached to the game object (the creature/character), and a number of behaviour scripts would also be added to the game object - but would also be added in the editor to the ICreatureBehaviour array. When you wanted to change the current ‘behaviour’ of the creature you would simple change the value in the public property CurrentAction.

Here is the Behaviour scripts:

using UnityEngine;

///<summary>
/// Sealed class to implement an example sleeping behaviour of a creature.
///</summary>
public sealed class SleepingBehaviour : MonoBehaviour, ICreatureBehaviour {

	///<summary>
	/// Gets the Action that this script implements.
	/// </sleeping>
	public CreatureAction ActionThisScriptImplements
	{
		get {
			return CreatureAction.Sleeping;	
		}	
	}
	
	// TODO: Implement the behaviours in here...
}

///<summary>
/// Sealed class to implement an example eating behaviour of a creature.
///</summary>
public sealed class EatingBehaviour : MonoBehaviour, ICreatureBehaviour {

	///<summary>
	/// Gets the Action that this script implements.
	/// </sleeping>
	public CreatureAction ActionThisScriptImplements
	{
		get {
			return CreatureAction.Eating;	
		}	
	}
	
	// TODO: Implement the behaviours in here...
}

// you get the idea...

I know there are many ways to implement this sort of stuff. Does anybody see any pitfalls/problems with this?

I haven’t actually tested this yet, it’s just a thought!

Ta

JT

2

The main problem I can see is that you are hard-coding the possible states in the CreatureAction enum. You would therefore have to edit the code to add in new states like “laughing”, “fleeing”, etc, which seems to defeat the object of changing the settings in the editor. Also, the enum will either be specific to each type of creature you need or else it will have to contain all the states of every creature.

There shouldn’t be any problem if you use strings instead of enumerated values to represent the states.

Also, it is common for state machines to need some set up code to be called each time a new state is entered and some kind of callback mechanism. For example, you might want to time how long a creature has been eating for animation purposes and then inform the control object when it has finished. You could extend ICreatureBehaviour to contain an OnEnterState method and an accessor to get/set the control object. The control object could then have a callback method to let the behaviour object choose the next state or whatever.

As you can imagine, the sky’s the limit with state machines but your scheme should be fairly easy to extend as you need.

3

Yes I can see where you are coming from with enum limitations. I need to weigh up the options between making the code easier to implement (i.e. not remembering the strings) and scalability.

Yeah, I should have made it clear that this was only a starter and did actually implement any of the behaviours and how the character made decisions to change between them. I would probably use delegated events to indicate when a particular behaviour was complete.

Thanks for your response.