低多邊形賽車遊戲 —— 直接在瀏覽器裡玩一場（或自己動手做）

低多邊形賽車遊戲，指的是幾何刻意做粗的賽車遊戲：平面著色的三角形、沒有法線貼圖、沒有高頻紋理細節。這個限制不是你得忍受的缺陷，而是讓遊戲在高速下成立的關鍵。車子幾秒內跑完四百公尺直線時，你的眼睛根本分辨不出輪圈輻條。它讀的是輪廓、面片明暗，還有景物掠過的速率。低多邊形幾何留給算圖器的餘裕，就是用來讓這些線索保持滑順。

這頁會談真正把好的低多邊形賽車和爛的區分開來的東西，然後直接放一個低多邊形世界在你面前，你現在就能在瀏覽器裡走過去。接下來會帶你在 3D 遊戲建構器裡做自己的賽道：在網格上鋪路、擺會當作速度提示的物件、把圈繞起來。不用下載，不用裝引擎。

低多邊形為什麼適合賽車

核心理由是知覺上的。時速 200 公里時，一片平面著色的面片掃過畫面，讀起來就是移動。帶細緻細節的貼圖表面讀起來是雜訊，因為貼圖縮小的速度比 mip 鏈能解析的還快。低多邊形直接繞過這件事：面片更少、更大，別名問題變小的同時，畫面預算還變大。你不再跟閃爍纏鬥，開始專心賣速度感。

第二個理由是算術。一段賽道用 2,000 個三角形而不是 40,000 個三角形建模，不只是畫得快。它讓你在撞到幀數上限之前，能塞進更多路段、更多景物、更多對手。在賽車遊戲裡，幀時間不是舒適度問題。它是輸入延遲。每一毫秒的 GPU 時間，就是玩家看到彎道跟車子回應修正之間的一毫秒。

這就是為什麼低多邊形賽車遊戲通常在中低階硬體上、甚至瀏覽器分頁裡就跑得動。算圖成本主要來自繪製呼叫和填充率，不是三角形吞吐量，所以一個積極做視錐剔除的低多邊形場景，在內顯上能以 60 fps 待在 16.6 ms 的預算內。這種風格不是弱硬體的替代方案。它是一個把硬體擋在一邊、別礙事的決定。

平面著色與動態感的判讀

平面著色讓每個三角形只有一個法線，所以每個面片只有一個亮度值。鏡頭平移時，這些值一格一格地跳。眼睛把這些跳動讀成速度訊號，就像低幀率的頻閃會讓輪子看起來在轉一樣。在平滑著色的表面上，這個訊號被抹進漸層裡，動態感就變弱。

三角形預算實際上花在哪裡

低多邊形賽車裡，車子很少是貴的那個物件。賽道才是。一條 5 公里、切成 100 公尺一段並做剔除的賽道，可見集合是有界的；一整塊 5 公里的網格就不是。把賽道按段編預算，讓剔除去做工。車子可以吃 6,000 到 12,000 個三角形；單一路段不行。

好的低多邊形賽車需要什麼

第一個限制是高速下的賽道可讀性。彎道必須在玩家到達之前就看懂。這代表路面與路外要有視覺區隔、路帶兩側的邊緣處理要一致、頂點要有清楚的提示。如果路面和路肩共用同一個明度與色相，玩家會直到進彎了才讀出那是彎。路面與環境之間的明度對比，比柏油上的紋理細節重要得多。

第二個限制是能賣出速度感的地平線。空蕩蕩的平坦地平線傳達不了任何速度資訊。你需要按已知間隔排列的物件——護欄、標誌、電桿、稜線面片——玩家才有速率參照。沿直線大致等距散開，然後讓間距在彎中壓縮。眼睛會把壓縮讀成減速、把展開讀成加速，即使速度值根本沒變。

第三個限制是鏡頭永遠不能弄丟路。追尾鏡頭需要隨速度縮放的前視距離、一個讓路帶在車底下維持可見的高度，還有一個跟著車頭轉、而不是硬切過去的偏航角。偏航角一硬切，世界就像被甩了一下，玩家會失去空間感。帶阻尼的偏航加上短時間常數——反應夠快但不是瞬間——就能把路穩穩留在畫面裡。

