《神都夜行录》是一款精致国风妖怪手游，呈现精美的场景和个性鲜明的妖灵。本文基于交互式AI模型，设计并实现了智能妖灵模拟系统。系统中智能妖灵综合效用、意愿和任务等多重决策机制规划行为，进行场景交互、妖灵交互以及玩家交互。策划通过定义资源点和资源点交互进行妖灵行为扩展。从玩家反馈可以看出，家园妖灵系统有助于增强妖灵和玩家的互动，提升神都世界的温度。

“世间妖怪，皆有温度”，《神都夜行录》是一款有温度的国风妖怪手游。国风妖怪（神都的世界里称作妖灵），容易让玩家联想到古籍《山海经》，极富吸引力。神都的设计紧紧围绕妖灵展开，精美的卡牌和皮肤，精心设计的技能，炫酷的特效；细腻的主线和支线任务，讲述妖灵故事；情义系统展示妖灵的性格、喜好，随养成阶段解锁的语音、札记等等。

 

神都的游戏系统和种种设计细节，向玩家呈现了鲜活的妖灵形象。另一方面，随着游戏行业和游戏技术的发展，游戏品质不断提高。各种AAA大作给玩家和游戏程序员留下深刻。本文尝试实现一套和场景渲染品质相媲美的AI模拟系统，使游戏世界更加真实，提升游戏代入感。

 

神都的家园系统是一套情感向的放置养成类系统。玩家将妖灵放置在家中，观察妖灵日常活动并和妖灵触发各种互动。妖灵放置养成需要解决妖灵在家中的自主行动问题以及和玩家的交互问题。模拟人生系列游戏是出色的生活类模拟游戏，对生活类模拟AI有深入的研究和技术分享。

 

本文系统借鉴了模拟人生的AI模型，以效用系统为基础，采用效用、意愿和任务等多重决策模型规划行为，使用分层状态机实现游戏内交互。多重决策模型将不同优先级的决策方式整合在一起，每一种决策方式分别负责妖灵不同交互维度的行为决策；根据不同情景和游戏规则设计交互状态机，满足从简单到复杂等各种粒度的交互逻辑。开发实践表明，本文的AI模型表达能力强，易于扩展，适用于交互丰富的生活类AI模拟。

模拟人生系列对生活类模拟AI有深入的研究。

• 《模拟人生》实现效用系统，智能体感知场景中的智能对象，根据智能体个性、需求、技能和社交关系等多个维度的属性进行决策；
• 《模拟人生3》使用分层决策进行大规模智能体模拟；
• 《模拟人生4》使用多任务技术(Multi-tasking)实现智能体并行交互，使用行动图规划行动序列。

基于效用函数决策、行动图规划行为序列灵活性高，表达能力强，适用于复杂的开放世界，用以实现涌现式AI (Emergent AI)。但在其它一些领域，行为树等技术同样能达到出色的效果，且性能更好。本文系统使用分层状态机实现智能体交互，能实现丰富的交互，交互过程的表达和控制更加直观。

 

猎魂觉醒使用效用系统进行建模，实现主城氛围AI系统(FolkAI)。FolkAI系统中NPC拥有需求，场景中资源点满足需求。FolkAI使用多参数的效用公式，来评估NPC加入资源点的意愿。FolkAI系统能营造出色的场景氛围，但NPC和玩家的交互层面还有更多挖掘点。

 

本文系统在FolkAI系统基础上，结合游戏需求，扩展决策模型和交互模型，提升系统中智能体的表现力和系统的交互性。

 

AI模型解决了妖灵在家中生活问题以及和玩家交互问题。一般地，在AI模拟中，拥有自主行为的智能体，不断感知环境，基于感知结果和自身知识选择行动序列，使行动产生的效果趋于给定问题的最优解。神都家园是情感向养成场景，AI模型综合考虑多个维度的妖灵表现，实现妖灵逼真的自主行为以及玩家和妖灵有温度的交互。具体地，本文将问题概括为四种交互类型，即:

 

1.丰富、逼真的自主行为包括

• 妖灵场景交互
• 妖灵间交互

2.有趣、有温度的玩家交互

• 妖灵玩家交互
• 玩家影响妖灵生活

AI模型概述

下图显示了系统的AI模型，妖灵感知到环境中的交互对象，使用多个决策机制进行决策，规划不同优先级的交互，输出到交互队列。妖灵执行交互，并将结果反馈到环境中。模型中使用《模拟人生》的方式描述环境中的交互对象/智能对象。交互对象包括资源点、妖灵和玩家。妖灵使用多重决策模型，不同决策模型依据游戏规则进行决策。包括基本需求、奇缘需求和委托任务。基本需求实现妖灵场景交互，妖灵间交互；奇缘需求实现妖灵和玩家交互；委托任务则是玩家直接影响妖灵生活。

 

 

