这篇文章在讲什么： 坏血，是一款开发三年的乘员组冒险模拟航海游戏。为参加 2026 年 7 月的不完美游戏节，我们用一个月时间将既有的半成品系统整合为可连续游玩 10 至 30 分钟的街机模式，并以该版本参展（现已开放免费下载）。本文复盘这一阶段在 AI 辅助开发流程、美术方向选型、开发者工具建设与玩法结构四方面的关键决策及取舍理由。

展会

5月底的时候我在小红书上刷到一个叫做不完美游戏节的账号发的帖子，粉丝当时虽然好像只有几十个（截止今天7月22日，他们账号的粉丝也只有200来人，感兴趣的开发者可以去点点关注），但是宣传的帖子让人觉得他们会是一个有一些品味的游戏展，而不是一个纯草台班子。于是我就点进去看了一下，发现里面的要求是游戏可以未完成以及可玩游戏时长至少10分钟，当时我就觉得这不就是给我们的游戏定制的活动吗？

尽管当时我们的游戏状态只满足第一个条件，也就是未完成(😅)，但是要在7月18日之前让我们的游戏能玩10分钟，听起来并不是一个难以达到的目标，毕竟我们的游戏已经断断续续做了3年了（之后我应该会单独开一篇帖子复盘过去3年的开发历程，讲讲为什么这点东西做了3年）

于是我和其他两个团队成员商量了一下，就决定报名参展了。展会当天相当热闹，大家的游戏质量都非常不错，玩家也非常多和热情，我们的展位基本从11点开始一直到收摊都没有断过人，不停地有玩家来试玩，提供了非常非常积极并且有帮助的反馈。此外因为我的游戏内引导完全没做，纯靠我一张嘴引导，展会结束之后嗓子基本哑了，喝水都疼。总之，整个展会体验比我预期得要好得多得多得多，简直是做慈善，所以再次感谢一下主办方，无论你们有没有看到这篇文章。

总的来说，我的体验是仿佛经历了长达一个月的game jam，非常有趣。这期间的开发经历有挺多东西可以和大家分享的，但是在进一步展开之前，先给大家看看我们从决定参展和展会那天的游戏有什么区别，此外，游戏的展会版本可以在这里免费下载并且游玩，欢迎大家积极提供反馈意见。

维度	5月30日（决定参展）	7 月 18 日（参展当天）
底层系统	已比较健壮：建造 / 寻路 / 船员 AI / 敌人 AI / 大地图 / 各种操控逻辑	又进行了深度优化，更健壮
战斗	一周搭出的底层逻辑，只有一种怪物	适当打磨过的战斗系统 + 多种怪物与 AI 船行为
地图	多岛大地图，港间 2–5 分钟航程	大幅压缩，只剩三座岛，其中一座有实质玩法
游戏循环	功能全是散的，不太可玩	做出了街机模式，能撑住 10–30 分钟兴趣的完整循环
美术	全是占位符：Tripo 直出 / 未筛选的第三方素材	重做与挑选，观感提升一档；定下 3D 建筑 + 2D 人物路径
音频	完全没有	粗糙但有意思的音乐与音效
资源管线	没有	Web 端世界地图编辑器 + 船只编辑器
UI	非常混乱的布局	新的布局与交互（后续仍需重做，但是玩家可以在开发者的指导下顺利进行游戏）

下面我会对过去几个月，包括筹备展会版本期间做出的关键决策，分类进行一个公开复盘，希望这些复盘的内容不仅是可以帮我们自己理清思路，也给其他开发者提供一些经验，同时让玩家知道我们做了些什么。

这篇文章没有明确受众，所以我基本是想到哪里写到哪里。大家挑着自己感兴趣的看就行。

AI写代码

几个月前在b站发的那个AI工作流分享的视频已经有几千个赞和几万观看了，并且让我的b站账号从60个粉丝增长到了2000个，说实话当时没有想到会有这么多人对一个有些平铺直叙并且缺乏细节讲解的内容，更多地是关注于方法论的视频有如此大的热情，所以或许也会不定期地做一些类似的内容。（同一套工作流的图文版在这里。）

