贫僧自东土大唐而来, 前往西天拜佛求经 ( 研发 )

我在东土,  要去西天.

这是研发的第一篇,  没有什么好回顾的.   直接讲下计划.  由于本人最近生病, 所以明天需要去成都就医   .  可能会对这个阶段的进度有影响.    哎,   第一天就来这出~~是不是让大家失望呢??    不过我相信万事开头难,  后面会好的.

首先是整个框架的设计.   框架分为  3  层.     (服务器和客户端均为此结构)

1:   网络层.   这一层没什么新鲜的东西,   需要实现的功能相对简单.  连接,  被连接,  断连接 , 被断连接.   send()一个buff,   recv()一个buff.  这一层会相对独立且在几个线程中运行.  与加密解密,  无关. 对socket封装.   上层只会知道一个id  连接, 或者断开 以及某id 接收到的buff,  以及向某id发送buff.   由于这部分实现于架构无关且与平台关联密切,   所以我会去实现一个基于windows的简单实现.   效率暂时不做需求.   并且期待以后会有朋友再来完成这块的实现.  以实现跨平台   和   高效率. 

2:   中间层.   这一层运行在一个线程中,  与具体的实现没有直接关系,   专注于处理 网络层, 管理连接状态, 管理  接收到的buff向逻辑层投递,  以及逻辑层产生的buff向网络层投递.  以及buff回收的辅助. 管理进程之间连接的状态, 对非法操作的第一次检验.(也可以做buff的加密解密.  压缩解压缩.  但是由于只有一个线程,  不清楚效率瓶颈,  所以也有计划把这部分做到逻辑层, 好像影响不大,  但是会有一次buff存储地转换,   多一层bug风险).

3:   逻辑层.   这一层做的就是逻辑工作了.  

对于服务器来说,  一个具体buff投递进来被分析成消息,  驱动对应obj 的消息处理函数调用,   就是消息机制.   另外一个是定时器的回调来驱动逻辑. 这两个机制构成了obj 的驱动.  所有的需要响应消息 或 定时器事件的物件都必须继承obj.  

对于客户端来说会更复杂一点,  因为客户端会多一层驱动:  即界面驱动.   而对于测试端,   界面驱动被换成了脚本驱动.  到实现层面上来说,  界面驱动  和   脚本驱动  会一致的调用  obj 接口实现.   客户端obj 中,   只有直接控制的玩家会被界面或脚本驱动.   脚本基于轮训机制或者   定时器机制.

也就是说,   逻辑层  分为    驱动  和  响应  两部分.   服务器的驱动层  只有定时器和消息.   而客户端还会多出  界面或者脚本.    当然客户端还有一个显示部分.   这部分好像只是读取obj list 的数据并做出显示,   对设计没有影响. 

架构大致就说到这里.   万里之行始于足下,   光想是没有用的,得做.   从哪里开始做呢 ??    请看下一篇:   关于内存管理.