《大型多人在線遊戲開發》讀書筆記

原作名:《Massively Multiplayer Game Development》 – Thor Alexander

一、MMP設計技術

【卡通城OL:面向大衆的MMO】

1. 遊戲設計問題：
   
   • ①孩子家長也必須是銷售對象 – a.兒童成人都喜歡; b.藉助信賴的品牌; c.角色共通; d.可與家人分享;
   • ②允許有衝突但是須禁止暴力 – a.取消玩家對戰; b.工作和娛樂的衝突; c.卡通式戰鬥; d.機器敵人; e.笑槽;
   • ③太多選擇會讓玩家無所適從 – a.指南(單人,互動,多人); b.任務(明確目標,提供故事線,多種升級系統提高趣味);
   • ④玩家希望立即享受遊戲樂趣 – a.下載時插播遊戲要素/背景故事; b.創建角色(定製); c.瞬間移動;
   • ⑤衆人面前普通玩家懼怕失敗 – a.確保成功; b.觀看戰鬥; c.強調團隊合作; d.新手老手一起遊戲;
   • ⑥複雜的系統令玩家不知所措 – a.避免用數字描述狀態(優先圖); b.適當的冗餘信息; c.背囊有限; d.合併並統一界面; e.避免不合理的按鍵; f.使用熟悉的界面; g.隱藏不必要細節; h.讓探索充滿樂趣; i.不要過於簡單;
   • ⑦玩家通常只會玩一小段時間- - 明確的目標可以節約時間;
2. 社會性問題：
   
   • ①受衆對”搗亂”容忍度很低 – 搗亂（指以降低遊戲完整性,在遊戲中反覆騷擾其他玩家的行爲）;
   • ②玩家無法容忍那些在現實生活中也會發生的社會問題–比如貴重物品被非法轉移等;
   • ③家長不放心孩子上網 – a.提供安全的交流形式(基於菜單的聊天系統); b.現實朋友的私密聊天(48小時祕鑰聊天頻道);
   • ④與社會特性不一致 – a.永遠不要阻止朋友; b.社交(羣組友好,聊天泡泡); c.合作性迷你遊戲;
   • ⑤剛開始遊戲會害羞 – a.輕量級羣組(任務臨時隊伍); b.打破沉默; c.共同的目標; d.朋友列表;
3. 輕量級RPG經驗：
   
   • ①讓玩家可立即享受遊戲帶來的快樂 – 比如遊戲最初,遊戲指南帶入一場戰鬥;
   • ②避免強迫玩家對不瞭解的事物進行選擇 – 比如最初角色選擇與遊戲職業/能力分離;
   • ③地理佈局應該完全由遊戲模式決定 – 比如礦洞挖礦, 碼頭池塘釣魚, 空地地標玩家聚集;
   • ④每次進行遊戲的時間應該較短 – 比如3小時大任務分解成子任務,增量進行;
   • ⑤允許並鼓勵玩家成爲觀衆 – 比如觀戰;
   • ⑥相比獨立做任務,團隊合作更有意義 – 儘可能鼓勵合作,加強玩家聯繫;

【每個人都需要某個人:怎樣讓玩家合作】

1. 讓玩家合作的緣由：
   
   • 降低系統開銷 – 假設可承受3000併發玩家,不合作需處理3000個AI,反之,3人/隊則只需提供1000個併發AI;
   • 使遊戲更富於變化 – 使玩家能自行創造快樂會延長遊戲生命週期,並帶動朋友家人加入分享快樂;
   • 使玩家建立起牢固的社會關係從而不願停止遊戲;
2. 玩家非必須下不會自主合作：
   
   • 合作遊戲多數情況回報更高,但別錯誤地去掉所有單獨遊戲的機會,OL中有很多內向的人,佔比超過現實比例;
   • 創建一系列不同的任務,它們中一部分適合獨立遊戲,另一部分適合玩家合作,這些任務最終提供了一個合作性的社會環境;
   • 示例： Ultima Online(礦工,鍊金等職業任務是蒐集並提供冒險物品,可獨立完成;同時,通過市場/NPC代賣與其他玩家進行合作);
3. 角色扮演是主流:在玩家可以提供獨特功能時合作最爲有效;
   
   • 人們參與MMP遊戲是因爲這些遊戲可使他們獲得成功,而所花時間比真實世界短很多[從心理學角度來說,這極具吸引力];
   • 遊戲中成功的定義非常多 – 使玩傢俱有獨特功能,每種功能都可用來滿足一類基本的個性化需求,並有助於滿足其他玩家的需求;
4. 功能提供模式:
   
   • 預先定義 – “角色分類”(遊戲加入很多特性使每種職業有各自的特色,並在合作中提供關鍵技能);
   • 功能定義 – “基於技能”(遊戲角色可學習掌握任何技能,但只擅長練習最多的技能,應提供技能指導和搭配建議);
5. 爲遊戲角色提供挑戰:
   
   • 設計遊戲內容不斷地支持並加強各類型功能,只有組合各類型功能,才能發現和征服遊戲中的每一個挑戰;
   • 挑戰,應讓不同角色可按照不同策略來組合征服,避免唯一方法導致缺少必備技能玩家而無法征服;
   • 不要把角色設計得只能少數情況下使用,而應在不同情況下都有用,避免功能太窄而缺少意義;
6. 保持功能的完整性:
   
   • 拓寬功能時,小心保持每個角色在遊戲世界黑暗能地位的完整性,避免削弱某類職業的價值;
   • 不應該讓某一類角色擔當完成遊戲中唯一類型的關鍵先生;比如死亡復活,牧師復活比跑屍復活裝備掉更少耐久.
7. 幫助玩家彼此找到對方:
   
   • 視覺區分 – 用差異化的原型/裝備區分職業,便於玩家更易尋找;比如在餐館,我們會方便的找到穿着制服的服務員;
   • 節點區分 – 創建可滿足某種玩家共同需要的場所,比如拍賣行/教堂/廣場,用於交易治療或聊天;
   • 功能界面–例如冒險小組可通過組隊UI,搜索特定職業設置爲空閒的玩家;
8. 幫助玩家進行交流:
   
   • 在實現玩家可便捷找到對方後,提供一些工具使玩家可管理彼此間的交互;
   • 簡化交流方式 – 比如戰略遊戲提供某種界面便於發出簡短命令來協調行動;
   • 交流不止於交談 – 比如貿易系統; 比如玩家門口放置商人NPC售賣物品; 比如無主之地中的頻死狀態閃爍提醒;

【遊戲平衡】

1. 爲遊戲中的數值建立基線:從項目中的核心繫統開始,比如戰鬥系統;
2. 爲數值編寫模擬程序:簡單地獲取用戶輸入的數據,使用一些原型系統算法對他們進行處理並顯示結果; [程序示例見P25];
3. 建立遊戲中的度量:對所關心的遊戲數值進行長期(按天、月、年或特定時間段進行維護)跟蹤和記錄; 項目中期;
   需跟蹤的因素:
   
   • 玩家升級 – 統計玩家升級情況,確定遊戲進展是否符合預期速度;
   • 物品使用 – 統計物品使用頻率如武器揮砍次數/裝甲穿着時間,一般使用頻率高的物品更強反之較弱;
   • 動作行爲 –瞭解玩家在遊戲中的時間究竟花在了哪裏,是打怪還是製造？比如治療是戰鬥時間的兩倍,則需提高治療效果;
4. 內部和外部測試:僅當測試玩家數量接近正式運營期望值時,纔可能對遊戲進行正確的平衡調整; 封測是無痛測試平衡性的最後機會;
   觀察玩家動作：
   
   • 玩家對物品/技能/動作的偏愛,升級速度等;
   • 注意力放在異常數據,比如過快的升級速度/大量財富; 遊戲數據/行爲異常通常可指出平衡中的錯誤;
   • 用心觀察那些玩家花費大量時間的地方; 增加難度或縮減難度;
5. 發佈後對遊戲進行平衡：
   
   • 如果某個修改對某些玩家不利,很可能導致他們離開遊戲;
   • “相對於修復,保留這個失衡的地方是否會導致更多的問題” – “是”,那就應該修改;
   • 在修改前將問題告知玩家,並解釋該失衡會對遊戲的造成的危害;並儘可能補償受影響玩家;
   • 提供論壇,便於玩家提供建議或看法;
6. 對新功能進行平衡:
   
   • 即使加入非常小的功能,在和其他功能相互作用後都可能帶來嚴重後果;須廣泛測試避免失衡;
   • 建立測試服,鼓勵玩家訪問並使用它,這樣,設計人員可安全地調節數值,降低發佈後不良影響的可能;

【用支付矩陣來設計遊戲平衡和AI】

1. 支付矩陣：博弈論概念,表示博弈中兩個或多個參與者在做出不同決定時的收益和損失;

2. 囚徒困境：
   

   簡單的格鬥遊戲及其納什均衡:
   

3. 延遲和停止：定義每個狀態所需最少和最多時間,然後爲每個狀態添加一個轉換表,顯示該狀態完成後可進入哪些狀態;

4. 自動化：
   
   • 自動化的矩陣測試; 記錄模擬/遊戲中的戰鬥日誌;
   • 選定敵對者後識別他們可選的動作列表建立矩陣,對當前合法的目標狀態進行估價後選則新狀態,從而構造複雜的AI系統;
   • 估價函數是該AI系統複雜的部分,它必須考慮AI的當前狀態及每個合法行爲的支付;
   • 要在選項中做出選擇,加權隨機數可用來創建一個簡單的[模糊邏輯系統];

【使用用例來描述遊戲行爲】

