【GameLook专稿，禁止转载！】

GameLook报道/随着AI从风口到实用技术的落地，越来越多的同行开始将AI融入到自己的研发工作流当中。不过，如今的AI大模型和工具，绝大多数都只能在特定研发环节帮助同行提升效率，真正能够一句话生成可玩游戏的模型，仍在探索中。

最近，在5月23日举行的”出海文娱增长闭门会“上，来自港中大MMLab的姜一雷作了题为“OpenGame：从自然语言到端到端可玩的Web游戏”的演讲。他分享了LLM如今做游戏的难点，并介绍了他参与的codeagent项目OpenGame的“解题思路”。

通过OpenGame，你只需要自然语言，就能指挥agent写代码帮你研发游戏。据姜一雷介绍，如果是做2D网页游戏，在该模型的模板基础上，大概一周时间就能做出可玩的产品。

开源地址：https://github.com/leigest519/OpenGame

那么，如今的code agent能做成什么样的游戏？还面临哪些挑战，以及未来会走向何方？

以下是Gamelook整理的完整演讲内容：

姜一雷：

今天很荣幸能向前面的各位学习，然后能去分享我们最近做的一个开源项目，叫做OpenGame，它相当于是面向game coding开发的Agentic框架。

在此之前先介绍一下我自己，我叫姜一雷，目前是港中文MMLab博一的学生，同时是在某大厂的基座团队做LLM的强化学习预训练的工作。我个人的研究领域也是Agent，以及怎么针对Agent能力的提升去设计一些框架和底层算法，相当于是通过强化学习去提升基模的能力。

今天的内容目录大概是这样的：

为什么我们要做这个工作，这个工作里面大概包含什么，以及怎么评估的。然后我也想讨论一下，从技术方面来讲，想要做成现在这样Web Game Coding的Agent有哪些技术上的难点，以及未来可能去怎么发展。

首先，为什么游戏code agent是比较难做的？我们这个东西相当于做了一个类似于首个开源的整体框架，能够把输入的一句话，就是自然语言，一句你对游戏的想法或者游戏设计，能够把它变成一个完整口，在这样一个2D的网页游戏。是一个端到端以及全自动这样的一个框架。

我们做了三个主体：一个是我们搭了整个agent，相当于现在用的词叫harness，相当于是为了针对这个任务去创造出一个比较好的harness；另外我们也去训练一个中等模型的基模，是27B的一个基模；然后相对应提出一个怎么样做评估的方法。

为什么游戏对LLM特别难？

为什么说游戏创作对大模型来说，尤其是对现阶段的LLM来说是比较难的东西，因为一个真正可玩的游戏其实是一个实时系统，它包含了一些主循环物理事件的处理，也包含了很多像美术、音频这样一些资源的管线，它是一个非常非常庞大的、相对来说非常复杂的系统，product system。

然后它中间跨文件的一些，无论是导入或者调用，其实耦合都是非常紧密的。现在LLM，比如说它在解一些coding题目，或者去底下的单个文件代码上面其实表现得会非常不错。但是，如果让它去写一些非常复杂的工程，尤其是从零开始写，比如说我想搭一个可能是二三十个文件的项目，你让它从头开始写，其实现在的通用Agent做的非常Bug。

从我们最开始的实验中，我们发现有3类失败模式，第一个是逻辑不自洽，比如说整个全局状态在主循环里一直漂移。另一个是对于你想用的这个游戏引擎，它对这方面的知识感知不是很好，比如说引擎里面已经实现了一些功能，但它不知道有这个功能，然后它自己想要从头写一遍代码，而不是去调用引擎里的某一个功能。第三个就是跨文件不一致。相当于它在创建project level项目的时候，跨文件调用非常差。

目前想到了一个方法，我们想把这个coding agent，在它的基础上把它专业化成为Gamedev的专家。

然后我们做出来大概是这样一个效果：

比如无论是个人的创作者或者甚至是教育领域，比如说老师现在想要把课堂变得更有趣，还是一些自媒体的创作者都可以根据他们想要的话题或者知识去构建出来一些更有意思的内容。

我们整个游戏的涵盖类型也非常多，无论是像马里奥这种平台游戏，还是保卫萝卜、植物大战僵尸这种类似塔防的游戏，亦或是UI heavy类似影游那种的，其实也都是可以做的。

