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