1. 用於設計人員和程序員之間進行關於遊戲需求的交流,把遊戲設計中的創造性思想系統地映射到一個技術性的設計模型上;
2. 每個用例代表了一個離散的行爲單元,它具有定義清晰的作用域、清楚的步驟以及明確的前提條件和後置條件;
3. 識別用例：
   
   • 角色：展示行爲的實體; 角色通常位於系統的外部; 比如玩家角色(PC)、NPC、怪物;
   • 事件：需識別出產生事件的對象,併爲每個事件提供一句話的描述;
   • 規則：一個事件是一件單獨的事情;一個事件可以用一句話簡單地描述;
4. 用例中的元素 – 一個標準模板：
   
5. 用例模型圖：
   
   • 爲系統的作用域提供可視化表示;
   • 識別用例之間的關係;
   • 有助於重構和組織相關的用例來進行子系統設計;
6. 開始實現：不建議從用例直接編碼,而是在用例基礎上建立更充實的設計模型(特別是序列圖);
   
   • ①序列圖 – 使開發人員有機會能更詳細地考察類接口和對象互動,隨着對對象和方法進行詳細說明,可逐漸建模一個類結構;
   • ②候選抽象概念 – 確定宿主結構; 第一步,識別用例步驟中的名詞,將候選的抽象概念具體化爲類、數據結構或重要屬性;
   • ③對抽象概念的分析 – 例如武器抽象:
     
     • 武器等裝備與其他類物品有何不同?
     • 是否不能裝備某些其他物品?
     • 是否每個裝備了的物品都可以作爲武器使用?
     • 爲了讓模型更簡明,排除那些不會成爲類、數據結構或屬性的候選抽象;
   • ④開發一個類結構 – 通過研究候選對象,幫助建立遊戲的結構視圖;
     隨着編寫更多的用例,遊戲的行爲和結構建模將更爲充實;
7. 用例的指導方針：
   
   • 描寫待解決的問題,而不是解決方案;
   • 迭代–用例是探索工具; 從一個與其他未實現的子系統依賴很少的子系統開始,儘可能實現,接着編寫相關子系統用例;
   • 面對面的合作–設計文檔很重要,但程序與設計的溝通與合作更重要;
   • 不要指望用例可以捕獲所有需求 – 例如安全、性能、延遲、運行期支持(行動報告/客戶支持調停)等無法構建用例;
   • 交流 – 在向團隊領導、製作人、計劃經理及其他團隊成員描述正在開發的遊戲時,作用巨大;
   • 避免線性思考 – 刻板堅持第一印象會遺漏重要的遊戲需求或識別出無效需求;
   • 不要過於強調工具 – 超大型項目可能從某些工具受益,但多數情況會成爲負擔,最後造成放棄用例;
   • 把重點放在清晰的交流上而不是格式上;
   • 避免把注意力集中在客戶端服務器細節上–比如哪個操作服務端執行,哪個在客戶端執行等;
   • 把遊戲和UI分離開 – 用例不應關心UI交互,比如按哪個鍵/菜單會導致某某行爲; UI是UI,遊戲是遊戲,要分離,各自進行用例描述;
   • 不要強求完全覆蓋 – 比如網絡、數據庫、進程管理等技術早已被實現者良好理解的,不需強求建立用例;

【使用生命值來設計轉換因子】

1. 根據物品造成/治療傷害的能力爲其賦予適當的價值,並以此爲基礎,確定遊戲經濟系統中大多數物品的價值;
2. 武器的價值：
   
   • 根據武器損壞/可使用前所能造成的所有傷害來決定其價格,而不只是把價格建立在其造成傷害的速度上;
   • 假設一枚貨幣等價於一點生命值,該基礎值可在以後調整;
   • 價值 = 攻擊次數 * （損壞後的平均攻擊力 + (全新時的平均攻擊力 - 損壞後的平均攻擊力) / 2）
   • 修復價格 = 基本成本 * 損壞百分比的平方 (鼓勵玩家儘早修復武器,越晚越貴)
3. 治療、防具和減輕傷害：直接把生命值大小映射到貨幣就可確定它們的價格;
4. 從NPC獲得的戰利品：
   
   • 戰利品價值 = (玩家武器的損壞 + 玩家防具的損壞) ; [統計角度]戰利品價值 = 2 * 玩家武器的損壞;
   • 總損壞量決定戰利品參考價值,即每個怪物平均會帶多少戰利品; 或者,知道怪物戰利品和減傷效果,即可確定其生命值是多少;
   • 玩家武器的損壞 = NPC受到的傷害 + NPC防具的損壞; 戰利品價值 = 2 * (NPC受到的傷害 + NPC防具的損壞);
5. 製造業：
   
   • 遊戲中若有貿易功能並且允許玩家制造武器,就應鼓勵玩家使用製造技能;
   • 部件價格之和不能超過武器價值,否則玩家不會去製造它們;部件價格也不可遠低於武器價值,否則成了印鈔機,破壞經濟系統;
   • 必須確定玩家通過製造物品並且用低於NPC商人的價格出售可獲得的最大利潤,得到這個值後,就可確定部件的組合價值;
   • 如果發現部件成本太低,可通過增加製造過程中的人力成本來進行調整;
6. 無關物品：
   
   • 有些物品與治療/傷害毫無關係,可藉助已知物品來得到與其他數據一致的價格;
   • 一旦對某個新物品類型中的某些物品初步定價後,就可通過配方把這些物品關聯起來以保持它們彼此間的一致性;
7. 校驗：
   
   • 交易日誌 – 將玩家間的交易價格和預設價格比較,如果實際交易價格有差異或交易量突然上下起伏,可得知價格制定有錯誤;
8. 總結：切記一味遵循這些轉換因子和定價方式; 這些只是用來幫助平衡的方法; 掌握基本思想,即可對物品價格進行各種變化;

【在MMP遊戲設計中加入故事情節】

1. 爲了一個更有意義的MMP：
   
   • 單機遊戲 – 設計需要更多的考慮故事情節、擬人化的角色交互以及爲玩家的行動創建一個更廣闊更有意義的環境;
   • MMP遊戲 – 爲一個典型RPG遊戲創建40~80小時詳細線性遊戲經歷,需要數百個月,傳統單機方式不適合,需要更具伸縮性的方法;
2. 遊戲與故事情節–尷尬的結合：遊戲的開放性與玩家對故事結構的期望是衝突的;
   
   • 遊戲劇情裏,玩家處於一個預定的故事結構之中,又想真正地擁有對結果的決定權,他們往往處於兩者的折中中;
3. 故事情節在遊戲中的功能：
   
   • 故事情節爲遊戲提供了結構；
     
     1. 創造一個熟悉而有結構的切入點(日常生活中人們接觸到的多數娛樂都是基於講故事的);
     2. 創建了一個隱含的線性發展過程,利用玩家對故事情節發展的基本期望,推動故事,滿足需求;
     3. 故事情節的存在保證了結局的存在 – 人們都希望在看故事的時候能夠看到結局;
   • 故事情節使玩家的行動更有意義；
   • 通過把行動和“戲劇性場景”結合 – 比如爲營救戀人殺6個怪物與爲戰鬥樂趣殺死6個怪物是截然不同的;
   • 使玩家更易在遊戲中投入感情 – 使玩家去關心場景,去鄙視壞人,去和英雄一起慶祝等等,把遊戲中有意義的方面聯繫在一起;
4. 挑戰更多的認知能力：
   
   • 遊戲能帶來滿足是因爲玩家可以用交互方式來主動地使用各種認知能力;
   • “純粹玩家” – 涉及認知能力有 反應、觀察能力以及空間和邏輯智能;
   • “劇情玩家” – 涉及不同認知能力如 社交、敘事和情感智能;
   • 玩家更傾向於測試反應和空間能力的遊戲,如《LOL》; 但《模擬人生》的成功展示了遊戲也可使用和挑戰玩家的社交和情感能力;
   • 當遊戲中行動具有特定意義時，玩家會主動使用範圍更廣的認知能力;
5. 使用有意義行動的最佳場所：
   
   • MMP遊戲沒有保存和重新開始,始終存在並持續發展,可以提供獨一無二的“真實”感覺;
   • MMP遊戲特別之處就是讓玩家在(以身體、情感、社交等方式)做出行動時能被別人看見;
   • 如果遊戲中唯一有意義的行動是機械的角色升級,那麼玩家無法成爲英雄或壞人,也就無法歸屬於這個世界;
6. 爲MMP遊戲模式加入故事情節：
   
   • 在那些具有進展的遊戲元素中加入故事情節 – 比如角色升級;
   • 通過創建背景來建立一些遊戲世界中的戲劇性場景 – 爲遊戲行動建立上下文從而使行動自身成爲一個逐漸展開的故事;
   • 創造機會讓玩家捲入那些具有故事形式的公衆事件或場景中去 – 使他們具有某個共同的目標就是一個很好的例子;
   • 1.把角色升級作爲故事 – 可用獎勵系統來確保並加強遊戲行動的故事性,回報不一定是物質的,可以是榮譽、聲望、社會地位等可衡量的;
   • 2.發掘戲劇性場景 – 背景故事和遊戲真正目的必須協調;
     戲劇性場景可用於單個角色、某個區域、整個遊戲世界;
     爲了更令人信服,戲劇性場景需”寫”入遊戲世界中,簡單或毫無新意並不重要,重要的是行動; 比如區域對抗,立雕像;
7. 公共目標：創造具有獨特生命力的、動態而一致的遊戲元素;
   
   • 目標 – 能根據玩家行動而變化,且未來不確定; 例如《率土之濱》歷史進程與州對抗; 《魔獸世界》安其拉開門等;
   • 危機 – 需玩家長時間持續行動才能解決的動態危機; 譬如某區域產生很多敵人對一條重要貿易路徑帶來危險;

【客戶服務和玩家聲望:一切都和信任有關】