此外，从那时候到现在，模型的能力又往前跃升了一个台阶，同时我自己的工作流也发生了进一步的提升，大概经历了这样一个历程

1. 尝试了superpowers这个skill
2. 结合superpowers和我自己的实践经验，做了一套适合我工作流程的skill，大概包含了如下几个重要部分：

阶段	Skill	作用	输入 → 输出
设计调研	/design-research	查别的游戏怎么解决同一个设计问题（循环/机制/进度/经济），给 2–4 款参考游戏对比 + 可以学习的地方	一个设计问题 → 横向对比报告
设计	/design	把一句话／草稿／聊天记录写成结构化游戏设计文档	想法 → 设计文档
设计审阅	/post-design-review	从实现者视角审设计文档：自洽性、可玩性、可实现性、与现有代码库的 gap	设计文档 → 问题清单
代码设计	/plan	从设计文档生成技术实现计划：架构、接口、带文件路径的有序步骤	设计文档 → 实施计划
第三方代码设计审阅	/codex-plan-review	把设计文档交给 Codex 跨模型审并按结论改文档，自动循环到无 critical 或 5 轮	实施计划 → 修订后的实施计划
代码实现	/execute	读计划逐步执行：自动编译验证、大任务派 subagent、断点续跑	修订后的实施计划→ 代码
代码测试	/test	跑 Unity editmode + playmode测试+自动修复	代码 → 测试结果
第三方代码审阅	/codex-code-review	把未提交改动交给 Codex 跨模型审，循环到无 critical（test 之后、commit 之前），自动循环到无 critical 或 5 轮	代码 → 修复后的代码
（上述skill的具体内容可以在这里看到）

3. 尝试把上面的skill自动化，又陷入了orchestration/harness的坑里一小段时间，做了https://github.com/tykisgod/quick-question，没有达到预期的效果，弃坑，但是
   1. 保留了所有skill以及整套流程的思想
   2. 做了tykit，一个本地让claude code直接操控unity的http server服务，比使用unity mcp响应要快
4. 现在，对于重的需求我都会完整跑设计调研到设计审阅；对于轻度和模糊的需求，跟claude把需求聊清楚了之后，我就放手让他直接进入代码设计，并且后续自动实现，测试以及审阅，我只回来看结果
5. 此外，我从1个claude code账号和1个codex账号升级到了5个claude code max账号 + 1 个codex pro，其中70%的额度花在了这个项目，剩下30%的额度用在了我同时在参与的另一个项目

以下是一些其他的经验之谈：

1. 永远相对聪明的那个模型（opus5/fable > sonnet），充分利用ultracode和workflow。我认为达成同样结果的前提下，返工多次显然比单次耗时长更要命，除非是加几个按钮或者是在我看来相对简单的工作（传统人肉写代码一个工作日以内），否则我几乎一定会用ultracode。日常和claude code聊天我也会用high/xhigh，在聪明的agent身上花钱和在蠢agent身上花时间，我选择前者，因为通常后者除了让人更焦头烂额或者自我感觉良好（也仅局限于自我感觉）这两种情况之外，还意味着付出更大的机会成本。我会时常开4-6个窗口做正交的事情。如果有长任务并且由于它是瓶颈导致我必须等待的时候，我会去做设计的工作或者去干我的另一个项目。
2. 对于衡量标准明确（衡量标准的一个例子：所有测试在这个任务开始前和完成后都得100%通过）的特定任务，比如“帮我把在某个特定场景下的游戏帧数优化到60fps”，“帮我把某个系统迁移到一个新的架构”，尝试使用/goal。我用一天半的时间，在几乎没有人工介入的情况下，把我们的游戏在我的电脑上从平均帧数15fps优化到了80fps，期间我只进行了若干次关键决策，人类精力占用时间仅为1小时左右。
3. 不定期跑/insights，优化流程。当你发现claude总是在同一个地方犯错，或者你总是在对它说同样的话，你可以试试优化一下你的流程。我们优化了包括但不限于监测文档和实现漂移的机制，保持claude记忆同步并且最新，tykit频繁卡死的问题。
4. 用mcp，或者别的什么工具让agent自己去读unity的log，不要给手动复制粘贴log。我用的是自己做的tykit工具，但是这种工具应该到处都能找到。无论是测试结果的log，运行时输出到某个文件的log，还是debug log，请务必自动化agent的读取流程，这个真的可以大大提升效率

