开发者日志 03：食堂开门以后，队伍开始有自己的时间表

修改于10/2111 浏览综合

大家好。

上一篇我先把黑白纸片的表现收住了：拥堵时会出现一份一本正经的小公文，疏通时真正移动的人会抬手，成功和失败也各自盖章。画面终于能把状态说清楚了。接下来我想确认另一件事：如果把这群人放进一个更像日常生活的地方，“排队”这个想法还能不能继续成立。

所以这一轮我没有继续堆装饰，而是做了一个食堂试做切片。它对应的是 10 月 3 日左右的版本，仍然是我一个人做的 PC 单机项目。食堂不是把原来的背景换成几个窗口就结束了，我想借这个场景验证：当终点从“离开队伍”变成“去对的窗口取餐”以后，原来那套简单规则会不会长出新的问题。

先做四关，不急着做完整食堂

我把食堂单独做成一组四关，同时保留原来的 12 关。这样做有两个原因。第一，我需要一个边界清楚的切片，能在一轮里把餐票、窗口和容量从头验证到尾；第二，如果食堂的规则还没有说通，就不应该靠更多地图把问题盖住。

这四关的人数是 8、12、16、18，难度不是靠突然加快速度，而是逐步增加队伍需要理解的关系。每个人手里有自己的餐票，窗口只接待某些票，窗口前还要留出可以服务的位置，窗口容量也会影响后面的人能不能继续往前走。玩家还是只调整路牌，人物仍然自己走；变化来自“这张票现在有没有合适的地方去”，而不是我直接把谁拖到窗口前。

第一关很克制：一种餐票，一个窗口，8 个人。它先让玩家看明白，窗口不是装饰，人物必须走到能接待自己餐票的地方，取餐完成以后才算离开。

第二关变成两股入口、两种餐票和两个窗口。12 个人从不同方向进来，队伍看上去仍然是一条条简单的路线，但中间已经会互相影响。这里要看的不是“能不能把箭头指向窗口”，而是两边同时进人以后，某一处空位被占用，会不会把另一股队伍也堵住。

第三关把人数加到 16，并加入交替出现的餐票和三处窗口。窗口有服务格容量，部分人不能永远沿着第一次选好的方向走，需要在运行中根据票面重新分流。这是我第一次把“改一块路牌”之外的判断压力放进来：玩家要观察队伍正在拿什么票，也要看哪个窗口还有位置。

第四关有 18 个人，三个窗口会随着时间换接待的餐票类型，而且第二股入口会在稍后加入。刚开始看起来正确的路线，过一会儿可能就不再正确。这个变化让我意识到，食堂里的排队不只是空间问题，也有一点时间问题：窗口还在原地，规则却已经换了一档。

这四关目前都有我写出来的可通解，但“有解”只说明规则和关卡数据能对上，不代表第一次玩的玩家一定能马上看懂，更不代表难度已经调好了。这些要留到真正的 PC 试玩。

餐票要出现在规则里，也要出现在画面里

做食堂时，我最怕的是把玩法藏在代码里，画面只剩下几个人和一排柜台。于是我把餐票符号放到了人物身上，也放到了窗口卡片上；窗口卡片会显示当前接待的票、服务容量和换档提示，入口处也会留下即将进场的票面信息。

真实运行截图：食堂试做 03/04。画面暂停在便于检查的状态，可以看到三张窗口卡片、○/△/□ 餐票标记、人物配件和不同的等待姿态。

人物也没有因为换了场景就变成一套新的素材。我继续使用不规则的圆身体和四根短肢，只给他们加上可复现的顶部样式、随身小配件、低饱和强调色和餐票符号。有人焦急地张望，有人耐心等着，也有人像快要睡着了。它们不会偷偷改变移动速度或胜负，只是让“正在等什么”更容易被看见。

我还把行走、等待、取餐和疏通拆成不同的动作状态。动作相位跟着模拟时间走，暂停时不会偷偷往前，重开时也会回到干净的准备状态。这样截图里的姿势才是局面的一部分，而不是绘图函数临时编出来的一层贴纸。

做到第四关时，窗口开始有自己的时间表

第四关是这一轮最像“食堂”的地方。窗口不是永远只收一种餐票，而是会在几个时间段里换档。画面里要同时给出三件事：现在接什么票、之后会换成什么、队伍里的下一批人从哪里来。

真实运行截图：食堂试做 04/04。窗口卡片显示换档后的接待关系，画面暂停在队伍重新分流前，方便检查当前路线和票面。

这也让“成精了”的感觉有了另一种来源。人物没有突然变聪明，他们只是继续拿着自己的票往前走；窗口也没有理解整张地图，它只是在当前时间接待某一类人。可是当票面、容量、入口时间和路牌方向叠在一起，队伍就会表现出一种像在自己安排秩序的样子。

从制作上看，这一关让我第一次认真区分了“规划”和“调度”。规划是开局前想好大致路线，调度是发现窗口换档以后，运行中给后面的人让出另一条路。玩家需要先规划，再接受局面会改变这个事实。

一个很具体的错误：结算还以为只有 12 关

食堂四关接进战役以后，我以为最容易出错的会是餐票路线，结果先出问题的是结算文案。原来的 View.lua 把战役完成写死成“12 关全部通行”。食堂明明只有四关，打完以后却会继续用旧战役的数字说话。

我先加了一条食堂专用的画面断言，让它在错误状态下直接跑起来。第一次红灯不是一句“数量不对”那么简单，而是报了 attempt to call a nil value (field 'GetCampaignCompleteText')。这说明我在测试里已经假定了一个按战役生成文案的入口，但显示层还没有真正提供它。

我随后补上 View.GetCampaignCompleteText，让它根据当前战役的关卡数量生成结算文字，再让 View.Refresh 使用这个结果。修正后的同一组检查是 19/19，通过后我才继续做截图和其他回归。

这个问题让我有点后怕。新增一组关卡时，最容易盯着地图、窗口和人物，觉得能走通就算完成；但玩家最后看到的那句结算话，同样属于规则的一部分。如果它还在讲旧故事，整个场景就会显得像临时拼接上去的。

我怎样确认这一轮真的跑过了

我先跑了纯 Lua 回归，覆盖双战役、食堂四关、人物样式、表现断言和静态路线配置：CampaignSpec 通过 16 组，CanteenSpec 通过，CharacterStyleSpec 检查了 12 种组合和 4 种等待风格，VisualSpec 有 494 个断言，StaticRouteSpec 检查了 8192 个静态配置。已知的食堂四关解法都能通关，但正式入口没有加载测试解法。

然后用本机 UrhoX Windows 运行验证。默认 Smoke 是 99/99，食堂画面和窗口换档各是 19/19，Lua、资源和引擎错误统计都是 0。截图是实际渲染画面，并且停在方便检查票面和窗口状态的时刻，不是我后期画出来的效果。

这轮也留下了一个需要继续处理的边界。我请求过 1024×600 和 1920×1080 两种尺寸，断言仍然通过，但测试窗口没有真正调整成功，实际截图还是 1740×921。因此我不会把它写成已经完成多分辨率验收。高 DPI、连续缩放、长时间运行，以及第一次打开时玩家能不能读懂餐票，都还没有被这几张图证明。