决策模型

效用决策 使用妖灵基础需求选择场景交互，驱动妖灵在家园中自主行动。效用模型中有两个妖灵相关的关键概念，即特征和需求。

 

特征对妖灵的个性进行建模，不同特征定义了妖灵选择不同交互的倾向。妖灵特征分为几类，主要包括基础特征和职业特征。基础特征如妖怪，描述妖灵共有性格特征；普通人描述来访NPC(一个类智能体)的共有性格特征。职业特征描述每个职业的性特征。家园妖灵的特征模型较为精简，但结合系统中其它模块，妖灵的个性化行为相当丰富。

 

特征使用需求和需求强度定义。妖灵需求主要包括体力、饱足和舒适等生理需求，以及猎奇等精神需求。需求有满意度，满意度通过响应曲线映射到快乐值。妖灵需求的快乐值加权和为妖灵整体快乐值。妖灵的满意度采用相似的响应曲线，如图4所示。以体力为例，随体力满意度增加，响应曲线斜率变小，体力对妖灵快乐值影响变小。

 

系统中的交互对象为智能对象(Smart Object)，智能对象定义妖灵需求效益和交互方式。智能对象包括场景中的资源点、妖灵和玩家。资源点是妖灵和场景交互的主要形式(玩家动态摆放的家具同样为资源点)；妖灵也是智能对象，用于妖灵间交互；玩家则定义了妖灵和玩家的交互，诸如各种奇缘玩法。在效用决策模型中，智能对象提供妖灵需求收益；决策时，妖灵计算智能对象提供的整体效益，从最优的一组智能对象中随机选择。

 

奇缘决策对妖灵的奇缘需求进行建模，驱使妖灵主动和玩家进行交互。模型中影响决策的关键概念为意愿。意愿包括个人意愿和整体意愿，定义妖灵和玩家触发交互的倾向。交互定义在妖灵身上，奇缘决策使用响应曲线把交互意愿映射到触发概率，并随机选择交互。

 

不把意愿需求设计为效用决策中的基本需求出于以下几点考虑：

1. 规避复杂性可能导致的投放风险。奇缘是家园中的核心玩法之一，关联到妖灵情义系统的投放和其它物品投放。妖灵意愿值需要易于演算。效用决策模型尽管很灵活，但要维持妖灵需求数值的稳定和平衡，需要仔细设计对资源点、妖灵需求快乐值响应曲线等，其中不乏一些技巧。未规避太多因素相互作用产生的不确定性，目前系统中，效用决策主要用于妖灵表现层，不涉及投放相关内容。投放由其它更加可控、易于演算的方式实现；

2. 精简演化模型较小服务器压力、便于离线演算。系统使用面向服务的分布式架构，一般地，家园逻辑在Service上执行（详细可见4）。目前游戏内所有服务共用Service进程，而AI模拟开销较大，为此AI模拟放在Town进程执行（Town进程可伸缩）。另一方面，家园逻辑需要支持离线更新，玩家下线时家园状态仍在变化，AI模拟状态更新较为复杂，有必要简化模拟，分离需要离线更新的家园逻辑。

任务决策用于实现玩家主动影响妖灵行为。目前，任务决策为命令式控制妖灵，优先级最高，且需要立刻执行。任务决策委派妖灵到特定岗位，岗位使用资源点定义。资源点描述交互内容，交互由玩法实现（参见上文效用决策）。任务决策模型简单直接，关键问题在于任务执行。

 

交互模型

妖灵使用多重决策模型选择交互对象，将不同优先级的交互加入交互队列，运行图5中的状态机执行交互。状态机开始，妖灵移动到资源点，移动到分配给妖灵的起始点，开始执行资源点行为。资源点行为是AI模拟中实现逼真妖灵行为、有趣玩家交互的关键。资源点行为使用分层状态机实现，用于支持单人交互和群组交互。

 

单人交互

单人交互实现比较直接，妖灵进入资源点，依次移动到资源点位置和起始位置，开始资源点行为。交互实现使用状态机描述，状态机包含进入动作、退出动作和子状态。状态机实现本身相对容易，关键点在于状态机同步。本文服务端执行交互状态机，向客户端发送同步行动指令；客户端把行动指令加入行动队列，并依次执行。

单人交互尽管由妖灵独立执行，但结合一些规则，能呈现丰富的群体行为（鸟群模型是另一个基于智能独立决策实现群体模拟的例子）。本文系统中，首先，巧妙设计资源点，能呈现有意思的群体行为。如图9c，本是两个独立的资源点，加上有意的设计和玩家观察脑补，主线中的CP妖灵在家中和谐相处。其次，通过设计资源点位置列表，不同资源点位置赋予不同意义，使用不同状态机参数，使在同一个资源点上的妖灵完成简单协作。

 

