欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

如何简洁实现游戏中的AI

程序员文章站 2024-03-25 23:03:40
...

端午节放假总结了一下好久前写过的一些游戏引擎,其中NPC等游戏AI的实现无疑是最繁琐的部分,现在,给大家分享一下:

从一个简单的情景开始

怪物,是游戏中的一个基本概念。游戏中的单位分类,不外乎玩家、NPC、怪物这几种。其中,AI 一定是与三类实体都会产生交集的游戏模块之一。
以我们熟悉的任意一款游戏中的人形怪物为例,假设有一种怪物的 AI 需求是这样的:

  •  大部分情况下,漫无目的巡逻。
    
  •  玩家进入视野,锁定玩家为目标开始攻击。
    
  •  Hp 低到一定程度,怪会想法设法逃跑,并说几句话。
    

我们以这个为模型,进行这篇文章之后的所有讨论。为了简化问题,以省去一些不必要的讨论,将文章的核心定位到人工智能上,这里需要注意几点的是:

  •  不再考虑 entity 之间的消息传递机制,例如判断玩家进入视野,不再通过事件机制触发,而是通过该人形怪的轮询触发。
    
  •  不再考虑 entity 的行为控制机制,简化这个 entity 的控制模型。不论是底层是基于 SteeringBehaviour 或者是瞬移,不论是异步驱的还是主循环轮询,都不在本文模型的讨论之列。
    

首先可以很容易抽象出来 IUnit:

public interface IUnit
    {
        void ChangeState(UnitStateEnum state);
        void Patrol(); 
        IUnit GetNearestTarget(); 
        void LockTarget(IUnit unit);
        float GetFleeBloodRate();
        bool CanMove();
        bool HpRateLessThan(float rate);
        void Flee();
        void Speak();
    }
public interface IUnit
    {
        void ChangeState(UnitStateEnum state);
        void Patrol(); 
        IUnit GetNearestTarget(); 
        void LockTarget(IUnit unit);
        float GetFleeBloodRate();
        bool CanMove();
        bool HpRateLessThan(float rate);
        void Flee();
        void Speak();
    }

然后,我们可以通过一个简单的有限状态机 (FSM) 来控制这个单位的行为。不同状态下,单位都具有不同的行为准则,以形成智能体。
具体来说,我们可以定义这样几种状态:

  •  巡逻状态: 会执行巡逻,同时检查是否有敌对单位接近,接近的话进入战斗状态。
    
  •  战斗状态: 会执行战斗,同时检查自己的血量是否达到逃跑线以下,达成检查了就会逃跑。
    
  •  逃跑状态: 会逃跑,同时说一次话。
    

最原始的状态机的代码:

public interface IState<TState, TUnit> where TState : IConvertible
    {
        TState Enum { get; }
        TUnit Self { get; }
        void OnEnter();
        void Drive();
        void OnExit();
    }

public interface IState<TState, TUnit> where TState : IConvertible
    {
        TState Enum { get; }
        TUnit Self { get; }
        void OnEnter();
        void Drive();
        void OnExit();
    }

以逃跑状态为例:

public class FleeState : UnitStateBase
    {
        public FleeState(IUnit self) : base(UnitStateEnum.Flee, self)
        {
        }
        public override void OnEnter()
        {
            Self.Flee();
        }
        public override void Drive()
        {
            var unit = Self.GetNearestTarget();
            if (unit != null)
            {
                return;
            }

            Self.ChangeState(UnitStateEnum.Patrol);
        }
    }
public class FleeState : UnitStateBase
    {
        public FleeState(IUnit self) : base(UnitStateEnum.Flee, self)
        {
        }
        public override void OnEnter()
        {
            Self.Flee();
        }
        public override void Drive()
        {
            var unit = Self.GetNearestTarget();
            if (unit != null)
            {
                return;
            }
 
            Self.ChangeState(UnitStateEnum.Patrol);
        }
    }

决策逻辑与上下文分离

上述是一个最简单、最常规的状态机实现。估计只有学生会这样写,业界肯定是没人这样写 AI 的,不然游戏怎么死的都不知道。

首先有一个非常明显的性能问题:状态机本质是描述状态迁移的,并不需要记录 entity 的 context,如果 entity 的 context 记录在 State上,那么状态机这个迁移逻辑就需要每个 entity 都来一份 instance,这么一个简单的状态迁移就需要消耗大约 X 个字节,那么一个场景 1w 个怪,这些都属于白白消耗的内存。就目前的实现来看,具体的一个 State 实例内部 hold 住了 Unit,所以 State 实例是没办法复用的。

针对这一点,我们做一下优化。对这个状态机,把 Context 完全剥离出来。

修改状态机接口定义:

public interface IState<TState, TUnit> where TState : IConvertible
    {
        TState Enum { get; }
        void OnEnter(TUnit self);
        void Drive(TUnit self);
        void OnExit(TUnit self);
    }

