http://www.cppblog.com/PeakGao/archive/2006/06/10/8381.html
在開發完一個遊戲後，看了一些文章和當前一些流行的技術後，感觸頗深，所以隨筆聊聊。
遊戲服務器的設計比較複雜，這裏也不打算寫出每個細節，只是講一下框架方面的想法。
1、實體系統和功能子系統
在服務器的框架部分，主要寫些基本的服務器功能模塊，可以實現一個實體系統，遊戲中的實體主要指那些生物對象，如角色，怪物，NPC等，其實在遊戲中沒有必要寫具體的角色類，怪物類，NPC類，我們可以將他們統稱爲實體，從遊戲服務器的角度看，他們沒有什麼不同，當策劃將這些實體對象進行配置後就成了具有類型差異的各種各樣的對象，如角色，怪物。功能子系統指MMORPG遊戲中一些必不可少的相對獨立的功能集，如運動系統，財產系統，社交系統，聲望系統等，每個實體具有自己的屬性集，一些功能子系統，一些特性集（決定了生物的類型），這些屬性集、特性集和子系統可依賴配置文件進行配置。這樣的好處是不會存在通過實現各種對象的類來人爲的增大類結構的複雜性，通過具體的類（或繼承類）實現各種生物甚至有時候會存在衝突，因爲有的對象既是A類型又是B類型。
2、基於服務的構建思想
遊戲服務器除了上面的實體和子系統外，其他有好多東西可以借鑑現在的SOA思想，如聊天系統，好友系統，師徒系統等是否都可以看作是一種遊戲服務呢？當開啓了這些服務，那麼相應的功能就能表現，關閉則隱藏。
3、封閉的數據管理層
服務器的數據管理比較複雜，如果我們講所有（或大部分）的數據交由一個獨立的數據管理層進行管理，那麼上層開發人員或者上層應用模塊就不直接關心數據在哪個地方，怎麼更新，怎麼存儲等。基於前面的實體系統，整個服務器的程序架構已經比較抽象，在這個抽象的類對象的基礎上構建封閉的數據管理應該比散亂的大量不同對象的系統中構建數據管理層來得更方便，比如實體對象的屬性集，基本可以涵蓋一個實體對象大部分的數據，那麼數據管理層只要管好屬性集就可以帶來不少的方便，而屬性集中的大部分屬性是通過配置而來的（至少很多需持久化的屬性肯定是配置的），除了實體系統的數據，還有那些子系統和基於服務的那些對象都可以納入數據管理層進行管理。
4、腳本化支持
對於遊戲服務器那些核心的模塊，通過腳本封裝（如Lua封裝）後，可以讓上層應用層進行很好的擴展和開發，所以遊戲服務器應該也必須支持腳本編程。像那些AI，任務，聊天等等大多數應用模塊中的大部分代碼都是可以拿腳本編寫的。考慮到腳本性能問題，一些對性能影響比較大的地方還是建議用c/c++實現，腳本里面進行調控即可。
還有一些亂七八糟的東西，考慮到怕不小心泄密，這裏就不多講了。
