27 posts tagged with "Philosophy"

前一陣子在 GitHub 上找到有興趣的專案，放到口袋清單之後，終於在上週 (2025-10-22) 忍不住把它拿出來玩了，這裡紀錄一下到目前為止 (2025-11-02) 的進度。

來自 Global Illumination, Inc. 的 Biomes​

Biomes 是一個（理論上）能夠在瀏覽器執行的開源方塊沙盒多人連線角色扮演遊戲 (MMORPG)。

為什麼我說「理論上」呢？因為這個專案已經葛屁兩年了，在親眼看到以前說不準它的實際情況。

並且專案停滯的時間點剛好是 OpenAI 收購 Global Illumination （Biomes 背後的公司團隊） 的時間點¹。

動機​

不熟悉我的讀者可能不理解我沒事幹麻去撿一個死兩年專案的屍體，這些是我曾經寫過相關的文章：

• 我喜歡 Minecraft，不過可能不是一般人認知的那種
• 關於我想用 ECS 實作 Minecraft 以分散式架構運行並在其中用增強式學習訓練完全視覺化之遞迴布林類神經網路以產出二維條碼人造語言那檔事
• 從 Goxel 到 Blender (Voxel art → 綁人物模型骨架)
• Project Malmo 簡介
• MineRL 挑戰 2021 - 競賽流程（翻譯）
• MineRL 挑戰 2021 - 比賽規則（翻譯）
• 一種利用資訊熵獎勵智能體構建方塊世界(Minecraft)的方法

作為一個開源 Minecraft 愛好者（？），我一直都有在關注開源軟體圈中與 Minecraft 的發展，特別是物色一個適合的目標 fork 它改成我想要的樣子。

Biomes 乍看之下完成度很高：

而且是使用貼近 Web 的技術（Typescript, WASM...）實做，對我而言理解的門檻會低得多（比起 C++ 實做的 Minetest）。

專案的第一印象​

• https://github.com/ill-inc/biomes-game
  • 2.6k ⭐

該專案使用異構單體庫結構，也就是：

• 單庫(Monorepo)：使用一個 Git 庫存放所有模組與程式碼。
• 異構(Polyglot)：多個模組涉及不同的程式語言與技術棧(Techstack)。
• 單體(Monolithic)：所有程式碼會組裝成單一的 Web 服務。

並且透過 Bazel 這個工具來處理複雜的仰賴鏈，接著在外面套一層 Python 腳本，所有操作都需要透過 b.py 完成。

雖然試著用 Bazel 把專案跑起來，但是似乎是工具版本不符的原因，整個過程並不順利。加上個人不是很喜歡這種「全家桶」結構，因此下一步就是開始拆專案。

拆拆拆​

一些比較大型模組會有自己獨立的 README.md：

find . -name README.md
./README.md
./voxeloo/README.md
./docs/README.md
./src/client/README.md
./src/shared/README.md
./src/server/README.md
./src/server/bob/README.md
./src/server/shared/README.md
./src/benchmarks/README.md
./src/galois/README.md
./src/galois/js/README.md
./.githooks/README.md
./scripts/tsconfig-replace-paths/README.md
./.devcontainer/README.md

接著是找到外部仰賴最少，即仰賴鏈最上游的模組。

docs​

第一個抽出的模組是網頁文件：

https://github.com/FlySkyPie/biomes-docs

它不仰賴別人的模組也沒有被仰賴，並且有自己獨立的 package.json，很容易抽出。

從 yarn 轉換成 pnpm、修復幽靈仰賴；並且處理的圖片都儲存在 git LFS 的問題之後就能正常運作了。

geometry.hpp 和 light_kernel.hpp​

接下來的兩個模組則是用 Python 生成 .hpp 函式庫：

• https://github.com/FlySkyPie/biomes-voxeloo-geometry
• https://github.com/FlySkyPie/biomes-voxeloo-light-kernelry

其中一個還使用了 Jinja2 — 基於 Python 的樣板引擎/函式庫。

voxeloo​

• https://github.com/FlySkyPie/biomes-voxeloo

接著是名為 voxeloo 的組件，使用了前述程序化生成的 .hpp。

在原本使用 Bazel 處理的仰賴鏈中，還包含了一些指向 GitHub 的外部函式庫，例如：catch2、eigen、robin-hood-hashing、zstd...。

在這方面我使用 CPM.cmake 來處理仰賴關係，只要目標有撰寫良好的 CMakeLists.txt，就可以把 C++ 專案當成套件拉進專案使用。

第三方函式庫​

• https://github.com/FlySkyPie/OpenSimplexNoise

