网络游戏核心技术与实战
-1 总结
带着问题
网页游戏,如何同时同步多个玩家信息
0 网络游戏编程
1 网络游戏的历史和眼花
1.1 网络游戏的技术历史
1.1.9 本世纪前10年的后半期: 基于WEB浏览器的MMOG在商业上的成功
3. 网络游戏的架构
3.1 游戏编程的特性--保持快速响应
3.1.2 将数据存放在内存中的理由
- 游戏数据要在16毫秒这一短暂时间内持续变化
3.3 物理架构详解
3.3.1 基本的网络拓扑结构
- 环型: 形成一个环,即使一条线路中断,还是能使用反反向的线路将信息传递给所有节点, 从一个节点到另外一个节点的平均拓扑数为所有节点数的一般
- 线型:
- 网状: 多个节点不规则的连接在一起
- 星型: 多个节点连接到一个特殊的中央节点,中央节点负荷很高
- 全网型: 所有节点互相连接,一个节点到另一个节点只需要1条线路,这种方式不适合那些线路维护成本很高的网络
- 树型
- 总线型: 多个节点由一条公共的总线连接
3.4 逻辑架构详解
3.4.1 MO MMO是什么--同时在线数的区别
MO: 同时在线为2~100人,游戏时间相对较短
MM0: 数百甚至上千,游戏通常几十个小时,而且不能充值游戏数据
3.4.4 同步方式/全网状结构的实现 -- 所有终端都拥有主数据
必要条件
- 初始状态完全相同
- 所有输入信息的数据包都确确实实的,毫无遗漏的发送到其他所有终端
- 游戏过程数据不会随机变化(如果结果完全相同的伪随机数没问题)
- 游戏过程数据的变化不会发生波动
要满足以上条件,需要做到
- 伪随机数的种子在所有终端保持一致
- 所有终端以完全相同的数据来初始化游戏
循环开始
- 所有终端开始输入信息的传输,在全部接受完成前始终处于等待状态
- 按照玩家A~Z顺序进行处理,依次改变游戏状态
- 渲染
- 受理下一个操作
- 发送自己这部分的输入信息
问题
- 人数增加后,收发信息的完整性极易奔溃
- 最慢的终端会拖长整体的传输时间
- 不能中途加入游戏
3.4.5 同步方式/星装结构
问题
- 响应较慢
- 如果玩家A中途离线,游戏无法恢复,只能强行中止
- 信息整理方面的逻辑增加时,程序的结构比全网的结构稍微复杂一些
- 玩家A的终端上传输负荷比其他终端高出许多,不公平
3.4.6 异步方式--接受各终端上游戏状态的不一致
三个重要因素 自己 对手 环境
3.4.8 自己和对手--对战游戏和玩家之间往来数据的抽象程度
特殊情况
- A攻击B
- A正在发送给包给B , A这里是打中了B,但是B在包发送的同时,进行了躲避,B显示没被A打中
3.4.9 保持结果一致性的方法--两种覆盖方法
- 采用造成伤害的那一方的结果
- 采用受到攻击的那一方的结果
就是把其中一者的结果 发给对方,并强行覆盖
3.4.11 互斥控制的实现--采用与同步方式类似的机制来实现异步方式
例如 两个人抢炸弹,如果不做处理,可能两个人同时拿到炸弹
对这种只能一个人拿到的物品,可以通过后台确认
就是捡炸弹的同时,给后台发送一个请求,谁的请求先到达后台,则返回结果为谁拿到
3.4.12 状态会自动变化的环境--静态环境和动态环境
纠正动态环境的误差
- 所有NPC的相关信息都在一个终端处理
- 定时修正NPC位置
- 根据某些规则将NPC分组
- 根据仇恨值信息进行分组
4. (实践)C/S MMO游戏开发
6. 网络游戏的辅助系统
这里的功能很多属于常用的业务功能,觉得有点多余
6.2 交互/通信功能
6.2.4 聊天
聊天功能的基本处理
- cli(游戏客户端)向聊天服务器发送信息,并同时向需要的客户端发送
- 需要在1~2秒内将信息送达需要的客户端(Push)
- 和邮件不同,不需要给不在线的玩家发信息,所以不用保存信息
- 服务器不需要保存用户日志