• 路面與路外的明度區隔路帶和周邊地形的明度差要大到讓邊緣一眼就看得出。拿不準的話，把地形壓暗，而不是把路面提亮。
• 固定間隔的速度提示物件等距排列，玩家才有速率參照。它們在彎中看起來的壓縮，就是速度感。
• 隨速度縮放的前視距離前視距離要隨速度變大；不這樣做的話，玩家高速時會跑到畫面外。
• 阻尼偏航的鏡頭偏航跟著跑，路才穩。硬切偏航是讓一條好賽道瞬間變得看不懂的最快方法。

現在就進這個世界走一圈

這頁嵌入的可玩世界，是我們今天能放進瀏覽器裡、最接近一條賽道的東西。它是低多邊形、平面著色，而且是要讓你走過去，不是用看的。用移動控制逛這個空間；幾何刻意做粗，好讓幀率維持在足以讀出動態、而不是只看到一個場景的水準。

移動時可以注意這些：地面平面上的面片在你經過時會以不同角度吃到光，而那些角度變化就是動態線索。地平線是有東西的，不是空的，所以你有東西可以參照。試一段長直線再進一個彎，注意你的速度感怎麼變，即使移動速度根本沒動。那就是地平線在發揮作用。

這個世界是示範空間，不是完成的賽道。它沒有計時器，也沒有對手。它的用途是展示低多邊形的判讀在你實際硬體上的即時瀏覽器工作階段裡怎麼表現——而對瀏覽器遊戲來說，那是唯一有意義的基準。

做一條你自己的賽道

在 3D 遊戲建構器裡做賽道，是把幾何擺到網格上，不是雕刻網格。你在世界單位裡工作，網格給你一致的尺度：一格等於一個已知距離，所以 20 格的直線不管誰來做都是固定長度。先鋪路帶，再擺物件，然後設生成點、把圈繞起來。

要小心的失敗模式是：在編輯器裡看得懂、跑起來卻看不懂的賽道。先做一段直線，把鏡頭移到駕駛視線高度，跑一遍，再繼續做。如果直線末端的彎從直線起點就讀不出來，先修明度對比或物件擺放，別急著加賽道。修一段比修二十段便宜。

低多邊形車輛與素材

車子和物件可以從兩個方向來：匯入現成的低多邊形素材組，或生成一組符合你賽道風格的。真正要管的限制是面片密度的一致性。一輛用 12,000 個三角形建模的車，丟進由 200 三角形路段組成的賽道，看起來就是不對，因為兩個物件解析細節的尺度不同。要嘛密度對齊，要嘛著色方式對齊，最好兩個都對。

Agent Sprite Forge 會生成精靈表與素材組，當你需要一整組視覺語彙一致的車與物件、而不是一堆各自下載來的模型時，這很有用。如果要生成，就把車和路邊物件在同一次生成裡一起做出來，色盤和面片密度才對得起來。生成過程分次進行，是賽道看起來像拼裝、而不是設計過的最常見原因。

The Cyclops' Island 是工作室素材裡低多邊形世界的實作範例：它示範了當每個物件共用同一套著色決定時，一個一致的低多邊形環境怎麼撐得住。動手做自己的素材組之前，可以拿它當色盤與面片密度的參考。

• 面片密度對齊讓車輛在每單位可見表面積上的三角形數，跟賽道路段維持在同一個數量級。密度落差太大，讀起來就是風格壞掉了。
• 一組素材一個色盤車和物件從同一個色盤生成。事後再加第二個色盤，通常是賽道看起來不搭的元凶。
• 全場平面著色素材組裡每個物件都用平面著色。一個平滑著色的物件擺在平面著色的場景裡，一眼就看得出來，而且會破壞動態判讀。
• 先重用，再建模一個護欄模型轉個角度、換個顏色，就夠覆蓋大半條賽道。獨特網格越少，繪製呼叫越少，幀時間越好。

走進它所屬的那個世界

精靈是沒有地方站的角色。最後這一步是別人沒給的：把你剛做好的精靈表，放進一個有人能走動的世界裡——一座小島、一顆行星、一個下雨的街角。這個網站上每個世界都是從一段文字描述做出來，然後發佈成一個你能玩的頁面。

常見問題