美术和音效

时间往回倒一倒，2023年这个项目刚起步的时候，我们对美术的计划是做成类监狱建筑师/环世界侧视2d人物，小物件+顶视2d建筑的，当时的原因如下

1. 我们认为2d美术素材的创作成本（无论是对于我们开发者还是未来的mod制作者）和性能成本都比3d低
2. 听说2d比3d要简单，以及听说新手开发者的第一个游戏最好不要做3d游戏
3. 这套表现形式用来承载我们游戏绰绰有余，虽然相对于监狱建筑师和环世界我们有z轴，矮人要塞也给我们提供了一个带z轴的顶视图操控范式，我们的游戏不可能比矮人要塞还要复杂。

那之后，（不出意外地）随着我们野心的扩大，我们也想尝试一下其他潜在更具表现力的方案，所以自那以后，我们按顺序尝试过如下选项

1. 2d侧视人物，2d侧视物件，类饥荒的2d 45度斜视建筑和场景：
   1. 为什么考虑了这个方案：对于2d俯视建筑，玩家在进行跨层建造，或者观赏模式的时候，同xy轴坐标不同z轴坐标的建筑在2d顶视/俯视表现下实在是不直观。我们还想出了专门为侧视做一个与顶视同步显示的方案，但是我们不想做一个看起来像是CAD的软件，所以我们想到了经典斜45度角的方案。
   2. 为什么否决了：对于我们这种可以无缝旋转相机，而不是有限固定可选角度（比如饥荒，过山车大亨1和2，等。提供了四个可以旋转的固定角度）的游戏来说，纸片感太重了，我不想让玩家在任何情境下联想到纸片马里奥或者类似的游戏，此外对于占地面积非正方形的建筑，我们没有在短时间内想到一个比较好的解决方案能让玩家理解建筑在地面的放置（如果有朋友知道的话，可以交流交流）
2. 2d侧视人物，2d侧视物件，3d建筑和场景
   1. 为什么考虑了这个方案：显然这个方案天然地能解决上个方案的问题，并且纸片马里奥问题也不复存在
   2. 什么否决了：并没有真的否决，事实上我们最终敲定了这个方案。在我第一次思考这个方案的时候，tripo和meshy这种工具出现了，让我觉得可以更进一步。当时看来，我们使用2d素材的唯一原因就是创作成本，但是ai建模工具看起来似乎可以解决相当一部分这个问题。此外对于性能来说，如果建筑和场景都用了3d的，似乎对于性能方面来说，人物使用3d的似乎也不会引入太多额外的问题，于是我们也开始了尝试3d人物
