三個我親眼看過業餘遊戲建構走偏的案例，每一個都用留下的爛攤子，教會你正確的設定究竟該長什麼樣子。
錯誤一：相信瀏覽器會乖乖記分
這是最常見、也是最容易避免的錯誤。有人做了一款排行榜遊戲，用 WebSocket 串接多人功能，卻讓用戶端算出最終分數後才 POST 到伺服器，傳入過程完全沒有驗證。我親眼目睹過這種情況——一個無聊的玩家大概花了四分鐘就打開開發者工具，找到網路分頁，開始送出九位數的分數。不是因為他是駭客，而是因為遊戲親手把筆遞給他，還請他自己批改自己的考卷。
解法並不巧妙，只是很繁瑣：絕不信任用戶端，沒有例外。每個動作都要在伺服器端重新驗證，每個物理更新都要跟伺服器認定的真實狀態核對一致，你得承擔狀態來回傳輸的延遲成本，而不是在本機端算好就顯示、祈禱沒人打開檢查工具。這就是為什麼伺服器端授權機制在這裡不是可有可無的附加項目，而是最低標準。一款能透過瀏覽器主控台就被破解的遊戲，會被視同壞掉，嚴重程度跟當機一樣，因為就功能而言，它本來就是壞的。
錯誤二：一個 canvas 元素加一聲嗶，就叫做遊戲
這種遊戲展示起來很漂亮，實際玩九十秒就會破功。一些 CSS 過場動畫、一個碰撞偵測、用正弦波代替一聲拳擊音效——螢幕錄影看起來沒問題，但第一個真正上手玩的人就會說動作感覺不對，卻又說不出為什麼。問題出在物理。自己土法手刻的「如果重疊就彈開」邏輯，永遠沒辦法把質量、摩擦力和碰撞反應調得精準，玩家就算說不出原因，也感覺得到那個落差。
這裡的遊戲建構使用的是真正的引擎渲染：
- 物理與渲染——網頁類遊戲使用 three.js 搭配真正的物理模擬，實驗室裡較重的項目則使用正統的 Unity 6。
- 美術——來自設計總監，而不是現成的素材包。
- 音訊 ——採用取樣樂器音色，而非模擬腳步聲的振盪器充數。
關於這件事並非可有可無的完整論述，請見《真實引擎，真實建構》。
驗證鏈能抓出截圖抓不到的失敗：
- 按下按鍵。
- 檢查分數是否確實有變化。
- 偵測是否有音訊輸出。
聽起來簡單到有點沒用，直到你發現有多少建構結果能完美渲染出第一幀畫面、卻因為某個事件監聽器從未綁定成功而悄悄卡死。一張靜態截圖看不出這件事，但一個必須撐過三輪遊玩測試的驗證器可以。
錯誤三：讓你朋友自己架伺服器才能玩你的遊戲
有趣的多人連線原型常常死在這一步——不是因為遊戲不好玩，而是「先 npm install 伺服器，再設定這三個環境變數」這件事，對一個週二晚上想放鬆的人來說門檻太高了。你做出了好玩的東西，卻把它埋在一份設定指南底下。
單人遊戲在這裡的發布方式跟任何網站一樣——一鍵發布到一個上線中的子網域，不需要額外學一套流程。多人連線之所以不同，是因為需要有一個真正的伺服器程序持續在某處運作，所以這類專案會發布到一個公開的遊玩頁面，代管全部幫你處理好。整件事的重點很單純：「想玩嗎？」應該是一個貼進群組聊天室的網址，而不是一份 README。
從這些對比中得到的啟示
注意到上面三個錯誤都漏掉了什麼嗎：本機雙人對戰。一個鍵盤、兩個人，通常是 WASD 對上方向鍵，手肘還會互撞——這是一種被低估的模式，因為它完全沒有發行上的難題。不需要連結、不需要伺服器，也不需要有個朋友半夜十一點還得點一下什麼東西。只要有人坐在你旁邊，加上三十秒的「不對等等，你是二號玩家，用方向鍵」。
| 本機雙人對戰 | 線上多人連線 | |
|---|---|---|
| 上手流程 | 「不對等等，你是二號玩家，用方向鍵」——三十秒搞定 | 配對機制、空蕩蕩的「等待對手中」畫面 |
| 發行方式 | 零——不需要連結、不需要伺服器、沒有人需要在半夜十一點點什麼東西 | 需要一個公開的遊玩頁面，還要有另一個人同時在線上 |
| 轉化率 | 幾乎是 100%——唯一的門檻是「把椅子轉過來」 | 在等待對手時就放棄了 |
展示區裡的空氣曲棍球與競技場亂鬥類作品，正是靠這一點取勝。
把這三項修正——伺服器端權威判定、真實引擎、代管的公開遊玩頁面——加上本機雙人對戰內建的優勢結合起來，你就能得到這套系統真正支援的完整範圍：
- 單人模式 ——基本款。
- 本機雙人對戰 ——白撿的勝利。
- 線上多人連線 ——設計來撐過一個開著開發者工具、閒到發慌的青少年。
每款遊戲都會收錄進「我的遊戲」庫中，並標示各自的發布狀態，所以你不用翻舊的聊天紀錄去找哪一版才是能用的。而如果你已經打包成 Android 版本，流程會直接接續到上架商店的流程，不必從頭再走一次。
