一隻喜鵲正在夜間博物館行竊,唯一能抓到她的就是光線。守夜人的燈籠是真正會投射陰影的 Light2D 光錐;展示櫃與柱子則帶有 LightOccluder2D 多邊形;而偵測判定正是對同一組幾何形狀發射射線。你所看到的陰影範圍,實際上就是潛行狀態本身——躲到能遮擋光線的展示櫃後方,同時也就擋住了守衛的視線。
方向鍵 / WASD 移動 · Shift 潛行 · E 撬開展示櫃 · X 振翅衝刺(守衛會聽見)· P 暫停 · M 減少動態效果。在被抓三次前,將五顆寶石帶回巢穴。
在寫下任何一行程式碼之前,已先產出三張概念美術稿:夜間關鍵美術圖、喜鵲角色設定表,以及博物館道具標示板。這些美術稿上所標示的每一項物件,都是最終遊戲中真實製作完成的資產——24 列,無一遺漏。關鍵美術圖旁的引擎畫面是實際運行的成品,而非模擬示意圖。


整個盜寶行動最初以灰色矩形進行測試——巡邏路線、光錐幾何、遮蔽物射線判定、撬開動作的按住機制、搬運動作,以及第三顆寶石到手後第三名守衛的出現、黎明重新開始機制。共進行了三輪灰盒測試;第一輪失敗的原因是自動導航停在距展示櫃 118 像素處,超出 78 像素的撬開判定範圍,修正方式是導向展示櫃中心並於 62 像素處停止。直到此時才開始製作任何美術資產。


這件作品中沒有手繪精靈。喜鵲與守衛是以固定 64 px/公尺的比例在 Blender 中建模、綁定並渲染的,而且每一個影格都經過渲染
兩次:一次用於色彩,另一次則透過相機空間法線著色器渲染。引擎將這兩部分都輸入到 CanvasTexture,因此掃過的燈籠確實會重新照亮鳥的背部與拼花地板的斜角。方向絕不會被鏡像處理—— flip_h 不會重新反轉法線貼圖的 X 通道,所以四個朝向都是真正各自渲染出來的。
守衛的步態並非手動擺出:CMU 片段 02_01 透過平台的動作捕捉套件重新定位到守衛骨架上,並取樣為每個方向六個影格,長時間靜止片段 15_04 則被擷取作為待機動作。提燈手臂是唯一經過人工處理的例外——夜間守衛是提著燈籠,而不是像自由的手臂那樣揮動它,因此該手臂的烘焙曲線被移除並手動設定,同時動作捕捉仍驅動全身其餘部分。


提著的光源漂浮在燈籠附近,而不是 開啟 這是本實驗室早已為之付出代價的一類缺陷。此處在每個方向的每個影格中,都會在 Blender 中量測燈籠玻璃像素的位置並寫入 char.json;在引擎中,暖色光暈
以及偵測錐體 每一影格都會重新對齊到該錨點。渲染器繪製的錐體與偵測測試投射的射線都從同一點出發——不存在第二個看不見的幾何結構。
實驗室在此主機的軟體渲染器上使用 Playwright 進行審核——沒有 GPU——所以下方的畫面更新率是底線,而非上限。難看的資料列也包含在內。
| 量測方式 | 值 |
|---|---|
| 匯出負載(pck) | 1.67 MB |
| 引擎執行環境(wasm,固定) | 33.7 MB |
| 負載中的原創美術素材 | 1.29 MB |
| 音訊音軌檔 | 0.46 MB |
| 雛型測試回合 | 3(r1 失敗:自動駕駛停在撬鎖範圍外) |
| 美術稽核回合 | 7——r1-r5 找到 10 個視覺缺陷,r6 乾淨,r7 進行確認 |
| 已渲染的精靈影格 | 152(76 個漫反射 + 76 個相機空間法線) |
| 使用的動作捕捉片段 | CMU 02_01 行走、15_04 待機(守衛);喜鵲為程序生成 |
| 自動測試流程 | 5/5 寶石,於 t=126 秒獲勝 |
| 審核中的畫面更新率 | 軟體渲染器,無 GPU——每秒僅有一小部分畫面 |
| 已知環境瑕疵 | 軟體光柵化器在連續遊玩約 5 分鐘後停止呈現世界畫布;HUD 則不受影響。已在第一輪調查過,並非場景圖缺陷。 |
每位守衛的燈籠都是啟用陰影的紋理遮罩錐形 PointLight2D。展示櫃與立柱是 LightOccluder2D——你看到的陰影正是藏身之處。
每個影格都透過 CanvasTexture 附帶對應的相機空間法線通道,因此鳥、守衛、鑲木地板與展示櫃的斜角都會受到燈籠光影響。
「被照亮」代表:位於錐角內、範圍內,且在遮蔽物圖層上有一條未受阻擋的射線——該射線是從繪製的燈籠玻璃處投射出的。
拼花地板、地毯走道與大理石邊框磚,每一種都在 Blender 中以俯視角渲染,並附有真實的浮雕法線貼圖。
守衛巡邏路徑與自我測試自動駕駛路徑使用相同的網格,該網格是根據實際的碰撞體外形建構的。
衝刺與抓捕時的羽毛爆散效果,以及在天窗月光中飄動的塵埃微粒。