3. 3d人物，2d侧视物件，3d建筑和场景
   1. 为什么考虑了这个方案：我们2024年的时候讨论过很多美术风格，下面附上了一张光谱图，大家可以看到我们认为我们游戏所有可能的美术倾向，僵尸毁灭工程是相当重要的一个参考，当时我设想我们的游戏画风应该是真实，残酷，无情的。如果我们往这个方向再进一步的话，我当时是想试试加上一些现代化改造的 psx 风格——即千禧年左右3d时代常见的有像素化纹理的超低多边形模型，但是加上现代化的光照和材质，不过这个想法在当时只是众多选项中的一种。后来的1-2年中（2025-2026），我也陆陆续续发现有越来越多的独立游戏开始走这个方向，并且达成了非常好的效果，除此之外，ai建模工具也在进步，tripo之类的工具的确可以做出满足我要求的psx风格模型了。那个时间点，我唯一的担忧就是，psx风格似乎和恐怖绑定了——我确实希望我们的游戏让人有真实感，但是我不希望我们的游戏会让玩家感觉到扑面而来的恐怖。后来Coinbase上线了他们那只广告，给“真实但不恐怖”的psx风格指明了方向，并且让我更加确信psx是个效果好，目前尚未被充分发掘（换句话说，就是能给大家带来新鲜感），并且大家能够欣赏的方向，所以我开始尝试往场景中添加psx的模型，包括人物，海洋和建筑
   2. 什么否决了：
      1. 3d人物的面部难以做到高辨识度。就是说，相同距离下，玩家更难以通过面部来识别和区分角色，这对于一个关注于角色情感培养的游戏是致命的。因为3d人物来说，大多数时候看到的都是头顶而不是他的脸。
      2. 对于3d人物来说，动作才是关键，否则无法传达情感，这部分我目前完全不知道怎么做。这是最关键的原因
      3. 没有大量统一风格，可复用的合适psx风格素材
      4. 性能，tripo的低模都有5000面，而对于我们的psx模型来说这显然是不必要的，而减面这个活儿我认为虽然是可完成的，但是在我们的优先级列表里显然无法被排到靠前的位置。此外我们的游戏当时出现了帧数大幅降低和卡顿的情况，性能能从美术捞一些回来就是赚到

现阶段，也就是大家玩到的这个demo中，我们还是决定使用2d侧视人物，2d侧视物件，3d场景和建筑，总的来说有如下原因

1. 为什么回到2d人物：我们找到了一个开箱即用的2d人物工具cc2d，内置一些基础动画。并且根据之前折腾3d人物的经验来说，我可以合理推测，无论是不是ai来做，2d的制作成本都要比3d更低。对于2d美术素材，借助AI我自己就能做（业余水平），但是同样是我来做，面对3d模型，哪怕有ai的帮助，同等精力下，我很难做出令我自己满意的效果
2. 为什么继续用3d建筑：说实话，目前的原因只是因为前述的其他选项不够好，所以我们之后可能会需要在这方面花费额外多的精力来确保我们有和其他美术素材搭配的3d建筑。在相当长的一段时间内，建筑可能都会是白盒
3. 地形：我们尝试了带编辑器的程序化生成任意地形和形态，效果令人意外的好，这个版本是原始的粗版，相信之后的版本会有质的提升
4. 此外我们整体环境的风格，包括水，灯效，开始朝拟真方向偏，因为素材多并且真实光效和环境+卡通人物有一种很神奇的美感。一个此方向上做得完美的例子是恶意不息（虽然它是纯3D游戏）

当前大家demo中看到的美术，大概用了3-5天左右的尝试和调整，除了插件的部分，大多数建筑都是codex gpt5.6 + blender的产物（做这批东西大概花了4个小时）。未来短期以内，我们的风格应该就是走这条路了

开发者工具

在ai编程出现之前，对于我们项目来说，在这个开发阶段，做一个网页端的编辑工具说实话有些奢侈，但是ai的出现让这些工具的造价极大降低，并且由于ai对于工具瞬间上手，没有学习曲线，没有工具抵触，这些工具的roi几乎是无限大。

editor脚本的例子：

1. 一键替换目标prefab的模型
2. 根据csv批量替换建筑模型
3. 程序化生成的船只合法性校验
4. 各种帮助批量修改挂载prefab的脚本，方便agent一键调用而不是通过mcp/tykit手动修改

游戏内调试工具的例子

1. 元素笔刷：用鼠标直接引燃建筑
2. Boss 测试面板：刷 Boss / 一键开 Boss 战 / 跳下一阶段 / 秒杀 / 实时读状态
3. 一键布场 preset：十几个测试场景，进游戏就是配好的船、怪、物资
4. 海况面板 / 特效调参面板：风速、浪高、水色、粒子参数全是运行时滑杆，调完一键「导出当前值」抄回代码
5. 性能探针快捷键：20 秒定长采集，直接给出 CPU/GPU 判决、drawcall、GC、主线程时间去向 Top 榜
6. 跳时间：直接跳到第六天与最终敌人决战

