使用AI融入游戏玩法的开发经验分享
6 小时前8 浏览综合
前言
这个项目是在2025聚光灯48小时游戏开发活动杭州站的独立游戏。我负责了绝大部分写游戏逻辑代码的工作，所以基于上述事实，我们最后决定要做一个关于情感链接的叙事向解密游戏，开发过程中使用了一些AI辅助工具来丰富玩法。
程序与架构
解密游戏通常都是线性的事件驱动的，即达成某一事件后才会解锁下一事件。这看起来需要一个相当健全的游戏流程管理器，这对于GameJam来说太重了，我们没有时间搭建这么复杂的游戏架构。不过Godot的设计理念给快速开发提供了一个好的思路：Godot对于场景（广义上的游戏场景）的设计理念是”所见即所得“，用对于玩家和开发者都是最直观的方式展示游戏内容。在我开发谜题时，我遵循了这一理念去编写脚本，比如：有一个密码箱，它的作用就是提供一个解密小游戏的一整个逻辑，包括但不限于解密的程序逻辑，解密用到的UI，解密之后触发的事件等等。然后重点在于将其封装成独立的一个场景，这个场景的功能与所有外界功能都不耦合，以此达到一个解耦+直观的方式管理谜题。除了刚刚讲的，与外界毫不相干，自己就能实现单个谜题的所有功能之外，还有一个好处其实是——便于调试，我们知道Godot编辑器中F6可以进入单个场景进行调试，这样可以加速开发效率，减少管理复杂依赖的脑力成本。至于如何让这么一个密封的，隔离的单个场景与整体游戏流程沟通，那就属于仁者见仁智者见智的事了。对于这个项目而言，我仅仅是维护了一个全局单例类，通过非常耦合的方式让所有谜题对象（场景）与之通信，从而修改其中的，用于标记游戏进程的变量——其实就是一堆Bool值，实在是不想管那么多了哈哈哈哈。不过我可以预想的，更加健壮的通信方式有，观察者与消息队列——就是订阅一下每个谜题场景解密之后触发的事件；任务队列与全局管理——就是维护一个表示游戏任务流程的队列，每完成头部的一个谜题就弹出，一直到最后一个，以此推动游戏流程。
美术与表达
这个游戏项目里，我们对美术的要求其实挺高的。为了在有限的时间里尽可能提升开发效率，我们引入了 AIGC 工具 来协助。很多图像资源，甚至部分模型，都是直接用 Tripo AI 生成的。现在的版本已经相当成熟，不仅能文生图、图生 3D，几分钟内就可以生成一个带有 UV 拆分和基础材质的模型。对于24h/48h的极限开发类型GameJam，是一个很好的提升资产搭建效率的选择了，节省下来的时间和精力可以更多地投入在程序逻辑和玩法设计上，而这些才是真正决定一个作品能否有亮点的核心。虽然 AI 生成的资源在风格一致性和细节上可能还不算完美，但在 GameJam 这种注重“快”和“能跑”的场合下，已经完全够用，我们采用统一后处理的方式很快就解决。更重要的是，它让小团队甚至个人开发者，也能在短时间内做出有完整表现力的 Demo，不至于卡在资产制作这一关。另外这个项目有一个比较特别的美术效果值得一提：表里世界切换的场景过渡。具体思路就是通过遮罩两个RT实现渐变环境，就像堕落之主的表里世界切换一样，一个球形或圆柱形空间慢慢放大，空间内的物体是一个世界，空间外的物体是另外一个世界。实际上是切换时进行瞬移到另一个世界，再采用切换前的世界那边的摄像机看到的RT去用屏幕空间进行采样，这样就实现了缓慢的世界切换效果。对于这个效果，程序同学和TA同学都有各自的难点：对于程序同学，他需要确保切换时摄像机RT的同步，以及两个世界不会有什么视角上的差异，好在Godot的Subviewport自带动态RT，可以很好的实现；对于TA同学，他的难点在于如何实现这么个遮罩空间的放大，主要是在Shader中通过一些坐标转换实现。当然我们的美术同学和策划同学也功不可没，没有他们就没有这么优秀的场景和剧情去更好地表达出想要的效果了 :)
AI与游戏
最近我其实一直在研究AI结合游戏的各种可能。但AI融入的过程也有一些难点，就拿这个项目而言：我们提供了一个彩蛋，玩家通过在先前的某个谜题完成后提供prompt，之后在游戏结局时通过这个prompt与AI交互，生成最终的彩蛋，我们用到了两个模型，一个Tripo，一个Deepseek：
Tripo API | Integrate, Automate, and Scale with AI 3D Modelinghttps://www.tripo3d.ai/apiDeepSeek 开放平台https://platform.deepseek.com/sign_in
Tripo用于根据提示词生成彩蛋模型，DeepSeek则是生成彩蛋对话。
Tripo现在最快的Turbo模式可以在大约5-8s内生成一个模型，但几秒的时间对游戏体验来说也有不小影响。我们担心这样会让玩家感觉卡顿或者出戏，所以为了尽量减少这种“空等”的时间，我们把生成逻辑放到异步流程里：当玩家完成前一个谜题时，就悄悄在后台触发模型生成；等到结局需要展示彩蛋时，再直接拿到已经准备好的结果。这样一来，玩家几乎感觉不到等待过程，就像彩蛋是即时呈现的一样。这个方法不仅缓解了速度上的不足，也让生成模型这件事更自然地融入了整个游戏流程。
为此我认为要想让3DAI大模型更好地融入游戏开发，必须至少实现以下几点：
1.快。生成速度虽然可以通过异步流程掩盖，但始终是越快越好；
2.高度自定义化（可配置化）。TripoAI的Turbo版本是生成速度是最快的，也是目前最适合游戏开发的。但是在高级自定义化方面还有可以改进的空间，比如AutoSize（自动尺寸：按真实物件的大小缩放模型），PBR（是否启用PBR），Texture（是否生成模型贴图），还有Compress（是否启用模型压缩）等等。再更加先进高级的内容就比如可以实现“模生模”，及通过一个自定义风格的模型生成另外一个同样风格的模型，就类似图像模态的那些功能，根据一张图像的风格做生成或修改。这样一来，开发者可以使用一个符合自己预期风格的模型去生成其他游戏素材，保持游戏风格的完整性，统一性。
3.稳定。这里的稳定不是指温度，而是至少确保开发者可以选定某一具体的坐标系，具体的维度之类的作为生成的模型的坐标空间，这样就能减少后期适配的各种BUG和开发压力。以上是我认为的目前AI3D大模型“真正”融入游戏需要跨越的三道门槛。
而对于大语言模型，压力更多地倾向于开发者这边了。因为其模态限制，诸如DeepSeek之类的LLM的所谓的与AI游戏开发的上限很大程度上就是取决于开发者及其游戏设计了。LLM的生成速率在我看来已经是完全可以融入游戏开发中了，而它的稳定性和可配置化也跟开发者对其自身的配置高度相关，所以要想很好地融入LLM到游戏中，开发者还是要做好“prompt工程”，对自己的游戏设计和LLM的使用都要有完备的理解。不过这并不意味着LLM可以高枕无忧地参与游戏开发，事实上还有很多功能是更复杂的游戏设计所需要的，比如：将LLM的对话上下文转存到本地。这很重要，现在大多数LLM的单次对话记忆空间有限，为了更好地服务于游戏开发，我们可能需要将一些对话记录在游戏存档中，比如剧情游戏中玩家做了哪些事情或者触发了哪些剧情之类的，如果只是云端存储，下一次打开游戏就可能会出现补全的文本不连贯，内容跟先前毫无关联等问题。虽然这些问题可以通过系统提示system prompt暂时弥补，但终归还是有体积限制。所以我认为能将上下文存储到本地是一个很刚需的操作，以此能实现更多复杂的游戏设计。OpenMemory MCP，本地记忆层就是为了解决这个问题而生。总之，我认为现在的AI融入游戏才刚刚起步，但也足够让我们探索更多好玩的东西了。未来随着更多模态的融入，更强大的生成质量，游戏领域会变得与AI领域密不可分（也可能早就密不可分了）。
结语
这个项目的开发经历我就不赘述了，和很多GameJam一样，累啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊。