游戏原型开发：从“失落方舟”看最小闭环与范围控制-平芜编程栈

“失落方舟”这个名字，最开始真没什么特殊含义。我们当时的开发室里挂着一张海洋世界观的概念图，画着一艘搁浅在荒岛边的旧船，大家在排期会上盯着它看了半天，随口就说：那这个项目就叫失落方舟吧。一期要做的事也很简单——让玩家醒在一座小岛上，收集材料，把船修到能出港，然后开着它在近海绕一圈再回来。

但就是这句“绕一圈再回来”，让我们整个团队吵了整整一个下午。有人想把天气系统排进一期，有人坚持要多做两个岛屿，还有人在讨论贸易系统的汇率表怎么填。最后还是主程一句话把会议拉回地面：“玩家在一期结束时，到底能完整地做成一件什么事？”答案收敛成一句验收目标：修好船，开出海，能回来。

这篇不是什么宏大项目的发布稿，而是“失落方舟一期”从立项到可玩原型的一份完整记录。里面包含我们怎么把范围砍到只剩一个闭环、怎么从零推数值、原型实现中踩过的坑，以及回头看非常想重新做的三个决策。如果你正在做生存建造类的原型，或者手上也有一个范围失控的项目，那这篇应该能帮你省掉几周试探的时间。

1. 立项起点：为什么一期只做“出岛绕一圈”这一个目标

1.1 一句话验收标准，胜过一整页功能清单

项目管理里最常见的死法，是每个人都对“完成”有不同定义。策划觉得系统列表做完了就算完成，程序觉得逻辑跑通了才算，美术觉得画面能看了才肯松口。结果就是项目无限延期，但谁也说不出具体差在哪。

“失落方舟一期”解决这个问题的方式很笨：把验收标准压缩成一句话——玩家从海滩醒来，采集六种材料修好船体，驾驶船只沿着近海固定航线绕行一周并安全返港。全过程要求能在十五分钟内完成一次，且重复游玩时数值不会崩。

这句话拆开来，其实就是三个可验证的技术点：船体有破损状态，采集和修理能改变这个状态；航行模拟能响应方向输入并消耗体力；航线上的检查点能记录玩家位置。这三件事只要在十五分钟内连续发生一遍，一期就算通过。至于剧情文本、天气变化、多岛地图，全部不进验收范围。

我们内部把这个叫“名词消失法”。立项文档里写的“开放海域生存冒险”，听起来很厉害，但没有任何可执行性。把它变成“修船出海绕一圈”，所有名词都消失了，剩下的全是动词和名词的可操作组合。团队再开会时讨论的就不是“世界观深度够不够”，而是“这边材料刷新密度要不要提高”，效率完全不一样。

1.2 围绕“修船—出航—返港”切出来的最小闭环

确定目标之后，我们要回答的下一个问题是：这个闭环里到底需要哪些节点？

最终留下的是六个节点：采集点、临时仓库、修理槽、出航许可、航行检查点、返港锚地。它们连成一个可以反复跑通的圆：

节点	玩家行为	系统响应	对应参数
采集点	搜索近岸与浅水区	产出木材、纤维、食物	刷新时间、单次产量
临时仓库	存放采集材料	容量上限、分类管理	存储格数
修理槽	消耗材料修复船体	破损度下降、船体外观变化	修理所需材料、修复耗时
出航许可	检查船体完整度	航行状态解锁	最低完整度阈值
航行检查点	沿岛屿边缘航行	记录到达、触发体力消耗	航行速度、体力消耗速度
返港锚地	回到起始沙滩	结算本局数据	用时统计、收集数统计

仔细观察会发现，这里面没有战斗、没有交易、没有技能树。因为一期要验证的核心假设只有一个：玩家能不能在“离开—探索—回来”的循环里获得持续的决策感。采集时要想先拿哪种材料，修理时要想先补哪块船体，航行时要想体力还够不够撑到下个补给点。这些决策本身能让玩家感受到紧张感，那后续加再多系统都有地基。如果连这种小循环都做不出乐趣，加战斗和贸易只会把问题掩盖得更深。

1.3 哪些功能被砍掉，以及为什么砍得心安理得

这是我觉得一期最值的部分——学会拒绝。我们砍掉了一个已在开发的天气模拟系统，砍掉了三个备选岛屿，还砍掉了完整的背包交易界面。

砍天气的理由很直接：天气系统会影响航行手感，但一期最重要的任务是验证手感本身。如果玩家在晴天状态下都觉得航行操控很生硬，那雨天只会放大这个缺点，让问题变得难以定位。不如先在无干扰环境下把操控手感调到及格线，再谈环境变量。

砍多岛的理由则来自一个很实际的约束：一期只有十周，人手就这么多。做三个岛屿意味着地图拼接、传送、各岛资源分配、不同背景音乐这些全部要跟上，工作量翻三倍，但核心循环不会因此变得更清晰。一个岛，反而能逼你把每个角落都利用起来，把体验密度做高。

砍交易界面的理由最有意思——因为主角根本没有背包空间问题。船就是唯一的容器，传送材料的方式就是“带在身上”，交易在闭环里没有位置。我们后来复盘发现，很多项目习惯性地加系统，不是因为玩法需要，而是因为“同类游戏都有”。一期教会我们的第一课：功能列表的完整度不是目标，闭环内每个节点的必要性才是。

2. 参数设计：把十五分钟做成一次有呼吸的航行

2.1 从期望时长反推资源量与消耗速度

“失落方舟一期”追求的不是三十分钟的沉浸体验，十五分钟刚刚好。太短，玩家刚理解机制就结束，没有成就感；太长，原型的节奏拖沓，不方便反复测试。所以参数设计的起点不是“什么数值看起来合理”，而是“十五分钟内每个阶段各占多少时间”。

我们按总时长倒推出一个粗略的时间预算表：

阶段	预算时间	设计意图
海滩醒来、收集首批材料	2分钟	快速建立目标
绕岛采集、往返修理	5分钟	理解“收集—使用”循环
出航、沿近海航行	4分钟	体验移动与体力消耗
中途补给、继续航行	2分钟	制造一次主动停驻
返港结算	2分钟	回收成就感

有了时间预算，资源量就变得可计算。假设岛上环绕分布着十二个采集点，每个采集点产出三份材料，玩家绕岛一圈能拿到三十六份。修理船体需要填满三个船槽，每个槽消耗九份材料，共二十七份。这意味着玩家至少要完成大半圈的采集才能修完，中途还需要做一次“先交哪份材料给哪个槽”的决策，顺便测试了资源管理的压力。

体力的计算也按同一条路推。我们把岛周长设计成两百六十米左右，航行速度零点八米每秒，理论上绕岛一整圈只需要五分半。但光靠移动本身太轻松了，所以加了体力槽：每秒划桨消耗两点体力，初始一百点体力只够全速运行五十秒。中途就必须停靠补给点吃食物恢复，否则后半程速度会掉到原来的百分之六十。这样一来，“航行中主动停一次”就不再是玩家可做可不做的选项，而是被数值逼出来的必须行为。

2.2 让玩家主动停一次：节奏感的隐形魔法

很多原型做出来之后感觉“平”，不是因为少了特效，而是因为玩家全程没有停下来过。全靠一口气冲到底的游戏，结束以后留下的记忆非常模糊。“失落方舟一期”特意设计了中途停靠点，目的就是在流程中间制造一个锚点。

具体做法是这样：把出航点放在岛的东北侧，返港点放在南侧，两点之间有大约两百米的近海航程。如果玩家一路全速前进，体力会在接近中途的位置见底。而那里恰好有一个浅水湾，湾里有两个食物采集点。玩家到那里时，船舶速度已经肉眼可见地下降，系统提示“体力不足”，大多数人都会选择靠岸采一次食物再出发。

就是这次主动停靠，把“出发—到达”变成了“出发—补给—再出发—到达”。玩家在罐头里塞进了一次思考、一次探索、一次资源交换，他们对那一段航程的记忆清晰度会高很多。这个经验是团队里一位做过动作游戏的好友分享的：“不是把数值调平衡，而是把节奏调出呼吸感。”之后的每一轮调整，我们都会先问自己：这一段玩家有没有必须停下来喘口气的瞬间？

2.3 首轮测试的数据记录与调整

原型第一版出来之后，我们组织了十个人的小范围测试。测试时显示平均值比预期短了不少：全程平均用时十一分四十二秒，而目标是十五分钟。差距最大的是采集阶段——预计五分钟，实际三分钟就完成了。

原因是采集点刷新得太慷慨：每个点放了三份材料，玩家第一圈就把船所需要的二十七份全部集齐，根本不需要第二次探索。修理阶段虽然需要时间，但从“集齐材料”到“上船出发”中间没有卡顿，情绪曲线太平。

第一次调整是把单个采集点产量从三份降到两份，同时把修理槽从三个改成四个，材料需求从二十七份提到三十二份。这样一来，十二个采集点共二十四份材料，玩家必须跑第二圈补八个缺口，采集时长精确地延长了九十秒左右。体感上，从“一趟收齐”变成了“两趟勉强够”，紧张感刚好出现。

第二次调整针对的是航行速度。零点八米每秒对测试机器来说偏快，玩家经常来不及转向碰上礁石。我们把速度调到零点六五米每秒，同时提高转角灵敏度——宁可让玩家慢一点，也要保证转向判断时间充足。最终测试平均值落在十三分四十秒到十四分二十秒之间，十个人里有八个人表示“还想再玩一次看看能不能更快”。这个反馈比任何指标都管用。

3. 实现阶段：状态机、配置表与存档分离

3.1 为什么初期选择“状态机加配置表”，而不是上行为树

很多同类项目一上来就用行为树管理所有角色逻辑，“失落方舟一期”没有。原因是团队规模小，程序只有两个人，行为树的调试成本高，一旦出问题很难快速定位。状态机刚好够用，而且直观得多。

整个游戏循环被抽象成几个状态：EMPTY_HAND（空手探索）、CARRYING（携带材料）、REPAIRING（正在修理）、SAILING（航行中）、DOCKED（停靠补给）。玩家行为触发状态切换，状态又决定当前可用的操作和UI显示。这样做最大的好处是规则清晰，任何新加入的成员十分钟就能看懂流程。

同时，所有采集点、修理槽、航向检查点的具体参数全部抽成外部配置表，以JSON形式存放。比如一个采集点的配置是这样：

{ "node_id": "collect_01", "node_type": "shore_harvest", "position": [120.0, 42.0], "spawn_items": [ {"item_id": "timber", "count": 2}, {"item_id": "fiber", "count": 1} ], "respawn_time": 18.0, "sprite_variant": 2 }

这份配置直接放在项目目录的资源文件夹里，策划不需要请求程序就能改刷新时间和产出数量。程序这边只管读配置、做逻辑、显示结果。这套“数据与逻辑分离”在原型期带来的收益很大——我们试过让完全没有编程经验的测试员直接改respawn_time，改完重启游戏就能看到效果，反馈迭代速度提高了不止一倍。

3.2 岛屿边缘碰撞：从“卡船”到“合理偏移”

原型第二阶段出现了一个非常恼人的问题：玩家开着修好的船沿岛边缘航行，偶尔会卡住不动，像是撞上了空气墙。程序端日志显示船舶刚体与某个碰撞体反复接触，但画面上根本看不出那里有障碍物。

排查链路大概是这样的：第一步，复现。在编辑器里沿固定航线重复航行，终于在第N次经过某个尖角时复现了卡船。第二步，定位。把碰撞体可视化打开，发现美术网格的凸包边界在尖角处生成了一根极窄的突出棱边，船舶刚体卡在棱边上，像车轮压到一根细铁轨。第三步，验证。临时将整个岛的碰撞体改成简单圆柱，卡船问题立刻消失，但船可以穿进岸边的岩石里，视觉穿帮。