因为时间限制，我这边就大概过一下我们这个东西是怎么做的。

首先是代码模型训练，我们在Phaser上面的宇宙上做三阶段的训练，首先是CPT，然后是SFT，然后再加上RL，这是一个比较常规的过程。

主要还是搭了一个agent harness，这里有6个阶段，首先分类就是针对每个游戏的类型去维持一个最小化和功能化的一个code agent，便于它在写游戏代码的时候能直接调用它，而不是从头开始写。所以第一步要有一个分类，比如说物理引擎，他可能是一个平台游戏，也可能是一个上帝视角游戏，这种类型就不需要考虑重力因素。

之后就是GDD生成，文档生成，资源生成，到最后相当于提取中间这个模板，然后直接把里面的hook给填上，最后是一个验证。中间的话就是训练的过程，以及我们管线的过程。

最后就是相当于Agent在过程中会不断演化自己，比如说我们首先会维护一个meta campaign，它是一个非常原始的母模板，针对任何游戏都可以调用这个模板。随着给他一些真实认知的任务过程中，比如说建一个马里奥式的游戏，那它建完之后，我会让他把这种游戏所需要的模板提取出来，放到我们的模板库。

这样，在下次遇到比较类似的游戏的时候，就可以按图索骥，直接提取出来比较类似的模板去用，往里面填充hook就可以了，就不用从头开始写。

device skill也是针对容易出现的bug，相当于每天的一个MD file，无论是在验证过程中还是下一次从头开始生成过程中，能让它把这个东西debug好。

接下来也比较困难，也就是这个游戏怎么玩？它和普通的代码其实还不一样，普通代码你可能有compile（编译）成功、test通过就OK了。

但是游戏不一样，游戏也有三个阶段，第一个阶段是这个东西能不能编译成功，如果都不能编译成功那肯定不行。第二个阶段就是里面有没有bug，比如有些游戏做出来它可能有bug，比如我们用SOTA模型去做马里奥游戏的时候，它完全不知道这个游戏角色的身高和它能跳跃的阶梯高度之间的关系，导致这个游戏永远无法通关。

第三步，游戏最重要的是好玩，那这个趣味性又怎么衡量？这不是更难了？所以说这个东西本身衡量起来是非常非常困难的。我觉得在我们这个工作里面，现在这个阶段只能尽力做的好一些，但是我们承认肯定不是完美。我们衡量三个阶段，也就是三项，第一个是build，能不能渲染，能不能编译；第二是游戏画面怎么样，就是我们从中间截图然后给他打分。

第三是和用户意图是否一致，就是比如说我在游戏里想做几个功能，我想要这个游戏有3个关卡，某个人物有什么功能，或者我想要交互技能是WASD还是上下左右，也就是你做出来的游戏是否和用户需求一致。

从结果上看，我们这个模型和harness都取得了非常好的效果。

Web Gamedev的痛点

最后想讨论的是web gamedev目前的几个痛点以及未来的几个方向。

第一个就是LLM和Code Agent的3D空间理解问题。当然，我们的OpenGame主要聚焦的还是2D游戏，下一个我们已经在做的相当于是OpenGame 3D吧，我们已经在做了。

从我们最开始做的时候就发现有几个比较重要的问题。第一个是3D的问题，比如说，LLM通过Unity或者Unreal的MCP去用或者调用API生成一些3D资产，但生成之后，比如说我想搭一个赛车的跑道，然后我跟它说要搭一个赛车道，旁边要有一堆树。然后这个agent会调用一些API来生成3D的资产，但是它不知道怎么摆，它心里面没有这个东西。比如常规我们应该是中间一条路，树是在两边，这是比较正常思维的一个场景。

但很有可能，他会把一棵树垒到另一棵树的上面，或者说它把树就种到路的中央。就是说，它不知道怎么去管理3D布局，这是非常重要的一个问题。然后像其他的一些比如说穿模，比如说你生成了一些NPC，一生成直接就卡墙里了。

从我们看，这是相当重要的一个问题，我们觉得模型本身是缺乏3D空间先验的，它在text token序列里面推理没有空间的理解能力。一些可能的方向，比如说符号化的空间表示，或者动态闭环，或者物理碰撞信号，这i可能是一些解决的思路。

