1% 的重量：遊戲工程師的視角切換

在小型遊戲工作室工作時，我對 3A 級開發抱有一種想像，以為那裡有更深奧的技術架構與極致的專業分工。後來真的進去了，才發現在每天打開 IDE 的那個個人範圍裡，工作內容其實與過去大同小異。我們依然在解 Bug、寫邏輯、優化性能，這份手感並沒有因為專案規模的擴大而產生本質上的改變。

但有一件事確實不同了：玩家的規模。過去的專案，玩家數量頂多是個萬字頭，後來進了 3A，量級直接跳到百萬。我花了一段時間才意識到，這個數字不只是 KPI 的差距，它會改變每一個技術決策背後的重量。

關於 Bug 的認知落差

專案收尾的前幾個月，我的工作幾乎被那些重現率極低、滿足特定條件才會觸發的 Bug 所佔據，大約 100 次才會發生 1 次。

按過去的經驗，這類邊緣案例通常丟進優先級最低的清單裡。我向主管抱怨這份工作缺乏效率，坦白說帶著一點傲慢。我認為相較於處理這種低機率的雜事，去優化現有的功能才是更有工程師價值的事。

主管只說了一句：「1% 的機率，代表當我們有 100 萬玩家時，會有 1 萬人遇到它。」

重新審視「重量」

那瞬間，我感到一陣慚愧。

仔細想，我的邏輯本身並沒有錯。在資源有限的環境下，以機率排序優先級是理性的。但主管那句話改變的不是我的邏輯，而是我的視角。從「這個 Bug 發生的機率是多少」，切換到「有多少人正在承受這個 Bug」。數字一樣，意義完全不同。

對那 1 萬個遭遇到 Bug 的玩家而言，這就是他們體驗的 100%。

這 1% 的重量不在於它是大是小，而是提醒我：不要把任何玩家的體驗，當成可以被犧牲的統計餘數。

視角切換

那之後，我的心態確實變了一點。不是說我變得完美主義，也不是說每個低機率問題都值得無限投入，資源限制的現實沒有消失。

但我開始在修這類 Bug 的時候，腦袋裡會多出現一張臉。不是抽象的「玩家」，而是某個剛好走到那個觸發條件、看到畫面卡住的人。這張臉讓我不那麼容易說出「機率這麼低，應該沒關係」。

這大概是我從那幾個月學到的最重要的東西。

有時候我會想，這個切換，其實就是遊戲工程師這個職業真正難的地方。我們常以為自己的職責是讓功能運作起來，但功能能跑，和設計者的意圖完整抵達玩家，其實是兩件不同的事。技術的專業，不只在於你寫出了多複雜的系統，更在於你是否願意為了那一萬個人，在細節上堅持到底。

進入百萬玩家的規模之後，我才真正理解這件事的重量。我的責任，不只是能跑的程式，而是一個完整的體驗。