1. 搗亂：指在遊戲規則允許的範圍內,故意通過一些方法來激怒、威脅或騷擾其他玩家;經常在沒明顯真實動機的情況下;
2. 規則只是工具：如果不適應遊戲設計的意圖,再好的規則都可能會被破壞或濫用;
3. 意圖：不能單憑玩家自身的行動去猜測他的意圖;
4. 客服部門：爲了解決那些開發團隊無法通過遊戲機制來發現或解決的問題、觀察有問題的玩家、以及貫徹執行服務條款協定;
5. 聲望：1. a.一般人所能看到和判斷的總體質量或特性;
   b.別人對某些特性或者能力的承認;
   2. 受到公衆尊重或尊敬的地方：好名聲; 比如淘寶的差評或好評;
6. 正當行爲：聲望系統用來阻止儘可能多的不良行爲,還可用來鼓勵/獎賞遊戲社區中的良好行爲;
   仔細平衡良好聲望的獎勵是很重要的;
   1.當人們對於和別人的交互感到高興時,應該讓他們能夠表達出來;
   2.以一種平衡的方式來獎勵良好行爲;
7. 惡意行爲：聲望系統還應該能阻止惡意行爲;
   1.必須給那些公認的”壞”人一些懲罰以促使他們改變或把他們從遊戲社會中趕走;
   2.讓玩家指控其他玩家的不良行爲時,他必須小心的斟酌他的決定;
8. 不能以封面來判斷一本書的好壞,同樣,對人也不能以偏概全：
   
   • 要判斷一個玩家的好壞,不能只根據幾個人的說法,而要根據他們對社會的實際影響;
   • 要根據玩家的行爲模式來判斷他們是不是在長期地搗亂;
9. 行爲模式跟蹤方法：阿佛加多信任度量; 貝葉斯分析;
10. 使用聲望：
    
    • 避免把評價過程變得很麻煩,和其他功能一樣,玩家需要儘快確定他們在和誰交互以及他們的感覺;
    • 要讓客服部門把聲望系統作爲一個讓遊戲社區處於正規的主動工具來使用;
11. 1. 當玩家與另一玩家進行了一次良好交互後,這個玩家想給他的不僅是一句”謝謝你”;
    2. 當玩家與另一玩家進行了一次不好的交互後,他需要某種立即的方式來讓對方及其他玩家知道他的感覺;
    3. 它允許玩家用很長時間來樹立一個他們是怎樣對待其他玩家或與其他玩家進行交互的真實形象;
    4. 有良好行爲的玩家應該受到獎勵;
    5. 玩家應該對他們的社區有真正的控制權;

【MMP體系結構】

【製作仿真框架,第一部分:結構建模】

1. 體系結構縱覽：
   
   • 1.客戶/服務器組件 – 網絡抽象層 → 分發消息數據包 → 遊戲仿真層接受消息並處理,保持客戶端和服務端遊戲狀態空間的一致性;
   • 2.通過代理仿真 – 服務端遊戲仿真層保留對遊戲狀態空間的唯一精確表示,通過請求交互; 永遠不要信任客戶端對於狀態空間的表示;
2. 支持類：
   
   • 詞典類/哈希表 – 詞典類是抽象數據類型,存儲按值訪問的元素;
   • 仿真事件 – 系統中的事件對象,包含了事件類型、源標識、目標標識、參數以及頻道(讓接受者過濾只獲得感興趣的事件);
   • 仿真狀態：該類是系統對狀態模式實現的一種描述; 狀態的基類 – CanTransition(能否轉換)和Transition(進行轉換);
   • 動作狀態：該類標識那些典型的遊戲仿真操作,譬如擊打對手或打開一扇門;
   • 控制狀態：定義了與它關聯的行動者可以從哪裏接受命令; 還可用在基於觀察的訓練中;
   • 用戶控制狀態：維護了一個等待執行的動作請求列表,這些動作由客戶端發出併爲服務端所接受；
   • AI控制狀態：負責確定用於執行的合適動作; AI技術（有限狀態機、行爲樹、神經網絡或者模糊邏輯）;
3. 核心類：
   
   • 1.仿真對象類SOB：所有由仿真層處理的核心類的基類,包括Actor、Area、Item、Obstacle(障礙物);
     
     • 可包含其他SOB – 會維護一個內容詞典(contents) 及 一個所有者標識(ownerID);
     • 聯繫詞典links – 維護與其他對象之間的聯繫,提供SOB之間的聚合或”整體/局部”的關係;
     • 屬性詞典Property – 以數據驅動的方式存儲每個對象特定於遊戲系統的屬性; 比如對象的位置/移動速度/生命值等;
     • 持久化機制 – 用一個通用的方式和存儲系統合作; 維護dirty標識,數據變化時設置,Store定期檢查進行保存或Restore;
   • 2.執行者Performer：爲Actor和ActorProxy類提供了在客戶和服務端共享的功能及接口;
     
     • 調度優先級 – 實現對調度的仿真;
     • 當前動作狀態 – 標識該對象當前所執行的動作,由PerformAction(執行動作)方法確定並進行設置;
   • 3.行動者Actor：能與仿真環境進行交互的服務端SOB;
     
     • 控制狀態 – 使其能被不同的空置房(agent)控制,包括玩家/AI或腳本驅動的過場動畫;
     • eventQueue – 批量存儲事件,延遲到下一次PerformAction被調度執行時一併處理;
     • ReceiveEvent – 可把需要立即處理的事件過濾出來,而不是放到事件隊列eventQueue中;
   • 4.行動代理ActionProxy – 行動者在客戶端的副本;
   • 5.非執行者類 – 那些不需要和仿真環境直接交互的核心類. 物品; 障礙物; 代理對象; 區域;
4. 管理器類和工廠類：以單例模式實現; 初始化時創建直到仿真層終止;
   
   • 1.仿真對象工廠 – 負責創建SOB並確保他們具有獨一無二的標識;
   • 2.仿真對象管理器 – 負責維護一個仿真對象的詞典; 提供ID查找對象引用、保存、載入;
   • 3.調度管理器 – 調度活動的執行者仿真對象,以安排時間調用它們的PerformAction回調方法;
   • 4.查詢管理器 – 爲在運行時訪問靜態遊戲數據提供了一個快速高效的機制;
5. 仿真類：把支持類、核心類和管理類包裝成一個良好的頂層接口方便管理;

【製作仿真框架,第二部分:行爲建模】

1. 把用戶和行動者關聯起來：
   
   • 服務端和客戶端SOB都提供AttachUser(連接用戶)和DetachUser(斷開用戶)的方法實現; 可實現接管玩家角色、變換玩家視角;
   • User(玩家)可被映射到服務端某個行動者實例以及與之對應的客戶端行動代理對象上,SOB根據狀態判斷是否接受連接;
2. 動作請求：ClientSOB → SendActionRequest → Server → ActorSOB eventQueue;
3. 動作調度：物理層:Tick() → 服務端仿真層:ProcessTasks() → 調度管理器:PerformAction() → Actor:ProcessEventQueue;
4. 事件廣播和處理：
   
   • 當行動者試圖進行轉換時,獲取控制狀態對象的目標動作狀態,隨後檢驗是否可轉換,進行切換或忽略;
   • 活動的SOB維護着一個訂閱者詞典(對其動作感興趣的其他對象可進行登記),通過調用訂閱者的ReceiveEvent方法進行通知;
5. 服務端事件處理：當事件訂閱者收到事件後,會傳遞給這個類型的事件所對應的事件處理程序,若該對象有用戶連接,則發送給客戶端;
6. 客戶端事件處理：事件消息 → 客戶端 → 行動者管理器 → (創建/查找)對應的行動代理對象;
7. 客戶端代理：行動代理對象:收到消息 → 查找合適的處理程序 → 處理 → 狀態轉換 → 通知;
8. 仿真與表示分離：觀察者設計模式; 遊戲的代理動作狀態類作爲被訂閱對象,當狀態改變時,通過自身的Notify方法,通知觀察者Update;

【爲遊戲腳本創建一個”安全沙盤”】

1. 腳本語言與MMP開發：
   
   • 網遊不僅需要持續地保持可靠性,還需經常更新內容;
   • 使用腳本語言實現經常變動的內容(如任務,UI等),可在不斷改進和修正的同時,保證代碼的可維護和穩定性;
2. 使用沙盤的理由：
   
   • 上層系統 – 遊戲規則/有趣的部分,會頻繁的修改(進行遊戲平衡、加入特殊事件、加入新物品/技能時);
   • 底層系統 – 網絡、數據庫接口、物理、移動、駭客檢測等,極少需要修改,且每次修改都必須非常小心;
   • 遊戲編碼和內容維護應當避免的做法:
     
     • 在正常的框架以外任意地創建和銷燬遊戲對象;
     • 直接控制遊戲中對象的移動、位置和方向;
     • 爲了適合特殊的關卡而對AI或尋路算法進行有條件的調整;
     • 繞開遊戲數據庫並且把遊戲數據寫到本地文件系統中;
     • 直接打開一個連接到其他服務端/客戶端的套接字,而不是使用現有的消息系統;
     • 直接嵌入SQL來查詢/更新數據庫,而不是通過現有的數據更新和讀取接口;
     • 向遊戲客戶端發送任意的文本消息;
     • 對某個現存子系統的使用與其設計目的不一致;
3. 安全沙盤的設計：
   
   • 1.需限制腳本語言提供的服務,控制底層系統中哪些可用;
   • 2.安全沙盤的關鍵元素:
     
     • a.定製缺省的受限執行環境以滿足遊戲的需要;(比如禁用Python某些模塊,用某些函數替代原始函數等);
     • b.支持對某些特定對象/屬性的訪問,同時禁止未經授權的訪問;
     • c.包裝對象和對象的屬性,對其進行保護;
4. 在安全沙盤中編寫遊戲代碼: 無需處理權限和數據保護,沙盤框架已進行處理;

【大型多人遊戲中的單元測試】

1. 爲什麼需要單元測試：
   
   • 可在開發過程中保證代碼的完整性,尤其是在整合過程中;
   • 在遊戲發展過程中,它可以在成品代碼中使引入錯誤的風險最小化;
   • 單元測試、持續代碼整合、小型發佈、結對編程、集體擁有代碼等組成敏捷開發;
