鴿舍

合約，與高塔

這件作品始於一份書面美術指導合約，而書面合約是比繪畫更嚴謹的色彩規範：二十種顏色以精確的十六進位碼確立——而由於這是一件 3D 作品——每一種都直接編譯進片段著色器中作為常數陣列，每個面的 UV 只編碼其調色盤索引。Dovecote 中沒有任何色彩貼圖。這也是為何調色盤只存在於一個檔案中的原因：兩份有序清單的副本，就是在新增一項後讓所有索引偏移、並悄悄重繪整座高塔的兩次機會。

書面合約的視覺部分——調色盤、比例、高塔幾何結構

同一座高塔，在引擎中即時呈現

一個證明高塔可解的求解器

時鐘規則存在兩份：一份以 Python 撰寫，用於構建四座高塔並在每座中搜尋出獲勝的旋轉排程；另一份以 Lua 撰寫，在執行階段以固定 1/60 步進運作，以確保已記錄的排程能精確重現。產生器還會記錄其模擬器結束時的精確時鐘與彈簧數值，遊戲則在開機時依這些數值重放 Lua 規則：兩套實作僅僅一致認定某座高塔「獲勝」是不夠的，它們必須在數值上完全一致，否則微小的漂移終將在某層鎖定的瞬間，讓捲揚者站錯扇區的一側。接著，一個刻意採用不同方法的第二套搜尋——對旋轉時間進行反覆深化搜尋，並共享已模擬的前綴——單獨從高塔資料重新推導出一條獲勝路線，機器人便依此在鍵盤上操作。四座高塔，每一輪皆如此。

離線求解器自身的輸出——此面板由重新執行搜尋所產生，因此不可能與實際出貨的高塔資料產生偏差

第三座高塔——旋轉他所站立的樓層，會將他一併帶動

畫面中的一切皆為 Blender 網格模型

本作品中沒有任何引擎內建基本形體出貨。樓層鼓輪、其階梯、塔頂與艙口、風向標、有石牆與海岸邊緣的岬角、鴿群，以及捲揚者本人，全都以腳本在 Blender 中建構，並以 glTF 格式匯出為 Defold 模型元件。捲揚者的臉部是值得特別一提的部分：眼窩已焊接於頭部，但鏡片玻璃與嘴部縫隙是各自獨立的模型，因此他能依計時器眨眼，並在彈簧數值低於四分之一時，睜大鏡片、張開嘴縫——一種僅由兩個網格組合而成、完全沒有骨架的表情。

艙口：他爬出，鴿群隨之升空

第四座高塔——每一層皆需對齊，每層皆有箱子，彈簧偏短

即刻載入特徵

此實驗室旨在證明一款真實引擎製作的遊戲，能在手機使用者失去耐性之前就開始可玩——而一件 3D 作品必須達到與 2D 作品相同的標準。每個負載都以預先壓縮的方式出貨，並在瀏覽器中解壓，因此任何靜態主機都能以最佳方式提供服務。以 Playwright CDP 網路節流測得的首次可玩時間：

總傳輸量 1.48 MB，佔 3.14 MB 套件的一部分——這是本實驗室出貨過最小的負載，且正是這件 3D 作品。這裡沒有任何壓縮花招：完全不出貨任何色彩貼圖。每個面的 UV 編碼的是合約調色盤中的索引，而該調色盤已編譯進片段著色器作為常數陣列，因此整件作品的外觀，僅需二十個 vec3 常數，而非圖集。實驗室自身的標準是在快速 3G 環境下 4 秒內達成首次可玩畫面，而本作品提前約一秒達標——值得明確指出的是，本系列前一件作品是一款攜帶 2048 寬精靈圖集的 2D 作品，卻以 0.3 秒之差未能達標。此數據為在軟體渲染下無頭測試所得，且主機與另一實驗室的渲染器共用，因此真實 GPU 與真實裝置的啟動速度都會比這些數字更快。

真實的引擎功能，靠實測換來