贫僧自东土大唐而来, 前往西天拜佛求经 ( 研发 )
2016-06-10 15:39
281 查看
我在东土, 要去西天.
这是研发的第一篇, 没有什么好回顾的. 直接讲下计划. 由于本人最近生病, 所以明天需要去成都就医 . 可能会对这个阶段的进度有影响. 哎, 第一天就来这出~~是不是让大家失望呢?? 不过我相信万事开头难, 后面会好的.
首先是整个框架的设计. 框架分为 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 的数据并做出显示, 对设计没有影响.
架构大致就说到这里. 万里之行始于足下, 光想是没有用的,得做. 从哪里开始做呢 ?? 请看下一篇: 关于内存管理.
这是研发的第一篇, 没有什么好回顾的. 直接讲下计划. 由于本人最近生病, 所以明天需要去成都就医 . 可能会对这个阶段的进度有影响. 哎, 第一天就来这出~~是不是让大家失望呢?? 不过我相信万事开头难, 后面会好的.
首先是整个框架的设计. 框架分为 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 的数据并做出显示, 对设计没有影响.
架构大致就说到这里. 万里之行始于足下, 光想是没有用的,得做. 从哪里开始做呢 ?? 请看下一篇: 关于内存管理.
相关文章推荐
- 我是运营,我没有假期
- 每个 Linux 游戏玩家都绝不想要的恼人体验
- 在 Fedora 上使用 Steam play 和 Proton 来玩 Windows 游戏
- 国外程序员推荐:每个程序员都应读的书
- Steam 让我们在 Linux 上玩 Windows 的游戏更加容易
- 如何使用 Steam Play 在 Linux 上玩仅限 Windows 的游戏
- 新一代iPad适配应用之游戏篇
- VB实现的《QQ美女找茬游戏》作弊器实例
- 插件管理框架 for Delphi(一)
- 使用CSS框架布局的缺点和优点小结
- C#实现洗牌游戏实例
- C#实现的算24点游戏算法实例分析
- 一起动手编写Android图片加载框架
- C#实现简单的井字游戏实例
- 基于.NET平台常用的框架和开源程序整理
- C++编写简单的打靶游戏
- C++实现基于控制台界面的吃豆子游戏
- 列举PHP的Yii 2框架的开发优势
- Windows窗体的.Net框架绘图技术实现方法
- 浅谈JavaScript 框架分类