2. 單元測試的定義：
   
   • 1.單元的定義 –
     
     • 須具有良好定義的接口且對其他單元的依賴較少;
     • 定義單元最有效的方式 – 從最底層或最基本的類開始,向系統上方進行直到高層類被定義;
   • 2.數據集的定義 –
     
     • 內部數據集:可直接硬編碼在單元測試內以提供一/多組數據用於測試;
     • 外部數據集:從文件、數據庫、套接字等單元測試代碼以外的其他資源中讀取數據;
     • 確保這些數據在測試時總是存在,並且在多次測試後不會改變; 保證其完整和一致！
   • 3.測試的定義 –
     
     • 應對所有衍生數據(根據單元狀態計算出的數據)或改變單元狀態的方法進行測試; 無需測試那些簡單獲取/改變數據的方法;
3. 單元測試框架：
   
   • 使用語言對應的xUnit等測試框架;
   • 儘可能使用簡單的測試方法;
4. 測試先行的設計:
   
   • 在編寫代碼前編寫測試代碼 – 測試真正需要測試/可能會出錯的代碼;
   • 編碼的步驟 –
     
     • 1.爲一個還不存在的函數或方法編寫測試代碼;
     • 2.必要的話,編譯測試代碼; 編譯將會失敗;
     • 3.通過編寫測試的函數或方法的存根版本(無實際功能,僅用來通過編譯)來修正編譯錯誤;
     • 4.運行測試:因功能未實現,測試將會失敗;
     • 5.通過編寫被測函數或方法的函數體來修正測試錯誤;
     • 6.運行測試:如果失敗,修正代碼; 如果成功,編寫另一個測試;
     • 7.重複1-6的步驟;
   • 讓自己成爲最初的受害者 – 從使用者角度編寫,是功能的作者也是設計決策的第一個受害者; 更快的理解設計決策所帶來的影響;
   • 單元測試和重構 –
     
     • 1.辨認出那些需要重構的代碼;
     • 2.編寫單元測試來證明現存的代碼能夠工作;
     • 3.開始重構,對代碼進行微笑的、慎重的修改;
     • 4.重新編譯並且對每個修改運行單元測試; 單元測試將失敗;
     • 5.重寫測試使得它符合新的代碼;
     • 6.重新運行測試,如果代碼能工作,繼續重構; 如果測試失敗,修正新代碼;
     • 7.重複1~6步驟;
5. 使用因素:
   
   • 測試過程自動化 – 從代碼庫獲取新代碼 → 編譯鏈接 → 運行所有單元測試 → 向團隊報告結果; 每天測試,失敗時優先修復;
   • 獨立的測試程序 – 使用獨立的可執行程序以批處理方式調用所有測試,每當代碼有新測試加入,自動加入,並可生成報告發出郵件/網頁;
   • 集成的運行時測試程序 –
     
     • 在運行環境中執行測試,單元測試可對宿主進程提供的資源進行訪問;
     • 不要讓對測試框架的調用破壞產品代碼;
     • 調用點應只有一行代碼,用來調用一個函數(測試識別、初始化、執行和報告等)以啓動測試過程,這樣就可通過條件編譯選項去除該函數;
   • 測試異步執行的代碼 – 關鍵點就是要在被測試代碼執行的同時強制單元測試等待異步代碼執行完; 系統函數或測試包含主循環;

【使用Twisted框架進行MMP服務整合】

【Beyond 2:構建虛擬世界的開源平臺】

【使用並行狀態機來創建可信的角色】

1. 狀態模式：利用多態爲同一個對象的不同狀態定義不同的行爲;
2. 並行狀態層：若某個功能與某一層中其他功能只能以互斥的方式執行,就放入該層中;而可獨立或併發執行的功能則放入不同層次;
   
   • 移動層:處理角色在遊戲世界中移動相關的問題; 停止 - 前 - 後 - 左 - 右等移動狀態;
   • 姿勢層:(下半身行爲)處理角色在移動時的外觀; 站立 - 坐下 - 步行 - 跑步 - 墜落 - 游泳 - 騎馬 - 平躺; 用途:
     
     • a.通知動畫子系統什麼時候該改變這個角色正在播放的動畫;
     • b.接受或拒絕用戶界面提出的狀態改變請求;
   • 行動層:(上半身行爲)處理角色可以進行的各種行動; 空閒 - 製造 - 施法 - 戰鬥 - 做手勢 - 出生;
3. 狀態管理器：維護了每個狀態層當前狀態的引用 – 當前行動狀態、當前移動狀態、當前姿勢狀態;
4. 跨層阻止：多數情況每層的狀態可獨立於其他層次執行,但總有例外,比如設計玩家處於空中時無法做出任何行動;
   
   • 實現 – 在移動抽象層增加blocked布爾變量,通過Block和Unlock方法設置或清除; 狀態轉換時判斷blocked,爲真表示不可轉換;

【使用觀察者/可觀察者設計模式】

1. 觀察者和被觀察者：
   
   • 一個被觀察者對象具有其觀察者的引用集合;
   • 當被觀察者對象被修改時,調用所有觀察者的Touch()/Update()方法通知它們;
   • 當觀察者要獲得被觀察者對象的狀態時,首先檢查該對象是否已被修改,然後查詢被觀察者內部狀態並更新自己的內部狀態;
2. 基本結構：
   
   • 該設計模式可使客戶端和服務端使用完全相同的類;
   • 在服務端,對仿真觀察並把檢測到的改變傳到客戶端;然後客戶端使用同樣的仿真對象並使用一個圖形觀察者來觀察它們;
3. 服務端架構：
   
   • 由仿真對象、相應的通訊觀察者以及通訊管理器組成;
   • 更新消息 – 服務端循環處理所有的仿真觀察者,如果某個觀察者被標記爲髒,就查詢其內部狀態以獲得一個將要發送給客戶的更新緩存;
     服務端保留該緩存,並生成一個包含了觀察者標識的修改消息,讓通訊管理器發送,客戶端接受消息後,進行同步處理;
   • 創建消息 – 服務端創建新的仿真對象 → 創建對應的通訊觀察者並掛接到通訊管理器 → 發送類標識和對象標識 → 客戶端接收後創建 → GUI;
   • 刪除消息 – 根據觀察者標識 → 銷燬對應的所有觀察者並從通訊管理器中移除 → 向所有正在監聽的客戶發送刪除消息 → 銷燬;
   • 新客戶消息 – 當新客戶訂閱仿真時,必須先接收仿真中所有對象的創建消息;
     傳輸時基於優先級,最高的最先被更新,其次下個循環再更新,防止佔用大量帶寬引起性能問題;
4. 客戶端架構：
   
   • 由仿真對象、相對應的圖形觀察者和一個通訊控制器組成(處理方針對象的創建、修改、刪除);
   • 每個仿真對象實現了可控制接口,用來解包服務端發來的消息並且更新它們的內部狀態;
   • 創建消息 – 獲取類標識 → 控制器獲取相應類型 → 創建具體控制器類 → 加入映射 → 後續消息即可被髮送給正確的實例了;
   • 更新消息 – 通訊控制器 → 獲取標識映射到的對象實例引用 → 更新緩存發送給對象 → 對象的Unpack(解包)方法處理;
   • 刪除消息 – 銷燬相應的可控制對象(析構函數應銷燬所有的圖形觀察者),並刪除所有對它的引用;
5. 增強：
   
   • 差別觀察者 – 當某個屬性改變時,必須用屬性索引/標識調用Update(),而後只打包被標記的已修改內容,達到節省帶寬的作用;
   • 每個連接一個觀察者 – 低速接收者積累一段時間的數據後調用SendChanges(),高速接收者每幀發送改變;
     爲所有觀察者建立一個在獨立線程中運行的公共隊列來避免通知延遲;
   • 優先級和視野 – 只發送客戶視野範圍內對象的更新;
     遊戲系統需實現一個方法來檢查某個對象是否在給定客戶的視野(九宮格/十字鏈表等AOI);

【服務端開發】

【無縫服務器:優點和缺點】

1. 殺死怪物不止一個方法：
   
   • 1.分割物理和遊戲計算 – 把檢驗角色移動、碰撞等物理空間計算與遊戲部分分離,並使用獨立服務器處理;
   • 2.讓AI獨立運行 – 把AI分離到獨立服務器中,缺陷是AI通常依賴玩家角色等遊戲對象屬性,需要對數據進行復制,帶來明顯的同步問題;
   • 3.“暴力”方法 – 使用更強大的服務器; 使用多線程;
   • 把遊戲世界分割爲更小的部分伸縮性更好,同時便於在不影響當前服務器負載的情況下添加更多的遊戲內容(比如新大陸);
2. 無縫世界模式的原型：
   
   • 分割遊戲世界 – 二維或部分三維遊戲可按照網格劃分; 對於那些真正的”6度空間”仿真遊戲來說,八叉樹等方式細分空間更適合;
   • 平均分配 – 相鄰區域的共享邊界,最小應與客戶端的遊戲世界或玩家的可感知範圍一樣大,再小會造成視野差別;
   • 詳細的代理對象還是精確的代理對象(兩者不可兼得) – 邊界區域中的對象可跨越服務器邊界進行交互;
     
     • 當對象進入邊界區域時,所在服通知相鄰服,使其創建代理對象來表示遠程對象;當其從邊界移至鄰服”內”時,該代理對象將被銷燬;
     • 代理對象需提供多少信息 – 必須包含位置、方向及對象類型等基本屬性; 對象屬性賦予優先級,儘快或延遲更新;
   • 定義邊界線 – 當對象越過”剛性”服務器邊界時,它的所有權會立即轉移給鄰服,沒任何延遲; “柔性”在轉移前只允許”略微跨越”邊界;
   • 靜態或動態邊界 – “靜態”不可變; “動態”根據負載(玩家數/AI數)調整邊界,必須通過一個原子事務低延遲的把一組對象整體轉移;
