系列四：游戏服务器的阶段小总结

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..