其中自然包括对游戏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就不用自己转换了。