至于我们是怎么解决，如果大家感兴趣的话，我们会在七八月份的时候会发布出来OpenGame 3D，我们也给出了一些解决方案实现了一些比较好的效果，到时候大家可以关注一下。

第二个点，我认为是非常重要的一个点，就是这个Game Agent怎么去eval，也就是怎么去“玩”到“体验”。这个也不是我说的，之前我跟Unity交流，他们在Gemini 3之后就大力发展AI业务，大家交流认为eval是最痛点的一个阶段，无论是你的agent group里怎么给验证反馈，还是说用RL训练的时候怎么给reward，其实都是非常非常中国要的。

我们大概分两条思路，大概是这么想的：第一个是黑盒的，相当于Game-VLA，就是我们input实时有一句话，就是完全模仿人，因为我不知道游戏的源码怎么搞，只知道这个游戏相当于是一个SDK，直接就用。那就是看这个游戏的画面然后输出动作，相当于像玩家一样把整个游戏玩一遍。

但是我们目前尝试有几个问题，首先这个路线，也就是Game-VLA路线，用现在的仿真模型，在zero-shot情况下走不通，也就是如果是他没见过的游戏让它直接玩，基本上它就是不会玩，效果很差。一个可能的解决方案是用few-shot去做，就是你把比较像的给他做一个in-context-learning（情景学习），或者把这个游戏一些比较重要的交互生成一些技能给他塞到这个context里面让它知道。

这个还有个问题是，比如你真的用Game-VLA去做的话，你想要检验这个游戏中的功能，比如说这个游戏有3关，我想测试第2关，那就必须把第一关玩完之后才能玩第二关。但有一个很大的问题，就是它能不能玩到第二关都不一定。

而且如果一个游戏有50关，我想要测试第49或者第50关，那非要把前面所有关都玩完吗？这个就太慢了，这就完全不可行，无论是agent loop还是rollout都太长了，完全没法做，可能训一个step就要好几天，完全没办法训练。

所以权宜侧可能就是白盒这样的东西，因为LLM、code agent生成的游戏，它的源码是完全accessable的，知道它代码是怎么写的，那么我们可以做一些白盒runtime state injection。核心洞见就是，把玩到某个状态，直接pass到某个状态。

因为游戏它其实就是一个state machine，原先的Game-VLA黑盒玩法是通过一个agent去玩到某个状态。这个state injection就是直接不玩，把参数改到对应state就行。

大概说一下白盒方案的一些思路，比如说直接抽调keypoint，这当然也需要LLM去帮我们，然后往里面注入，再去执行。这个比较快比较稳，但局限就是仅限于白盒自生成游戏，我觉得如果将来技术发展到更好的话，我觉得还是有一个流式的黑盒Game-VLA，也就是它能像人那样实时去玩这个游戏。但是这个需要大模型那块把仿真人模型训练好才可以。

未来方向

未来的方向，当然是从2D到3D。OpenGame是一个偏学术性的，我看到不少创业公司也在做类似的东西了。我感觉2D的技术门槛已经没有那么高了。如果想做的人，直接在OpenGame上改一改，一周就做出来了。技术门槛可能在3D，但是对于产品我可能不是太懂，我只是从技术上来说，所以只是提供技术参考。

今天的分享就这些，谢谢大家。

【GameLook专稿，禁止转载！】

GameLook报道/最近几年，随着旗舰级产品纷纷选择跨端，移动端的性能优化问题逐渐成为了困扰许多手游玩家与游戏厂商的问题。

尤其是随着玩家对跨端游戏画质与光影表现追求的不断提高，许多厂商开始选择在移动端使用UE引擎，而近两年几乎每款使用UE的手游，都会在上线初期遭遇移动端优化问题。包括库洛的《鸣潮》、叠纸的《无限暖暖》、完美的《异环》……

UE引擎固然在光影渲染上，尤其是大世界氛围构造上，具备明显优势，但是其对硬件性能的消耗，也导致几乎没有厂商能够在移动端优化这一问题上幸免。

而就在上周，全球主要的智能手机芯片架构提供商ARM，召开了一场关于ARM新图形技术的发布会。该发布会以ARM和腾讯海外子公司Sumo Digital联合开发的新游戏《Neural Dawn》（中文名：光影新生）为例，向外界展示了ARM如何将桌面级的图形技术，应用在移动端之上。

