這篇在講什麼

除了梯子之外,《Endless End》還需要另一種垂直移動工具:升降梯。這篇在整理我怎麼拆它的需求、控制責任怎麼分,以及初始位置怎麼根據 checkpoint 決定。

升降梯需要解決哪些事

我當時先列了三個核心需求:

  1. 玩家站上平台一小段時間後,升降梯自動啟動
  2. 升降梯能把玩家帶到上一層或下一層
  3. 升降梯初始化時,要停在比較接近玩家最近 checkpoint 的那一層

第三點很重要,因為這個關卡的垂直路徑不是自由移動型。如果升降梯一開始停在錯層,玩家重生後可能會失去合理的返回路線。

物件結構怎麼拆

一套完整的升降梯大致包含:

  • 升降平台本體
  • 上層停靠點
  • 下層停靠點
  • 視覺表現物件

而升降梯控制器本身需要知道的,主要是:

  • 目前所在樓層
  • 上下目標位置
  • 是否正在移動
  • 速度與初始化參數

我把控制責任分成玩家端和升降梯端

如果把所有邏輯都堆在同一個腳本裡,很快就會亂掉。所以我最後把責任拆成兩邊:

  • 玩家控制器負責判斷自己是否站在升降梯上,什麼時候觸發
  • 升降梯控制器負責實際移動平台,並在移動期間把玩家一起帶走

這樣做之後,行為邊界會比較清楚。

玩家端負責什麼

玩家控制器會持續往下做檢查,只要命中升降梯 layer,就進一步判斷:

  • 升降梯現在是不是空閒狀態
  • 玩家是否真的站穩在平台上

條件成立後,再呼叫升降梯控制器開始動作。

這樣的好處是,觸發條件仍然由角色主導,不會變成場景物件自己硬接管玩家太多狀態。

升降梯端負責什麼

升降梯控制器負責真正在平台上發生的流程:

  1. 啟動時先把玩家 x 對齊平台
  2. 判斷這次目標樓層是上層還是下層
  3. 進入移動狀態,避免重複觸發
  4. 在移動過程中同步更新玩家位置
  5. 到達目標樓層後結束移動並更新目前樓層資訊

當時我是用 coroutine 來跑這段流程:

初始位置怎麼決定

因為這不是可呼叫式電梯,所以初始位置必須合理。

我的做法是根據玩家最近一次使用的 checkpoint,來推斷升降梯應該停在上層還是下層:

  • 如果最近重生點在上方,就讓升降梯初始化在上層
  • 如果最近重生點在下方,就初始化在下層

這樣玩家重生後,至少會保有一條成立的回程路線。

這套做法的優點與後續問題

這版的優點很明確:

  • 玩家端和場景端責任分得清楚
  • 自動啟動的節奏符合關卡需求
  • checkpoint 導向的初始化能避免明顯卡關

但後來我也記下幾個問題:

  • 玩家和平台之間仍然有一些互相依賴
  • coroutine 位移有時會讓手感略微發抖
  • 如果之後要做更複雜的電梯系統,現在這版抽象程度還不夠

我自己的整理

升降梯這種機制的重點,不只是平台會動,而是整個「誰判斷觸發、誰負責位移、誰持有狀態」要分清楚。

一旦這三件事混在一起,後面要改就會很痛苦。

先記住的重點

  • 升降梯和梯子的差別,在於前者是場景主導的移動
  • 玩家端負責觸發,升降梯端負責位移,責任要分開
  • 初始位置要考慮 checkpoint,不然容易出現回程斷裂
  • 如果平台位移手感不穩,之後要優先檢查同步與更新時機