這篇在講什麼
除了梯子之外,《Endless End》還需要另一種垂直移動工具:升降梯。這篇在整理我怎麼拆它的需求、控制責任怎麼分,以及初始位置怎麼根據 checkpoint 決定。
升降梯需要解決哪些事
我當時先列了三個核心需求:
- 玩家站上平台一小段時間後,升降梯自動啟動
- 升降梯能把玩家帶到上一層或下一層
- 升降梯初始化時,要停在比較接近玩家最近 checkpoint 的那一層
第三點很重要,因為這個關卡的垂直路徑不是自由移動型。如果升降梯一開始停在錯層,玩家重生後可能會失去合理的返回路線。
物件結構怎麼拆
一套完整的升降梯大致包含:
- 升降平台本體
- 上層停靠點
- 下層停靠點
- 視覺表現物件

而升降梯控制器本身需要知道的,主要是:
- 目前所在樓層
- 上下目標位置
- 是否正在移動
- 速度與初始化參數

我把控制責任分成玩家端和升降梯端
如果把所有邏輯都堆在同一個腳本裡,很快就會亂掉。所以我最後把責任拆成兩邊:
- 玩家控制器負責判斷自己是否站在升降梯上,什麼時候觸發
- 升降梯控制器負責實際移動平台,並在移動期間把玩家一起帶走
這樣做之後,行為邊界會比較清楚。
玩家端負責什麼
玩家控制器會持續往下做檢查,只要命中升降梯 layer,就進一步判斷:
- 升降梯現在是不是空閒狀態
- 玩家是否真的站穩在平台上
條件成立後,再呼叫升降梯控制器開始動作。

這樣的好處是,觸發條件仍然由角色主導,不會變成場景物件自己硬接管玩家太多狀態。
升降梯端負責什麼
升降梯控制器負責真正在平台上發生的流程:
- 啟動時先把玩家
x對齊平台 - 判斷這次目標樓層是上層還是下層
- 進入移動狀態,避免重複觸發
- 在移動過程中同步更新玩家位置
- 到達目標樓層後結束移動並更新目前樓層資訊
當時我是用 coroutine 來跑這段流程:

初始位置怎麼決定
因為這不是可呼叫式電梯,所以初始位置必須合理。
我的做法是根據玩家最近一次使用的 checkpoint,來推斷升降梯應該停在上層還是下層:
- 如果最近重生點在上方,就讓升降梯初始化在上層
- 如果最近重生點在下方,就初始化在下層
這樣玩家重生後,至少會保有一條成立的回程路線。

這套做法的優點與後續問題
這版的優點很明確:
- 玩家端和場景端責任分得清楚
- 自動啟動的節奏符合關卡需求
- checkpoint 導向的初始化能避免明顯卡關
但後來我也記下幾個問題:
- 玩家和平台之間仍然有一些互相依賴
- coroutine 位移有時會讓手感略微發抖
- 如果之後要做更複雜的電梯系統,現在這版抽象程度還不夠
我自己的整理
升降梯這種機制的重點,不只是平台會動,而是整個「誰判斷觸發、誰負責位移、誰持有狀態」要分清楚。
一旦這三件事混在一起,後面要改就會很痛苦。
先記住的重點
- 升降梯和梯子的差別,在於前者是場景主導的移動
- 玩家端負責觸發,升降梯端負責位移,責任要分開
- 初始位置要考慮 checkpoint,不然容易出現回程斷裂
- 如果平台位移手感不穩,之後要優先檢查同步與更新時機