3.2决策模型中的任务决策中提到，任务决策委托任务型资源点给妖灵。考虑到服务端性能、伸缩性和离线演算等种种因素，无法在家园进程直接运行AI模拟，从而运行任务状态机更新家园状态（详细可见4实现）。本文把任务相关的家园交互抽象为Model-View。Model部分运行使用类似Timeline的结构，分阶段运行任务逻辑，更新家园状态。View部分为妖灵表现部分，妖灵进入状态机后，接收和执行来自Model关键位置的命令。View部分不会更新Model。这一结构类似3.3.2群组交互中的群组状态机执行结构。

 

群组交互

单人交互通过有意的资源点设计和组合，能涌现有意思的群体行为，但实现的群体协作相对简单。群体交互基于规则控制成员协作，完成群体目标。群体交互包括妖灵之间有组织的群体行为，以及妖灵和玩家的互动玩法等。

 

图7显示了妖灵群组交互状态机。群组执行状态机和个体状态机的结构基本一致，包括移到到资源点、移动到资源点起始位置，开始执行资源点行为。开始资源点行为时，妖灵创建或者加入群组，执行群组的命令，收到中止或退出命令时，退出资源点行为，完成资源点交互。

系统中，群组形成方式包括基于资源点形成群聚和妖灵邀请形成社交群组。基于资源点形成群聚，妖灵开始资源点行为时，创建或者加入资源点相关的群组；妖灵邀请形成群组，妖灵决策依据特征匹配或奇缘需求等方式触发和其他妖灵或玩家的交互，邀请交互对象形成群组。 形成群组后，开始执行群组状态机。群组状态机包括准备、执行、退出和中止等多个状态。群组状态机运行时发送命令到成员，成员反馈执行结果（如图8）。可以参照《Squad Tactics: Planned Maneuvers》。

群组巡逻基于资源点形成群组，妖灵进入资源点，创建群组：

1. 群组准备阶段，命令组员加入资源点，加入群组，召集组员到自定位置；组员就位后，形成巡逻队列，群组准备就绪；

2. 开始运行巡逻状态机，发送移动命令到组员；组员处理移动命令，开始移动；

3. 群主决策退出资源点，发送退出命令；组员执行退出命令，退出资源点；

4. 群组解散。

群组巡逻相对简单，不过包含群组执行的完整过程。

奇缘玩法中，妖灵邀请玩家形成社交群组：

1. 触发奇缘，妖灵跟随玩家，邀请互动；

2. 玩家接受邀请；

3. 创建玩法，玩家和妖灵进行玩法；

4. 玩法结束，结算。

妖灵在家中有丰富的行为，玩家乐于观察妖灵生活，脑补出各种小剧场，自发分享到社交平台。

 

系统中包含四个核心组件，包括Service进程、Avatar进程、Town进程和客户端（如图10）。具体地Service进程上的AvatarHome负责家园功能逻辑和状态持久化，并将状态同步至Avatar进程和Town进程。家园功能包括清洁度、耐久等基础养成数值，以及家园妖灵放置管理和AI简化模拟。其中，AI简化模拟只运行必要的逻辑，如任务委派、任务状态更新。妖灵表现在Town进程实现。此设计出于几点考虑：

1. 家园Service和其它Service共用进程，而Service伸缩性没有Town进程高，需要避免在 Service进程上运行吃性能的系统；

2. 玩家下线后，家园逻辑同样需要更新，需要避免复杂逻辑。

AI模拟系统逻辑复杂、有大量状态跳转，不适合持久化和离线演算。AI模拟执行决策、状态机、寻路等耗时计算。为此，Service进程只运行一个简化模拟，Town进程执行完整AI模拟。

Town进程的HomeDungoen/TownFieldServer管理场景单位，使用Service保存的部分AI状态初始化AI系统，运行完整AI模拟。AI系统核心模块如图11。MountAIManager管理AI模拟中的资源ResourcePoint，以及妖灵MountAI； impJob、impFate和impMount/MountAIManager 分别负责委托任务、奇缘决策和效用决策几种决策模型相关的状态管理和计算；MountAI 执行决策模块输出的交互，发送命令到SMount；SMount是对应MountAI的战场单位，执行MountAI的命令，更新战场单位状态。

Avatar进程Avatar模块转发客户端请求，主要用于界面操作。客户端和Avatar进程、Town进程连接，家园界面相关操作如放置妖灵，经由Avatar转发到AvatarHome;场景中妖灵交互，由 TownFieldServer的AI系统处理。

 

 

