源地址:http://www.cnblogs.com/metoy/p/4305326.html?utm_source=tuicool&utm_medium=referral
一、前言
此游戏服务器架构是一个单服的形式,也就是说所有游戏逻辑在一个工程里,没有区分登陆服务器、战斗服务器、世界服务器等。此架构已成功应用在了多款页游服务器 。在此框架中没有实现相关业务逻辑,只有简单的测试用的注册登陆功能。但在此框架中添加相应的业务逻辑也是比较轻松的,只需要添加相应的协议,编写对应的消息处理器即可。
下面是项目代码的地址:
服务器工程---GameServer,游戏服务器工程
测试客户端---TestClient,模拟客户端与服务器通信,用于测试服务器功能
项目工具 ---Tools,服务器搭建用到的jar包以及相关eclipse插件
二、服务器运行环境
此服务器是基于tomcat启动,所以GameServer是一个web工程,但此游戏服务器还是基于socket通信的,没有使用tomcat的http通信。游戏服务器的启动是通过在WEB-INF目录下的web.xml中添加一个监听器。这个监听器用来监听tomcat的启动和停止,当tomcat启动时则启动游戏服务器开始监听端口,当tomcat停止时则做相应的销毁操作。
可能很多人会疑惑为什么要基于tomcat呢?
基于tomcat运行有很多优势:
1、方便调试。在我们调试服务器程序时,可是利用tomcat的热加载功能,使修改的代码不用重启就可以生效
2、方便打包部署。部署一个web程序到tomcat是一个比较容易的事,对第三方jar包的依赖tomcat也会帮忙处理好
3、利用tomcat提供的数据源。这可能不算是优势,但起码还算便捷
4、方便开发GM。我们可以很容易的在次架构中加入一个机遇web的管理系统,直接管理当前游戏服务器的在线玩家
三、通信层
java开发socket服务器最常用的就是mina和netty这两个nio框架。网上有测试说netty性能稍好一些。但是由于mina在生产环境中没遇到什么问题,而且本人对mina源码比较熟悉,还是采用了mina作为通信层框架。(netty3跟mina代码结构差不多,但是netty4变化比较大,本人稍微未对源码理解透)
通信协议:flag(1 byte)+length(4 byte,消息号加消息内容的长度)+protocol code(4 byte)+content
flag:是一个预留标识
length:表示消息号和消息内容的长度
protocol code:自定义消息号,通过次消息号选择相应的消息处理器,自然消息号是不能重复的,一个int表示范围足够使用
content: 消息内容,一个有序的数据的数组。protocol code和content都要在开发功能时定义在‘消息协议’文档中的,例如GameServer项目中的“消息协议.xls”
此项目中没有对消息内容进行加密,若要加密也是很容易添加上。
消息处理:
服务器收到客户端发来的消息,MsgDispatcher会根据其消息号选择对应的MsgProcessor进行处理。MsgProcessor会读取content做相应的处理。
此架构的持久层使用了ibatis,可能大家觉着ibatis已经过时,现在最多时用的是mybatis。但在生产环境中ibatis一直未出现什么问题,还是可以再用的。还有mybatis的使用必须每次open一个connection使用完必须close掉,多少感觉有点麻烦(如果使用spring aop到可以避免这种问题)。而在ibatis中,它提供了一个SqlMapClient类,这个类是线程安全的,我们只需要把数据库操作交到SqlMapClient,它内部会帮我们open、close数据库连接。
做游戏开发都知道,游戏对数据库的要求比较低,我们不需要什么复杂的数据库操作,所以在持久层我们使用ibator做代码生成工具(相应的插件在Tools项目中有),可以节省大量的开发工作。
以上是对这个java页游服务器的简单概述,具体代码细节请看项目源码,语言描述似乎有点困难^_^。篇幅可能有点小,希望管理员不要老给移除掉,
十三次作业
十二次作业
十一次作业
十次作业
找回感觉的练习
CSS背景样式和列表样式
盒子模型案例应用
display属性
margin外边距属性