雲風—開發筆記(1)

折騰了好久，終于可以開始正式項目開發了。

之前的這段日子，我們陷落在公司的股權配置設定問題中，糾結于到底需要幾個人到位才啟動；更是反複讨論，到底應該做個怎樣的遊戲。林林總總，終于，在已經到位的幾位同學的摩拳擦掌中，叮當決定自己挂帥開始幹了。

就這麼不到十個人，空曠的辦公室，跟我們起先想像的情況不太一樣。尤其是主策劃還沒有落定。我說，叮當，你好歹也是一資深遊戲玩家，帶了這麼多年的遊戲部，跟了這麼多成功的項目，沒吃過豬肉總見過豬跑吧，我就不相信你幹着會比别人差。若不是我必須盯着程式實作這塊，我都想自己做主策劃了。不過有你幹，我放心。

主策劃的位置，咱們可以先空着，前期工作不能延。産品經理代理一下遊戲主策劃的位置也是創業公司必須的；正如我這挂牌的 CTO ，除了負責系統架構以外，也得兼個程式員做實作嘛。

經過兩天對項目計劃表的讨論後，我們今天就算正式開工了。

遊戲是怎樣的？半保密，不在這裡多寫，怕大家罵。再說了，這個東西現在說是怎樣的，一兩年後肯定有變化，多說無益，多解釋無益。簡單說呢，就是一個戰鬥系統類似魔獸世界，但系統核心玩法差異很大，更為輕松，更偏重 PvP 的 MMORPG 。為什麼是這樣一個東西，不想解釋，反正不是拍腦袋想出來的。

既然是開發筆記，就寫寫現在在做些啥，打算怎樣做下去。

我們先集體玩了一周魔獸世界，雖然大部分人已經是 wow 老玩家，但還是有一兩個人玩的比較少，大家一起熟悉一下。主要是熟悉戰鬥系統，還有美術風格的感覺。培養點興趣，對未來我們自己做的東西至少在表層上大家都有點感覺，有愛。

瞥開美術和策劃的計劃不談，主要寫寫程式的計劃。

在 Closed Beta 前，有 8 個曆程碑，到一期截至，就開始有内部運作的版本。這次完全抛棄以往在網易積累的任何一點成品，全部從零開始做。但是，對于程式員來說，一切都在腦子裡，其實工作量并不大。有機會重頭來，恐怕是大部分程式員夢寐以求的機會。

當然，我們購買了一套 3d engine （不介紹，不解釋），起點高一些。伺服器也會盡量用一些成熟的開源庫。

一期打算實作基本的使用者登陸，場景漫遊，包括在場景中做各種跑、跳、走、騎乘等動作。

一期程式員三人：

• 雲風：負責總體規劃，總體協定設計，以及部分伺服器子產品的實作。
• 怪物公司：負責用戶端的設計與實作。
• 蝸牛：負責伺服器的細節設計與實作。

吵架是我們的傳統，自今天就開始了。按照慣例，我無法說服項目組認可我的所有設計和技術選擇。不過大家妥協的結果是，先按我的想法做，一期雛形在下周末前完成，根據實作過程中遇到的問題，我們在修正甚至全部重構目前的設計。一周半時間的代價是目前我們可以承受的。

ps. 程式員就是這麼一種奇怪的生物。好的程式員都有自己獨立的思想。對自己實作或即将實作的代碼有愛。按照别人的思想去實作是件無比痛苦的事情，會覺得在浪費自己的生命。是以，大部分有活力的項目開始都是一個人建立起來的。在大公司，好多老程式員都喜歡招聘所謂有潛力的新人，認為他們白紙一張，好塑造。說到底就是聽話。但事實的結果一般是，要麼培養出來一個庸才，無法擔當；要麼，在技術選擇上最終分道揚镳。我總是對他們說，想想你願不願意總聽着别人的意見幹活？如果你不願意，那麼就别指揮别人幹。自己不願意做的事情，就别讓别人幫你做。

我的設計草稿是這樣的：