ARM的全新神经网络技术，不仅能大幅提高移动端游戏的画质表现（在移动端使用光追），还能降低硬件性能损耗，大大减轻游戏厂商的优化负担。

根据官方信息，《Neural Dawn》预计在今年下半年上线，与此同时ARM也将发布搭载神经图形技术的新一代Arm Mali GPU。

移动端版本的“DLSS”与“帧生成”？

这次ARM发布会，最核心的点就是对外展示了神经超采样与降噪（NSSD）、神经帧率提升（NFRU）两项技术。而这两项技术如果用比较简单粗暴的方式去理解的话，其实有点类似于英伟达DLSS与帧生成技术的移动端版本。

首先是NSSD，这项技术其实是ARM此前神经超采样技术（NSS）的拓展版，NSSD技术能够借助AI能力，先以较低分辨率进行渲染并大幅减少光线采样数量，随后再通过神经网络进行超级采样与降噪。

这意味着NSSD技术允许移动端使用光线追踪技术，并在有效消除光线追踪产生的噪点的同时，显著降低GPU运算成本和功耗。这种先用低分辨率渲染，再进行重建的思路，其实就类似于近几年桌面端的DLSS、FSR技术。

然后是另外一项技术NFRU，这项技术的原理是提取两组连续帧，并生成中间帧，直接提升帧率。据发布会介绍，目前该技术可将原生30 FPS的图像内容，高效提升至60 FPS。如果是熟悉PC端图形技术的朋友应该很快就反映过来，这项技术与DLSS的帧生成技术十分类似。

在发布会上，ARM的开发者生态系统战略总监，与Sumo Digital美术总监兼《光影新生》总监就介绍了，《光影新生》如何借助NSSD与NFRU技术，在移动端上实现不属于高端PC与主机的画面效果。

据悉，《光影新生》是全球首款使用UE引擎MegaLights功能的手游。MegaLights最早亮相于2024年上线的UE5.5，是一项实时光照系统，支持在单一场景中使用大量动态光源，并产生复杂的直接光照和光线追踪阴影效果。

MegaLights一直以来都是应用在高端PC主机设备上，过去移动端的GPU几乎无法承担该功能所需要性能与功耗成本。而NSSD与NFRU技术让《光影新生》能够搭载MegaLights，使游戏呈现出电影级的光照效果。

《光影新生》的移动端实机表现（图源：ARM官方）

UE手游的优化有救了？

最近几年，越来越多国内旗舰级跨端产品，开始使用UE。这主要是因为UE在开放世界以及光照技术上具备Unity难以比拟的优势。因此我们能够看到许多试图在场景构建上，向写实风格靠近的二游，纷纷采取了UE制作。比如《鸣潮》《无限暖暖》《异环》。

然后这些游戏几乎都在上线初期遇到过移动端优化的问题，厂商们一边是不断对游戏进行优化，一边也纷纷推出了云游戏版本。

《异环》上线不到一周就公布了优化方案，其中移动端性能问题是一个重头

而另一方面，每当厂商对跨端游戏进行画质升级时，不管是加入DLSS/帧生成技术提升性能表现，还是加入光追提升画面表现，大部分情况下都是PC端独享，移动端玩家则只能望洋兴叹，“快乐是他们的”。

《鸣潮》在去年年初加入了光追

其实过去几年，自从跨端游戏兴起以及手游整体内容品质进步以后，整个手游产业链就一直在为“向玩家提供硬件性能范围内更好的画面体验”而努力。这其中付出最多努力的自然是各家游戏厂商，除此之外像引擎厂商，比如UE与Unity也都提出了一些解决方案。甚至一些手机厂商，比如华为就在2021年提出了在手机端实现光追的技术方案。

而ARM作为整个产业链的最上游——芯片服务提供商，由他们直接在硬件端提出解决方案，其实才是最能从根本上解决问题的方式。ARM的新技术让移动端玩家享受与PC端同等的高品质画面效果拥有了可能性。

而GameLook认为更重要的还是这两项技术，有可能像当年英伟达的DLSS那样，大幅减轻开发者的优化负担。

事实上，虽然最近两年一些玩家经常抱怨DLSS与帧生成，认为这是“拼好帧”，还有不少顶配用户将不开DLSS的原生帧数作为评价硬件性能与游戏优化表现的指标。但不可否认的是，DLSS的出现确实降低了很多厂商的优化负担，尤其是一些中小开发者团队，也有底气像大型开发商那样挑战UE 5的写实风格项目。