OpenSimplexNoise 原本的 Git Repo 沒有 CMakeLists.txt，所以我 fork 之後加上 CMakeLists.txt。

• https://github.com/FlySkyPie/tomasakeninemoeller

opttritri.h 和 tribox3.h 這兩個檔案原本是直接放在專案內的，我就稍微朔源了一下然後一樣加上 CMakeLists.txt。

voxeloo Python 榜定​

• https://github.com/FlySkyPie/biomes-voxeloo-py

Biomes 對 voxeloo 實做了兩種綁定/交叉編譯，將其從 C++ 專案轉換成其他語言的函式庫，其中一個是 Python，並且透過 pybind11 實現。

我使用 scikit-build 作為 Python 的建置後端 (Build Backend) 將奇打包成一個 Python 庫 (Python Wheel)，並且補上型別資訊 (Stub)。

我曾經有一個同事，是動畫師之類的，雖然不同部門、不算熟、也沒什麼深入聊過，但是我認為我從他身上學到一個很重要的概念—「演出」。

他經常會用「演出」來形容一段角色動畫，也經常在做動畫前先自己用肢體表現一次，呈現多種角色動作的形式。當下我其實沒有太多想法，直到後來我才隱約知道他說的「演出」是什麼意思。

這是當下我知道的「演出」：

後來我看到了：

這是透過動作捕捉器，直接將人類演員的肢體動作錄製成能在遊戲內使用的動畫影格，動作更自然也不用讓動畫師手工調整。

接著我看到了：

很多短影音往往包含了有趣的上下文與故事，但是仔細觀察會發現這個影片中的角色的動作跟前一個動作捕捉演員有著接近的神韻：一些明顯且誇大的神情或肢體「演出」。

岔開一下話題，這是一個我很享受的 Factorio 影片：

然後這是那個 Factorio 影片的幕後花絮：

可以發現影片的整體節奏並不像正片一樣緊湊，作者的情緒起伏也沒這麼浮誇。

作者也表示，劇本是模仿 3Blue1Brown 的緒事風格「事情可能怎麼被發現」，而刻意營造出「他自己發現」的氛圍。

簡單來說，「演出」一種精細設計的虛假呈現；是一種謊言，如果任何戲劇作品出現不現實的情節，那十之八九是一種「演出」。

我不太記得孔子在國文課本裡說了什麼，但是我記得賣油翁的一句：

「但手熟爾」，只是手藝熟練罷了

真正和這句話發生共鳴來自於我高職在練習證照的學科與術科；以及我那算到幾乎快爛掉的基本電學習題的經歷，並且真正發酵是我開始使用 Linux 幾年之後，那幾個原本在學科考古題裡面的指令已經內化成我日常生活的一部分。

程式語言是手段；不是目標，事實是軟體工程師其實經常需要根據需求學習新的語言，原因可能是為了維護舊專案或是針對特定問題的語言特性...等等。不過我認為依然需要選擇一門程式語言當作「母語」，必須是成為肌肉記憶最後帶進棺材的一部分，它可以成為學習其他語言時進行典範 (Paradigm) 參考的基準¹。

Javascript/Typescript 是我選擇作為「母語」的語言，我會持續學習它的歷史、它的生態、它的語法，當我試著重構一些老專案的時候，我可以看到過去的開發者如何在 Promise 尚未納入規範就開始使用 Promise²；當我試著在 3DS 上建立 Javscript Runtime ³，我窺見了 Node.js 的工具鏈以及 Runtime 和 Engine 的差別...

我決定向賣油翁學習，精練一門手藝這件事甚至早在 ChatGPT 橫空出世以前。前一陣子在公司的壓力之下我被迫嘗試使用 Cursor，然而實際上它非常的不好使，有一些特定的任務我要花大量的時間撰寫提示詞來約束它。

「那是你提示詞下的不好」「你應該要多搭配一些規則」...有些人或許會這樣說，不過我想那些「有些人」的心中沒有賣油翁；它們或許本來就討厭寫程式，寫提示詞對它們而言是一種解放。不過對我而言，與其「節省時間」寫提示詞，「浪費時間」打磨我的手藝，反而才是我認為正確的道路 — 賣油翁的道路。

也不是完全不能用 LLM 寫程式，但是老實說用例十分有限：

• 如果我不熟悉語言、不熟悉當下的開發主題或領域
  • 我無從驗證 LLM 生成內容的好壞或是有效與否，因此不宜用 LLM。
• 如果我熟悉語言、當下的開發主題或領域，但是 LLM 很難命中我的預期解法
  • 需要花大量的時間琢磨提示詞，但是同樣的時間我自己寫更快，因此不宜用 LLM。