3. 無縫世界模式的有點：
   
   • 擁有更大的遊戲空間 – 而分區遊戲區域大小受限於單個服務器所能處理的玩家數量; 一個更大的遊戲世界與更好更有趣的遊戲無必然聯繫;
   • 可伸縮性和可靠性 – 動態平衡調整以適應不斷增加的負載; 靜態亦可停機時根據玩家數量和分佈調整;
   • 不確定的邊界線 – 錯誤常與服務器間來回移動數據有關,動態不確定的邊界可降低玩家對這些錯誤的濫用行爲,但錯誤必須找到並修正;
   • 不需要載入地圖 – 載入操作會被平攤到遊戲世界每一個分塊,僅在需要時纔會被載入;
4. 無縫世界的缺點：
   
   • 不確定法則:不僅僅是客戶端 – 每個玩家有自己的視野,多人遊戲必然引入不確定性,而客戶端必須對其進行處理(航位推測法);
     服務端代理對象不可能和其對應的真實對象完全同步,交互需通過異步處理,而缺乏同步是很多錯誤的根源;
   • 對設計的影響 – 系統複雜會出現大量競爭和失敗問題; 這會直接導致開發週期延長/使遊戲更不穩定;
   • 示例:給一個物品 – 詳細見P182事件序列; 複雜度是單服操作的好幾倍;
   • 構築遊戲世界/美工 – 地形建模、貼圖繪製、對象放置等,分塊操作,整合等需特別小心處理; 尺寸需小於邊界大小;
   • 運營和擴展 – 常見問題爲”物品複製”,根本原因是競爭條件,代理和相應的對象不能保持完全同步會導致大量”失效狀態”錯誤;
   • 對額外的複雜度處理失當 – 比如只支持同服玩家交易,會暴露邊界,爲更多的遊戲侵入行爲打開大門(比如反覆跨服休整後打BOSS);

【服務端對象的更新頻率】

1. 視覺連貫性與精確度：目標是視覺和感覺上都很好,即使犧牲一小部分視覺精確度; 指導方針是”如果玩家發現不了,那就不要緊！”
2. 需要發送哪些數據：
   
   • 環境變化 – 極高的優先級; 不一致會造成大量碰撞和同步問題,環境數據應包含打開/關閉的門及旋轉風車等循環移動等;
   • 玩家之間/玩家與NPC的交互 – 戰鬥信息至少需要和環境變化一樣及時; 交易聊天等可略微延遲;
   • PC和NPC的移動 – 服務端必須以足夠高的頻率發送其移動信息,保證玩家視覺上感覺是連貫的;
3. 帶寬限制：
   
   • 更新頻率 – UDP包頭28字節,TCP包頭72字節; 頻率高會使包頭部分消耗額外帶寬; 頻率低會加重視覺上的跳躍和偏差感,丟包影響大;
   • 分區的地形和連續的地形 – 分區地形會自動爲最遠範圍賦予上限,連續地形中需使用額外代碼確定界限;
4. 每個用戶在服務端需要的數據：每個玩家在服務器上都應有一個發送隊列和位置列表(包含最近幾次發送更新時玩家的位置),且長度相同;
5. 管理數據的大小：應建立某種機制將遊戲環境劃分成區域,在這些區域中可方便知道某個特定玩家的視野中有哪些玩家(比如九宮格AOI);
6. 更新隊列：玩家發送隊列由一系列時間槽組成循環隊列; 循環更新(比如位置)發送後移動到特定槽(控制頻率),一次性更新(比如聊天)發送後丟棄;
7. 缺省的更新頻率：近距離物體頻繁更新,遠距離放緩更新;
8. 計算範圍：
   
   • 精確的範圍計算需要大量CPU時間 – 等式3-1(P190);
   • 可用曼哈頓距離等方法近似處理 – 等式3-2; 可計算出從一點走到另一點時所需經過的正方形街區數;
   • 得到近似距離並知道最大的可視範圍,即可通過線性函數計算出更新應置入哪個時間槽中;
9. 調整優先級：
   
   • 長時間保持靜止的PC和NPC,服務端可以一開始就發送位置,之後偶爾更新以防數據包的丟失;
   • 處於同一羣組的玩家 或 被選爲目標的PC/NPC,應提高更新頻率; 這表示玩家想要了解目標更多信息;
   • 根據玩家過去的位置列表調整 – 比如停留超過幾秒則調低頻率, 直線奔跑可預測中等頻率, 不規則轉向或移動使用更高頻率;
10. 調整隊列：若玩家優先級調整突然發生很大變化,應在隊列中加入一個新的更新(一次性的);

【MMP服務器開發和維護】

1. 正在使用什麼服務器：讓系統的每個組件都向與它連接的其他組件報告版本;
2. 應該和誰建立連接：將可連接的服務器等信息集中放在一個隨時可訪問的地方比如一個網頁上;
3. 怎樣才能知道角色出了什麼問題：
   
   • 服務端應儘可能向客戶端提供精確有用的出錯反饋,比如錯誤代碼;
   • 讓用戶可看到服務器日誌或日誌的某些合理部分,比如使用服務器進程日誌網頁;
   • 不斷監視所有服務器 – 用腳本週期性檢查可能問題,比如網絡、進程、內存等問題,並轉發給開發團隊;
4. 對複雜度進行管理：
   
   • 分支:
     
     • a.堅持使用命名規範(包含”Dev”),所有測試服都必須進行相應的命名;
     • b.爲開發服務器和運營服務器建立獨立的環境,不要交叉;
     • c.應使用一個自動構建系統來進行每日構建和用於檢查的構建;兩臺獨立電腦來構建運營和開發版本;
   • 共享代碼 – 服務端和客戶端怎樣構建？是否相同的OS構建？是否相同OS和硬件環境下運行？
     客戶端和服務端代碼共享還應考慮是否隱藏了服務端內部實現;

【使用Python進行精確的遊戲事件廣播】

1. 事件驅動編程：和線程相比,事件是非搶佔式的,只在調用時才執行,且持續執行直到任務完成;
   
   • 同步和異步調用 – 同步(阻塞)調用在執行完前不會把控制權返回給調用者; 異步(非阻塞)調用立即返回,獨立於調用者的執行而繼續執行;
   • 併發模擬 – 通過把玩家的請求分解成原子操作,在每個遊戲循環裏依次處理,因完成時間短,會製造出併發處理的假象;
   • 高級遊戲事件 – 比如遊戲世界中的物品、其他玩家或是關鍵的遊戲系統進行交互; 底層(網絡/物理/碰撞)則可提供鉤子;
   • 遊戲服務端主循環 – (WaitForRequests() → ProcessRequests()); 請求包含客戶端玩家請求/遊戲某次循環的異步調用;
   • 事件和線程並不是互斥的 – 主線程遊戲循環,其他線程對網絡消息等進行處理,通過一個隊列放入取出請求;
2. 延遲調用：使用請求的方式來對函數或者方法進行調用,從而使它們可以在未來的某個時間被處理;
   
   • 6個主要元素 – a.調用的目標對象; b.調用本身; c.調用的參數,必須符合形參列表; d.調用的執行時間,這必須是將來的某個時間; e.當延遲調用完成後所調用的回調函數; f.回調函數的參數;
   • 延遲調用接口 – Call(target, call, args, delay, cb, cbArgs);
   • 延遲調用的實現 – a.延遲調用必須能被緩存在某種類型的容器裏,並可在以後取出; b.延遲調用不能在期望的執行時間之前執行,若安排在同一時間,則依據FIFO(先進先出)方式被處理;
   • 調用 – 與普通函數調用區別在於怎樣指定所調用的對象和方法;決定是否提供回調函數接收通知;
   • 延遲調用缺點 – 調用方必須知道被調用的目標對象的標識; 遊戲中的事件往往導致某些動作的執行,狀態的改變,調試和維護會變得困難;
3. 事件廣播：對事件驅動系統的第一個改進 – 在它之上加入一個層次來爲遊戲事件實現廣播機制;
   
   • 遊戲事件 – 一個整形常量標識,用於表示遊戲中發生的某件事情;
   • 事件處理器 – 任何可調用的對象/函數/方法,它們在特定事件發生後被調用;
   • 事件廣播器 – 把事件派發給對其感興趣的對象,這些對象會爲某個特定事件向事件廣播器註冊(register)一個事件處理器;
   • 事件參數 – 事件必須是函數式的,可接受參數以包含更多意義;
   • 使用事件廣播 – 首先爲關心的事件聲明一/多個處理器;接着把處理器註冊到事件廣播,並傳入實現這些處理器的函數或方法的引用;
   • 優勢與劣勢 – 成功解耦了事件發送者和接收者; 事件分發只有一段代碼方便添加日誌和調試; 但會造成很多低效的無效調用;
4. 精確的事件廣播 – 對事件驅動系統的最後改進 – 精確註冊,不僅可指定關心的事件還可指定在什麼情況調用處理器;
   
   • 遊戲事件索引 – 索引可根據事件、事件源和目標組合;
   • 事件索引派生類 – 若要使用更多標準來註冊事件處理器,可從遊戲事件索引基類派生;
   • 使用遊戲事件索引來註冊事件處理器或發送遊戲事件;

【實現移動和物理模塊的注意事項】

1. 可以發佈遊戲嗎：保證足夠的真實性從而讓玩家持續遊戲,並加以足夠限制使遊戲可及時而經濟的被實現; 團隊達成共識;
2. 這是一場戰爭：對設計和實現評估時,必須考慮惡意玩家會怎樣利用這些信息以欺騙服務器;
3. 服務端永遠是對的：比如防止客戶端侵入房屋獲取屋內物品 –
   
   • 先確認是否合法進入,而後才把房屋內容發送給這個客戶端;
   • 要求把房屋中的物品保存在一個固定的保險箱裏,並有一把單獨的鑰匙;
   • 把進入房屋實現成將玩家傳輸到另一區域,這樣就不能僅僅通過移動進入房屋;
4. 移動的代價：
   
   • 假設每秒15個移動數據包(20byte) – 每玩家300byte/s,若同屏20人則需6Kbyte/s,這還僅僅是雕像般的移動; 佔用太高！
   • “暫時頻道”法 – 客戶端仍然產生數據包,但只發送一個更新週期中最新的移動數據; 這對於瞬時信息非常有用;
   • 採樣點:
     
     • a.服務端收到移動數據包時會根據該前一個包做判斷(前後位置以及採樣點合法),若無效發送修正數據包(實際移動),並廣播給附近玩家;
     • b.關鍵要確保兩個位置之間的採樣點距離應小於遊戲中最小的碰撞/觸發體; 避免穿過門等障礙物;
     • c.另一關鍵要對兩次更新的移動距離設置上限; 比如最大速6m/s,每秒更新4次,上限設爲2m,超速修正,防止手工數據包;
     • d.增加欺騙檢測機制,比如記錄玩家最大移動速度歷史,統計非法移動,使GM可針對性細緻監視;
5. 移動速度：
   
   • 應瞭解在遊戲中允許提高移動速度會加大系統對移動數據包的檢驗錯誤;
   • 保守做法是隻允許兩種速度(快速和慢速); 或縮小地圖尺寸比例;
6. 玩家可從這裏到那裏嗎？
   
   • 遊戲世界中的移動 – 開始設計時假定玩家哪都不能去,隨後開闢道路來指定可合法移動到的位置,會相比障礙物阻擋少很多漏洞;
   • 瞬間移動 – 確定有效目的地,無碰撞會使傳輸更穩健,即時偶爾角色重疊,玩家亦會很快移動走;
   • 平移動畫 – 跳躍輕功等,比如瞬移5米,可在服務器確認後開始動畫; 也可立即顯示動畫,失敗時在障礙處被迫停止; 都比無法移動感覺好;
7. 碰撞檢測：基本方針是儘量把在任何時刻必須進行碰撞檢測的物體數量最小化;
   
   • 碰撞體 – 先用一個簡單的幾何形狀來構建碰撞體並用於粗略判斷是否碰撞,若碰撞再使用更細緻的幾何體進行精確判斷;
   • 角色碰撞體 – 使用軀幹圓柱體(不低於膝蓋上方,不高於肩膀),這樣角色不會被簡單物體(如樓梯)阻擋;
     障礙物碰撞體的長寬需大於角色合法移動的最大距離,且高度要高於角色碰撞體的最低點;
   • 角色間碰撞:
     
     • 優勢：a.使遊戲更真實; b.避免角色重合的視覺問題; c.實現簡單,碰撞通用處理; d.更有趣的機制,比如攻城阻擋戰略的實現;
     • 劣勢：a.CPU負荷增加; b.瞬間移動實現難度加大; c.碰撞騷擾(比如阻擋出口等); d.多玩家搶點代碼複雜; e.AI碰撞;
   • 縮放 – 應考慮角色模型大小的多樣性和獨特性; 把握針對不同尺寸變化實施獨特遊戲機制的機會;
8. 物品放置：允許”放置”,使玩家可在遊戲世界留下自己的”標誌”; 比如獲取房屋並裝飾,是非常誘人的;
   
   • 可能被利用的地方:應儘可能避免在公共區域任意的放置物品;
     
     • 在對戰區域放置大量物品,使其他進入玩家暫時失控(因物品數據包會佔用大量帶寬);
     • 通過富有創造性的方式堆疊物品形成通路,進入通常無法進入的區域; 或是站在物品上,收取物品放置到其他地方;
   • 可行方案:
     
     • 歸屬權在一定時間內屬於原主人,之後可被其他玩家撿取,若一段時間未被認領則自動銷燬;
     • 將放置物抽象爲某種通用的容器,類似袋子,並且不能被堆疊也不能放置在其他容器中;
     • 指定一些預定義/可接受的位置用於放置,比如公共基座允許團體放置裝飾;
     • 不允許公共區域放置,只允許放置在安全區域,比如玩家的房屋中;
     • 實現一些四處走動並會拾取放置物品的NPC;
     • 物品只能在預定義的放置處有限疊加,比如畫掛牆上,花瓶放桌上;
     • 發送數據時,與物品相關的信息設置一個上限,賦予那些會影響遊戲的對象更高的優先級,比如有威脅的怪物;
9. 侵入檢測：
   
   • 加密只是爲了贏得更長時間,來持續加固系統以檢測和防止惡意玩家的侵入;
   • 對設計進行評估時,優先選擇那些很難活不可能被侵入的遊戲機制;
   • 記錄玩家行爲,但不要過量也不能影響性能,構建於商業數據庫系統上的異步日誌機制是強有力的工具;
   • 用更多的侵入檢測代碼對有惡意嫌疑的玩家進行更細緻的評估; 比如不停試圖達到允許的移動距離上限玩家,進行更多檢測或通知GM跟蹤;

【客戶端開發】

【客戶端移動預測】

1. 遊戲需良好的移動預測：原因 – 玩家需要獲得即時反饋; 網絡數據包延遲的不確定性;
2. 命令時間同步：
   
   • 即時戰略遊戲如《星際爭霸》必須基於尋路請求來把對象移動到特定的位置;
   • 僅發送”移動X到達位置P”不如”移動X使其在未來的某個時間T到達P”,若客戶端與服務端時間同步,可通過調整X客戶端速度達到精確同步;
   • 服務端通過X的速度V以及最低和最高延遲驗證命令是否正確後,通知所有客戶端X必須在T時刻移動到P;
   • 在調整速度時,注意使用平均速度;爲了平緩移動速度的驟然變化(比如10m/s到7m/s),可在到達P前等量減慢X的最終速度;
3. 合併路點：
   
   • 路點 – 物體移動路徑上的一系列關鍵點; 例如怪物,無路點不可移動;若有則始終朝第一個路點移動,達到後刪除首路點;
   • 方法 – 服務端只需要在移動開始的時候發送一個初始的路點列表,在這個怪物停止移動前就不用再去更新它了;
   • 客戶端發現它到終點的直線上無障礙物則可自行移動,若一個對象撞上另一對象時服務端發出停止命令; 兩端有差異時,合併路點;
4. 插值和推導：
   
   • 推導 – 使用最後得到的位置和對象的速度來預測其未來的位置和速度; 延遲越大,差異越大,需插值平滑防止跳躍;
   • 將對象的移動路徑切割成100ms-200ms的時間片進行推導,當服務端和客戶端路徑點不同時,客戶端插值調整到服務端的路徑點;
   • 線性插值; 曲線插值(比如FPS遊戲中,不是在跳躍就是在地上,需要拖回地面的曲線平滑,否則會造成滑翔的視覺錯誤);
5. 爲瞄準延遲使用反向仿真：
   
   • 上述方法不足以解決FPS中的問題 – 當玩家延遲較大時,可能已經瞄準目標並在合適的時刻按下了扳機,但已有方法會使擊中無效;
   • 如果服務端可以知道客戶端進行射擊時的情景,它就能正確地判斷目標是否被擊中了;
   • 得到確認的消息序列沿着歷史記錄回溯,並計算出發送命令時客戶端對象的位置,完成擊中/未擊中計算後,疑問對象被放到它當前的時間和位置中去;
   • 示例 – 客戶端A在400ms前收到B最後一個移動數據包,因此,根據此時B的速度和方向,推斷A按下扳機時B的位置,如果擊中,則判定擊中;

【保持流暢:異步客戶和時空穿梭】

1. 共享狀態的基本問題：
   
   • MMP遊戲裏必然有一些對玩家都必須相同的共享數據,有些數據還會以不可預見的方式改變,怎樣發送這些共享狀態的改變？
   • 重要成果 – 分佈式交互仿真(DIS)、仿真網絡(SIMNET)、高級架構(HLA);
2. 航位推測法：客戶端預測方法,廣泛應用於需要發佈位置數據的遊戲中比如FPS; 減少發送數據; 補償網絡延遲;
   
   • 使用帶有時間戳的信息進行預測可使移動更流暢;
   • 很難對會突然變向的對象預測,對其流暢的顯示意味着不精確;若該對象並不需要在每個玩家視野中都具有相同表現,亦可使用航位推測;
3. 仿真時間：通常並非真實時間(wall-clock time);
   
   • 服務端需要對分發時間值所花費的時間進行補償 – 簡單方法是用一個集中的時間源發出一堆訪問,而後把平均回覆時間的一半加在接收到的值上;
   • 仿真時間必須完全獨立於幀頻率,對客戶端時間的操作應獨立於畫面更新的節奏;
4. 直接操縱時間：
   
   • 常用方法 – 讓所有客戶端的仿真事件略微落後於實際時間,服務端需要使用某個網絡消息時,可提供一個到達客戶端的時間;
   • 上述方法會引起以個固定的延遲,但可通過一些聲音和動畫效果立即對玩家的請求進行確認,並馬上開始玩家的行動;
   • 控制時間 – a.最小更新時間(一個對象的狀態發生改變到它的狀態可以再次發生改變所要經過的最短時間);
     b.時間戳下限(一個參與者可能獲得下一個更新的最早時間);
5. 總結：
   
   • 讓客戶端保持流暢比精確更重要; 讓每個玩家都覺得他纔是遊戲中唯一的玩家; 不惜一切代價避免停滯和跳躍;
   • 讓玩家能夠知道遊戲中發生的事並能參與其中; 讓玩家可以掌控自己的遊戲世界比讓他們爲其他玩家的遊戲世界做貢獻更爲重要;

【使用程序生成遊戲世界:避免數據激增】

1. 運行時生成的優點：
   
   • 有效減少數據量 – 用一個隨機數種子和一個良好的隨機數發生器就可生成整個遊戲世界,只要玩家使用相同的種子和生成函數,所見便相同;
   • 細節生成 – 只需通過發佈新的生成程序和生成DLL進行更新,地形/對象/新貼圖等改變都可在各個客戶端自動生成;
2. 運行時生成的缺點:
   
   • 性能影響 – 須謹慎決定哪些數據在運行時生成?哪些在載入遊戲關卡時預先生成?哪些在更新/發行時預先生成?
   • 增加複雜度延長開發時間 – 生成函數本身不復雜,但動態的細節層次函數可能非常複雜;
   • 多數生成函數很難控制 – 簡單解決方案是預先生成到某個特定的細節層次,然後動態生成來補充其餘的細節;
3. 地形生成算法的分類：
   
   • 靜態算法 – 先確定網格大小而後對整個網格操作,因控制方便,可用來把地形預先生成到一定的細節層次,而後動態算法補充;
     斷層線算法(迭代次數越多,生成的地形越美觀);
   • 細分算法 – 等離子算法(靜態算法); 可建立一個樹狀結構來模擬自適應網格算法;
   • 動態算法 – Perlin噪聲算法; 分型布朗運動(fBm); 多重分型算法(MojoWorld虛擬世界創建程序的主要驅動力);
4. 修改程序生成的地形：手工修改; 靜態算法修改; 僞動態算法修改;
5. 高效地渲染程序生成的地形：ROAM算法;
6. 生成貼圖：
7. 在程序生成的地形進行碰撞檢測：避免在碰撞檢測時進行三角形判斷;
8. 大型遊戲中世界中的比例問題：
   
   • float在1000公里左右不夠精確,double在一萬億公里時不夠精確;
   • 儘量少用雙精度,僅用於表示物體位置或關鍵位置,其他使用單精度;
   • 替身(Impostor)渲染;

【爲固定大小的對象編寫一個高速有效的分配器】

1. 遊戲系統會頻繁地分配很多對象,像矩陣、向量等,這些對象更適合於分配在棧上,不僅可減少內存/高速緩存不一致帶來的問題,也可避免使用指針;
2. 一個簡單的向量分配器：分配一塊連續的內存,大小是類T大小的整數倍,用指針數組保存空餘內存塊;最初每個分塊指針都在數組中,用索引指示下一個空餘塊(初始爲0),分配時返回索引位置的內存塊,將索引遞增1指向下一可用空閒內存,釋放分塊時索引減1,,並將內存塊指針放回指針數組中;
3. 重載操作符,使調用者不需做額外工作即可使用分配器功能,比如重載C++中的new和delete運算符;
4. 字節對齊：所有分配都應該至少和8個字節邊界對齊，以獲得最佳性能; 針對緩存線和處理器中的向量單元,分配16位或32位對齊可能更好;
5. 降低分配器內存開銷：把管理分配的數據結構放在未分配的內存塊中;
   
   • 不再需要內存指針數組,而只需在每個空閒塊開始的幾個字節裏,保存指向下一空閒塊的指針; 循環鏈表;

【使用貼圖定製三維角色】

1. 角色定製的類型：
   
   • 網格定製 – 可改變角色輪廓; 分段網格交換; 避免引起光照或碰撞問題;
   • 貼圖定製 – 網格已固定,所需資源較少,對引擎功能依賴低,可提供大量變化;
2. 貼圖合成簡介：定義和構造一個可用於貼圖合成的區域,最好支持調色(hueing)和Alpha混合;
3. 分層：例如 – 0皮膚 → 1身體藝術<紋身/傷痕> → 2毛髮 → 3衣服 → 4外衣 → 5徽章;
4. 貼圖定製模板和樣本:貼圖到網格的正確映射是貼圖定製成敗的關鍵; 定義貼圖區域的結構稱爲貼圖模板;
5. 樣本集合:提供一個抽象層來簡化用戶與貼圖定製系統之間的交互;隔離細節並確保在對模板修改或細分時不會影響用戶已作出的關聯;

【遊戲機平臺上MMP遊戲的獨特挑戰】

1. 環境：遊戲機更多地處於一個共享的環境中–人們聚集和社交的地方;
   
   • 分屏模式 – 讓2-4人在同一臺遊戲機上共同遊戲可降低很多問題的複雜度,包括交流、分組和交易;
   • 減少單次遊戲持續時間 – 加快連接尋找朋友、決定做什麼、到達目的地這一過程,使玩家半小時內足以進行一次有效遊戲;
2. 登錄：簡化登錄過程，記住用戶名，密碼可通過一系列按鍵動作來輸入,或同用戶名一樣使用虛擬鍵盤;
3. 分辨率：小心決定低分辨率下的文本顯示方式； 分屏模式進行組合顯示(如小組名單/雷達地圖)；
4. 聊天頻道：一對一聊天； 和少量玩家分組式聊天; 和大量朋友或在行會中聊天; 大型事件中關於戰略/戰術的聊天;
   
   • 語音 – 通道切分; 無法過濾內容; 帶寬需求高(可用P2P分佈式聊天);
   • 表情 – 自定義表情需要額外傳輸時間,可能導致某些玩家不願使用,一組不需額外傳輸時間的缺省表情非常重要;
   • 簡短的固定表達 – 形象的手勢、簡短而固定的文本消息、熱鍵觸發的聲音事件等;
5. 選擇目標：就近/最弱/團隊目標/小組成員; 隱式目標選取 – 系統自動把處於攻擊範圍的對手作爲目標(例如FPS中對準什麼就攻擊什麼);
6. 菜單：a.功能分組置於頂層菜單,從而平鋪開使玩家可用手柄中不同的按鍵來觸發; b.通常建議大部分菜單功能組合起來,置於一個獨立的頂層菜單上;
7. 背囊管理和交易：可使用虛擬指針拖拽; 裝備、保存、交易、物品使用,需特別注意;
8. 補充界面：若可通過行會網站、玩家組織、關於遊戲訣竅的站點或其他Web拓展來建立遊戲以外的存在,會加強玩家集體感;
   
   • 鼓勵外部集體的一個方法是給與他們訪問任何遊戲數據的權限,只要不帶來安全/隱私的風險、帶寬問題、不涉及專有知識;

【遊戲系統】

【從原料到成品:社會經濟中的職業生涯】

1. 原料獲取和加工：
   
   • 原料採集系統 – 玩家能力/技能/屬性可影響採集結果(數量、質量、耗時); 原料核心亦可控制採集結果;
   • 超越期望的樂趣 – 引入製造系統的每一階段,概率結果不應進行懲罰,而是用一些超出預期的結果來獎勵玩家;
   • 時間投入和原料產出以及風險和回報 – 比如縮短時間降低質量獲取更多低級原料; 危險地點採集稀有物品;
   • 實例 – 製造專家委託 → 採集專家 → 危險區域護送(任務公告欄)/朋友 → 複雜技巧獲取高質量原料 → 採集附產品 → 活着回來豐厚回報;
2. 社會經濟中的合作製造：通過對原料採集、物品需求度、合理的技能多樣化及豐富的製造配方進行考慮；
   
   • 製造物品 – 製造技能 → 配方 → 詳細描述所需工具、原料或其他物品;出問題時所需原料 → 原料/工具質量決定成品質量 → 製造時間;
   • 時間投入與產品價值 – 稀有度決定價值,通過對原料/工具的技能等級或產出控制； 玩家合作製造;
   • 原料、工具和物品的作用 – 工具可由玩家制造,獨特限制,成品質量影響; 成品可作爲其他物品部件,比如零件與引擎;
   • 對新制造的工具進行改進和修理 – 使用和製造物品相同的方式進行修理和改進,簡單把所需修理或改進的物品組合起來;
3. 物品製造在社會經濟中起到的作用：
   
   • 社會作用 – a.設計爲需要很多不同的技能集合; b.調整風險和回報間的關係使從事製造業的玩家依賴於冒險玩家;
   • 製造業、物品和聲望 –
     
     • a.把信息提供給感興趣的玩家 – 廣告欄、任務發佈欄;
     • b.外部網頁建立公告欄鏡像使玩家遊戲外可尋找合作伙伴;
     • c.可獲取製造物品的特定信息非常有用(總數、質量、殺怪數、使用者平均聲望技能等級等); 大型戰役致命一擊信息可獲取/傳播等;
   • 保持需求(重要) – a.讓物品會損壞; b.讓玩家的物品保持較高的週轉率;

【玩家房屋供給:我的房屋就是你的房屋】

1. 成長之路：價格高供應量少 → 不斷存錢 → 選址(地產有限) → 內部裝飾 → 升級更好的房屋。<成就感、展示、商業、收藏>
2. 商業方法：僱傭商人NPC銷售貨物 → 增加房屋需求。
3. 地段、地段、地段：a.直接在房屋邊通過的人流更易帶來顧客(拍賣將降低房屋重要性); b.戰利品展示等可炫耀的事情;
4. 應該把戟放在哪裏：個性擺放來展示創造力和設計能力; 珍惜品市場; 垃圾儲藏室(人們不喜歡放棄) – 建議開始就進行限制;
5. 讓玩家管理一家商店、開家酒館或擁有一座壯麗的城堡可讓玩家以一種難以置信的方式對身邊的世界產生影響;

【社會遊戲系統:促進玩家社會化並提供遊戲回報的另一途徑】

1. 社會遊戲系統：就是那些給予不同的社會行爲支持、鼓勵、回報和懲罰的系統;
   
   • 吸收新成員融入虛擬世界 – 良好的設計可幫助玩家學習和應用遊戲世界中的社會期望(譬如進入圖書館就知道那是安靜的地方不應打擾他人);
   • 促進玩家的交流和聯繫 – 公開的、私人的、近距離的、羣體中的聊天系統; 但社交不止於交談;
   • 支持和促進合作遊戲 – 積極回報正確的社會行爲並阻止反社會行爲;
   • 培養歸屬感 – 馬斯洛需要層次第三步,歸屬、聯繫、被他人接受、付出與獲得愛和友誼;
   • 小型世界網絡 – 六度分離; 通過提供更強的社會系統,降低所需度數,進一步增強玩家間聯繫;
