一直不做 3D，不是因为只缺少几组 API​

要解释 Dora SSR 为什么过去一直没有做 3D 功能，答案不能只从技术实现里找。

这并不是因为我们没有想过，也不只是因为实现模型、相机或灯光的接口很困难。真正让我犹豫的，是 3D 从来不只是一个功能性问题。

那几天，我和我的好 buddy，一起把玩一台 A10mini。

掌机一直握在我手里。我负责按按钮、看画面，把刚才发生的现象告诉他；他帮我分析原因、查找资料，再准备一个新版本给我测试。

我们像平常结对调试一样来回折腾了几轮，终于有一天，Dora 出现在 A10mini 的 Ports 菜单里。

我选中它，按下 A 键。菜单退去，引擎启动。

从社区伙伴的一次纯 Lua PR，到 Dora Agent 生成第一段真正合我口味的 Jazz Hiphop。

过去做游戏时，我经常在寻找音效这件事上感到很烦。

如果是一部对音乐要求很高的作品，答案其实很清楚：应该去寻找自己喜欢、也真正理解作品的专业音乐创作者合作。音乐不是给游戏填空，它本来就是作品表达的一部分。

麻烦的反而是那些小型游戏、实验原型和突然冒出来的创意。

Agent 可以帮我踩油门，但需求、架构和技术选型的方向盘还得握在人手里。

我还在聊需求，它已经想去改文件了​

在让 Agent 执行一项长程任务以前，我有一个自己的习惯：先不让它写代码，而是把它拉来当一会儿产品经理。

我会先说出一个可能还很模糊的想法，再和它一起拆需求、补边界、比较几种实现方案。哪些是必须做的，哪些只是听起来很诱人；哪个方案短期省事，哪个方案以后比较好维护；最后又该用什么现象证明这件事真的做完了。

Codex 负责提需求和试玩，Dora Agent 负责创作；几十款实验后来变成了引擎本身的训练场。

这一次，我请 Codex 去当用户​

最近我做了一件看起来有点绕的事。

我让 Codex 扮演一名使用 Dora SSR 的游戏创作者，通过 Web IDE 给 Dora Agent 提需求。Dora Agent 负责设计、写代码、构建和修正；Codex 则像用户一样继续追问、启动游戏、观察画面、使用键鼠操作，再把发现的问题发回下一轮会话。

我以前对开源有一种很朴素的想象：代码已经放到 GitHub，许可证也允许大家免费使用，这件软件大概就算交到用户手里了。

后来维护 Dora SSR 的时间越来越长，我才发现这个想象有一点离谱。像是把菜谱贴在门口，然后宣布晚饭已经送达。

Agent 会写代码以后，下一个问题是：它能不能自己把游戏跑起来，并看懂发生了什么？

我想离开电脑一会儿，Agent 却停在了浏览器门口​

我一直想让 OpenCode、Codex 这样的外部 Agent 自动开发 Dora 游戏。

理想中的画面有点贪心：我把想法交代清楚，Agent 自己查资料、修改代码、构建和运行。即使我暂时离开，它也能根据结果继续调整。等我回来时，面对的不是一句“代码已经写好，请你手动测试”，而是一个已经走过几轮验证、把成功和失败都记录下来的项目。

从 Dora XML 到 DoraX：声明式结构、组件复用和数据驱动怎样进入游戏场景。

那些还没有“数据驱动”的日子​

在很久以前——久到今天的前端开发者也许会把它称作“上古时代”——做 UI 常常就是用一门通用程序语言，依次创建控件、设置属性、加入父节点，再绑定事件。

这种方式当然能工作，而且非常直接。只是界面最后长什么样，往往不会完整地出现在代码的任何一个地方。它像一份施工记录：先搬来一块板，再拧上两个螺丝，最后接一根电线。读代码的人要在脑子里把所有步骤重新组装，才能看见那张界面。

当代码的读者不再只有人，编译器也开始参与人和 Agent 之间的协作。

以前写程序，有一种做积木拼搭的快乐​

我过去做过嵌入式和 C++ 应用开发。那时候，写下代码往往只是开始：后面还有环境、编译、部署、连接设备和调试，把大批中间操作的任务排成一队，等着把一个小改动送到屏幕上。

如果现在回头看，这大概可以算经典的“古法编程”。程序员先搭好环境和工具链，再把代码一块块拼起来，最后装到设备上，看看这座积木能不能站稳。

从一份线下发来的核心算法代码，到两次公开 PR，社区伙伴与我一起把 SDF 接进了 Dora。

游戏里的文字，很少老实待在原来的大小​

做普通文档时，文字选好字号便会安静地待在那里。游戏里的文字却没有这么听话：标题会放大登场，按钮会弹跳，伤害数字会从角色头顶冒出来，整个 UI 还可能跟着窗口和场景节点一起缩放。

程序员只是想让文字动一动，文字纹理却会在每次放大时认真交出自己的像素边缘。

于是问题来了：TrueType 字体里明明保存的是矢量轮廓，为什么游戏文字放大以后仍会模糊、露出锯齿？