feat: add production campaigns, gameplay labs, and review documentation
This commit is contained in:
@@ -0,0 +1,114 @@
|
||||
# 环路车场:转盘发车玩法研发记录与阶段结论
|
||||
|
||||
记录日期:2026-09-10\
|
||||
当前状态:**暂缓研发,保留 Demo、实现和测试,供后续复盘。**
|
||||
|
||||
## 阶段结论
|
||||
|
||||
本轮已经验证了车辆沿复杂轨道行驶、旋转道路、自动批量放行和提前错峰调度的技术可行性。路线提示、状态说明和连续行驶表现也经过多次调整。
|
||||
|
||||
但当前玩法仍没有提供足够明显的策略乐趣。最终试玩反馈是:**“比较无聊,没有策略点。”** 玩家主要在左右转动和发车之间循环;系统处理了车辆选择、出车顺序和交通冲突,玩家缺少需要权衡后果的决定。已有的目标转动次数,尚未让这种取舍在体验中成立。
|
||||
|
||||
本轮决定先暂停这个方向。订单、旋转预算、局部道岔等改进只完成了讨论,尚未实施,也未通过试玩验证。
|
||||
|
||||
## 1. 实验起点与玩法假设
|
||||
|
||||
实验以独立的 Car Loop Lab 开展,不修改主游戏的规则和主线关卡。
|
||||
|
||||
基础结构是方格或六角内部路网,加一圈同形、固定的顺时针外环。小车沿配对轨道转弯,从棋盘边缘汇入外环,最终到达右上角车库。只转动内部道路,停放车辆的位置和朝向保持不动;方格每次转 90°,六角每次转 60°。
|
||||
|
||||
最初采用“自由点车”:玩家选择车辆发车,遇到前车或交叉冲突时停车,空间清空后继续。之后提出“转盘发车”:把逐辆点击交给系统,让玩家集中处理道路无法继续放行的节点。
|
||||
|
||||
新模式的假设是:降低逐辆操作的负担,通过左右转向和转动次数形成规划挑战。需要验证的核心问题是:**自动化之后,留下的玩家决定是否仍然有趣。**
|
||||
|
||||
## 2. 研发演进与反馈
|
||||
|
||||
以下按迭代顺序记录,不代表每个阶段都经过独立的用户研究。
|
||||
|
||||
| 阶段 | 实现和调整 | 触发反馈与认识 |
|
||||
| --- | --- | --- |
|
||||
| 基础车场 | 支持方格、六角路网,短车身和明显的车顶箭头,沿曲线转向并驶向车库 | 外环需要贴合内部棋盘轮廓:方盘配方环,六角盘配六角环 |
|
||||
| 即时多车发车 | 自由点车由起点排队改为点击立即出发,多车同时行驶,途中检测真实占位和交叉冲突 | 逐辆等待影响操作响应;发车指令应立即可见 |
|
||||
| 长路线与规模 | 增加真实多弯路线和 10/16/22 辆样本;另做 96 辆桌面关卡,六角 169 格、方格 15×15 | 验证长路径、大棋盘和大批车辆的表现;页面随后改为适配窗口、去掉滚动条和过多留白 |
|
||||
| 视觉整理 | 参考 Hex Video Lab v2;调整车辆大小和白箭头,移除车身下方多余色条,减弱道路对比和格缝,移除六角外缘伸出的引道线 | 试玩反馈棋盘显得乱、看久容易疲劳;复杂路线需要更克制的背景表现 |
|
||||
| 交通问题修复 | 修复未发车车辆“预占未来整条路线”造成的误阻挡;处理两车互卡、自由模式自动演示停滞等问题 | 看起来能走却停住,会破坏规则可信度;自由模式仍保留途中让行 |
|
||||
| 转盘发车初版 | 底部改为左转/发车/右转;系统依当前方向逐辆放行,不自动转盘;无车可走时由玩家转向后再次发车 | 希望减少逐车操作,让玩家处理每轮的转向节点;同时修正左右旋转按钮的箭头表现 |
|
||||
| 路径解释与关卡目标 | 发车时显示车身同色的实际路径;两种棋盘各制作三个 16 辆关卡,加入目标转动次数与左右方向差异 | 自动运行时玩家看不到原先靠悬停才出现的路线;关卡需要体现转向和次数的作用 |
|
||||
| 整轮放行与状态说明 | 一次启动本轮可放行车辆;显示可发车、放行中、需转盘、到站中等状态;路线改用原悬停提示的线型,移除外环尾迹 | 串行发车让人无法判断“还有车能走”还是“只是在等动画”;运行阶段需要明确 |
|
||||
| 提前错峰调度 | 从途中停车让行,改为根据完整行程安排出发时刻;独立路线并行,有冲突的车在原位倒计时后出发 | 车辆贴在一起等待令人不舒服;调度要同时覆盖交叉口、外环汇入和终点,避免把拥堵移到出口 |
|
||||
| 路线颜色收敛 | 所有转盘发车路线统一恢复为原来的绿色提示线,保留淡色光晕;出盘后收起 | 试玩更偏好原版绿色提示,不再按车身颜色绘制多色路线 |
|
||||
| 乐趣评估与暂缓 | 操作和通行已较顺畅,但玩家认为玩法无聊、没有策略点 | 本轮决定先放下,记录过程与结论;后续建议停留在讨论阶段 |
|
||||
|
||||
## 3. 暂缓时保留的版本
|
||||
|
||||
### 玩家操作
|
||||
|
||||
- 进入“转盘发车”模式后,左、右按钮仅转动内部道路,中间按钮安排当前朝向下可放行的整批车辆。
|
||||
- 发车不自动旋转。转盘后也不会自动发车,需要玩家再次点击中间按钮。
|
||||
- 有冲突的车辆在起点等待自己的通行时段,显示短倒计时;已出发的车辆沿预定轨迹连续前进。
|
||||
- 放行阶段显示待发、盘内、外环数量,尚未实际起步的车辆仍计入“待出发”。盘内放行及待发安排完成后,才允许继续转盘。
|
||||
- 统一使用绿色 `#329378` 提示路线:淡色光晕、实线与端点。车辆离开棋盘后收起提示,外环不显示尾迹。
|
||||
- 默认 2× 速度,可调 1–3×。目标转动次数用于评价,目前不是硬性失败条件;颜色不承担订单或通行规则。
|
||||
- 自由点车模式作为对照保留,仍采用即时出发和实时停车让行。96 辆超大样本属于自由模式,转盘发车模式使用专门的 16 辆样本。
|
||||
|
||||
### 可复现的转盘发车样本
|
||||
|
||||
下表来自当前 `rotationPlan()` 的求解结果。左右序列是最少转动次数的一组参考解,不表示只有这一条解。每次转动后都要发车;批次车辆数的第一项是初始朝向直接发车的数量。
|
||||
|
||||
| 棋盘 | 关卡 | 种子 | 目标转数 | 参考转向 | 各轮放行数量 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 六角 | 转向开路 | 3 | 2 | 左、左 | 2、8、6 |
|
||||
| 六角 | 折返放行 | 14 | 2 | 右、左 | 3、7、6 |
|
||||
| 六角 | 连续调度 | 8 | 4 | 左、左、左、左 | 3、1、5、2、5 |
|
||||
| 方格 | 转向开路 | 6 | 2 | 右、右 | 6、4、6 |
|
||||
| 方格 | 折返放行 | 12 | 2 | 左、右 | 7、4、5 |
|
||||
| 方格 | 连续调度 | 19 | 3 | 左、左、左 | 4、4、5、3 |
|
||||
|
||||
六个关卡在初次放行之后,先向左或向右的最少总转动次数不同;第二关的最优解需要折返。这证明了关卡存在方向差异,但目前的体验反馈表明:**计算上的差异还没有转化为足够清楚、有吸引力的玩家决策。**
|
||||
|
||||
## 4. 已验证的内容与证据范围
|
||||
|
||||
- 调度改动后的最近一次完整回归为 `npm test`:100 项通过;`npm run build` 通过。之后的绿色路线调整完成语法检查、静态构建和浏览器视觉检查。本记录本身是文档变更,没有重新运行整套测试。
|
||||
- 真实应用帧循环测试覆盖六个转盘发车关卡通关、先走另一转向后的继续通关、禁止自动转盘、转后等待发车、重置和切换模式取消待发安排。
|
||||
- 调度测试覆盖互不冲突的路线同时出发、交叉路线错峰但行程仍可重叠、帧间扫掠碰撞、上一轮车辆预订通行时段,以及弯道、汇入口、外环、车库的车距。
|
||||
- 测试中途切换 1×/3×/1.5×,并使用变化的帧间隔;所有车辆共享同一模拟时钟,避免速度变化打乱调度。
|
||||
- 浏览器实测六角“转向开路”第一轮两车并行;左转后八车一轮中,三车先发、五车待发,随后接续完成。还检查了窄窗口布局和不同车身颜色使用同一绿色路线。
|
||||
- 本轮验证针对浏览器实验实现,没有完成原生引擎移植验证。
|
||||
|
||||
上述证据支持运行正确性和表现改进,不能据此证明游戏有趣。本轮乐趣判断来自研发过程中的定性试玩反馈,尚无独立样本的通关率、重复游玩意愿等数据。
|
||||
|
||||
## 5. 为什么目前缺少策略感
|
||||
|
||||
以下是对反馈的设计解释,仍需后续实验验证。
|
||||
|
||||
1. **系统接管了大部分操作决定。** 玩家不再选择具体车辆、顺序和避让方式,剩下的动作主要是左右转动及整批发车。
|
||||
2. **试错代价较弱。** 当前目标是全部清空,多转几次依然可以继续。目标转数虽存在,但尚未形成玩家愿意追求的挑战。
|
||||
3. **决策后果难以读懂。** 整盘道路复杂,玩家不容易在转动前预测这一转将释放谁、会为下一轮留下什么方向。绿色路线解释的是正在发生的运动,对转动前的规划帮助有限。
|
||||
4. **放走车辆通常只带来单向收益。** 车辆离开会腾出空间,当前规则很少要求玩家为后续目的保留某辆车或某个通行机会。
|
||||
5. **观看占比仍高。** 多弯轨迹和大量车辆能够增加动画内容,却没有相应增加有意义的决定。
|
||||
|
||||
值得保留的经验是:清晰状态、统一提示线、真实路线和提前错峰,让玩家更容易理解并舒服地观看运行。但下一轮若恢复研究,优先需要验证决策本身,而不是继续扩大车辆数量和路线长度。
|
||||
|
||||
## 6. 已讨论、尚未实施的方向
|
||||
|
||||
| 方向 | 希望产生的决定 | 当前判断 |
|
||||
| --- | --- | --- |
|
||||
| 出车订单 | 例如先送红车再送蓝车,展示当前与下一单;玩家同时考虑当前任务和下一批所需道路方向 | 优先候选。颜色将成为规则;需要重新设计可解的关卡,尚无玩法验证 |
|
||||
| 更清楚的旋转目标 | 例如三次内得金牌,转动消耗可见标记,允许撤销;让当前收益与后续转动成本有关联 | 与订单结合更值得测试,单独强化已有转数显示可能仍不足 |
|
||||
| 一个局部道岔 | 选择接通哪一条路,并限制切换次数,形成更直观的局部取舍 | 备选方向,需要验证额外控件是否值得其复杂度 |
|
||||
|
||||
讨论中的首选小实验是“订单+旋转目标”:8~10 辆车、两种颜色,同时展示当前和下一单,沿用错峰发车,并增加撤销操作。关卡刻意设置一种情况:眼前最容易完成的选择,会让下一批多花一次转动。
|
||||
|
||||
这些属于恢复研发时的候选假设,**不是已采纳的下一阶段开发计划**。重新评估时可观察:玩家能否说明自己的选择理由,是否会主动考虑下一批,是否能理解转错的代价,以及通关后是否愿意重试更少转数的解。
|
||||
|
||||
## 7. 恢复研究时的入口
|
||||
|
||||
- [转盘发车 · 六角 Demo](http://localhost:4173/labs/car-loop/index.html?mode=batch&kind=hex)
|
||||
- [转盘发车 · 方格 Demo](http://localhost:4173/labs/car-loop/index.html?mode=batch&kind=square)
|
||||
- [Lab 使用说明](../labs/car-loop/README.md),[早期视觉适配记录](../labs/car-loop/design.md)
|
||||
- [玩法与关卡规划](../labs/car-loop/batch.js):当前朝向放行、双向旋转搜索、样本种子。
|
||||
- [完整行程调度](../labs/car-loop/schedule.js),[出盘与车库轨迹](../labs/car-loop/routes.js)。
|
||||
- [模型与求解](../labs/car-loop/model.js),[自由模式实时交通](../labs/car-loop/motion.js),[界面与渲染](../labs/car-loop/app.js)。
|
||||
- [模型、交通与调度测试](../tests/car-loop.test.js),[批次关卡测试](../tests/car-loop-batch.test.js),[真实应用帧循环测试](../tests/car-loop-app.test.js)。
|
||||
|
||||
启动:在项目根目录运行 `npm run dev`。转盘发车模式的专项验证:`node --test tests/car-loop.test.js tests/car-loop-batch.test.js tests/car-loop-app.test.js`。
|
||||
Reference in New Issue
Block a user