2. 爲什麼要讓玩家社會化？
   
   • 創建自洽社會 – 儘量創建一個不需開發人員參與即可獨立運轉和發展的自洽世界,縮減開支,增強虛擬世界玩家的聯繫;
   • 減少”反社會”玩家 – “玩家搗蛋投訴”佔客服時間40%,而將其花費在幫助技術困難或遇到程序錯誤的玩家身上,會更有建設性;
   • 增加玩家的股份 – 玩家對虛擬世界投入(朋友/虛擬活動/金錢等)越多,忠誠度越高;
   • 創建更豐富的遊戲世界 – “廣度”指實現更多遊戲系統尤其是社會系統; “深度”指提供更豐富的遊戲體驗;
     
     • 更好的AI、更復雜的任務以及更廣闊的地理區域; 更復雜的社交系統;
     • 它不僅僅是一個遊戲 – 有些玩家在遊戲中發現了他所未開發的技能或天賦; 領袖體驗、克服游泳恐懼、虛擬婚姻到真實婚姻等;
3. 目前使用的社會系統：
   
   • 聊天 – 頻道聊天; 廣播; 圖形表情; 語音; 肢體動作如”揮手”;
   • 層次結構 – 行會系統; 效忠君主系統; 金字塔效應;
   • 聲望 – “根據某人的人格或其他品質對其作出一般評價;某個人或某種事物所受到的相對評價或尊重;” 玩家可評價他人;
   • Bartle類型 – 根據玩家動機分爲四種類型:探險、獲得成就、殺人和社交;
     
     • 探險者希望瞭解遊戲世界，會繪製地圖，測試遊戲機制/數據等;
     • 獲得成就的人爲自己創建遊戲相關目標並完成(積攢戰利品或尋求地位);
     • 殺手會纏着其他玩家,尋求展示比其他玩家更爲優越的機會; PK或尋求各種方法來和其他玩家搗蛋;
     • 社交玩家喜歡與其他玩家進行交互,即進行社會化;
   • 匹配服務 – 幫助玩家尋找或加入其他玩家; 譬如夢幻西遊的劇情/任務隊伍查詢/加入(等級職業限制等);
4. 回報社會性遊戲的創新方法:
   
   • 對目前的社會遊戲系統進行改進 – 更易用的界面; 根據玩家反饋和建議完善; 藉助問卷幫助系統選擇組合玩家隊伍; 重要信息手機通知;
   • 增加社會聯繫 – 馬爾科姆.格拉德威爾《引爆流行》少數法則,”鏈接者”能認識大量其他人,找到他們並給予回報,即可創建和加強社交網絡;
   • 開發與真實世界平行的社交系統 – 玩家聚集點往往都都是那些建立起真正友誼的玩家;
     
     • 應該使用人們在真實生活中使用的社交系統並且把它們運用在遊戲世界中,譬如虛擬飲食/服裝經營,增強投入感和滿足感;
   • 爲新的社會行爲定義規範和禮節 – 命名規範; 鼓勵符合遊戲文化的社會規範;
   • 通過儀式 – 設計通過儀式(成就里程碑)增強參與感;譬如5級纔可選一個專業領域,10級纔可選擇一個姓;
   • 新的經濟體系 – 貨幣、戰利品或商業組成; 貨幣可使用不同類型等價物,譬如有用的物品、時間、空間、聲望等;
   • 導師 – NPC管理的學徒/導師系統;
   • 社會化 – 要想方設法報答社會性玩家 – 譬如長期在公共頻道分享故事,幫助其他玩家,向不熟悉遊戲的玩家介紹遊戲系統的玩家;

【爲創建和管理行會設計靈活的命令集】

1. 創建：對初始成員的最小數量做出要求避免濫用行會創建; 允許行會某些成員可改變行會名(投票制？);
2. 領導：數字表示等級,比如領袖爲0,普通成員爲100; 可對每個等級進行定義和命名,並指定職責和能力;
3. 標識：提供除名稱外的其他標識; 譬如紋章/飾章,使用源自遊戲的完全虛構的圖記,避免帶來“真實世界”問題; “紋章學”; “可預覽”;
4. 行會維護：增刪成員; 等級設置; 管理權限等;
5. 財產：行會銀行/倉庫; 共享裝備; 金錢捐贈/提取; 查詢財產提存記錄;
6. 專用區域：特定區域供行會成員使用; 特定建築供特定等級的成員進入;
7. 交流：行會內部交流; 限定可加入行會的臨時頻道; 指定多個所有者; 成員移除/禁言;

【創建聲望系統】

1. 友誼和仇恨的實現：每個NPC都屬於某個派系,定義不同關係(友好→中立→仇恨)時的可能反應; 聲望調整; 目擊者傳遞; 派系聲望;
2. 寬恕：個人聲望; 標記”全局”或”非全局”,比如獸人士兵攻擊精靈士兵,目擊者爲全局的,則會引發種族對抗; 仇恨衰減;
3. 投降：提供不會消逝的永久個人聲望調整,避免投降場景短期可用,長期則出現問題;
4. 玩家對戰的設置：玩家追隨者/召喚獸使用主人的聲望; 可通過”玩家關係”面板設置是否仇視其他玩家,確保寵物行爲符合期望;

【城邦政府在在線社區中的作用】

1. 公民生涯：賦予玩家初始歸屬感,並提供一些導引; 無論參與度公民都可享受歸屬和導引帶來的社會優越性; 避免城邦間流動性過大;
   
   • 國籍 – 國籍獲得、更改所需步驟、對國籍濫用帶來的問題及對策;
     
     • 登錄時授予國籍,提供城邦簡單數據,比如總資產、總人口、佔領區域、完成的任務、平均聲望; 默認玩家無選擇時平均分配並給予獎勵;
     • 更改申請 → 緩衝時間 → 流浪狀態 → 找到擔保人 → 繳納統治者規定的物資/費用 → 加入新國籍;
     • 限制每個賬戶只能擁有一個國籍; 避免”傀儡型”賞金獵人、濫用選舉系統等;
   • 國籍可能帶來的權益 – 包括可從玩家及周圍環境獲得保護; 根據角色能力獲得獎勵; 參與城邦相關行動和任務;
     
     • 國籍權益與城邦核心特徵以及所佔區域的核心特徵掛鉤; 譬如傾向魔法/戰鬥/生活職業;
     • 權益與城邦擴張相關,佔據特定區域獲得相連的技能獎勵,亦可區域類採集、冒險或資源佔領,鼓勵玩家在該區域聚集,加強公民聯繫;
     • 權益與參與政府任務相關,消滅採集區惹麻煩的NPC、獲得建造資源、守衛/偵查特定區域;玩家爲其社會權益工作,冒險將更有意義;
2. 參與城邦工作：強健的在線政府系統可爲玩家提供大量的參與機會;
   
   • 領袖選舉 – 投票權限制公民在線時長/等級/活躍度; 提供候選者簡單數據(屬性、成就、聲望)及宣言; 勝利者廣播併發布到網頁上；
   • 政府職業如”賞金獵人” – 玩家滿足基本要求(時長/戰力)後可申請,統治者通過查看成就/玩家評價決定是否授予;
     
     • 玩家需要時即可呼叫賞金獵人,之後可瞬移至玩家身邊,爲避免濫用,需支付一定費用;
     • 鼓勵賞金獵人擴大巡邏範圍,比如設置動態路點,到達時刻獲得一定報酬,促使巡邏到不常去的地點;
     • 提供工具識別玩家殺手並跟蹤,基於聲望、行會關係、所殺玩家數等,在一定時間內驅逐出城邦;
     • 使負責的賞金獵人付出的時間和努力的回報要遠高於正常冒險; 記錄行爲(應答數,忽略數,殺敵,路點),用於清除濫用職位能力的玩家;
   • 讓玩家能自行參與城邦工作可讓他們感到自己是社會的一份子; 選舉,影響發展方向,職位參與等各種形式包容並引導,建立更強的社會聯繫;
3. 定義政治過程：
   
   • 成爲統治者：
     
     • 滿足基本的等級在線時長/行會領袖,一定數量(總人口特定百分比)玩家宣誓(付出一定代價如錢或資源)支持後,成爲候選人;
     • 候選者接受相應條款(要求捐獻大量金錢,與總人口通脹等掛鉤;公開賬戶角色的行爲等信息)後,提出宣言(治理計劃等)後,開始參與選舉;
     • 選舉持續一定時間,避免服務器壓力過大以及控制權力轉移是的改變和混亂; 限制連任次數或一定時期內擔任次數(譬如每年不超過三次);
     • 罷黜 – 考驗公民的團結度,超過一定百分比即自動廢除,在下次選舉前,系統NPC代管(根據歷任平均數據開展工作);
     • 辭職 – 可選擇立即辭職; 登入次數/行動數不達標,將自動失去職位;
   • 統治者權力與義務：確定法律，指定稅率，負責職位及城市發展支出間的財政分配，任命賞金獵人等不需選舉的政府職位;
     
     • 法律包括a.是否允許攻擊公民;b.安全區設置;c.不同聲望可享受的權益;d.物品製造/銷售限制;e.技能限制等; 限制法律變更次數及時限;
     • 在預先指定的範圍內調整稅率(對內/對外),稅收存入國庫,不可直接提取,但能分配職位收入/發展城市/建造銀行等;
4. 城邦爲不同政體間的大規模戰爭及領土擴展提供了有意義的背景;一個強有力的在線政府系統爲解決在線社會中的很多問題提供了強大的框架;