• 如果我熟悉語言、當下的開發主題或領域，並且 LLM 很來電，很快就命中我的預期解法。
  • 節省手工開發時間，採用。

LLM 生成文件的能力似乎被不少工程師視作「自動補全文件」的解方，畢竟很多工程師都很懶得寫文件，但是我認為「作為 LLM context input 的文件」跟「給人類閱讀的文件」應該嚴格區分，因為 LLM 能夠很輕易的產生或更新大量的文件，但是人類的認知負荷容量並不會因此提昇，每個人能夠處理的資訊量依然是固定的，大量的甚至可能灌水的生成式內容反而會大幅度的消耗人類的處理量能並且提高認知負荷。

即便機械手臂在製造業能夠造成產能的提昇，實際上工廠依然是嚴格分離機械手臂和人類的工作區以免發生事故，只有特殊處理的「協作型機械手臂」能夠和人類直接處於同一個空間工作，這些協作型機械手臂透過特別的反饋來避免傷害工作人員。我認為 LLM 應該也有相同的問題，只是由比較不明顯的「精神傷害」取代傳統的「物理傷害」，因此不應該讓 LLM 的生成式內容「直接侵害人類的工作空間」。

拖鞋普遍給人的觀感都是隨便、不正式。我其實也這麼認為，不過我試著從反向的角度看這件事。

台灣是四面環海的熱帶/副熱帶氣候，潮濕而且炎熱，硬要套上那種「西裝領帶」來自較為寒冷乾燥地區的文化似乎有點莫名其妙。

有些動物會築巢，巢穴的本質是「溫暖的小窩」，相對於「險惡的自然環境」的淨土，而「家」就是人類的巢穴，更有「家是最後的堡壘」這麼一個概念，是美國人習以為常的概念。私以為台灣以治安良好而聞名，人與人相處的距離十分的近，「家以外是險惡的自然環境」的概念幾乎從台灣人的腦中消失，那麼在「自己的巢穴穿著不那麼有保護機能的拖鞋」似乎也顯得沒這麼奇怪了。

※封面圖是 AI 生成的，沒有任何人類受到跟拍，提示詞在這裡。

「根據 GDPR，你有權將數位足跡從我國的監控系統中消除，並且你提交的申請已經由賽博管理司通過核准。但是根據我國的交互觀測基本法，你在我國停留期間的所有記憶將會被消除，接下來我們將根據交互觀測施行細則第二十條對你執行記憶消除術。」

「道理很簡單，你不想被觀測，那你也不能觀測我們，彼此彼此。」

※關於人工消除記憶的科幻設定可以見：記憶裂痕 Paycheck (2003)

仔細想想，目前的婚姻制度跟現代人價值觀或生活習慣有點脫節了吧？ 應該立法建立不同的契約強度，例如： 婚姻 Education，婚姻 Trial，婚姻 Pro，婚姻 Enterprise（？）

醫院的領藥等待區有一些桌椅，桌子上貼著「禁止飲食」。然後我剛剛看到有個人坐在那邊打開流質食物的罐頭倒進管子開始進食（？）

問：他有違反「禁止飲食」嗎？

工業革命的時候一堆國家燒煤燒得很爽，現在又建立減少溫室氣體的全球秩序來牽制發展中國家； 然後現在是一堆國家收集資料跟訓練 AI 玩得很爽，我就看到時候會不會又建立什麼國際秩序限制發展中國家收集資料跟訓練模型 ._.

說詞我也都想好了：什麼訓練是高耗能產業應該避免啦；被生成式 AI 灌暴的資料之海造成人類原創的資料資料很珍貴，不能隨便蒐集啦；人權數據履歷，模型背後沒有血汗資料標籤員....之類的。

是的，生程式內容現在在我眼裡跟溫室氣體沒兩樣。

這個想法其實去年就有了，只是一直沒有找時間寫下來。

我奶奶葛屁的時候靈堂是放在殯葬管理所，然後單位會根據往生的年紀給予不同的臨時牌位， 舉例來說我奶奶算是高齡壽終正寢，臨時牌位是有紅色緞帶裝飾還有彩色印刷花紋的紙板， 而隔壁的往生者則是黑色緞帶的樸素紙板，隔壁的追思者多數看起來是勞動階級—會拿香煙點香的人， 往生者是因為年少輕狂過了頭還是職業意外我就不得而知了。

總之看到臨時牌位的差異讓我不禁感慨，人葛屁了還要被打成績， 而且我奶奶最後的二十年是受傷需要人照顧的，倒數的五～十年更是人棍一般的狀態； 足不能行、目不能視、口不能嚼、耳不能聞， 還因此被發了紅色緞帶「你好棒棒活到這個歲數」看起來格外諷刺。