mudos到传奇一路走来网游差不多快15个年头了吧。从最早的商业版本游戏传奇的泄露到ro2的服务器泄露,网游的服务端架构已经日趋成熟平均在线人数都在千人以上。eAthena(雅典娜计划)是根据ro2服务端改写而成,按现在的市场上的商业产品分类r02比传奇其实高不了太多,属于2D版本的游戏,但相比传奇是从一个单机版计划转为网络游戏的过渡期。ro2是纯粹的网络游戏设计从一开始就是面向网络的。我估计ro2成熟度相对欧美一流公司仍然有一代左右的差距。和国内某些自开发版本的网游技术成熟度是相当的。相对于一个新技术网络游戏的核心技术一直是商业公司的机密难得有机会管中窥豹。因其代码放在服务端又加上重重的保密措施,这次的泄漏事件向我们展示较新的商业版本。前面说过eAthena的技术已经比较成熟的无论2D或3D就架构而言差距不会太大,服务端主要是数据的组织的整理。eAthena分为3大部分加上若干的工具。3大部分主要是char--主要负责快速存储数据相当于内存数据库。login--负责登陆和退出维护加密帐户。map--主要的游戏服务器以地图作为管理的边界是比较先进的理念了 。工程内还有其他的工具,文档包括各种命令的介绍包括script_commands.txt别名F***ing Manual,和各种数据配置的文档。单从服务器其个个分割点来看官网服务器应该有更多的配套软件,例如游戏的配置工具,内容的脚本开发工具等等。很遗憾看到模拟器的map服务为跨平台为单线程结构,如果不能开两个以上的线程很难想象服务器可以支持脚本调试。不过因为服务器端做了绝大部分的框架工作eAthena的脚本相对比较简单,提供的只是有限的扩展。脚本和服务器的可扩展性是相对的,过多的脚本会导致服务器潜在的安全问题。不能提供一个写不错的脚本给非计算机专业人员是比较危险的。结束语虽然没有机会看到真正的商业代码,eAthena给我们始终是一个管中窥豹的感觉。归于强脚本的mudos和脚本配置平衡的eAthena。在性能上的差距还是很明显的如以下测试
http://www.timestretch.com/FractalBenchmark.html
毕竟脚本比C执行速度要慢30倍,估计读配置时间都要比脚本更快。mudos的道路恐怕不太好走,就目前的情况看脚本和C的差距还不是一个量级的。
闲言两句,扁平设计似乎是游戏服务器的一个发展趋势,功能模块围绕主要数据展开成环形包围在主要数数据结构周围。功能模块之间的数据耦合降低的最低。这也许应该当作基本的设计要求。当一个模块移除不应当影响到游戏的其他的模块是最好的设计。每个模块的框架设计稳定有适当的脚本扩展,脚本的扩展以满足数据策划为主,辅助以游戏逻辑的适当扩展。