整個遊戲系統（一期工程需要的）大體由這樣一些部分組成：

• 用戶端，運作在玩家的終端上，用一條 TCP 連接配接和系統通訊。它接入遊戲伺服器網關。
• 網關，負責彙總所有用戶端，大體上和我很多年前的想法一緻 ，雖然會有一些實作上的小改變，但思想沒有根本變化。
• 客戶代理(Agent) ，運作在網關的後端，在邏輯上，每個用戶端都有一個 agent 負責翻譯和轉發用戶端發來的請求，以及回應。衆多 agent 可以實作在同一個程序中，也可以是多個不同的程序裡。可以用腳本虛拟機的形式跑，也可以是别的形式，這些都不太重要。這一次，我們最大可能使用獨立的 lua state 來實作單個 agent。
• 資料服務，儲存玩家資料，場景資料等。前端用自己的代碼和協定同系統其它部分溝通，後端這次想采用 redis 做儲存。
• 場景管理器，用于管理靜态場景和動态副本。
• 若幹場景伺服器，用于玩家在裡面做漫遊。

網關之後的服務是互相信任的，并組成一個虛拟網絡可以互相通訊。通訊底層暫時采用 zeromq ，通訊協定采用 google protobuf 。

用戶端到 agent 的通訊協定與網關後各個邏輯結點之間的通訊協定将隔離，分開設計。甚至不保證采用一緻的技術實作方案，以及協定設計風格。

這裡的設計關鍵在于 Agent 的設計，大部分的工作量是圍繞它而來的。

單個 Agent 的工作流程代表了項目一期的結果會展現的東西，大體上邏輯流程如下：

1. 等待使用者認證
2. 把認證系統交給認證伺服器認證，失敗則傳回 1 重試。
3. 從資料庫擷取使用者資料(一期資料很少,僅有預設的使用者名,使用者形象) ，并轉發給用戶端。
4. 取得使用者所在場景号，從場景管理器取得場景服務的位置，并申請加入場景。
5. 從場景伺服器，同步環境。
6. 轉發使用者在場景中漫遊的請求，并同步場景的實時資料。
7. 一旦用戶端發生異常或得到推出消息，通知場景伺服器離開。

這裡，和曆史上我們的遊戲伺服器設計有一個小的不同。我認為，使用者的角色在場景中的位置，動作狀态，甚至以後的戰鬥數值狀态，都是屬于場景資料的一部分，而不是使用者資料的一部分。

使用者資料中，和場景有關的隻包括他目前所屬的場景。由場景自己來儲存角色在場景中的狀态資料。簡單而具體的說，類似網易曆史上的西遊系列，玩家的坐标是玩家的屬性之一，是會在持久化時存放在玩家資料裡的。經過我這兩年的思考，我覺得這種設計方法是有問題的。

從我現在的直覺上來說，虛拟角色的屬性不應包括角色的地理位置資訊。那是角色的外在限制。而場景更應該擁有在它其中的 PC 和 NPC 的位置以及各種狀态。PC 下線隻應該認為是 PC 處于一種特殊狀态（不被周圍的 PC/NPC 所見或影響），而并沒有脫離這個場景。是以我更願意把 PC 下線定義成 detach ，而上線則是 attach 的操作。在這點上，場景，作為一個實體，擁有它自己的資料邏輯。

agent 相關的協定粗略的設計如下：

• auth 登陸認證 
  • user/pass 取得 userid ，傳回成功或各種失敗
• userdb
  • 用 userid 取得 avatar list
  • 用 avatar 取得 avatar data (包括場景名)
• scene manager
  • 用 場景名 取得 scene id
  • 用 scene id 取得場景狀态，傳回允許進入或各種擁堵狀态
• scene
  • 把 avatar attach 到場景
  • 取得 avatar 的場景上下文
  • 把 avatar detach 出場景
  • avatar 設定坐标,速度,行為(跑,走,站立),方向
  • avatar 騎乘狀态改變
  • avatar 做特定動作

好吧，未來一周的工作任務就是這些了。需要明天再做細化整理。然後就是實作了。