在开发完一个游戏后，看了一些文章和当前一些流行的技术后，感触颇深，所以随笔聊聊。
游戏服务器的设计比较复杂，这里也不打算写出每个细节，只是讲一下框架方面的想法。
1、实体系统和功能子系统
在服务器的框架部分，主要写些基本的服务器功能模块，可以实现一个实体系统，游戏中的实体主要指那些生物对象，如角色，怪物，NPC等，其实在游戏中没有必要写具体的角色类，怪物类，NPC类，我们可以将他们统称为实体，从游戏服务器的角度看，他们没有什么不同，当策划将这些实体对象进行配置后就成了具有类型差异的各种各样的对象，如角色，怪物。功能子系统指MMORPG游戏中一些必不可少的相对独立的功能集，如运动系统，财产系统，社交系统，声望系统等，每个实体具有自己的属性集，一些功能子系统，一些特性集（决定了生物的类型），这些属性集、特性集和子系统可依赖配置文件进行配置。这样的好处是不会存在通过实现各种对象的类来人为的增大类结构的复杂性，通过具体的类（或继承类）实现各种生物甚至有时候会存在冲突，因为有的对象既是A类型又是B类型。
2、基于服务的构建思想
游戏服务器除了上面的实体和子系统外，其他有好多东西可以借鉴现在的SOA思想，如聊天系统，好友系统，师徒系统等是否都可以看作是一种游戏服务呢？当开启了这些服务，那么相应的功能就能表现，关闭则隐藏。
3、封闭的数据管理层
服务器的数据管理比较复杂，如果我们讲所有（或大部分）的数据交由一个独立的数据管理层进行管理，那么上层开发人员或者上层应用模块就不直接关心数据在哪个地方，怎么更新，怎么存储等。基于前面的实体系统，整个服务器的程序架构已经比较抽象，在这个抽象的类对象的基础上构建封闭的数据管理应该比散乱的大量不同对象的系统中构建数据管理层来得更方便，比如实体对象的属性集，基本可以涵盖一个实体对象大部分的数据，那么数据管理层只要管好属性集就可以带来不少的方便，而属性集中的大部分属性是通过配置而来的（至少很多需持久化的属性肯定是配置的），除了实体系统的数据，还有那些子系统和基于服务的那些对象都可以纳入数据管理层进行管理。
4、脚本化支持
对于游戏服务器那些核心的模块，通过脚本封装（如Lua封装）后，可以让上层应用层进行很好的扩展和开发，所以游戏服务器应该也必须支持脚本编程。像那些AI，任务，聊天等等大多数应用模块中的大部分代码都是可以拿脚本编写的。考虑到脚本性能问题，一些对性能影响比较大的地方还是建议用c/c++实现，脚本里面进行调控即可。
还有一些乱七八糟的东西，考虑到怕不小心泄密，这里就不多讲了。