王者光彩中的小兵，便是由游戏AI操作着的npc角色
01 npc的AI是如何运作的？
常日我们都认为“行为树”、“状态机”组成了游戏AI，也有把GOAP（目标导向型行动操持）当做是游戏AI设计的，实在这样的观点是不对的。npc的AI是这样运行的：
就像现实中的我们思考问题一样，在游戏的每一帧（游戏运行的最小韶光单位），npc们都会这么思考——首先，“我”（这个npc）有什么事情要做吗？拿出“小本子”看看事情操持，如果有事情要做，就会明确一个todoThing（现在要干什么）。有了todoThing就会仔细想一想，这个todoThing能做的成吗？由于“操持赶不上变革”，有些原来操持好可以做的事情，现在可能由于环境（circumstance）发生了变革，以至于无法进行了：
当无法进行或者原来就没有todoThing的时候，npc就会开始思考“我现在要干啥”。这里便是我们常见的“行为树”发挥浸染的地方，但是不论是“行为树”、“蓝图”，实际上返回的都是一段数据，并且被记录到“小本子”里作为事情操持，然后重新开始看是否可以实行这个操持，终极开始实行详细行动。
以是“把想要做什么写进小本子”，才是AI的核心，而“行为树”只是写入“写入小本子”的“写法”之一，包括脚本代码（如Lua）、UE4的蓝图等都是“写小本子的写法”。“写小本子”这件事情得有思路，不管是蓝图还是行为树都是把设计师的思路“写进去”的过程，而GOAP供应的是一种设计游戏AI内容的思路。行为树和GOAP，只是游戏AI中最核心的一环的数据录入的思路和办法之一，因此行为树和GOAP都不即是游戏AI。
下面是代码韶光
首先我们须要有一个关于角色状态的东西，它也会返回当前角色是否可以实行AI（本文所有图片的伪代码利用TypeScript）：
export class CharacterState{ public value : number = 0; //这里用于返回是否能实行AI public CanRunAI():boolean{ return (1 & this.value) == 0; //可以设计更多状态不能实行AI } public static STATE_STUN = 1; public static STATE_POISONED = 1 << 1; public static STATE_CONFUSED = 1 << 2; //...这里可以根据游戏设计来定义更多状态}
接着便是角色工具，在角色工具中，有一些内容是设计师须要设计的：
export class Character{ //npc一定是属于角色类的，只是某些属性的值和玩家的不同而已 //此处省略AI无关的其他数据 private todoThing:Object; //这便是“小本子” private state:CharacterState; private teamId:number = 0; //这里正是策划设计的主要部分，也是AI的大脑 private WhatToDo():Object{ let res = {} //Unity推举的做法在这里是行为树 //这里开始则是这个角色的AI实行内容 //如果你大多是if else，那就跟行为树没差异了，顶多实行效率高些 return res; } //这个函数是图中的“3T.想一想实行细节” private CanDoBehave():boolean{ if (!this.todoThing) return false; return ( //这里正是策划须要设计规则的地方 //这里的内容多和少都不坏，取决于游戏规则的繁芜度 //但是如果这里依赖了其他工具，依赖的越多，设计越蹩脚。 false ); } //这正是AI的核心流程，也是每一帧实行的内容 public FixedUpdate(){ if (true == this.state.CanRunAI()){ if ( !this.todoThing || //2F.如果“小本子”没东西 false == this.CanDoBehave() //3T.如果“小本子”的事情做不了 ){ this.todoThing = this.WhatToDo(); //实行AI } //接下来当然是详细怎么实行AI的问题了。 } }}
可见，“行为树”在全体AI中，是完备可以被其他方法取代的内容。
02 “群体AI”是究竟怎么回事儿？
当一个游戏AI进行“思考”，也便是准备小本子的时候，除了会参考一些自身状态，还会参考一块“小黑板”内的信息。这块“小黑板”的信息，游戏的其他系统也会写入一些必要的数据，以帮助游戏AI更好的明确自己该做什么。
这小黑板上的数据，包括两种类型的：
游戏全局的一些状态：比如游戏如果有景象，那么现在是什么景象？可能NPC会须要由于下雨天，以是找屋子躲起来，或者撑起伞。这些数据都是随着游戏推进，数据发生变革的时候会改写的数据，对付游戏AI而言，是只读数据。当然只管我们举例只说了景象，但是常日情形下，游戏进程中的所有变量都该当被写在小黑板里，供NPC的AI获取信息。一些“命令”：在这个小黑板当中，也会记录一些由其他系统，比如玩家操作系统带来的命令。比如“1组去A区”便是一种命令，当NPC在思考AI的时候，会创造有一条“1组去A区”的命令，此时如果这个NPC创造自己是1组的，他就会去A区。当然，信息只是用来参考的，“不听话”的1组队员，完备是可以忽略这条指令的。我们把稳到了，在“小黑板”上有一些“命令”，这个“命令”正是很多游戏中“群体AI”的核心关键所在。比如在即时计策中，玩家操作一个小队的角色移动到某个地方，便是一个“群体AI”；
即时计策中，玩家掌握一个小队保持队形驶向某处，便是一个“群体AI”
除了玩家操作的，还有游戏中场景里刷了多个仇敌，仇敌与仇敌之间像小组一样的协作作战；还有足球类游戏中球员之间的跑位、合营等，都是范例的“群体AI”。
在FIFA20等足球游戏中，球员有组织的行动也是一种“群体AI”
而“群体AI”的发起者，未必来自于一个更高等的系统（常日被认为是“游戏AI系统”），由于这个“命令”对付实行游戏AI的npc来说不是只读的数据，以是也可以由一个npc的AI发起。
但是不论是谁发起的，都该当是在列表里新增一条，而不是轻易修正已经存在的数据，当游戏运行了一定帧数之后，自动打消掉，因此每一条“命令”必不可少的数据是“持续韶光”。
纵然已经有的条款，也不能“修正”而只能“新增”，由于采纳不采纳的判断，是由游戏AI根据这些信息“思考”出来的，我们只供应信息，不供应办理方案
因此，当我们看到游戏中角色有序的群体实行某件事情的时候，常日是通过这种办法来发起“群体AI”，然后每个npc独自行动的时候恰好形成了步调同等的结果，实际上他们之间相互并没有任何“沟通”。
下面是代码韶光
先是本章的主角——小黑板：
//这是小黑板上的command的构造export class BlackBoardCommand{ public executorKeys:Array<string> = []; //期望这个指令的实行者的key public tick:number = 1; //持续多少帧 //这是要实行的内容的详细数据约定，所以是灵巧的东西，但他必须是一个数据构造，而不能是any public command:Object = {}; }//小黑板export class Blackboard{ //游戏运行时候暴露给AI的一些数据，这些数据对付AI只读，本文省去get set private runtimeData:Object; //这里是吸收到的命令，外部只能新增，以是也用private，本文省去get set private commands:Array<BlackBoardCommand>; //根据实行这关键字，过滤出所有干系的命令 public GetCommandsByExecutorKey(executorKey:string):Array<Object>{ let res = new Array<Object>(); if (this.commands){ this.commands.forEach((cmd, index)=>{ if (cmd.executorKeys.indexOf(executorKey) >= 0){ res.push(cmd); } }); } return res; } //每一帧都会实行这个，来管理commands public FixedUpdate(){ if (this.commands && this.commands.length > 0){ let i = 0; while (i < this.commands.length){ if ( --this.commands[i].tick < 0 ){ this.commands.splice(i, 1); }else{ i++; } } } }}//全体游戏只有一个var GameBlackBoard:Blackboard = new Blackboard();
一个听话的NPC会这么实行“群体AI”，在Character工具中，我们进行了一些小小的变革：
//首先我们加入了一个小队id，这当然不是所有游戏都须要的，看设计需求 private teamId:number = 0; //这里正是策划设计的主要部分，也是AI的大脑 private WhatToDo():Object{ let res = {} //Unity推举的做法在这里是行为树 //这里开始则是这个角色的AI实行内容 //如果你大多是if else，那就跟行为树没差异了，顶多实行效率高些 //我是绝对服从命令的好孩子，组织让我去那儿我去哪儿 //以是在末了我会判断是否有command要我移动 //按照约定，该当是带有"teamX"的是要我做的事情 let commandMoves = GameBlackBoard.GetCommandsByExecutorKey("team" + this.teamId); if (commandMoves.length > 0){ //这里便是根据命令来重新定义结果了，这是须要设计师设计的，包括数据构造和选择办法 //在这里，我们假设选取第一条的command就直接可以做为结果 res = commandMoves[0].command; } return res; }
“小黑板”的数据，“勾引”着每一个npc做出了自己的行为，恰好能够形成一种“有组织”的错觉。
03 打断事宜，从“A过去”和“走过去”提及
在PC上的一些即时计策(RTS)和即时制的对战游戏(MOBA)比如《星际争霸2》、《英雄同盟》中，玩家有一个“微操”，便是在“A过去”和“走过去”之间做一个选择：
所谓“A过去”：常日是玩家按键盘上的A键（常日是默认A键），然后点选某个目标地点，角色会移动过去，但是路上一旦创造仇敌、一旦遭受攻击等，角色将会暂时放弃移动，转而和仇敌交火。所谓“走过去”：常日是直接鼠标右键点击某个地点，或者按M（大多游戏默认）然后点击某个地点，此时角色会移动过去，但是路上无论有什么情形发生，即便角色挨打，也会连续向目标走去，直到走到为止。“A过去”和“走过去”是完备不同的操作，比如在魔兽争霸3中，如果“走过去”打建筑物，就会盯着建筑物打，而不顾周围的情形，纵然挨打也不会停下手里的事情；如果用“A过去”点地面，则会各自探求要打的建筑物，而当敌方有士兵涌现的时候，也会优先攻击士兵
当然，这里我们并不是要谈论在玩游戏的时候玩家如何选择“A过去”还是“走过去”，我们的思考是——这两种移动模式，其实在游戏AI的设计中，都是可能被用到的模式。比如当我设计一个正在巡逻的士兵的时候，由于他是高度当心的，以是这个士兵在多个点之间的移动，该当始终是“A过去”的，一旦移动中创造情形，就要做出行动；而如果我们在设计一个被正在被追杀的难民，他的逃跑过程该当是向逃离点“走过去”的；同样的如果我们设计了一场在危险的山道上的战斗，山上随时会有泥石流，这时候所有的仇敌的移动是“A过去”的，一旦碰着敌情就能立即反应，而当预感到泥石流涌现的时候（比如屏幕开始震撼，地上涌现泥石流的阴影表示泥石流的阶段要到了），这些仇敌都会找到最近的安全区域（泥石流无法击中）“走过去”，这时候不应该会由于在这段移动中遭遇了玩家角色就不顾泥石流的危险去和玩家的角色战斗。
以是这里我们引出了第一个问题：“A过去”和“走过去”的打断问题，一定只针对移动吗？仔细一想并不是，而是只要符合：
须要一定韶光来完成。这事情可以随时被打断。那么这个事情就跟“移动”是一样的，就有打断问题。
比如吃东西这个事情，对付大多人来说是“A过去”的，但是我们依然可以利用“走过去”塑造出淡定哥
接着第二个问题是：如果是“A过去”的，什么时候打断行动？我们可以大略的归纳出一些韶光点，比如：
有仇敌进入以自身为半径的圆形范围内（可以称之为“鉴戒范围”）的时候会打断。当然这个鉴戒范围不一定是正圆的，根据游戏还可以设计多个扇形范围，正面的半径大一些，背后的半径小一些之类的。当受到了来自仇敌的攻击的时候会打断，由于自身的“鉴戒范围”未必比仇敌的射程短，以是须要这样打断，想一下如果一个喝醉酒的士兵正在歪歪斜斜的走向安歇处，他该当是迷迷糊糊的，以是“鉴戒范围”非常小，而此时他溘然被人殴打，就该当“酒醒了”。自身Buff发生变革时：由于有时候攻击并不是直接的，他可能是给角色添加了一个buff，比如让角色中毒了，没有直接侵害，但是也算是有攻击性的。当然对付Buff的理解也不该如此狭隘，比如我们做一个类似GTA这样的开放天下游戏，在一个沉着的小村落落里，npc正在清闲地战斗，而好事的玩家逮住了最近的npc就打，此时这个npc会通过创建一个“求救”的AoE（当然嗓门越大的npc这个AoE范围就越大）给附近所有其他npc添加一个buff，这个buff是“斗殴了”，而其他原来在闲步的npc，收到了这个“斗殴了”的buff，有些会转变为错愕地逃跑，有些路见不平的npc则会加入到战斗中来。我们可以看到，1、2两个点的归纳是系统级的——即是由游戏的其他系统来决定的，并不是所有游戏都有“仇敌”的观点，也并不是所有游戏都有“攻击”“侵害”之类的观点，因此1和2并不适宜所有的游戏，比如我们现在来做一个类似《开罗拉面店》的游戏，这是一个“和平时代”的游戏，以是根本不存在“仇敌”“攻击”的说法；
开罗拉面店中的雇员、客人都是由游戏AI操作着的npc，但是游戏中并不存在“进入鉴戒范围”、“受到攻击”等情形，和平年代不须要战斗
由此我们进行重新抽象，但是游戏的类型各式各样，并且他们都须要游戏AI，以是我们没法很好的归纳出“游戏AI须要被打断当前实行的事宜的韶光点”来。此时我们须要把思维逆转一下——AI的行动从来不是被外部打断的，也便是外部从来不打断在实行“小本子”里内容的npc，而是npc常常会清空小本子。
在游戏AI每一帧运作的开端，我们都会判断“小本子”里是否有内容，利用的是这个特性——用移动来举例子：
在这样一张舆图下，我们的角色要移动到右上方的学校里，清晰可见的是：学校和角色的间隔并不是一下就能走到的，角色须要几十上百帧不断地移动，才能到达学校。即当如果“小本子”里的事情是“走到学校”的话，没有其他成分打断的时候，这个行为要实行良久。详细要多久，也是没法打算的，由于我们不能担保过程中角色不会由于“跌倒”而停息几个回合、由于“崴脚”而减速几个回合……有非常多的动态缘故原由会影响这个行为的实行，但是只要终极不发生比如“学校没了”、“角色晕厥了”之类的分外情形，“小本子”里的任务就始终是这个，这就实现了“走过去”的效果。
而如何做到“A过去”呢？事实上我们真正的需求是一个“在小本子的事情没做完的时候打消掉小本子事情的方案”，而这个方案可以大略到——就给这件事情限个时：
//原来的“小本子”内的数据{"type":"move", "x":30, "y": 10}//现在的小本子内的数据{"type":"move", "x":30, "y":10, "tick":1}
我们紧张到现在的数据中多了一个"tick"，这个"tick"便是实行多少帧逻辑后，如果事情还在，就把它从“小本子”里抹掉。而上面的例子里，便是“在向(30,10)移动了1帧之后或者到达目的地后（把稳这是或关系的两个条件），打消掉这个事情”，由此当npc第一帧向着目标移动之后，事情就没有了，就会重新思考一次“todoThing=???”的问题，在“3F.思考要做什么”一环里，会重新根据当前情形去看是否“该去战斗”了。由此实现了“A过去”的“当心性”，而且这还是一个带“当心程度”的方案，即“tick”值越大，npc越不当心。当我们用多了"tick"这个条件往后，会创造一个征象——为了确保角色的灵巧性，我们总是会去设计这个“tick”，那为什么不默认便是有每1帧运算一次呢？是由于担心效率吗？实在并不是，还是为一些分外的、须要坚持的事情留余地。
而从编程的角度出发，我们更不应该选择其他的工具或者事宜，来打断正在实行的AI事宜，由于这意味着须要实行打断AI事宜的工具，将依赖于有AI的工具，这是一个依赖关系缺点问题。
以是，关于AI的行为被打断这件事，并不应该有任何分外处理去打断一个实行中的AI（即主动抹除“小本子”上的事情），而该当由AI的设计师通过设置“tick”的办法来自行决定某个AI的“敏感度”。
04 好的AI设计，是“可拼装”的
在实际的游戏AI制作事情过程中，可掩护性和可实行性的问题就会冒出来。如果我们现在做一个餐馆经营类游戏，现在来设计里面的做事员的AI，那他大致该当是这样的：
当我们初次完成这个行为树的时候，乍一看他非常美好，只要这么循环，就能做出一个送餐做事员所有的事情了。但是，如果这时候制作组引入了新的设计：
偶尔会有英雄级顾客来访，比如马拉多纳、巴菲特、约翰尼德普等。做事员本身是有方向性的，比如球迷做事员会优先做事马拉多纳；财经谜会优先做事巴菲特……而做事员本身还有崇拜人，比如同样是球星，做事员可能是贝克汉姆的粉丝，以是当贝克汉姆、马拉多纳和贝利同时呼叫的时候，这个做事员会优先去贝克汉姆这里。普通的做事员只能一次端一份菜送给顾客，而SR以上的做事员可以一次端2份菜送给顾客，并且会优先从准备好的菜里选择两份目的地更靠近的；更有SSR的做事员可以一次送3份，并且在前往做事台之前，可以记录2位顾客的需求。当做事员“待机中”的时候，会有小概率做一下小动作，而不是始终呆板的站在那里发呆。如果有超过2个做事员在“待机中”，他们可能会“谈天”。这样的设计即合理又丰富了游戏内容，并且完备不影响npc行为的和谐性，基于这两个需求，我们可以得出做事员和顾客2个工具（本文只设计干系数据，无关数据全部省略）：
//做事员，Maid由于是二次元感更强烈些export class Maid extends Character{ //喜好的顾客类型，由于只须要优先级，以是越早的越喜好就好 //喜好的顾客类型乃至可以是游戏中还没设计的，以是用字符串，可以预填写数据 private favouriteCustomerTypes:Array<string>; //喜好的顾客，同样是越早的越喜好 //喜好的顾客乃至可以是一个“不存在”的客户，比如"mayun"而游戏数据中并没有id:"mayun"的顾客 private favouriteCustomerIds:Array<string>; //罕有度，SR是4，SSR是5 private rank:number; //同时可以真个盘子数，这是策划设计的，应该可以随时掩护这个规则 private DishCarriage():number{ return Math.max(this.rank - 3, 0) + 1; } //同时可以做事的客户数量 private MaxReception():number{ return Math.max(this.rank - 4, 0) + 1; }}//顾客export class Customer extends Character{ //是否是一个英雄级 private isHero:boolean; //客户的id，比如巴菲特等都是由于这个id而是巴菲特的 //当然外不雅观等属性会有所不同，但是外不雅观等属性在本文中不敷述了 private id:string; //客户的类型 private customerType:string;}
如果我们用常见的行为树办法设计，要改变之前的行为树以符合这个需求，可就十分困难了，如果原来这只是一个做事员的AI，不同做事员还有不同的AI，那就难上加难了。这根本的问题在于2点：
行为树的条件仅仅支持“如果是……否则……”（if (xxx()==true) {} else if (...)）的构造，但实际上很多时候我们要判断乃至要利用的并不是一个布尔结果。比如上述的需求中，我们哀求“优先接待贝克汉姆”，如果我们把它理解为“呼叫者为贝克汉姆”并且“我最喜好的是贝克汉姆”，看起来只是2条布尔判断(if (xxx()==true)）都知足，并没有问题，但是如果贝克汉姆已经被别人接待了，我要接待第二喜好的，大概第二喜好的也被别人接待了，我要优先接待第三喜好的……因此这并不是一个“目标是谁”+“目标是我第几喜好的人”的问题，而是“通过排序我该找谁”，有了这个“谁”就有了我要去的目标，这个目标也包括其他客人，但是如果这个“谁”并不存在，那么解释现在没有客人召唤做事员。因此，在这样精确判断或者“状态数量多到险些无限”的情形下，行为树险些是无法支持的。好的AI该当是“可拼接”的，这详细表现在AI函数（即WhatToDo函数）本身该当可以被赋值，以及所赋的值可以是类似concate()拼接出来的。这个问题的导火索是追加的需求3，即待机中的做事员做小动作等。如果只有一种行为的做事员，即所有的做事员利用的都是上面的行为树做的AI，那么这个问题并不会被创造，但如果游戏中有多种做事员，有些是只卖力接待顾客的、有些是只卖力上菜的、有些即卖力上菜又卖力接待顾客，按照传统的行为树的做法，就要有3种行为树，知足这3种不同做事员的AI，而这3种做事员的数据不同，仅仅只有外不雅观等本文不谈论的“表现用属性”以及AI不同。只要颜色不一样，我们就能认可她们的行为不一样。以是外不雅观属性和所利用的AI不同，就足以形成多种做事员了。
而基于这两个问题的思考，我们不得不重新去核阅，若何设计AI的构造是好的。
第1个问题实在仅仅只是一个数据输入的问题，我们只要不用行为树而改用脚本，就立即办理了。
而第2个问题的实质是：目前我们所利用的包括GOAP在内的险些所有的游戏AI的架构思路都是“反人类”的——这些思路哀求设计师先宏不雅观的想好了一个NPC该当会做的统统事情，然后一条条细节追逐下去，正如本段开始的那个“行为树”，我们必须方案好了一个“做事员”所有的行为，然后把这些行为“进行中”的阶段当做一种状态，然后去“深入剖析”这个状态到底做了什么。如果把这个思路用在传统工业，比如服装制造等拥有上百年流水线生产履历、且今后几百年制作流程和内容不会有变革（顶多制作手腕和工具发生变革）的事情时，我们可以利用有限状态机。但是，设计师的思维与此是相反的——设计师对付设计的思维正如他们的灵感一样，是从一个点上迸发出来的。
设计师的设计每每就像火山爆发一样，从一个点溘然就冒出许许多多有趣且非常有代价的设计来，如果我们的程序设计采取类似GOAP这样的“向内包裹”的思路，就仿佛用一个袋子套住火山口，不让它喷发——这并不符合好的设计的特点，好的设计，该当是让喷发出的每一点子都能闪光。
以是我们放下“你现在的需求我都能实现”的“自傲”，来看一下我们如何为“将来”做出准备。先从一个设计师的正常思维出发，就拿我们在这一段的“做事员”设计来看这个AI的思维过程：
列出大纲：首先我们列出了一个大略的大纲，即这个“做事员”到底会干什么，乍一看列出了险些所有的可能性，但事实上这只能算是“头脑风暴”，大概结果上看起来至少80%的内容都有了，但实际上这里产生的设计，很可能是“误导开拓”的。行为树和GOAP都在这里为设计师的设计画上了句号，纵然能掩护，也认为“今后会加的东西不多了，目前构造已经非常清晰了”——但事实上，目前构造险些不清晰，正如我所说：设计师在这里仅仅只是做了“头脑风暴”。列出大纲的步骤非常自然，根据生活履历抽象出会干些什么，同时由此可以得到最根本的“行为树”，但这个“行为树”却缺点地被当做了大多游戏的核心AI。
发散思考：这并不是一个“唯一”的过程，由于在游戏开拓过程中：每次互换中、美术参考资源网络整理中、实际生活再度仔细稽核体验中……等等各种对项目细节的故意识的、无意识的研究中，都可能刺激以产生突发灵感。设计师可能从细节出发开脑洞
设计师还会从玩法功能角度大开脑洞
还有基于“养成”等游戏特性展开的脑洞
深耕灵感：每一个灵感被深耕的时候，又可能萌发出很多好的设计，这些设计每每并不繁芜，但是却可以为游戏带来更丰富的内容，以及更突出游戏主题的内容。在理解了设计师的设计过程、以及项目发展过程中的各种idea的变革、迭代、进化过程之后，我们可以对付AI的实现方法重新进行构思：
首先我们抽象一下贱戏设计师的设计思路：在游戏设计师的理解下，游戏AI便是很多很多个“一件事”的组合，而这个“一件事”每每是一些列“事情”的顺序过程或者组合。由于可能是一个过程，以是在“一件事”中，有些条件被知足了，就会发生另一件事。比如：“做事生从A点走到B点（不管是否端着盘子），都可能由于顾客丢在地上的杂物跌倒”，这个“一件事”是指“做事生移动”，同时“端着盘子”或者“没有端盘子”；而引发的另“一件事”，便是由于“顾客丢在地上的杂物（被做事生踩到）”（条件），以是产生了新的“一件事”：“跌倒”。设计师心中的AI行为的变革实在更靠近于这样一个模式。
我们之前在第3段的时候说过，由于每一个AI事宜的运作，都是多少个tick往后重新思考的，以是实际上对付设计师来说，并不存在“什么韶光点打断”的问题，而是只要想清楚“什么事情会打断”。包括“一件事”结束，都是一个打断，打断的结果便是转向另“一件事”
而实际上在这个“一件事”的全体过程中，所有的情形都可以是“条件”，包括“一件事”走完往后。因此，我们完备可以把每一个“一件事”都算作一个“管理器函数”——这个函数决定了是否这一帧要跳转到另一个函数，如果不要就照操持行事。在代码上利用好角色思考函数本身可以被赋值的特性：既然这是个可以被赋值的属性，那么改变它的值就不是不可能的事，而在比如Unity的Behaviour Designer等插件中，行为树的利用本身也是可以被重新赋值的（BehaviorTree下就有ExternalBehavior可以被赋值），以是利用这个性子对付角色的WhatToDo函数重新赋值来实现AI的变革是好主张。
下面是代码韶光
首先，我们要小小的改造一下Character中的WhatToDo，这样他的值就可以是写在其他脚本里的函数：
//这里正是策划设计的主要部分，也是AI的大脑private WhatToDo(character:Character):Object{ let res = {} //Unity推举的做法在这里是行为树 //首先我们从小黑板得到一些跟我们干系的事情，省去脚本真个麻烦 let commandMoves = GameBlackBoard.GetCommandsByExecutorKey("team" + this.teamId); //然后我们调用约定好的脚本 if (this.AIScript) res = this.AIScript(character, this.sameAIScriptRunned++, commandMoves, this.runningAIParam); return res;}//脚本端通过脚本接口改变这个值，实现了“一件事”之间的跳转private AIScript : (character:Character, runned:number, commandMoves:Array<Object>, eventParam:Object)=>Object; //同一个脚本已经实行了多少次，这是个很“甜”的东西private sameAIScriptRunned:number = 0;private runningAIParam:Object;//而实际上扩展性好的跳转，跳转到的“状态”，不应该是固定的//比如当“舞蹈完成”往后，“舞娘”该当连续跳下一只舞，而其他人可能就下台连续饮酒了。//只管“舞蹈完成”往后都会进入同一状态，但是我们不一定非得用if else，可以用“afterDance”//即这个Object的构造是：key=跳转的key“afterDance”等，而value是一个AIScript类型的函数//{"function key": (Character, number, Array<Object>, Object)=>Object}private aiWarpFunc = { "default":StandStill //设置一个默认值，以避免跳转的函数并不存在}; public AIScriptWarp(scriptKey:string, eventParam:Object){ if (this.aiWarpFunc){ if (this.aiWarpFunc[scriptKey]){ this.AIScript = this.aiWarpFunc[scriptKey]; this.sameAIScriptRunned = 0; }else if (this.aiWarpFunc["default"]){ this.AIScript = this.aiWarpFunc["default"]; this.sameAIScriptRunned = 0; } } if (eventParam) this.runningAIParam = eventParam; //实在没有就不跳转，保持现在的}
而设计师则通过脚本接口来写脚本完玉成部AI的运作：
//程序供应的脚本接口var MaidAIWarp = function(maid:Character, scriptKey:string, eventParam:Object){ if (maid){ maid.AIScriptWarp(scriptKey, eventParam); }}//判断是否有客人呼叫，有就返回构造var CustomerCalls = function():Object{ if (true) { //这当然不能是true的，详细游戏详细实现 //这个数据也是不对的，该当是返回一个呼叫的客户的列表，当然这里只是举例，以是没法实现 return { customers:[ { "x":10, //为脚本选好得当的站位 "y":10, "caller":new Customer() //这个客人是谁 } ] } }}//判断是否到位了，这里就假设是的var MaidArriveAtPosition = function(maid:Character, x:number, y:number):boolean{ //只管这个函数在脚本层也可以实现，但是供应一下也不坏 return true; //假设是true，本文中就不做详细设计了，只是解释用}//往下都是设计师设计的脚本var StandStill = function(character:Character, runned:number, commands:Array<Object>, eventParam:Object):Object{ return {"behave":"stay", "tick":1};}//做事员的待机var MaidWaiting = function(maid:Character, runned:number, commands:Array<Object>, eventParam:Object):Object{ let callers = CustomerCalls(); if (callers && callers["customers"] && callers["customers"].length > 0){ //假设就走向第一个客户 let targetCustomer = callers["custmoers"][0]; //跳转到角色的“move”下的函数，当然那个函数未必是MaidWalkTo，但我们按照约定做就好了 //第二和第三个参数也是设计师之间的约定，是根据游戏设计来的 MaidAIWarp(maid, "move", {"x":targetCustomer["x"], "y":targetCustomer["y"], "event":"CustomerCalls"}); return; //不return是要失事的，这是个毛病。 } return {"behave":"stay", "tick":1}; //这是“小本子”的内容，由每个项目单独设计方案}//如果是走路怎么办，把稳，var MaidWalkTo = function(maid:Character, runned:number, commands:Array<Object>, eventParam:Object):Object{ //乃至可以写一个别的脚本函数单独处理，而那个脚本函数也未必只有这个函数调用 if (DealWithMaidTouchThing(maid) == true){ return; //跳转到别的事宜了 } //此处因篇幅省去非常判断 if (MaidArriveAtPosition(maid, eventParam["x"], eventParam["y"]) == false){ return {"behave":"move", "x":10, "y":10, "tick":1} //只为演示一下，以是坐标的取法不对 }else{ if (eventParam["event"] == "CustomerCalls"){ MaidAIWarp(maid, "service", {}); //... return; } }}var DealWithMaidTouchThing = function(maid:Character, thing?:any):boolean{ //如果角色移动中碰到了什么东西，也可以单独写一个处理的函数 //返回boolean见告调用者是否该当MaidAIWarp return false;}
从构造上来看，是不是觉得aiWarpFunc这个动系有些多余？如果单看流程的话，实在没有这个东西，我们直接在脚本里调用对应的接口是很好的。首先如我们上面说的，每个角色的“afterDance”不一定是一样的事情，我们大可不必去(if (character...))；其次是为了如果我们的设计师恰好都不会写脚本的时候，当我们要建立excel表去做一个灵巧性很高的AI，这里就可以是“角色属性”的一环。
这样，AI就实现了“可拼接”的灵巧构造，并不是说“行为树”做不到这样的效果，毕竟行为树实质是if else，没有if else实现不了的功能，只是方便未便利的问题。
05 未来游戏AI会都用Deeplearning？
事实上是不会的，大概人工智能会在游戏领域被利用，但是淘汰不了游戏AI，由于他们实质便是不同的东西。游戏AI和我们常日理解中的人工智能最靠近的一点功能是“陪玩”。由于在游戏当中，有那么一些元素（大多是角色），他们不属于玩家可以掌握的范围——他们可能是玩家的对手、可能是拖累玩家的互助伙伴、也可能是玩家的强力队友。
纵然是在FIFA这样的足球类游戏中，AI会做什么，对付玩熟习了的玩家依然是了然于心的
对付这样的一些角色来说，玩家不应该可以直接掌握他们，由于对付玩家来说他们的行为该当是一个不那么确定的成分，这样才有策略性可言。如果我们十分理解这些“机器人”的行为，或者对付这些机器人会做什么险些“一无所知”乃至他们的行为“出人意外”，那游戏就会变得并不那么好玩了。
AlphaGo生来是为了证明当有大量的数据，人们通过算法剖析就可以得出相对最好的办理方案。以是AlphaGo生来就不是为了成为“游戏陪玩”的，而是为了击败围棋达人才存在的。而“游戏AI”与我们常日理解的“人工智能”最大的差异也在于——“游戏AI”是为了让游戏中的这些角色元素变得更有活力，而不是为了让游戏中的对手变得让玩家无法击败。
AlphaGo存在的意义便是证明，以大数据网络、剖析为核心的Deeplearning可以为人类在办理问题的时候带来极好的办理方案
但是如果在游戏中，我们由于对手的套路“太诡异”、“藏得太深”等成分，无法总结、或者剖析出一些得当的对策，这并不有趣。能让玩家凭借判断等技巧，结合履历对抗得了的才是好的游戏设计。设想一下，如果《怪物猎人》中一个非常厉害的AI操作要佃猎的龙，玩家险些降服不了，由于不知道龙会想出什么鬼点子，做出什么诡异的招式，这样还能好玩吗？
如果《怪物猎人》的AI是一个像AlphaGo一样聪明的家伙，那么他会选择让飞龙在安全的地方睡觉，一旦有玩家进入园地，立即飞走，去另一个更远的、安全的地方睡觉，以此拖满50分钟韶光，这险些是必定可以降服玩家的方法，但如果是这样的AI“陪玩”，玩家并不会愉快，乃至会摔手柄
“更聪明的AI”并不是游戏设计须要的AI，游戏设计须要的AI，至少是规则可以琢磨的，由此玩家才能想出对策来得到游戏的乐趣。比如在回合制游戏中，某一种仇敌的作战办法便是“只攻击血量数字最高的角色”，那么当玩家找到一个攻击力不高的角色，使劲给他堆血量的时候，就会创造自己做对了——由于那种怪物总是打那个攻击力不高的角色，而那个角色只要捐躯不高的攻击力来防御，为其他高攻击力角色供应输出机会，便是很好的策略——玩家通过对AI的理解得出了一个合理的策略得到了游戏的上风，从而非常快乐，这便是AI“陪玩”的意义。以是DeepLearning不会是“游戏AI”的未来，由于“游戏AI”要办理的问题和DeepLearning办理的问题不一样。
总结
以是，当我们在说设计游戏AI的时候，实际上是在设计：基于游辱弄律例矩而产生出的一套让npc运作的规则，这套规则中npc会根据游戏进行的情形来进行一些决策，做出“不那么机器化”的行为。只要玩家足够有剖析能力、有足够的游戏履历，总是可以摸清AI规律（能摸清但摸不透）来对抗的——这才是“游戏AI”。