幽靈 @[email protected]

研发（R&D）一般不直接参与游戏开发，而主要负责开发库和工具、物色有应用前景的技术并对其进行研究。

其中自然包括对游戏AI的研究。 AI在游戏中的职能包括NPC的操纵和调试、整个游戏的控制（meta-AI）、自动调整和环境分析。此外，AI除了脚本（script），行为树（behaviour tree）和状态机（state machine）之类的经典模型外，也有近来关注度较高的增强学习和机器学习模型。

要研究游戏AI就少不了AI沙盒，因为需要能轻易反复试错并使用多种方法进行验证的环境。

然而研究部门一旦以研究目的构建沙盒，就容易做得“针对实验”、“迷你游戏”。这种环境易于操作乍看没问题，但加载AI时就会遇到麻烦。

换句话说，由于AI仅在最宽松的环境得到测试，而游戏环境复杂且受限，于是容易出现意料之外的问题。 这么一来加载AI的代价就很大。 开发一线对此也心知肚明，所以也不会轻易尝试。

即便强行操作，问题一样会大量出现。根治不了，风险也会增加。

要避免此类故障，就得考虑开发过程中存在的问题和限制，并准备明显能够运用到开发过程、接近游戏环境的实战型AI沙盒。

但是，由研发部准备实战型AI沙盒是比较困难的。 如开头所述，研发并不专职游戏开发，不具备开发接近游戏环境的知识经验。 强行创建显然会耗费大量工时，势必对研发部的本职工作造成影响。

此外，还有两条路：“使用现成环境”和“参与游戏开发”。

现成AI环境有ALE（Arcade Learning Environment）、ML-Agents或者提供AI专用API的《Starcraft 2》。如能使用这些环境，研发部就不用自行开发了，但这些环境不开源，就算开源因为授权限制也没法用，就算能用也发生过小游戏（mini game）或怀旧游戏（retro game）的问题。此外，最近出现的AI环境大都针对强化学习，很难验证其他模型。

另一条路就是参与游戏开发，在AI相关功能尚在构建的游戏中直接对AI进行试验和验证，研发部无需自行创建沙盒，直接获得实战环境。

不过，一旦涉及游戏开发，开发作业是优先确保的，研究这边就很难有机会推进。 此外，开发阶段出现bug、规格改动导致环境跟着变，无法指望稳定的环境。 于是得出结论，用开发阶段的游戏研究AI并不现实。

最后，研发部决定把已上市的自家作品改成AI沙盒。既然已经上市就是现成又稳定的实战环境，而且可以优先进行感兴趣的研究。

接下来就是选择合适的作品了。选择条件就是“AI的职能尽量多，研究起来简单”（できるだけ多くの役割のAIを簡単に研究できること） ，能构建的场面越多越理想。符合该条件的两个备选分别是2016年的DARK SOULS III和2013年的ARMORED CORE VERDICT DAY。

比较讨论下来，几乎全部项目（例如“移动区域”、“战斗距离”）都有大量选项、自由度更高的ACVD被选为AI沙盒。而ACVD没有现成的PC版，所以只移植了需要的部分。

此外，ACVD有不少AI模型未对应行为树（behavior tree）、强化学习，需要扩充。

然而ACVD的AI和游戏环境紧密结合，直接扩充有困难。代码也比较复杂，贸然操作可能会引发意外的bug或故障。

于是把AI部分从游戏抽离，这么做还有“进行某些研究时可以无视ACVD的情况”“方便移植”“能适配新的AI模型”的好处。

作业的具体内容是用中间件（中間層）替换了ACVD里的AI环境（AI関連の実装）。中间件具备原作环境的几乎全部机能，外部AI连接于其上。于是，对游戏环境而言一切照旧，而真正的AI则在和泛用接口进行交互。

此外，考虑到调试，测试员能直接操作通常由AI控制的角色会方便不少，所以中间件除了接AI，还能接手柄。

在推进过程中，研发部发现游戏环境和AI有不同的数据倾向。以角色的位置坐标为例，游戏环境擅长处理自身世界具体位置的“世界坐标”，而对AI而言则是以自身为出发点离开多少距离的“局部坐标”更容易处理。

所以中间件加上了这种差异的转换功能，游戏环境和AI就不用自己转换了。

用调整好的AI沙盒进行的验证当中，讲座介绍了两个NPC操作实例。首先是研发部内部举行比赛的例子，使用经典AI模型（脚本、行为树、状态机）。

所有研发部成员使用Lua语言创建自己的AI，参加循环赛。 旨在搜集比赛数据。胜负及比赛中的受创情况等信息也得到可视化。

而在强化学习的案例中，首先要考虑两个特点。

第一个是强化学习“很难自行适应最新的算法”。具体原因有：规模大、实装里的数学容易弄错、不优化就会把大量时间浪费在学习上、难以调试。

第二个特点是“需要大量实时数据”。这与其他机器学习相同，尤其在强化学习中，要在学习的同时收集数据，而作为验证者还是希望把数据收集的时间压缩到合理范围内。

作为针对措施，对于最新算法自适应问题，研发部采用已在Python中实装的学习算法。原因有许多主流的学习算法都使用Python且开源、几乎全部用于机器学习的库都支持Python。

但最近遇到过要把Python环境的学习算法用到C++开发的游戏上的问题。解决办法是在游戏和算法间使用Python的强化学习工具包Gym和网络通信库grpc。

对于需要大量实时数据，则通过并行强化学习提高效率、禁用学习中用不上的描画降低计算成本。 通过这些措施，普通配置的PC也能玩转合适时长的强化学习了。

这么一来，主要问题得到了解决，但Gym并不支持学习期间环境参数的改变，譬如场地。另外，它也不支持对战型学习，学习AI之间不能对打。于是研发部自建实例管理服务器解决了这些问题。

最后I7-8700，GeForce GTX 1060配置的PC，在128并行实例（並列実行のインスタンス数128）环境下，花了大约12个小时确认了强化学习的动作。

——「ゲームAI研究をしたい！ ゲームを持たない研究開発部署は、発売済みタイトルから実験場を生み出した！」

@konata 那我多发猫图！

把自动删除嘟文打开了！

是不是可以帮此方哥哥节省一些服务器硬盘（

我不演了我摊牌了。

我是鬼。

@arksci_sky @strawbery 幼稚鬼👻！

@arksci_sky @strawbery 👻！👻！