我在东土, 要去西天.
这是研发的第一篇, 没有什么好回顾的. 直接讲下计划. 由于本人最近生病, 所以明天需要去成都就医 . 可能会对这个阶段的进度有影响. 哎, 第一天就来这出~~是不是让大家失望呢?? 不过我相信万事开头难, 后面会好的.
首先是整个框架的设计. 框架分为 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 的数据并做出显示, 对设计没有影响.
架构大致就说到这里. 万里之行始于足下, 光想是没有用的,得做. 从哪里开始做呢 ?? 请看下一篇: 关于内存管理.
如果觉得《贫僧自东土大唐而来 前往西天拜佛求经 ( 研发 )》对你有帮助，请点赞、收藏，并留下你的观点哦！