奇缘玩法是系统妖灵和玩家深入的互动，目前包括赠礼、捉迷藏、散步、对诗和划拳等玩法。玩法使用同一个交互状态机实现邀请、群组形成、玩法建立等过程。每个玩法单独实现状态机运行玩法逻辑。玩法状态机根据玩法需求做了相应优化。

 

散步玩法，妖灵和玩家沿路径移动，玩家听妖灵讲述一段故事，从而更加了解妖灵。散步包括对话流，妖灵路径跟随、玩家跟随状态机、相机状态机等。

 

移动过程，玩家和妖灵需要保持队形，同时需要避开静态障碍物。由于mapper使用一个单位的半径生成寻路网格，寻路得到的路径只能保证单人移动避免碰撞；此外，某些窄道只能通过一人。观察现实中行人移动和通过窄道的表现，本文使用简单规则实现两人群组移动。两人群组中，妖灵为主动移动者，执行寻路和路点移动；玩家跟随妖灵移动，并执行图12状态机，避免碰撞。玩家跟随状态机包括队形移动、等待妖灵和尾随妖灵。队形移动状态通过预测妖灵移动目标，使玩家和妖灵保持一个队形；队形移动时玩家预测碰撞，如果前方有阻挡，进入等待状态；等待妖灵状态玩家站原地，等待妖灵移到玩家前方；玩家进入尾随妖灵状态，此时玩家保持在妖灵身后，并探测是否允许回到队形移动状态；如果允许，回到队形移动状态。

 

相机状态机在自由镜头和玩家镜头间切换。自动镜头控制相机在远近景镜头间切换，狭窄区域有镜头限制；玩家操作移动时，状态机切换到玩家镜头。

 

使用H48压测机器人进行压力测试，压测机器人访问家园并在在家中随机移动，测试妖灵决策和交互，如图13。压测模拟3.6万玩家登录，部署8个Town，每个Town有4500左右个家园，4万左右妖灵。测试结果CPU在45%左右，Postman数据显示，AI模拟占15%，战场更新（移动和AOI更新）占52%。代码没有明显性能瓶颈，主要因素为AI模拟规模。内存问题，使用objgraph排查脚本泄露，查到几处循环引用和引擎库内存泄露；使用VisualStudio的诊断工具排查引擎内存问题，发现脚本使用不当导致的mapper内存泄露。

本文实现了一套生活类AI模拟系统，应用于《神都夜行录》家园妖灵模拟。本文AI模型是混合型的，采用多重决策模型和分层状态机，兼顾游戏性、性能和扩展性。

 

从接触群体AI模拟至今将近一年，参与了主城智能NPC模拟系统开发和家园交互式妖灵模拟系统开发。简单做一些总结。

 

首先，关于功能需求开发：

1. 站在巨人的肩膀上 行业发展已久，遇到的很多问题10年前甚至更早已经有深入讨论，基本思想至今适用。GDC、各类书籍博客、KM以及Google，都能学习大量前辈经验；

2. 脑洞大开,即便没有玩过大量游戏，即使对玩法毫无兴趣，游戏程序员要也参与到游戏玩法设计的讨论中。头脑风暴时，和策划一起打开脑洞，切忌过早考虑可实现性(除非笃定不能实现，或者想偷懒)；整理想法时，再回到现实，仔细分析，谨慎考虑，明确问题；如有必要，玩竞品游戏，调研相关技术；

3. 快速迭代 讨论需求、明确问题很重要，但切忌考虑太久。先确定一个方案，实现保底方案；持续思考解决方案，如果能做得更好。

然后，关于实现：

1. 关注点分离 不论是架构还是代码，不要让它变得越来越臃肿。设计模式能帮上大忙，组件化、分层、策略等等。一次只做一件事，把它做好；

2. 无处不在的状态机 状态机可能会被推崇行为树的程序员诟病。确实需要承认状态机的问题。不过在合适的时候务必用上这一利器。需要管理状态时，不要再加大量的is_doing_something判断游戏对象的状态。界面状态、玩法实现等等，都可以使用状态机进行管理。我是状态机重度依赖者。

最后，模拟系统开发还在继续，会有更多有趣的养成内容和玩法陆续加入系统中。

 

👇相关阅读👇

《神都夜行录》降妖司机密档案揭秘：主创人员专访

《神都夜行录》美术篇：角色设计流程大揭秘

《神都夜行录》策划篇：角色动作与特效设计

《神都夜行录》策划篇：降妖师变身术设计

《神都夜行录》UX篇：创意思维如何应用在游戏设计中

  —— END ——