游戏内容编辑工具

1. 世界地图编辑器（网页端，六个模式）：画怪物区多边形和刷怪时间线、画岛屿轮廓和地形预设、摆城市、配国家和外交关系、用类似 EU4 的方式涂格子瓜分国境、配每座城卖什么和价格
2. 预设船只编辑器（网页端）：俯视网格画格子摆建筑、挖洞、放船员和物资，输出游戏读的船只配置
3. 对话编辑器（网页端）：编选句规则和文法词表，实时预览展开出来的样例台词

7 月 16 号，我把世界数据整个缩编了一遍：裁掉大部分岛屿、城市、国家和领土格子，重画出生点和所有遭遇区，最后只留下三座岛。如果没有那个编辑器，这会是一个要手改一堆 CSV 和 JSON、改完还得反复进游戏验证有没有改错坐标的活。

坏血的街机模式是什么

这次放出的下载就是街机模式，关注于战斗和快节奏游戏，此外我们还有更注重于船员管理和冒险模拟的生涯模式，尚在制作当中。

总的来说，这个模式你需要在7个游戏日内击败所有来袭的敌人，并且尽可能获取更高的分数。

正如前面所说，在决定参加展会之前，我们手上已经有了一堆半成品系统，并且我非常确信我们可以用那些系统构造出一些及格的玩法，因此我们原本的计划是做一个包含了战斗，大地图，船员管理和跑商的demo。但是这其中除了战斗，其余的都属于高层次的玩法，并且跑商的路途需要靠战斗，建造和管理来填充，这部分内容我们只有战斗勉强及格，剩下几个部分都毫无乐趣可言。

所以思来想去之后，最终我把目光投向了那个所有人都在使用的捷径：roguelite/roguelike。roguelite之所以是个好结构，原因在于无论一种玩法形式如何，规模如何，你都可以轻松把它塞入这个结构，因为roguelite提供了一种可预测的，清晰易懂的游戏结构，并且给玩家提供了可感知的强度阶梯。

当然最终的展会版本稍微远离了传统的roguelite一些，而更偏向于成为了一个鼓励玩家达到更高分数的街机模式。主要是我不希望玩家在展会现场，在完全弄明白这个游戏的核心机制之前死亡太多次，但是之后的更新我可能会让这个模式更有挑战性。

生涯模式，坏血理想中的样子

这部分现在还没有太多可以说的，但是我希望这个模式能够给大家带来一些新的模拟经营体验，包括以下机制的杂糅：

1. 船员管理
2. 战争模拟
3. 跑商
4. 政治模拟

所以，如果你喜欢如下游戏，你可以关注一下我们：

1. 环世界
2. 潜渊症
3. 暗黑地牢
4. 异星工厂
5. 王国风云

公开开发

总的来说，6月份开始，体感上我们算是度过了这个项目的第1阶段，即，从

1. 对技术，玩法可行性的有高度的不确定感
2. 主要时间花在技术和玩法验证的阶段 进入到了
3. 底层技术架构已经成型，现在的新代码基本可以依托底层逻辑比较轻松地进行扩展，玩法探索方向也相对明确
4. 虽然有相当一部分底层代码仍然缺乏，但是底层代码制作的占比时间逐渐下降，时间开始更多地分配到玩法搭建和迭代，并且逐渐有据可依
5. 工作流逐渐成型，并且方向比较清晰 的阶段。

并且由于我们开始实施街机，生涯模式拆分开发更新的计划，我觉得是时候引入外部的真实玩家（也就是在读这篇文章的你）来和我们一起把这个项目继续向前推进了。大家有任何问题都可以在网页留言，或者加入你喜欢的社区直接与我们交流，你的反馈可以真实并且及时地影响我们的开发方向。

更多关于未来的计划，你可以点击这里

游戏本体在这里免费下载游玩