前言
这个项目是在2025聚光灯48小时游戏开发活动杭州站，我的队友有美术同事，TA同事，还有一个不知道哪里来的奇怪的策划同事，我自己在项目中担任主程，其实可以预见的，真正写游戏逻辑代码的就我一个，所以基于上述事实，我们在浪费了一整天时间后，正式确定要开发一个解密的，有感情内涵的游戏。
程序与架构
我应该如何向你描述整个游戏的程序架构呢，既然你已经知道了这是一个GJ项目，你就大概能猜到事实上没有什么架构，也不配谈什么架构，我在仅有的24小时不到的时间内绞尽脑汁，费尽心力地去搭建一个庞大的屎山代码程序，也领悟到了一些解密游戏和Godot开发理念的不谋而合。
我们正常的解密游戏通常都是事件驱动的，即达成某一事件后才会解锁下一事件，不论在游戏场景上，还是对于游戏流程都是相当线性的。这看起来似乎需要一个相当健全的游戏流程管理器，不过对于快速开发来说，Godot的设计理念提供了一个好的思路。
Godot对于场景（广义上的游戏场景）的设计理念是”所见即所得“，用对于玩家和开发者都是最直观的方式展示游戏内容。在我开发谜题时，我遵循了这一理念（虽然当时并不知道还有没有什么更好的方法了）去编写脚本，比如：有一个密码箱，它的作用就是提供一个解密小游戏的一整个逻辑，包括但不限于解密的程序逻辑，解密用到的UI，解密之后触发的事件等等。然后重点在于将其封装成独立的一个场景，这个场景的功能与所有外界功能都不耦合，以此达到一个解耦+直观的方式管理谜题。
除了刚刚讲的，与外界毫不相干，自己就能实现单个谜题的所有功能之外，还有一个好处其实是——便于调试，我们知道Godot编辑器中F6可以进入单个场景进行调试，这样可以加速开发效率，减少管理复杂依赖的脑力成本。
至于如何让这么一个密封的，隔离的单个场景与整体游戏流程沟通，那就属于仁者见仁智者见智的事了。对于这个项目而言，我仅仅是维护了一个全局单例类，通过非常耦合的方式让所有谜题对象（场景）与之通信，从而修改其中的，用于标记游戏进程的变量——其实就是一堆Bool值，实在是不想管那么多了哈哈哈哈。不过我可以预想的，更加健壮的通信方式有，观察者与消息队列——就是订阅一下每个谜题场景解密之后触发的事件；任务队列与全局管理——就是维护一个表示游戏任务流程的队列，每完成头部的一个谜题就弹出，一直到最后一个，以此推动游戏流程。
美术与表达
之前提到小队里其实大部分都算是美术，所以这个项目我们对美术的要求挺高的。
为了加快开发效率呢，其实也有使用AIGC工具协助，许多图像资源甚至模型资源都是采用AI生成，对于GJ来说，AI生成的模型其实已经非常够用了。
对于风格不统一之类的问题，我们采用统一后处理的方式解决，虽然效果不尽人意，但还算说得过去。有一个比较特别的美术效果值得一提：
表里世界切换的场景过渡。具体思路就是通过遮罩两个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 Modeling
https://www.tripo3d.ai/apiDeepSeek 开放平台https://platform.deepseek.com/sign_in Tripo用于根据提示词生成彩蛋模型，DeepSeek则是生成彩蛋对话。就目前看来这两种不同模态的模型各自都有自己的融入难点：
Tripo生成慢，虽然最快的Turbo模式大约8s，但这8s对于游戏开发而言太重要了，一般情况下，我们只能通过游戏异步流程生成，比如项目中的在前一个谜题触发生成，在结尾才获取结果。
我相信没有玩家会希望无缘无故等待这么长时间游戏却没有任何反应。除了生成耗时久，还有：模型生成的方位（模型朝向）不确定；模型可定制性不强等问题。
为此我认为要想让3DAI大模型更好地融入游戏开发，必须至少实现以下几点：
1.快。生成速度虽然可以通过异步流程掩盖，但始终是越快越好；
2.高度自定义化（可配置化）。就拿Tripo为例，其最快的Turbo版本并不支持v2.0版本及以上的高级配置，比如AutoSize（自动尺寸：按真实物件的大小缩放模型），PBR（是否启用PBR），Texture（是否生成模型贴图），还有Compress（是否启用模型压缩）等等更加先进高级的内容。
这些Turbo版本都用不了，但它又是最快的，最适合游戏开发的，所以目前我们只能在生成速度和自定义质量之间做权衡。所谓的高度自定义化，除了我刚刚提到的那些配置之外，还希望有更多的功能，例如：可以实现“模生模”，及通过一个自定义风格的模型生成另外一个同样风格的模型，就类似图像模态的那些功能，根据一张图像的风格做生成或修改。这样一来，开发者可以使用一个符合自己预期风格的模型去生成其他游戏素材，保持游戏风格的完整性，统一性。
3.稳定。这里的稳定不是指温度，而是至少确保开发者可以选定某一具体的坐标系，具体的维度之类的作为生成的模型的坐标空间，这样就能减少后期适配的各种BUG和开发压力。
以上是我认为的目前AI3D大模型“真正”融入游戏需要跨越的三道门槛。
而对于大语言模型，压力更多地倾向于开发者这边了。因为其模态限制，诸如DeepSeek之类的LLM的所谓的与AI游戏开发的上限很大程度上就是取决于开发者及其游戏设计了。
不同于3D模型，LLM的生成速率在我看来已经是完全可以融入游戏开发中了，而它的稳定性和可配置化也跟开发者对其自身的配置高度相关，所以要想很好地融入LLM到游戏中，开发者还是要做好“prompt工程”，对自己的游戏设计和LLM的使用都要有完备的理解。
不过这并不意味着LLM可以高枕无忧地参与游戏开发，事实上还有很多功能是更复杂的游戏设计所需要的，比如：将LLM的对话上下文转存到本地。这很重要，现在大多数LLM的单次对话记忆空间有限，为了更好地服务于游戏开发，我们可能需要将一些对话记录在游戏存档中，比如剧情游戏中玩家做了哪些事情或者触发了哪些剧情之类的，如果只是云端存储，下一次打开游戏就可能会出现补全的文本不连贯，内容跟先前毫无关联等问题。虽然这些问题可以通过系统提示system prompt暂时弥补，但终归还是有体积限制。所以我认为能将上下文存储到本地是一个很刚需的操作，以此能实现更多复杂的游戏设计。
OpenMemory MCP，本地记忆层就是为了解决这个问题而生。
总之，我认为现在的AI融入游戏才刚刚起步，未来随着更多模态的融入，更强大的生成质量，游戏领域会变得与AI领域密不可分（可能早就密不可分了）。
结语
这个项目的开发经历我就不赘述了，和很多GJ一样，累啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊。