QQ: 2#4#2#1#0#6#7#6#4 #表示为空
Mail: lin_style#foxmail.com #替换成@
系列一:游戏服务器的总体框架
系列二:游戏服务器的邮局路由
系列三:游戏服务器的邮局服务器
该篇的小总结主要是想综合我手上的代码情况做个总结。此篇后,可能会暂时停止编码,我发现我的很多思维上的东西,其他类似的已经有很多交集点。因此我觉得需要潜心专研几个其他的框架。 而现在手头上的编码大概有4000行左右(不完全统计),一些很基本的服务器和框架形状已经呈现,达到目的了,再下去就是闭门造车了。而且对以前发的文章一些新的方法也不在更新了。
目前已有的组件:
- CommonLib:顾名思义
- ClientPlay:模拟的客户端
- PostofficeRoute:控制邮局的路由
- PostofficeServer:邮局
- ServerBin:逻辑服务器
- ServerDPC:无。一个延迟的事件处理(对逻辑服务器的全局控制)
目前编码的风格方式:
可以参考前面的几个章节。因此在目录的大分类上,把最主要的提取出来,使得一目了然(自认为):
- Config:配置文件
- Protocol:协议文件
- Logic:逻辑层
- Brdige:粘贴逻辑/网络层的一个文件头,主要是放置两边通用的信息
- Network:网络层
- Standalone:一些独立的对象文件
- 其他:一些主函数体
在工程的内部,我就开始细分。见图:
既然是做游戏,那么为了符合一个理解,我把Role,Scene单独提炼了出来。在Standalone里我放置了平常需要用到的单独对象,比如需要自定的时间、封装的线程生命周期,可以放到"OS"这个单独的目录里,其他也是如此。不过注意,我把算法"Algorithm"单独提取了出来。
这样通过目录的分层和工程内部的分层,起码对我来说,隔个十几天再去回顾时,这些名字和结构很容易提醒起我这是干嘛的
并且在名字上,为了保持统一性,比如这个工程师PostofficeServer(邮局的),那么他可能对bin和PostofficeRoute都要进行通讯,那么在Network里命名规则就是CServerXXXX, CServer即PostofficeServer的缩写,XXXX如果是Route,就表示是对PostofficeRoute的通讯。除此之外,在Logic,protocol里等等,我都采取了这样的规则( “C主方次方” )。一点小规则。。
每个组件现在能完成的功能:
- ClientPlay:可以加入协议开始和服务端调测
- PostofficeRoute:可以根据CPU数自动的开启对应的UDP线程对客户端回应;可以根据邮局服务器的更新做出负载控制(见前三章);可以动态的接收连接
- PostofficeServer:可以做出与Route的控制更新;可以接受客户端的连接;可以和ServerBin进行通讯;可以动态的接收ServerBin的连接;可以支持PostofficeServe和ServerBin的对应关系;可以进行客户端在ServerBin的动态跳转
- ServerBin:主要配合PostofficeServer的调试。数据库,角色等不具体写代码
- ServerDPC:无。一个延迟的事件处理(对逻辑服务器的全局控制)
完成这些功能调试后暂时收工:
- 客户端到ServerBin的信息互相转发
- 客户端动态的在ServerBin上切换
尾声:
在不知不觉的挤时间中,它终于有点了小的模型和设计。截止发布这篇文章为止,svn的版本已经到了200。这就可以看出平时我对它的时间是多么的零碎。
不过,最近发生了一点事,进度拖了很多。咳~~end..