开发 / ROBLOX
平台在起跳前离开了：一个清楚的移动障碍故事
这是明确虚构的教学故事，讨论停顿、登台与失败后的继续。分别规划周期、角色运输和多个客户端观察检查，不把示意方案当成实际游戏测试。
打开大图 ↗1. 看见了平台，却没有看见时刻表 #
想象一个虚构原型：伊拉走到道路缺口，看见附近的平台，准备跳过去。她转动相机时，平台开始离开。跳跃瞄准的是刚才还有表面的地方。这是分析设计的假设情节，不是我们游戏中的真实经历、玩家评价或已经执行的测试。角色名字只是帮助讨论，不能成为声称收集了玩家数据的依据。
开发者第一个问题不应是玩家为什么慢。近处平台看起来可能可以登上去。写下预期：新手能够区分安全等待、登台窗口和移动状态。如果这些状态看不见，更精准的动画本身仍不能解释规则。障碍与人之间需要清楚的约定，而不是要求提前记住隐藏时间表。
2. 区分登台与运输 #
等待平台、落在平台上、移动中留在表面、走向固定出口，是几项独立任务。把它们全部称为跳跃，会隐藏有用区别。这个故事先研究登台是否容易理解。角色能否可靠随平台移动属于另一项技术问题；空平台的漂亮轨迹不能证明运输已经正确。即使登台提示清楚，也可能仍存在乘坐问题。
小型原型可以规划宽阔等待区、一个平台和出口。先决定玩家是站着乘坐，还是越过移动物体。这里选择登台、乘坐、离开，这是设计意图，不是 Roblox 自动具备的行为。平台走十二 studs 不代表角色需要跳十二 studs；登台间隔要有自己的尺寸与可达性检查。
3. 留下安静观察的地方 #
玩家应当能看完一个周期，而不必站在危险边缘。建议练习等待区为固定的 10 × 10 studs，平台为 8 × 8。这些是之后评价的初始尺寸，不是经过测量的舒适保证。留下转动相机、错过一次发车的空间，避免马上撞到另一个人或移动部件。等待本身不应不断迫使人向前冲。
用地面形状和小地标区分安全区与登台点。观察计划记录玩家停在哪里、是否看见平台回来、是否理解可以等下一次。还没有实际观察时，它们是问题，不能写成所有玩家的行为结论。如果人在理解规则之前就因为站位跌落，需要先处理等待空间，而不是只延长平台时间。
4. 描述整个周期 #
建议四个状态：入口停顿、去往出口、出口停顿、返回。第一张表给出二、三、二、三秒，总计十秒。这是计划时刻表，不是平台已经测出的时间。实现仍需要确认到达点与实际停顿，物体的位置和状态提示也需要一致，不能只凭画面似乎停下就宣布周期正确。
途中到达的人不一定正好等十秒，等待取决于当前阶段。不要无论何时都显示固定的十秒倒计时。先提供看得见的重复和明确终点。以后增加倒计时时，要跟随机制真实状态，而不是独立装饰动画。先单独比较入口停顿，再增加出口停顿，就能分别评价各自作用。
| 状态 | 建议时长 | 玩家任务 | 仍需检查 |
|---|---|---|---|
| 入口停顿 | 2 秒 | 准备登台 | 信号与真实停顿一致 |
| 去往出口 | 3 秒 | 留在平台上 | 运输与客户端观察 |
| 出口停顿 | 2 秒 | 转到固定地面 | 出口可达与视角 |
| 返回 | 3 秒 | 在岸上等下一次 | 返回表面可见 |
5. 提前说明发车 #
入口标记可以有三个状态：等待、可登台、发车。颜色之外增加符号和简短文字，避免只靠一种颜色猜规则。练习计划可以把停顿最后半秒用于提醒；这半秒包含在两秒中，不是秘密额外添加。这个时长仍需在具体相机与设备上评价，不能声称人人都有足够反应时间。
提醒不是保证最后一刻起跳也安全。它说明窗口即将结束，允许哪些动作要由检查过的机制决定。不要让标记自己循环，否则平台已经走了，标记仍可能允许登台。先定义状态对应关系，再实际检查。如果声音补充提醒，也保留无声音时仍可理解的可见提示。
6. 比较不同到达阶段与视角 #
下一段假设情节中，伊拉在平台返回时到达，另一个虚构玩家只看见发车的末尾。两人都应知道在哪里等待、接下来会发生什么。不要只从周期起点检查：玩家会在加载之后、走另一条路回来或恢复尝试时到达。预先挑选的好时机成功登台，并不覆盖其他入口阶段。
规划每个阶段的到达，用普通相机观察。在手机上，调整视角与准备移动同时发生，需要单独检查。不要只按作者熟练键盘操作确定窗口。如果角色或装饰挡住表面，先记录为视野问题。停顿能帮助读懂运动，却不能消除物理遮挡。分开现象才能选择下一项修改。
7. 区分轨迹和物理行为 #
当前官方说明中，Anchored 防止物理作用移动部件，但 CFrame 或 Position 仍可更改。TweenService 插值属性，并不证明角色可靠随表面运输。因此，移动固定平台的原型必须把乘客检查与动画检查分开。物体在编辑视图里走到目标，不代表角色在同一段移动中能安全站住。
另一种架构使用物理组件与 mover constraints，例如 AlignPosition 向目标施力，LinearVelocity 用力维持速度。选择需要考虑连接、方向和实际机制表现，不能简单换一个名字。本故事不提供运输脚本。先与开发者确定架构，再检查站立、起跳、出口和碰撞。不要永久连接角色来掩盖错误；恢复自由移动也属于设计。
打开大图 ↗8. 一个客户端不是整个体验 #
网络物理涉及服务器与客户端。固定部件由服务器拥有；非固定部件可能自动分配模拟所有权。这是项目技术边界，不是要求手动指定所有者就能解决一切。运动架构需要说明状态在哪里确定，以及参与者怎样观察。选择了架构之后，仍要检查角色与平台的相对表现。
计划乘客与岸上观察者两个角色，之后交换位置。对照表面位置、登台信号和离开时刻，本地看起来流畅不能证明两人看见一致。不为这个故事修改别人的游戏或正式项目所有权。把不同表现连同条件交给机制开发者。两人测试不能覆盖所有网络条件，但比只看空平台更有信息。
9. 让失败之后仍有清楚下一步 #
假设故事中伊拉还是失误了。之后应当清楚知道回到哪里、怎样再次尝试，而不是重新猜规则。为原型确定靠近等待区的安全恢复区与独立返回机制。这是设计要求，不是完整存档、重生或检查点系统，也不表示我们已实现任何游戏的恢复逻辑。
检查恢复的人能否观看当前周期，而不是在即将发车的表面上出现。确定一个人失败时共享平台是否继续运行；自动为所有人重启可能打断另一个乘客。整个场景重启另作情况记录。明确失败、再试、新进入规则。角色被送回并不证明进度已经跨会话保存，不能把这两种结果混为一谈。
10. 逐项比较修改 #
建议基准 A 每方向运动三秒，没有停顿。B 只增加入口两秒停顿，周期变成八秒。C 在 B 上增加出口停顿，得到建议十秒。独立 D 回到 B，只增加状态标记。它们是对比计划，不是已经发表的改善结果。不要把所有改变放在一起，再把成功全部归因于某一项。
研究停顿时保持尺寸、相机和运输机制一致。周期变长是新增停顿的后果，不是另行调整速度。记录是否理解下一班、登台决定和失误位置，实际统计尝试而不预填数字。运输故障需要独立修正与检查，提示容易理解不证明物理稳定。如果改变机制，重新标注版本，不能继续当成原先只改停顿的比较。
11. 观察后再填写矩阵 #
第二张表列出条件和问题，实际结果为空。它覆盖各阶段到达、登台、乘客、观察者、手机和恢复。每次记录 A/B/C/D、设备、日期、进入阶段与具体观察。如果确实发生，可以写因为标记被挡住，在返回时尝试登台，这比笼统说玩家不懂更有用；没有发生就不能把例句写成事实。
没有真实尝试数量与清楚成功定义，不计算成功百分比。登台成功、安全乘坐、自主离开是不同结果，应分别记录。保留意外情况，而不是只挑成功例子。执行之前，矩阵仍是计划。阅读文档或比较示意图不算 Roblox、手机或物理运输测试，也不能证明某款游戏已通过。
| 条件 | 问题 | 实际结果 |
|---|---|---|
| 分别在四个阶段进入 | 等待与登台是否容易理解？ | |
| 停顿早期与接近结束登台 | 能看见什么信号，哪里接触？ | |
| 移动表面上站立与跳跃 | 预期运输是否维持？ | |
| 乘客与观察者，然后交换 | 状态和离开时刻一致吗？ | |
| 手机与普通相机 | 准备移动时能看见提示吗？ | |
| 失误与再尝试 | 恢复安全，当前周期清楚吗？ | |
| 第二位乘客与全场景重启 | 规则是否仍对参与者有效？ |
12. 用可检查决定结束故事 #
这个假设故事不以所有人现在都会正确跳跃结束，而以设计决定结束：可见周期、安全等待、登台与出口窗口、对应信号、明确恢复。每一项都需要未来观察结果。把版本说明与空矩阵放在原型资料旁，让其他开发者知道意图和待检查工作，不必猜哪些结论已经完成。
交接时用一句话说明问题，指出单独改变的原因和运动架构。以后实际检查时，只附自己有权使用的图像，不把绘图当成游戏截图。下一步取决于视野、时序或运输观察。清楚障碍给玩家学习规则的机会，也让开发者用具体条件解释失误，而不是许诺任何条件下绝无错误。
原始资料
Roblox Creator Hub — Parts, physical properties and AnchoredRoblox Creator Hub — BasePart Anchored and transform changes
Roblox Creator Hub — TweenService property interpolation
Roblox Creator Hub — Mover constraints
Roblox Creator Hub — Assemblies
Roblox Creator Hub — Network ownership