本次ARM发布会上介绍新技术的适用人群时，也特地提及了小型开发者团队

当然，ARM这次推出的神经技术与DLSS只是原理存在部分相似的地方，二者并不能划等号。今年上半年英伟达的DLSS 5曾经因为过分激进的AI重建渲染方式，甚至直接改变了游戏的美术风格，这在全球范围内都引发了巨大争议。

而ARM开发者生态系统战略总监Peter Hodges最近在接受外媒采访时，就提到ARM的NSSD技术与DLSS 5技术并不相同，“这不是生成模型，而是理解场景中色彩和形状的相互作用，并根据部分信息进行重建，而不是凭空想象。如果重建结果与真实情况不符，那不是特征，而是错误。”

Peter Hodges还表示NSSD技术的相关模型已经公开，他们鼓励开发者查看，并且根据自己的需要重新训练这些模型。

【GameLook专稿，禁止转载！】

GameLook报道/作为Nexon旗下代表性IP之一，《蔚蓝档案》如今已经稳稳占据了一席之地。即便上线运营已满4年，这款游戏至今仍是日本和韩国最受欢迎的二次元游戏之一，持续受到玩家喜爱。

那么，如果从负责统筹开发的“制作人”视角回头审视《蔚蓝档案》的研发过程，会得出怎样的结论？

曾于2018年至2021年担任《蔚蓝档案》制作人的车敏瑞，在NDC（Nexon Developer Conference） 26的演讲《蔚蓝档案项目复盘——从游戏制作人的视角出发》中，回顾了《蔚蓝档案》从开发到上线后约一年的整个过程，并总结了其中“做得好的地方”与“做得不好的地方”。
NEXON Games 车敏瑞

做得好的地方：

1、明确建立了 Vision Build

车敏瑞在回顾《蔚蓝档案》的开发过程时表示，最值得肯定的一点，就是团队在早期清晰地建立了“Vision Build”。所谓“Vision Build”，是指在开发初期通过关键里程碑制作出一个真正“能跑起来”的游戏版本，用它向整个开发团队清晰传达产品的核心愿景。

为此，团队制作了一个从启动到战斗、总计约5分钟、可以“实际游玩”的版本，整体体验已经与正式上线版本相近。当然，这个版本并不意味着所有内容都已完整完成，但团队尽可能减少了用“视频占位”来替代实际实现的部分。

车敏瑞认为，这样做的价值非常明确：它不仅能让开发者切实感受到“有趣的故事”和“出色的美术”究竟会以怎样的形式呈现出来，也能帮助每位开发成员思考，自己该如何完成目标、如何让产品朝着既定方向落地。因此，这无疑是项目早期“做对了的一件事”。

他还提到，自己当时作为制作人，向美术总监和剧情负责人赋予了较大的权限；而在Vision Build制作完成并与团队共享之后，所有人对于“接下来到底要做什么”都变得更加明确，这也让项目后续开发得以明显提速。当然，即便如此，团队依然对游戏最终品质的最低标准以及开发排期进行了事先协商与统一。

2、项目排期控制得不错

在车敏瑞看来，《蔚蓝档案》开发中另一项做得比较好的事情，是整体上较好地守住了开发进度。按照原计划，《蔚蓝档案》原本目标是在2020年11月底上线，最终则是在延期约3个月后，于2021年2月4日率先在日本市场推出。

虽然延期了3个月，但如果从项目立项时点算起，《蔚蓝档案》仍然是在3年内完成上线。放到近年的众多游戏项目中来看，这已经算是相当不错的排期执行表现。车敏瑞还提到，如果这款游戏再晚一点推出，其上线时间就会与《赛马娘 Pretty Derby》撞车。

那么，团队是如何相对顺利地控制住开发节奏的？车敏瑞给出的第一个原因，是在开发过程中持续为团队设定“简单但明确的短期目标”。

例如，在FGT（焦点小组测试）阶段，目标是做出可游玩2小时的内容量；到了CBT（封闭测试）阶段，目标则变成可游玩20小时的内容量；而在正式上线时，则要准备足以支撑上线后1个月乃至3个月运营排期的内容体量。换言之，团队始终以一个个可量化、可验证的短期节点来推进项目。