public interface IState<TState, TUnit> where TState : IConvertible
    {
        TState Enum { get; }
        void OnEnter(TUnit self);
        void Drive(TUnit self);
        void OnExit(TUnit self);
    }

还是拿之前实现好的逃跑状态作为例子:

public class FleeState : UnitStateBase
    {
        public FleeState() : base(UnitStateEnum.Flee)
        {
        }
        public override void OnEnter(IUnit self)
        {
            base.OnEnter(self);
            self.Flee();
        }
        public override void Drive(IUnit self)
        {
            base.Drive(self);

            var unit = self.GetNearestTarget();
            if (unit != null)
            {
                return;
            }

            self.ChangeState(UnitStateEnum.Patrol);
        }
    }
public class FleeState : UnitStateBase
    {
        public FleeState() : base(UnitStateEnum.Flee)
        {
        }
        public override void OnEnter(IUnit self)
        {
            base.OnEnter(self);
            self.Flee();
        }
        public override void Drive(IUnit self)
        {
            base.Drive(self);
 
            var unit = self.GetNearestTarget();
            if (unit != null)
            {
                return;
            }
 
            self.ChangeState(UnitStateEnum.Patrol);
        }
    }

这样,就区分了动态与静态。静态的是状态之间的迁移逻辑,只要不做热更新,是不会变的结构。动态的是状态迁移过程中的上下文,根据不同的上下文来决定。

分层有限状态机

最原始的状态机方案除了性能存在问题,还有一个比较严重的问题。那就是这种状态机框架无法描述层级结构的状态。
假设需要对一开始的需求进行这样的扩展:怪在巡逻状态下有可能进入怠工状态,同时要求,怠工状态下也会进行进入战斗的检查。

这样的话,虽然在之前的框架下,单独做一个新的怠工状态也可以,但是仔细分析一下,我们会发现,其实本质上巡逻状态只是一个抽象的父状态,其存在的意义就是进行战斗检查;而具体的是在按路线巡逻还是怠工,其实都是巡逻状态的一个子状态。

状态之间就有了层级的概念,各自独立的状态机系统就无法满足需求,需要一种分层次的状态机,原先的状态机接口设计就需要彻底改掉了。

在重构状态框架之前,需要注意两点:

因为父状态需要关注子状态的运行结果,所以状态的 Drive 接口需要一个运行结果的返回值。

子状态,比如怠工,一定是有跨帧的需求在的,所以这个 Result,我们定义为 Continue、Sucess、Failure。

子状态一定是由父状态驱动的。

考虑这样一个组合状态情景:巡逻时,需要依次得先走到一个点,然后怠工一会儿,再走到下一个点,然后再怠工一会儿,循环往复。这样就需要父状态(巡逻状态)注记当前**的子状态,并且根据子状态执行结果的不同来修改**的子状态集合。这样不仅是 Unit 自身有上下文,连组合状态也有了自己的上下文。

为了简化讨论,我们还是从 non-ContextFree 层次状态机系统设计开始。

修改后的状态定义:

public interface IState<TState, TCleverUnit, TResult> 
        where TState : IConvertible
    {
        // ...
        TResult Drive();
        // ...
    }

public interface IState<TState, TCleverUnit, TResult> 
        where TState : IConvertible
    {
        // ...
        TResult Drive();
        // ...
    }

组合状态的定义:

public abstract class UnitCompositeStateBase : UnitStateBase
    {
        protected readonly LinkedList<UnitStateBase> subStates = new LinkedList<UnitStateBase>();

        // ...
        protected Result ProcessSubStates()
        {
            if (subStates.Count == 0)
            {
                return Result.Success;
            }

            var front = subStates.First;
            var res = front.Value.Drive();

            if (res != Result.Continue)
            {
                subStates.RemoveFirst();
            }

            return Result.Continue;
        }
        // ...
    }
public abstract class UnitCompositeStateBase : UnitStateBase
    {
        protected readonly LinkedList<UnitStateBase> subStates = new LinkedList<UnitStateBase>();
 
        // ...
        protected Result ProcessSubStates()
        {
            if (subStates.Count == 0)
            {
                return Result.Success;
            }
 
            var front = subStates.First;
            var res = front.Value.Drive();
 
            if (res != Result.Continue)
            {
                subStates.RemoveFirst();
            }
 
            return Result.Continue;
        }
        // ...
    }

巡逻状态现在是一个组合状态:

public class PatrolState : UnitCompositeStateBase
    {
        // ...
        public override void OnEnter()
        {
            base.OnEnter();
            AddSubState(new MoveToState(Self));
        }

        public override Result Drive()
        {
            if (subStates.Count == 0)
            {
                return Result.Success;
            }

            var unit = Self.GetNearestTarget();
            if (unit != null)
            {
                Self.LockTarget(unit);
                return Result.Success;
            }

            var front = subStates.First;
            var ret = front.Value.Drive();

            if (ret != Result.Continue)
            {
                if (front.Value.Enum == CleverUnitStateEnum.MoveTo)
                {
                    AddSubState(new IdleState(Self));
                }
                else
                {
                    AddSubState(new MoveToState(Self));
                }
            }
            
            return Result.Continue;
        }
    }
public class PatrolState : UnitCompositeStateBase
    {
        // ...
        public override void OnEnter()
        {
            base.OnEnter();
            AddSubState(new MoveToState(Self));
        }
 
        public override Result Drive()
        {
            if (subStates.Count == 0)
            {
                return Result.Success;
            }
 
            var unit = Self.GetNearestTarget();
            if (unit != null)
            {
                Self.LockTarget(unit);
                return Result.Success;
            }
 
            var front = subStates.First;
            var ret = front.Value.Drive();
 
            if (ret != Result.Continue)
            {
                if (front.Value.Enum == CleverUnitStateEnum.MoveTo)
                {
                    AddSubState(new IdleState(Self));
                }
                else
                {
                    AddSubState(new MoveToState(Self));
                }
            }
            
            return Result.Continue;
        }
    }

看过《游戏人工智能编程精粹》的同学可能看到这里就会发现,这种层次状态机其实就是这本书里讲的目标驱动的状态机。组合状态就是组合目标,子状态就是子目标。父目标 / 状态的调度取决于子目标 / 状态的完成情况。

这种状态框架与普通的 trivial 状态机模型的区别仅仅是增加了对层次状态的支持,状态的迁移还是需要靠显式的 ChangeState 来做。

这本书里面的状态框架,每个状态的执行 status 记录在了实例内部,不方便后续的优化,我们这里实现的时候首先把这个做成纯驱动式的。但是还不够。现在之前的 ContextFree 优化成果已经回退掉了,我们还需要补充回来。

分层的上下文

我们对之前重构出来的层次状态机框架再进行一次 Context 分离优化。
要优化的点有这样几个:

首先是继续之前的,unit 不应该作为一个 state 自己的内部 status。

组合状态的实例内部不应该包括自身执行的 status。目前的组合状态,可以动态增删子状态,也就是根据 status 决定了结构的状态,理应分离静态与动态。巡逻状态组合了两个子状态——A 和 B,逻辑中是一个完成了就添加另一个,这样一想的话,其实巡逻状态应该重新描述——先进行 A,再进行 B,循环往复。
  
  由于有了父状态的概念,其实状态接口的设计也可以再迭代,理论上只需要一个 drive 即可。因为状态内部的上下文要全部分离出来,所以也没必要对外提供 OnEnter、OnExit,提供这两个接口的意义只是做一层内部信息的隐藏,但是现在内部的 status 没了,也就没必要隐藏了。
  
具体分析一下需要拆出的 status:

  • 一部分是 entity 本身的 status,这里可以简单的认为是 unit。
  • 另一部分是 state 本身的 status。
  • 对于组合状态,这个 status 描述的是我当前执行到哪个 substate。
  • 对于原子状态,这个 status 描述的种类可能有所区别。
  • 例如 MoveTo/Flee,OnEnter 的时候,修改了 unit 的 status,然后 Drive 的时候去 check。
  • 例如 Idle,OnEnter 时改了自己的 status,然后 Drive 的时候去 check。
    经过总结,我们可以发现,每个状态的 status 本质上都可以通过一个变量来描述。一个 State 作为一个最小粒度的单元,具有这样的 Concept: 输入一个 Context,输出一个 Result。

Context 暂时只需要包括这个 Unit,和之前所说的 status。同时,考虑这样一个问题:

  • 父状态 A,子状态 B。
  • 子状态 B 向上返回 Continue 的同时,status 记录下来为 b。
  • 父状态 ADrive 子状态的结果为 Continue,自身也需要向上抛出 Continue,同时自己也有 status 为 a。
    这样,再还原现场时,就需要即给 A 一个 a,还需要让 A 有能力从 Context 中拿到需要给 B 的 b。因此上下文的结构理应是递归定义的,是一个层级结构。

Context 如下定义:

public class Continuation
    {
        public Continuation SubContinuation { get; set; }
        public int NextStep { get; set; }
        public object Param { get; set; }
    }

    public class Context<T>
    {
        public Continuation Continuation { get; set; }
        public T Self { get; set; }
    }

public class Continuation
    {
        public Continuation SubContinuation { get; set; }
        public int NextStep { get; set; }
        public object Param { get; set; }
    }
 
    public class Context<T>
    {
        public Continuation Continuation { get; set; }
        public T Self { get; set; }
    }

修改 State 的接口定义为:

public interface IState<TCleverUnit, TResult>
     {
         TResult Drive(Context<TCleverUnit> ctx);
    }

public interface IState<TCleverUnit, TResult>
     {
         TResult Drive(Context<TCleverUnit> ctx);
    }

已经相当简洁了。

这样,我们对之前的巡逻状态也做下修改,达到一个 ContextFree 的效果。利用 Context 中的 Continuation 来确定当前结点应该从什么状态继续:

public class PatrolState : IState<ICleverUnit, Result>
    {
        private readonly List<IState<ICleverUnit, Result>> subStates;
        public PatrolState()
        {
            subStates = new List<IState<ICleverUnit, Result>>()
            {
                new MoveToState(),
                new IdleState(),
            };
        }
        public Result Drive(Context<ICleverUnit> ctx)
        {
            var unit = ctx.Self.GetNearestTarget();
            if (unit != null)
            {
                ctx.Self.LockTarget(unit);

                return Result.Success;
            }

            var nextStep = 0;
            if (ctx.Continuation != null)
            {
                // Continuation
                var thisContinuation = ctx.Continuation;

                ctx.Continuation = thisContinuation.SubContinuation;

                var ret = subStates[nextStep].Drive(ctx);

                if (ret == Result.Continue)
                {
                    thisContinuation.SubContinuation = ctx.Continuation;
                    ctx.Continuation = thisContinuation;

                    return Result.Continue;
                }
                else if (ret == Result.Failure)
                {
                    ctx.Continuation = null;

                    return Result.Failure;
                }

                ctx.Continuation = null;
                nextStep = thisContinuation.NextStep + 1;
            }

            for (; nextStep < subStates.Count; nextStep++)
            {
                var ret = subStates[nextStep].Drive(ctx);
                if (ret == Result.Continue)
                {
                    ctx.Continuation = new Continuation()
                    {
                        SubContinuation = ctx.Continuation,
                        NextStep = nextStep,
                    };

                    return Result.Continue;
                } 
                else if (ret == Result.Failure) 
                {
                    ctx.Continuation = null;

                    return Result.Failure;
                }
            }

            ctx.Continuation = null;

            return Result.Success;
        }
    }
public class PatrolState : IState<ICleverUnit, Result>
    {
        private readonly List<IState<ICleverUnit, Result>> subStates;
        public PatrolState()
        {
            subStates = new List<IState<ICleverUnit, Result>>()
            {
                new MoveToState(),
                new IdleState(),
            };
        }
        public Result Drive(Context<ICleverUnit> ctx)
        {
            var unit = ctx.Self.GetNearestTarget();
            if (unit != null)
            {
                ctx.Self.LockTarget(unit);
 
                return Result.Success;
            }
 
            var nextStep = 0;
            if (ctx.Continuation != null)
            {
                // Continuation
                var thisContinuation = ctx.Continuation;
 
                ctx.Continuation = thisContinuation.SubContinuation;
 
                var ret = subStates[nextStep].Drive(ctx);
 
                if (ret == Result.Continue)
                {
                    thisContinuation.SubContinuation = ctx.Continuation;
                    ctx.Continuation = thisContinuation;
 
                    return Result.Continue;
                }
                else if (ret == Result.Failure)
                {
                    ctx.Continuation = null;
 
                    return Result.Failure;
                }
 
                ctx.Continuation = null;
                nextStep = thisContinuation.NextStep + 1;
            }
 
            for (; nextStep < subStates.Count; nextStep++)
            {
                var ret = subStates[nextStep].Drive(ctx);
                if (ret == Result.Continue)
                {
                    ctx.Continuation = new Continuation()
                    {
                        SubContinuation = ctx.Continuation,
                        NextStep = nextStep,
                    };
 
                    return Result.Continue;
                } 
                else if (ret == Result.Failure) 
                {
                    ctx.Continuation = null;
 
                    return Result.Failure;
                }
            }
 
            ctx.Continuation = null;
 
            return Result.Success;
        }
    }

subStates 是 readonly 的,在组合状态构造的一开始就确定了值。这样结构本身就是静态的,而上下文是动态的。不同的 entity instance 共用同一个树的 instance。

优化到这个版本,至少在性能上已经符合要求了,所有实例共享一个静态的状态迁移逻辑。面对之前提出的需求,也能够解决。至少算是一个经过对《游戏人工智能编程精粹》中提出的目标驱动状态机模型优化后的一个符合工业应用标准的 AI 框架。拿来做小游戏或者是一些 AI 很简单的游戏已经绰绰有余了。

心动了吗?还不赶紧动起来,打造属于自己的游戏世界!顿时满满的自豪感,真的很想知道大家的想法,还请持续关注更新,更多干货和资料请直接联系我,也可以加群710520381,邀请码:柳猫,欢迎大家共同讨论