網絡遊戲公司成長到一定的階段，會有一些經驗和技術的積累，這些積累會在日後的遊戲開發使用，但如果揹負了過重的歷史包袱，就應該丟棄，開發一套全新的架構在適應現在的遊戲開發技術需要。
而我，最近就在考慮一個可複用的服務器框架，這個問題思考已經不是一天兩天的事情了，但還未正式開始實施。
框架設計目的
1：加快遊戲開發過程，縮短開發週期——設計和代碼的複用
2：提高產品質量——由所謂的“精英”程序員開發和維護
要提高效率，必須要能有效的複用，整理了一下思路，把複用分成了幾個層次
1：最低層：源代碼級別的複用，提供諸如常見的隊列，buffer，序列化，內存，線程等等基礎設施的封裝
2：組件層：該層提供二進制複用模塊，如網絡模塊，IPC通信等
3：框架層：該層採用底下幾層的代碼和組件，搭建一個框架，比如直接把底層的網絡消息映射到上層腳本系統，線程的控制，消息驅動，起到總體調度的作用
4：腳本層：該層主要編寫遊戲邏輯，由腳本支持組件和腳本代碼構成
5：最高層：編輯器，編寫各種各樣的編輯器——任務編輯器，物品編輯器，技能編輯器等等，通過生成的腳本或數據和它的底層交互。
基於這種構想，如果底層提供了良好的設計，理想情況下更多應該是策劃使用編輯器構建遊戲
結合服務器架構：
以上的層次劃分只是針對最複雜的邏輯服務器，這裏不談服務器的架構設計，每個服務器總能使用其上層次的部分。
人員考慮（看起來像招聘信息:D）
源代碼層：需要多年的c++開發經驗，對常用的程序庫比較熟悉，尤其是泛型程序設計，其他不做太多要求
組件層：具備一定的接口設計能力
框架層：具備一定的接口設計能力
腳本層：需要大量遊戲開發經驗，對遊戲邏輯和策劃溝通方面相當瞭解
編輯器：通常不需要太高的技術要求，能按照設計實現就行
實施過程：
理想是美好的，現實是殘酷的。不得不考慮一些風險，首先考慮公司現狀是否需要這麼一批人做這樣的一件事，其次是否具備這樣的研發能力，是否具備上述的各種技術人才，其三如果失敗，那麼會有什麼得失。
