第14章 手動重構引擎
手機徹底沒電是在七月十八日凌晨三點。
林浩按了十三次電源鍵，屏幕始終漆黑。他把它放在窗台上，對著月光——月光很亮，但沒用。鈣鈦礦電池需要的是太陽光中的紫外線，月光太弱了。他試了檯燈，試了手電筒，都沒用。那0.0%的電量像一道深淵，把所有未來的可能性都吸了進去。
他站在窗前，看著手裡這塊黑色磚頭。2028年的技術結晶，現在成了一塊廢鐵。小藝休眠了，或者說，死了。在電量歸零的瞬間，那個溫和的女聲，那些精確的數據，那些超越時代的洞察，全都沉默了。
他唯一剩下的，是記憶。是之前看過的那些資料，那些架構圖，那些算法思路。但記憶會模糊，會出錯，會遺漏細節。他不能再問「小藝，這個函數怎麼寫」，不能再問「這個參數的最佳值是多少」，不能再問「如果遇到這個bug該怎麼解」。
他只能靠自己了。
林浩把手機收進抽屜最底層，用幾本書蓋住。然後他坐回電腦前，打開一個空白的文本文檔。
標題：「浩宇1.0引擎重構備忘錄」。
他開始寫，用最樸實的語言，把自己還記得的東西都記下來。
「1. 高並發戰鬥引擎核心思路：事件驅動+協程+無鎖隊列。但2002年沒有協程庫，用狀態機模擬。無鎖隊列用CAS實現，但2002年的C++編譯器不支持原子操作，用互斥鎖+內存屏障替代。」
「2. 網絡同步優化：客戶端預測+服務端矯正。關鍵：狀態快照差分壓縮。算法思路：將遊戲狀態編碼為位圖，只同步變化的部分。壓縮用簡單的遊程編碼（RLE），2002年CPU能承受。」
「3. 物理引擎簡化：2D剛體碰撞，用分離軸定理（SAT）檢測。但《傳奇》是格子移動，不需要連續物理。改為格子碰撞+射線檢測，性能更高。」
「4. 技能系統：用腳本驅動，但2002年沒有好的腳本引擎。改為配置表+硬編碼。每個技能是一個狀態機，有前搖、施法、後搖三個階段。」
「5. AI系統：行為樹，但太複雜。改為有限狀態機（FSM），五個狀態：閒置、追擊、攻擊、逃跑、死亡。」
他寫了三頁。停下來時，天已經蒙蒙亮。窗外有鳥叫聲，清脆的，一聲接一聲。
他看了一眼時間：凌晨五點。他睡了兩個小時，夠了。
阿坤和王磊是早上八點來的。兩人都帶著黑眼圈，但眼神清醒。阿坤背著一個鼓鼓囊囊的書包，裡面是他從學校圖書館借的數學書：《計算幾何》《圖論導論》《數值分析》。王磊提著一個塑膠袋，裡面是二十包泡麵，十根火腿腸，一箱礦泉水。
「這是接下來一周的糧草。」王磊把塑膠袋放在牆角。
「我推演了狀態同步的數學模型。」阿坤拿出草稿紙，上面是密密麻麻的公式，「但有個問題：如果網絡延遲超過300毫秒，預測糾正會導致明顯的畫面抖動。2002年，很多玩家還在用56K貓，延遲可能到500毫秒。」
林浩接過草稿紙看。阿坤的推導很嚴謹，但思路還是傳統的那一套：降低延遲，優化算法。這解決不了根本問題。
「我們換一個思路。」林浩說，「不追求零延遲，而是讓玩家感受不到延遲。」
「怎麼做？」
「客戶端不只做預測，還做預渲染。」林浩在白板上畫，「服務端同步的不僅是當前狀態，還有未來幾幀的預測狀態。客戶端收到後，不是立即糾正，而是平滑過渡到預測狀態。這樣即使有延遲，畫面也是流暢的，只是有輕微的『飄移感』。對《傳奇》這類遊戲來說，可以接受。」
阿坤盯著白板，手指在空中比劃，心算。過了一會兒，他說：「需要服務端做狀態預測，計算量會增加30%。」
「但客戶端體驗會好很多。」林浩說，「玩家不會因為延遲高就罵娘，只會覺得『這遊戲有點飄，但能玩』。在2002年，這已經是降維打擊了。」
王磊插話：「服務端扛得住嗎？我們只有一台二手IBM伺服器。」
「所以需要優化。」林浩說，「阿坤，你來設計預測算法，要准，但不要太複雜。王磊，你來優化服務端架構，用事件驅動，避免線程切換開銷。我負責把整個引擎的手工重構出來。」
「手工重構？」王磊皺眉，「什麼意思？」
「意思是我要用手抄代碼。」林浩說，「把我腦子裡的架構，一行行寫成2002年能運行的C++代碼。沒有現成的庫，沒有參考文檔，只有記憶。我會先寫核心框架，你們基於框架實現具體模塊。」
阿坤和王磊對視了一眼。他們從林浩的語氣里聽出了什麼——一種破釜沉舟的決心，一種不成功便成仁的狠勁。
「從哪開始？」阿坤問。
「從最核心的戰鬥引擎開始。」林浩說，「今天，我要寫出戰鬥引擎的骨架。阿坤，你繼續完善數學模型，今晚我要看到完整的預測算法偽代碼。王磊，你搭建測試環境，我要能在一台機器上跑起十個客戶端模擬器，模擬不同網絡延遲下的表現。」
「十個客戶端……」王磊苦笑，「咱們就三台電腦。」
「用虛擬機。2002年有VMware了，雖然慢，但能用。」
「行，我試試。」
分工完畢。三人各自坐下，面對電腦。
林浩新建了一個C++工程。開發環境是Visual C++ 6.0，2002年的主流。界面很古老，但他熟悉。他新建了一個頭文件：BattleEngine.h。
然後他開始寫。沒有自動補全，沒有語法高亮（VC6有，但很基礎），沒有在線文檔。他完全靠記憶，把那些在2028年看來理所當然的設計，翻譯成2002年能理解的代碼。
第一行：
// 浩宇1.0 高並發戰鬥引擎
// 設計目標：支持單服5000人同時戰鬥
// 核心思路：事件驅動 + 狀態同步 + 預測矯正
// 作者：林浩
// 日期：2002年7月18日
然後是類定義。他先定義了幾個核心類：BattleUnit（戰鬥單元）、Skill（技能）、Buff（狀態）、BattleField（戰場）。每個類只有最簡單的屬性和方法聲明，具體實現後面再填。
寫到Skill類時，他停住了。技能系統是戰鬥的核心，但2028年的設計太複雜，有技能前搖、施法時間、彈道、命中判定、傷害計算、效果施加……一套下來，一個技能類可能有幾十個屬性和方法。在2002年的硬體上，這麼重的類，實例化幾百個就會卡死。
他必須簡化。
他刪掉了原本的設計，重新寫。這次，一個技能只有五個屬性：id、名稱、施法時間、冷卻時間、效果類型。效果類型是個枚舉：直接傷害、持續傷害、治療、控制、召喚。傷害計算用一個簡單的公式：基礎傷害+攻擊力係數攻擊力-防禦力係數防禦力。控制效果只有兩種：定身、沉默，持續固定時間。
簡單，但夠用。至少對第一個demo來說，夠用了。
寫到Buff類時，又遇到問題。2028年的Buff系統支持多層疊加、持續時間刷新、效果合併、優先級判斷。但2002年不能這麼搞。他再次簡化：Buff不能疊加，同類型後到的覆蓋先到的。持續時間用幀數計算，每幀檢測是否到期。效果只有屬性修正（加攻、加防、加減速）和狀態附加（定身、沉默）。
他寫了一個上午。到中午時，頭文件寫完了，大概三百行。這只是骨架，但結構清晰，職責分明。
「阿坤，來看一下。」林浩說。
阿坤走過來，站在他身後，看屏幕。他看得很慢，很仔細，有時會停下來，想幾秒，然後繼續。
「這個BattleField類，」阿坤指著一行代碼，「用二維數組存儲單元引用，查找效率是O(1)，但內存開銷大。如果地圖大，會爆內存。」
「地圖不會大。」林浩說，「第一個demo，戰場就100x100格，每個格存一個指針，4位元組，總共40KB，可以接受。」
「那單元移動時的碰撞檢測呢？還是遍歷所有單元？」
「用空間分區。把戰場分成10x10的區塊，每個單元只和同區塊及相鄰區塊的單元檢測碰撞。算法你熟。」
阿坤點頭：「四叉樹或者網格。我推薦網格，簡單，2002年夠用。」
「行，那你來實現。」
阿坤回到自己電腦前，開始寫空間分區算法。林浩繼續寫源文件。
下午，他遇到了第一個大難題：事件驅動框架。
2028年的遊戲引擎，事件系統是核心。玩家操作、技能釋放、傷害觸發、狀態變化，全都是事件。事件隊列、事件監聽、事件派發，一套完整的發布-訂閱模式。但在2002年，C++沒有lambda，沒有函數對象，沒有標準庫里的function。要實現事件系統，得用函數指針，或者自己造輪子。
林浩選擇了最土但最可靠的辦法：用整數類型標識事件，用switch-case分發。每個事件有一個結構體，包含事件類型和一堆union欄位。監聽者註冊回調函數，事件發生時，遍歷所有監聽者，調用對應的函數。
他寫了兩個小時，寫出了事件系統的雛形。測試時，發現性能有問題：每次事件派發都要遍歷所有監聽者，如果監聽者多，會成為瓶頸。
「用哈希表。」王磊不知什麼時候站到了他身後，「事件類型做key，監聽者列表做value。查找效率O(1)。」
「但2002年沒有std::unordered_map，得自己實現。」
「我有現成的。」王磊說，「以前寫外掛時攢的代碼庫，開源鏈地址哈希表，經過優化，在2002年的機器上跑得飛快。」
「好，拿來用。」
王磊從他的舊硬碟里翻出代碼。確實是優化過的哈希表，用了內存池、緩存行對齊、快速哈希函數。林浩集成進去，事件派發的性能提升了五倍。
晚上八點，戰鬥引擎的核心框架完成了。能跑，但不完整。林浩寫了一個簡單的測試：創建兩個戰鬥單元，互相攻擊。屏幕上，兩個像素小人你一拳我一拳，血條減少，直到一個倒下。
很原始，但基礎邏輯是通的。
「接下來是網絡同步。」林浩說，「王磊，你的UDP可靠傳輸層怎麼樣了？」
「搞定了。」王磊說，「基於RUDP（可靠UDP），加入了前向糾錯、選擇性重傳、流量控制。在模擬的200毫秒延遲+5%丟包環境下，傳輸可靠率99.9%。」
「好，集成進來。」
集成網絡層花了三個小時。到晚上十一點，他們終於能在兩台電腦之間跑起戰鬥demo了。一台做服務端，一台做客戶端。客戶端控制紅色小人移動、攻擊，服務端同步狀態，另一個客戶端能看到。
延遲明顯，有卡頓，但能玩。
「還不夠。」林浩說，「要加預測和矯正。」
阿坤拿出了他今天的成果：三頁紙的預測算法偽代碼。林浩看了，思路清晰，但實現複雜。
「我們分步來。」林浩說，「先實現最簡單的：客戶端預測移動，服務端矯正位置。技能和傷害先不做預測，等同步。」
「行。」
又寫了兩個小時。凌晨一點，預測移動完成了。測試時，故意加了300毫秒延遲。紅色小人在客戶端移動得很流暢，但在服務端的視角里，它有輕微的「飄移」，會突然跳到正確位置。這是預測錯誤的矯正。
「視覺上有點怪，但能接受。」王磊說。
「嗯，先這樣。」林浩說，「今天到此為止。明天做技能預測和傷害同步。」
三人癱在椅子上。累，但興奮。他們用一天時間，做出了一個可用的戰鬥引擎骨架。雖然簡陋，但架構先進，有擴展性。
「老大，」王磊突然說，「你腦子裡的這些東西，到底從哪學的？」
林浩沉默了幾秒。窗外是沉沉的夜，沒有月亮，只有幾顆星星。
「如果我說，我夢見過未來，你信嗎？」
王磊笑了：「我信。不然沒法解釋。你寫的這些設計，我從來沒見過，但仔細一想，又覺得就該這麼設計。像是……站在山頂看山路，知道哪裡該拐彎，哪裡該直行。而我們還在山腳下摸索。」
阿坤輕聲說：「我也有這種感覺。你給的算法思路，不是憑空想的，是經過千錘百鍊的最優解。但你又沒時間千錘百鍊。」
林浩沒回答。他關了電腦，站起身。
「睡覺。明天六點起。」
「六點？！」王磊哀嚎。
「嗯，六點。我們只有兩周了。」
三人簡單洗漱，躺下。工作室里只有兩張行軍床，林浩睡地鋪。硬地板，但累到極致，躺下就著。
第二天，六點，鬧鐘響。
三人爬起來，用冷水沖臉，泡麵當早飯，然後繼續。
第二天，做技能預測。更難，因為技能有前搖、彈道、命中判定，任何一步預測錯誤，都會導致嚴重的不同步。林浩設計了「預測-驗證-回滾」機制：客戶端預測技能命中，如果服務端驗證不通過，就回滾到上一個狀態，並補償玩家。
實現這個機制，又花了一天。到晚上時，他們終於能在高延遲下，比較流暢地釋放技能了。雖然偶爾會有「技能打中了但沒傷害」或者「沒打中但跳傷害」的bug，但概率很低。
第三天，做狀態同步優化。阿坤實現了狀態快照差分壓縮，把每次同步的數據量從2KB降到了200位元組。這意味著，在56K的撥號網絡下，同步延遲能從500毫秒降到100毫秒。這是質變。
第四天，做AI。簡單有限狀態機，但林浩加入了一些小技巧：AI會走位，會逃跑，會吃藥。雖然還是很蠢，但比《傳奇》里那些站樁怪強多了。
第五天，整合。把戰鬥引擎、網絡層、AI、資源管理全部整合到一起。出了無數bug，修到凌晨三點。
第六天，第七天，第八天……
每天睡四小時，吃泡麵，喝礦泉水。工作室里堆滿了草稿紙、泡麵盒、空水瓶。三人的鬍子長了，頭髮油了，眼睛紅了。但代碼一行行增加，功能一個個實現。
到第七天晚上，他們有了一個可玩的demo：一個簡單的戰場，玩家控制一個角色，可以移動，釋放三個技能（火球、治療、衝鋒），打五個AI怪物。有血條，有藍條，有經驗值，有升級。雖然美術只有簡陋的像素圖，雖然音效只有「噗噗噗」的簡單音效，雖然內容少得可憐——
但它流暢。
在模擬的200毫秒延遲下，移動流暢，技能釋放流暢，戰鬥流暢。沒有卡頓，沒有漂移，沒有明顯的不同步。這在2002年，是奇蹟。
王磊控制角色，在戰場上跑了一圈，放了幾個技能，打死一個怪。他盯著屏幕，看了很久。
「我操。」他說，聲音很輕。
阿坤也盯著屏幕，手指在顫抖。
「我們……做出來了？」他問。
「做出來了。」林浩說，聲音沙啞，「浩宇1.0引擎，第一個可玩demo，完成了。」
三人坐在電腦前，看著屏幕。紅色的像素小人在簡陋的地圖上奔跑，釋放火球，怪物倒下，經驗條增長。
很簡單，很粗糙。
但它是完全基於全新架構的，是他們三個人，用兩周時間，從零寫出來的。
「接下來，」林浩說，「我們要在兩周內，基於這個引擎，做出《浩宇傳奇》的第一個版本。內容要足夠多，能讓玩家玩上一天。美術要看得過去，不能太醜。運營後台要簡單，能開服，能收錢。」
「兩周……」王磊喃喃道。
「嗯，兩周。」林浩說，「但我們有引擎了。有了引擎，內容生產會快十倍。阿坤，你負責數值和關卡設計。王磊，你負責運營後台和支付系統。我負責美術資源和劇情文案。」
「美術你也會？」阿坤問。
「不會，但可以學。」林浩說，「2002年的遊戲美術，像素圖，我能畫。劇情文案，我能寫。我們沒時間找外包了，全部自己來。」
王磊看著林浩，看了很久，然後笑了。
「老大，我服了。」他說，「我這輩子沒服過誰，但我服你。你說干，我就干。你說兩周，我就兩周不睡覺。」
阿坤點頭：「我也是。」
林浩看著他們。兩個夥伴，眼裡的光和他一樣，是疲憊的，但燃燒的。
「那就干。」他說。
三人擊掌。很輕，但很重。
窗外的天又黑了。星星出來了，很多，很亮。
工作室的燈，又亮了一夜。
浩宇1.0引擎，活了。
而浩宇科技的第一個遊戲，就要誕生了。
時間，還剩下兩周。
他們，必須贏。
林浩按了十三次電源鍵，屏幕始終漆黑。他把它放在窗台上，對著月光——月光很亮，但沒用。鈣鈦礦電池需要的是太陽光中的紫外線，月光太弱了。他試了檯燈，試了手電筒，都沒用。那0.0%的電量像一道深淵，把所有未來的可能性都吸了進去。
他站在窗前，看著手裡這塊黑色磚頭。2028年的技術結晶，現在成了一塊廢鐵。小藝休眠了，或者說，死了。在電量歸零的瞬間，那個溫和的女聲，那些精確的數據，那些超越時代的洞察，全都沉默了。
他唯一剩下的，是記憶。是之前看過的那些資料，那些架構圖，那些算法思路。但記憶會模糊，會出錯，會遺漏細節。他不能再問「小藝，這個函數怎麼寫」，不能再問「這個參數的最佳值是多少」，不能再問「如果遇到這個bug該怎麼解」。
他只能靠自己了。
林浩把手機收進抽屜最底層，用幾本書蓋住。然後他坐回電腦前，打開一個空白的文本文檔。
標題：「浩宇1.0引擎重構備忘錄」。
他開始寫，用最樸實的語言，把自己還記得的東西都記下來。
「1. 高並發戰鬥引擎核心思路：事件驅動+協程+無鎖隊列。但2002年沒有協程庫，用狀態機模擬。無鎖隊列用CAS實現，但2002年的C++編譯器不支持原子操作，用互斥鎖+內存屏障替代。」
「2. 網絡同步優化：客戶端預測+服務端矯正。關鍵：狀態快照差分壓縮。算法思路：將遊戲狀態編碼為位圖，只同步變化的部分。壓縮用簡單的遊程編碼（RLE），2002年CPU能承受。」
「3. 物理引擎簡化：2D剛體碰撞，用分離軸定理（SAT）檢測。但《傳奇》是格子移動，不需要連續物理。改為格子碰撞+射線檢測，性能更高。」
「4. 技能系統：用腳本驅動，但2002年沒有好的腳本引擎。改為配置表+硬編碼。每個技能是一個狀態機，有前搖、施法、後搖三個階段。」
「5. AI系統：行為樹，但太複雜。改為有限狀態機（FSM），五個狀態：閒置、追擊、攻擊、逃跑、死亡。」
他寫了三頁。停下來時，天已經蒙蒙亮。窗外有鳥叫聲，清脆的，一聲接一聲。
他看了一眼時間：凌晨五點。他睡了兩個小時，夠了。
阿坤和王磊是早上八點來的。兩人都帶著黑眼圈，但眼神清醒。阿坤背著一個鼓鼓囊囊的書包，裡面是他從學校圖書館借的數學書：《計算幾何》《圖論導論》《數值分析》。王磊提著一個塑膠袋，裡面是二十包泡麵，十根火腿腸，一箱礦泉水。
「這是接下來一周的糧草。」王磊把塑膠袋放在牆角。
「我推演了狀態同步的數學模型。」阿坤拿出草稿紙，上面是密密麻麻的公式，「但有個問題：如果網絡延遲超過300毫秒，預測糾正會導致明顯的畫面抖動。2002年，很多玩家還在用56K貓，延遲可能到500毫秒。」
林浩接過草稿紙看。阿坤的推導很嚴謹，但思路還是傳統的那一套：降低延遲，優化算法。這解決不了根本問題。
「我們換一個思路。」林浩說，「不追求零延遲，而是讓玩家感受不到延遲。」
「怎麼做？」
「客戶端不只做預測，還做預渲染。」林浩在白板上畫，「服務端同步的不僅是當前狀態，還有未來幾幀的預測狀態。客戶端收到後，不是立即糾正，而是平滑過渡到預測狀態。這樣即使有延遲，畫面也是流暢的，只是有輕微的『飄移感』。對《傳奇》這類遊戲來說，可以接受。」
阿坤盯著白板，手指在空中比劃，心算。過了一會兒，他說：「需要服務端做狀態預測，計算量會增加30%。」
「但客戶端體驗會好很多。」林浩說，「玩家不會因為延遲高就罵娘，只會覺得『這遊戲有點飄，但能玩』。在2002年，這已經是降維打擊了。」
王磊插話：「服務端扛得住嗎？我們只有一台二手IBM伺服器。」
「所以需要優化。」林浩說，「阿坤，你來設計預測算法，要准，但不要太複雜。王磊，你來優化服務端架構，用事件驅動，避免線程切換開銷。我負責把整個引擎的手工重構出來。」
「手工重構？」王磊皺眉，「什麼意思？」
「意思是我要用手抄代碼。」林浩說，「把我腦子裡的架構，一行行寫成2002年能運行的C++代碼。沒有現成的庫，沒有參考文檔，只有記憶。我會先寫核心框架，你們基於框架實現具體模塊。」
阿坤和王磊對視了一眼。他們從林浩的語氣里聽出了什麼——一種破釜沉舟的決心，一種不成功便成仁的狠勁。
「從哪開始？」阿坤問。
「從最核心的戰鬥引擎開始。」林浩說，「今天，我要寫出戰鬥引擎的骨架。阿坤，你繼續完善數學模型，今晚我要看到完整的預測算法偽代碼。王磊，你搭建測試環境，我要能在一台機器上跑起十個客戶端模擬器，模擬不同網絡延遲下的表現。」
「十個客戶端……」王磊苦笑，「咱們就三台電腦。」
「用虛擬機。2002年有VMware了，雖然慢，但能用。」
「行，我試試。」
分工完畢。三人各自坐下，面對電腦。
林浩新建了一個C++工程。開發環境是Visual C++ 6.0，2002年的主流。界面很古老，但他熟悉。他新建了一個頭文件：BattleEngine.h。
然後他開始寫。沒有自動補全，沒有語法高亮（VC6有，但很基礎），沒有在線文檔。他完全靠記憶，把那些在2028年看來理所當然的設計，翻譯成2002年能理解的代碼。
第一行：
// 浩宇1.0 高並發戰鬥引擎
// 設計目標：支持單服5000人同時戰鬥
// 核心思路：事件驅動 + 狀態同步 + 預測矯正
// 作者：林浩
// 日期：2002年7月18日
然後是類定義。他先定義了幾個核心類：BattleUnit（戰鬥單元）、Skill（技能）、Buff（狀態）、BattleField（戰場）。每個類只有最簡單的屬性和方法聲明，具體實現後面再填。
寫到Skill類時，他停住了。技能系統是戰鬥的核心，但2028年的設計太複雜，有技能前搖、施法時間、彈道、命中判定、傷害計算、效果施加……一套下來，一個技能類可能有幾十個屬性和方法。在2002年的硬體上，這麼重的類，實例化幾百個就會卡死。
他必須簡化。
他刪掉了原本的設計，重新寫。這次，一個技能只有五個屬性：id、名稱、施法時間、冷卻時間、效果類型。效果類型是個枚舉：直接傷害、持續傷害、治療、控制、召喚。傷害計算用一個簡單的公式：基礎傷害+攻擊力係數攻擊力-防禦力係數防禦力。控制效果只有兩種：定身、沉默，持續固定時間。
簡單，但夠用。至少對第一個demo來說，夠用了。
寫到Buff類時，又遇到問題。2028年的Buff系統支持多層疊加、持續時間刷新、效果合併、優先級判斷。但2002年不能這麼搞。他再次簡化：Buff不能疊加，同類型後到的覆蓋先到的。持續時間用幀數計算，每幀檢測是否到期。效果只有屬性修正（加攻、加防、加減速）和狀態附加（定身、沉默）。
他寫了一個上午。到中午時，頭文件寫完了，大概三百行。這只是骨架，但結構清晰，職責分明。
「阿坤，來看一下。」林浩說。
阿坤走過來，站在他身後，看屏幕。他看得很慢，很仔細，有時會停下來，想幾秒，然後繼續。
「這個BattleField類，」阿坤指著一行代碼，「用二維數組存儲單元引用，查找效率是O(1)，但內存開銷大。如果地圖大，會爆內存。」
「地圖不會大。」林浩說，「第一個demo，戰場就100x100格，每個格存一個指針，4位元組，總共40KB，可以接受。」
「那單元移動時的碰撞檢測呢？還是遍歷所有單元？」
「用空間分區。把戰場分成10x10的區塊，每個單元只和同區塊及相鄰區塊的單元檢測碰撞。算法你熟。」
阿坤點頭：「四叉樹或者網格。我推薦網格，簡單，2002年夠用。」
「行，那你來實現。」
阿坤回到自己電腦前，開始寫空間分區算法。林浩繼續寫源文件。
下午，他遇到了第一個大難題：事件驅動框架。
2028年的遊戲引擎，事件系統是核心。玩家操作、技能釋放、傷害觸發、狀態變化，全都是事件。事件隊列、事件監聽、事件派發，一套完整的發布-訂閱模式。但在2002年，C++沒有lambda，沒有函數對象，沒有標準庫里的function。要實現事件系統，得用函數指針，或者自己造輪子。
林浩選擇了最土但最可靠的辦法：用整數類型標識事件，用switch-case分發。每個事件有一個結構體，包含事件類型和一堆union欄位。監聽者註冊回調函數，事件發生時，遍歷所有監聽者，調用對應的函數。
他寫了兩個小時，寫出了事件系統的雛形。測試時，發現性能有問題：每次事件派發都要遍歷所有監聽者，如果監聽者多，會成為瓶頸。
「用哈希表。」王磊不知什麼時候站到了他身後，「事件類型做key，監聽者列表做value。查找效率O(1)。」
「但2002年沒有std::unordered_map，得自己實現。」
「我有現成的。」王磊說，「以前寫外掛時攢的代碼庫，開源鏈地址哈希表，經過優化，在2002年的機器上跑得飛快。」
「好，拿來用。」
王磊從他的舊硬碟里翻出代碼。確實是優化過的哈希表，用了內存池、緩存行對齊、快速哈希函數。林浩集成進去，事件派發的性能提升了五倍。
晚上八點，戰鬥引擎的核心框架完成了。能跑，但不完整。林浩寫了一個簡單的測試：創建兩個戰鬥單元，互相攻擊。屏幕上，兩個像素小人你一拳我一拳，血條減少，直到一個倒下。
很原始，但基礎邏輯是通的。
「接下來是網絡同步。」林浩說，「王磊，你的UDP可靠傳輸層怎麼樣了？」
「搞定了。」王磊說，「基於RUDP（可靠UDP），加入了前向糾錯、選擇性重傳、流量控制。在模擬的200毫秒延遲+5%丟包環境下，傳輸可靠率99.9%。」
「好，集成進來。」
集成網絡層花了三個小時。到晚上十一點，他們終於能在兩台電腦之間跑起戰鬥demo了。一台做服務端，一台做客戶端。客戶端控制紅色小人移動、攻擊，服務端同步狀態，另一個客戶端能看到。
延遲明顯，有卡頓，但能玩。
「還不夠。」林浩說，「要加預測和矯正。」
阿坤拿出了他今天的成果：三頁紙的預測算法偽代碼。林浩看了，思路清晰，但實現複雜。
「我們分步來。」林浩說，「先實現最簡單的：客戶端預測移動，服務端矯正位置。技能和傷害先不做預測，等同步。」
「行。」
又寫了兩個小時。凌晨一點，預測移動完成了。測試時，故意加了300毫秒延遲。紅色小人在客戶端移動得很流暢，但在服務端的視角里，它有輕微的「飄移」，會突然跳到正確位置。這是預測錯誤的矯正。
「視覺上有點怪，但能接受。」王磊說。
「嗯，先這樣。」林浩說，「今天到此為止。明天做技能預測和傷害同步。」
三人癱在椅子上。累，但興奮。他們用一天時間，做出了一個可用的戰鬥引擎骨架。雖然簡陋，但架構先進，有擴展性。
「老大，」王磊突然說，「你腦子裡的這些東西，到底從哪學的？」
林浩沉默了幾秒。窗外是沉沉的夜，沒有月亮，只有幾顆星星。
「如果我說，我夢見過未來，你信嗎？」
王磊笑了：「我信。不然沒法解釋。你寫的這些設計，我從來沒見過，但仔細一想，又覺得就該這麼設計。像是……站在山頂看山路，知道哪裡該拐彎，哪裡該直行。而我們還在山腳下摸索。」
阿坤輕聲說：「我也有這種感覺。你給的算法思路，不是憑空想的，是經過千錘百鍊的最優解。但你又沒時間千錘百鍊。」
林浩沒回答。他關了電腦，站起身。
「睡覺。明天六點起。」
「六點？！」王磊哀嚎。
「嗯，六點。我們只有兩周了。」
三人簡單洗漱，躺下。工作室里只有兩張行軍床，林浩睡地鋪。硬地板，但累到極致，躺下就著。
第二天，六點，鬧鐘響。
三人爬起來，用冷水沖臉，泡麵當早飯，然後繼續。
第二天，做技能預測。更難，因為技能有前搖、彈道、命中判定，任何一步預測錯誤，都會導致嚴重的不同步。林浩設計了「預測-驗證-回滾」機制：客戶端預測技能命中，如果服務端驗證不通過，就回滾到上一個狀態，並補償玩家。
實現這個機制，又花了一天。到晚上時，他們終於能在高延遲下，比較流暢地釋放技能了。雖然偶爾會有「技能打中了但沒傷害」或者「沒打中但跳傷害」的bug，但概率很低。
第三天，做狀態同步優化。阿坤實現了狀態快照差分壓縮，把每次同步的數據量從2KB降到了200位元組。這意味著，在56K的撥號網絡下，同步延遲能從500毫秒降到100毫秒。這是質變。
第四天，做AI。簡單有限狀態機，但林浩加入了一些小技巧：AI會走位，會逃跑，會吃藥。雖然還是很蠢，但比《傳奇》里那些站樁怪強多了。
第五天，整合。把戰鬥引擎、網絡層、AI、資源管理全部整合到一起。出了無數bug，修到凌晨三點。
第六天，第七天，第八天……
每天睡四小時，吃泡麵，喝礦泉水。工作室里堆滿了草稿紙、泡麵盒、空水瓶。三人的鬍子長了，頭髮油了，眼睛紅了。但代碼一行行增加，功能一個個實現。
到第七天晚上，他們有了一個可玩的demo：一個簡單的戰場，玩家控制一個角色，可以移動，釋放三個技能（火球、治療、衝鋒），打五個AI怪物。有血條，有藍條，有經驗值，有升級。雖然美術只有簡陋的像素圖，雖然音效只有「噗噗噗」的簡單音效，雖然內容少得可憐——
但它流暢。
在模擬的200毫秒延遲下，移動流暢，技能釋放流暢，戰鬥流暢。沒有卡頓，沒有漂移，沒有明顯的不同步。這在2002年，是奇蹟。
王磊控制角色，在戰場上跑了一圈，放了幾個技能，打死一個怪。他盯著屏幕，看了很久。
「我操。」他說，聲音很輕。
阿坤也盯著屏幕，手指在顫抖。
「我們……做出來了？」他問。
「做出來了。」林浩說，聲音沙啞，「浩宇1.0引擎，第一個可玩demo，完成了。」
三人坐在電腦前，看著屏幕。紅色的像素小人在簡陋的地圖上奔跑，釋放火球，怪物倒下，經驗條增長。
很簡單，很粗糙。
但它是完全基於全新架構的，是他們三個人，用兩周時間，從零寫出來的。
「接下來，」林浩說，「我們要在兩周內，基於這個引擎，做出《浩宇傳奇》的第一個版本。內容要足夠多，能讓玩家玩上一天。美術要看得過去，不能太醜。運營後台要簡單，能開服，能收錢。」
「兩周……」王磊喃喃道。
「嗯，兩周。」林浩說，「但我們有引擎了。有了引擎，內容生產會快十倍。阿坤，你負責數值和關卡設計。王磊，你負責運營後台和支付系統。我負責美術資源和劇情文案。」
「美術你也會？」阿坤問。
「不會，但可以學。」林浩說，「2002年的遊戲美術，像素圖，我能畫。劇情文案，我能寫。我們沒時間找外包了，全部自己來。」
王磊看著林浩，看了很久，然後笑了。
「老大，我服了。」他說，「我這輩子沒服過誰，但我服你。你說干，我就干。你說兩周，我就兩周不睡覺。」
阿坤點頭：「我也是。」
林浩看著他們。兩個夥伴，眼裡的光和他一樣，是疲憊的，但燃燒的。
「那就干。」他說。
三人擊掌。很輕，但很重。
窗外的天又黑了。星星出來了，很多，很亮。
工作室的燈，又亮了一夜。
浩宇1.0引擎，活了。
而浩宇科技的第一個遊戲，就要誕生了。
時間，還剩下兩周。
他們，必須贏。