最后的解决方式是双碰撞体方案：底层用一个覆盖岛面主体的大型圆柱碰撞体，负责阻挡船舶越界；近岸处再挂一圈分段式凸包碰撞体，负责处理岩石、浅滩等局部遮挡。船在深水区域碰不到复杂碰撞，驶近岸边时才会被凸包细密拦截。这样既不卡船，也不会穿帮。代价是多个碰撞体同时参与物理运算，但对一期这个规模来说性能开销可以忽略。

这个坑给我们的教训是：原型的物理碰撞不要直接搬美术网格。宁可先用几个几何体拼出粗碰撞，把玩法跑通，再逐步细化。直接贴网格的后果就是各种意想不到的微小凸起，排查起来极其浪费时间。

3.3 存档语义理清：局部进度与全局进度的分离

一期开发到中段时，我们发现了一个典型的存档设计混乱问题：玩家修好船、出航一圈回来后，系统记录的是“已完成出航”，但游戏里的船只状态却还是破损状态。读档时数据对不上，玩家会看到修补好的船在存档里消失，退回上一条船体的损坏状态。

根因是存档字段混在一起。我们把“当前这一局的表现”（比如采了多少料、航行了多远）和“整个项目的解锁状态”（比如船体已修复至二级）全都塞进同一个字典里，读档时生命周期完全不同的两组数据互相覆盖。

修复办法是强制分文件存。运行时进度单独存为一个session对象，只负责当前这一局的状态；永久解锁进度存为unlocks对象，只记录跨局保留的内容：

progress = { "session": { "zone": "north_island", "collected_materials": 12, "current_position": [103.2, 71.5] }, "unlocks": { "boat_level": 2, "sail_mode": "coastal" } }

两个对象在代码里由不同的管理器读写，互不干扰。界面显示时再按需组合。这个调整前后只花了一天，但避免了一整类“明明存了档却像没存”的玄学反馈。从那以后，我但凡做带存档的原型，第一件事就是先分清楚哪些状态是局内的、哪些是跨局的，这个习惯一直保留到现在。

4. 复盘清单：三个差点改变工期的决定

4.1 先写系统再填数据，是最亏的排期方式

规划排期时，“失落方舟一期”原本的计划是先实现采集、修理、航行三大系统，系统跑通后再慢慢调整数值。听起来没什么问题，实际上差点让项目延期。原因很简单：没有数据支撑的系统测试等于盲人摸象。

我们花了整整两周把采集与修理系统搭完，用了一组随手填的材料数，结果一测发现采集速度过快，玩家的探索欲望只有两分钟就消失了。于是返工调刷新率，又发现采集点的配置结构不合理，程序代码里写死了坐标，策划根本改不了，又要动代码。一来一回，等于把系统重新磨了一遍，工期白白多花三周。

正确的顺序应该是：先用极简代码做出可操作的草稿，立刻塞一组粗糙数值开始测，根据手感反推系统还有哪些功能缺口，再决定要不要扩张系统。系统是顺着数据长出来的，而不是先盖好房子再想家具怎么摆。

4.2 本地存档不等于可以随意堆放状态

我上面提到的局部进度与全局进度混淆问题，本质上是一个设计原则：任何状态都必须先定义生命周期再写入存储。我们一开始觉得原型阶段的存档随便记记就行，结果被读档覆盖整得头大。

后来的稳定做法是，每次新加入一种存档字段之前，先问它属于“单局内会变”还是“跨局保留”。单局的写进 session，跨局的写进 unlocks。如果两者在某种玩法里有关联，比如船体修复等级影响航行速度，那就在读取时做一次运算合并，而不是把合并结果直接存回存档里。这种“存事实、不存结果”的方式，比想象中难坚持，但换来的麻烦会少很多。