与此同时，在开发周期中，团队尽量避免陷入“这样做真的可以吗”之类的犹豫，而是采取“先做出来，再根据反馈调整”的思路，避免开发者在中途反复摇摆、迷失方向。也就是说，先把版本做出来，之后根据外部反馈和内部评估决定修正方案，再把这些修正反映到下一个版本中。正因如此，《蔚蓝档案》的开发推进得相对迅速。

3、较早搭好了长期运营的基础框架

《蔚蓝档案》并不是一款“上线即结束”的产品，而是一款需要长期持续运营的游戏。因此，团队从开发初期开始，就围绕“长期运营”这一目标，在游戏内部预先埋下了不少设计上的基础设施。

其中最具代表性的就是“属性克制关系”。游戏并不希望玩家依靠单一角色就能通吃所有内容，而是希望玩家拥有多名不同属性的角色，以更顺畅地攻略不同玩法内容。换句话说，项目在早期就已经为后续角色池扩张与内容迭代搭好了结构基础。

在此之外，团队还准备了可以长期承载玩家挑战需求的PVE竞争型内容，而这最终就落到了《蔚蓝档案》的“总力战”系统上。车敏瑞表示，正是因为这些基础在早期就已经铺好，才让《蔚蓝档案》后续得以更好地维持用户留存率。

做得不好的地方

1、版本稳定性不足

不过，《蔚蓝档案》在日本上线初期，其实曾因为“游戏稳定性”问题遭到大量批评。比较典型的例子是，2021年5月13日游戏曾进行过长达36小时的维护，而2021年8月26日又进行过一次长达50小时的维护。这些都属于让大量玩家不满的“超长时间停服维护”。

对此，车敏瑞表示，这听起来可能像是在解释，但当时的NEXON Games更习惯于与Nexon内部体系以及内部QA团队协作，对于与外部发行商协同推进项目则没有那么熟悉。

除此之外，游戏上线后的热度也显著超出预期，DAU一度达到最初目标的500%以上，这同样给版本稳定性带来了额外压力。

他还提到了一些外部因素，例如东京的AWS数据中心曾发生火灾事故，以及受到疫情影响，团队与发行方相关人员直到一周年之后才真正在线下见面。换言之，早期稳定性问题并不完全来自研发本身，也受到了一系列外部条件的冲击。

2、日常向内容不足

从产品定位上说，《蔚蓝档案》本质上是一款强调玩家与众多美少女角色“建立情感连接”的游戏。因此，理论上它需要提供足够丰富的、偏“美少女恋爱模拟/日常陪伴”方向的内容，来支撑玩家与角色之间的互动体验。但在《蔚蓝档案》上线初期，这一部分显然做得还不够。

对此，车敏瑞坦言，问题背后有很现实的开发成本因素：UI、美术演出以及剧情文本，本身就是整个项目中最“昂贵”的资源之一。

更现实的是，当时真正有美少女游戏开发经验的从业者本就不多，而在这些人里，真正做过“日常向内容”开发的人更是少之又少。正是这种人才与经验层面的现实困难，限制了团队在这部分内容上的推进。

3、更新内容不足的争议

最后，车敏瑞提到，《蔚蓝档案》开发与运营初期另一项明显做得不够好的地方，就是所谓的“无更新”争议。严格来说，《蔚蓝档案》真正开始大幅提速、形成更强势能，是在主线剧情“伊甸条约”更新之后。

但问题在于，这部分内容是在上线相当一段时间之后才实装的。在那之前，《蔚蓝档案》一度因为“更新量太少”而承受了不少负面评价。

对于这一点，车敏瑞表示，团队最初是以“上线时准备好3个月的更新内容”为目标来推进开发的。但在真正进入运营之后，他们才发现，3个月远远不够，理想状态下应该准备至少6个月以上的内容储备。对这一点，他也直言感到遗憾。

在演讲最后，车敏瑞表示：“每当我转到新的项目时，都会像这样把项目中做得好的地方和做得不好的地方整理出来。只有这样，才能在后续工作中把做得好的部分进一步放大，同时尽可能减少做得不好的部分，团队和个人也才能持续成长。”

他也借此提到，目前自己正担任NEXON Games IO本部新作《Project RX》的PD，并希望大家今后继续关注NEXON Games IO本部、《蔚蓝档案》以及《Project RX》。