韓服網路拓撲圖：

國服網路拓撲圖：

韓服與國服對比：

韓版架構：一組七類程序，玩家三線連線

韓版優劣：架構複雜，難以查證、跟蹤與除錯，難以上手、維護與培訓，不穩定，效能差，邏輯易混亂，最高僅1500人；優點是同內容下玩家數量可擴充單服最高僅1500人；優點是同內容下玩家數量可擴充單服

國服架構：一組兩類程序，玩家單線連線

國服優劣：最高2900人，單線管理不易擴充單服

何為架構：

何謂架構（作為動詞）？“架構”就是程式人員對需求的設計，對各個產品、各種功能、各部分模組及流程多種需求的設計

有哪些架構（作為名詞）？網路，邏輯，資料流，功能（策劃案），配置表（資料結構）

架構從哪裡來？從需求中來。哪些需求？玩法的、安全的、效能的、運營的，甚至是團隊成長的

如何成長為架構師？學習，參考，實踐，驗證，改進

國服版本設計方法：

設計原則：簡單，可控，穩定，高效能

一些具體的設計目標（略舉一二）：

                             大二的學生都可以讀得懂、能寫、能控

                             因事沒來上班時，有人能動你的程式碼因事沒來上班時，有人能動你的程式碼

                             不怕有問題，隨時可追查

設計框架：一組伺服器僅含兩個程序，DB負責資料快取、賬號認證、計費通訊等第三方介面接入；GAME負責遊戲邏輯、玩法、遊戲內容構建

DB架構設計圖：

DB架構設計：

資料快取策略：賬號列表管理，同賬號下最多三角色資料快取（讀取規則，快取上限，排程策略）

全域性性資料存取策略：開機即讀取，定時儲存，全域性快照快照

第三方介面通訊策略：基於防禦性的介面互訪規則（日誌審計，邏輯防禦），基於驗證重發的通訊規則

DB設計經驗：

嚴重問題：DOWN機（記憶體，資料庫訪問，登入堵塞），資料錯亂，資料不儲存

解決方法：

                               儘可能簡單的表結構

                               儘可能簡單的SQL語句

                               定長的陣列

                               可控的壓力閥值（由GAME控制）

總目標：不要讓單玩家掌控你的機器資源

Game架構設計圖：

Game架構設計：

幀輪詢機制：物件管理體系；網路、邏輯、AOI分執行緒；主邏輯一秒三幀，網路傳送一秒六幀

訊息佇列機制：網路訊息，AI訊息，位置同步訊息，資料存取訊息，定時器訊息，指令碼呼叫訊息資料存取訊息，定時器訊息，指令碼呼叫訊息

引擎與指令碼：開發速度、穩定性、熱更新

Game主邏輯架構：

邏輯的驅動來源：網路訊息，AI訊息，定時器訊息三大驅動方式

邏輯的驅動方式：在主迴圈幀中分別處理來自於各訊息佇列的訊息（便於統一管理、效能監控）息佇列的訊息（便於統一管理、效能監控）

具體的內容組織：玩家，NPC、怪、寵物，家族、師徒、戀人，物品、裝備，任務、活動等

Game物件管理體系：

物件的層級：簡單動態物件（無邏輯的活物、空艇等），複雜動態物件（NPC，怪物，玩家），物件集合（師徒，戀人，組隊，家族，王國）

個體物件設計：定義屬性，方法，常用介面，介面保護，設定資料重新整理、存取規則

集合物件設計：定義管理方式，資料結構，資料同步方法，異常處理原則

Game網路架構：

基本模型：EPOLL

資料的memcpy：一次性接收，無memcpy；發資料時有一次memcpy。資料快取事先建立。

資料收發：統一的收取訊息佇列，處理函式；單個玩家獨立的傳送佇列，按幀傳送，小包拼接。最多：位置，物件載入，狀態。

效能：2900人線上，80M頻寬

GameAI架構：

基本模式：狀態+訊息，主迴圈輪詢

狀態：空閒，狂燥，逃跑，返回

訊息：初始化，處理，傷害，到達，結束

狀態與訊息的關係：由訊息實現狀態間跳轉，改變AI策略，由狀態的自輪詢實現怪物智慧的自我觸發

Game定時器架構：

基本模式：以時間尺作為排隊方式，只執行當前時間刻度的邏輯（借鑑linux原始碼）

主要功能：提供自維護邏輯的執行（技能、BUFF、安全監控、統計等）全監控、統計等）

基本實現：引擎層實現架構，向指令碼層提供定時器訪問介面，指令碼層通過介面訪問

相關功能：新增定時器（一次性、輪詢、按條件控制），回撥函式，定時器銷燬

Game狀態機架構：

基本模式：行走、戰鬥等玩家主要行為，皆通過狀態機機制實現，“狀態+訊息”的基本觸發方式

狀態：坐下，近攻，遠攻，站立，移動等

訊息：設定狀態，刪除狀態，開始，終止等

關係：維護一定時間，且與其他狀態有互斥等互動行為的可以設定為一個狀態

Game場景管理架構：

基本內容：場景靜、動態邏輯載入，區域自觸發邏輯，物件可見、範圍相關的邏輯（傷害範圍，可見範圍等）

基本方式：稱之為LinkMap的資料結構，按“層+二維陣列”的模式組織場景裡的靜、動態可管理資源。層陣列”的模式組織場景裡的靜、動態可管理資源。層與層之間可設定可見性、可計算性；二維陣列內的各物件之間可以設定可見性

面向運營的架構要素：

指令碼化，熱更新，多日誌

單一系統的線上開關控制

單一系統的資源統計

版本的快速迭代、驗證（30分鐘解決問題）

單個技術人的全面素質培養，獨當一面，靈活應對

預估風險，作好準備方案（既要考慮壞，也要考慮好）

基於互不信任的架構和邏輯思路

曾經犯的經典錯誤及改進：

DB：資料回檔，不儲存，當機，認證無返回

物品系統：index不對應，命名不統一，溝通不充分

交易系統：日誌不充分，追查難，多資料存放點

狀態機系統：控制太精確，雙方無主從關係，狀態不同步

一些體會：

儘量減少對第三方庫的使用和依賴

儘量做到程式碼自解釋

儘量不使用技巧性過強的設計方法

儘量少上設計模式的當

程式碼是為他人而寫

實踐出真知，預防抗風險，分享促成長，團隊強才是真的強

目前的狀態：

速度：從策劃案開始交付實施之日，兩週之內出一箇中型玩法或中型系統

質量：“簡單、可控”保證了系統穩定，防禦性程式設計思維保證了留有後路，30分鐘內解決伺服器問題（要麼修正錯誤，要麼關閉區域性系統），不停機更新

團隊：人人都可以雙端開發，獨當一面；技術全面；技能素質和心理素質全面

設計本天成，妙手偶得之