2.介面管理器：
這個管理器最為重要的就是維護乙個資料結構（根據不同專案的實際情況來自定義資料結構）。 資料結構如： 乙個array，裡面順序儲存著當前開啟的介面，array裡面對應的值就是每個介面需要記錄的一些必要資訊，如：開啟介面時傳入的引數、介面的zorder、介面的名稱等……
每次開啟和關閉介面都通過管理器執行。
期望管理可以實現如下功能：
（1）可在介面開啟或關閉時統一處理一些任務。（包括等待伺服器資料返回、預載入和釋放資源等）
（2）隨時知道當前顯示最上層的介面是哪個。
（3）切換場景再切換回來，可以按照層級重新開啟之前開著的介面。
（4）應對類似【強化–探險—強化】這種介面迴圈開啟的情況。
（5）還有太多太多太多可實現的功能了，看專案需求………………
3.資料管理器：
遊戲的核心資料層。監聽所有伺服器返回的介面，不同更新伺服器返回的資料。我們想要做到的，就是無論什麼時候，從資料管理器裡拿回來的都是最新的資料。 而且我們也可以封裝一些需要計算的2級屬性，如：當玩家公升級時，體力值變化了（1級屬性），那我們同步體力值的同時，也同步結算且更新玩家的hp（根據體力值換算的2級屬性）。反正玩家只管在資料管理器中拿資料用就是了。 當然，為了避免資料管理器超級龐大，管理的主要還是整個遊戲的一些通用資料，某些系統的部分特殊資料，可以交給各自系統的系統管理器去管理。
4.通用方法類：
個人覺得可以分成三種型別：
（1）和遊戲相關的，如：建立通用的頭像框、建立乙個通用的動畫特效等。
（2）和遊戲無關，和引擎相關的，如：獲取本地可寫入路徑、讀寫本地快取的封裝。
（3）和遊戲與引擎都無關的，例如加密、解密、時區換算等各種演算法。
通用方法的必要性不必多說，一人付出，眾人受益，分成幾種型別的目的也主要是為了以後做其他新專案方便移植。
5.訊息分發器：
個人覺得是乙個很重要、很方便、很好用的乙個解耦神器。
觀察者模式，介面與資料分離的最佳伴侶。不止介面與資料，各系統之間的訊息通訊同樣可以通過訊息分發來通知狀態改變。
PMP各大管理系統
專案管理系統 project management system pms 專案管理資訊系統 project management information system pmis 配置管理系統 configuration management system，cms 配置管理系統專案管理系統的乙個子系統...
Buff系統框架設計
buff的配置檔案 buftype 1 精神類buf 2 物理類buf 3.元素類buf 4.其他類buf 5.被動類buf bufsubtype 1000 1999 精神子類 2000 2999.物理子類 3000 3999.元素子類 4000 4999.其他子類 5000 5999.被動子類。所...
再議成就系統框架設計
根據的設計，其實還有幾點可以優化 1.group組的buff是靠嚴格的配置的偏移量計算出來的，這個太不可控了。buff可能出在無法檢查的策劃小錯誤上 2.如果已經有n種型別的成就，而有乙個新的需求，其事件是已有的幾種成就組事件的組合，則需要 產生一種新的成就組，使用新的成就buff。儲存空間浪費，冗...