网络游戏核心技术与实战

-1 总结

带着问题

网页游戏,如何同时同步多个玩家信息

0 网络游戏编程

1 网络游戏的历史和眼花

1.1 网络游戏的技术历史

1.1.9 本世纪前10年的后半期: 基于WEB浏览器的MMOG在商业上的成功

3. 网络游戏的架构

3.1 游戏编程的特性--保持快速响应

3.1.2 将数据存放在内存中的理由

  1. 游戏数据要在16毫秒这一短暂时间内持续变化

3.3 物理架构详解

3.3.1 基本的网络拓扑结构

  1. 环型: 形成一个环,即使一条线路中断,还是能使用反反向的线路将信息传递给所有节点, 从一个节点到另外一个节点的平均拓扑数为所有节点数的一般
  2. 线型:
  3. 网状: 多个节点不规则的连接在一起
  4. 星型: 多个节点连接到一个特殊的中央节点,中央节点负荷很高
  5. 全网型: 所有节点互相连接,一个节点到另一个节点只需要1条线路,这种方式不适合那些线路维护成本很高的网络
  6. 树型
  7. 总线型: 多个节点由一条公共的总线连接

3.4 逻辑架构详解

3.4.1 MO MMO是什么--同时在线数的区别

MO: 同时在线为2~100人,游戏时间相对较短

MM0: 数百甚至上千,游戏通常几十个小时,而且不能充值游戏数据

3.4.4 同步方式/全网状结构的实现 -- 所有终端都拥有主数据

必要条件

  1. 初始状态完全相同
  2. 所有输入信息的数据包都确确实实的,毫无遗漏的发送到其他所有终端
  3. 游戏过程数据不会随机变化(如果结果完全相同的伪随机数没问题)
  4. 游戏过程数据的变化不会发生波动

要满足以上条件,需要做到

  1. 伪随机数的种子在所有终端保持一致
  2. 所有终端以完全相同的数据来初始化游戏
  3. 循环开始

    1. 所有终端开始输入信息的传输,在全部接受完成前始终处于等待状态
    2. 按照玩家A~Z顺序进行处理,依次改变游戏状态
    3. 渲染
    4. 受理下一个操作
    5. 发送自己这部分的输入信息

问题

  1. 人数增加后,收发信息的完整性极易奔溃
  2. 最慢的终端会拖长整体的传输时间
  3. 不能中途加入游戏

3.4.5 同步方式/星装结构

问题

  1. 响应较慢
  2. 如果玩家A中途离线,游戏无法恢复,只能强行中止
  3. 信息整理方面的逻辑增加时,程序的结构比全网的结构稍微复杂一些
  4. 玩家A的终端上传输负荷比其他终端高出许多,不公平

3.4.6 异步方式--接受各终端上游戏状态的不一致

三个重要因素 自己 对手 环境

3.4.8 自己和对手--对战游戏和玩家之间往来数据的抽象程度

特殊情况

  1. A攻击B
  2. A正在发送给包给B , A这里是打中了B,但是B在包发送的同时,进行了躲避,B显示没被A打中

3.4.9 保持结果一致性的方法--两种覆盖方法

  1. 采用造成伤害的那一方的结果
  2. 采用受到攻击的那一方的结果

就是把其中一者的结果 发给对方,并强行覆盖

3.4.11 互斥控制的实现--采用与同步方式类似的机制来实现异步方式

例如 两个人抢炸弹,如果不做处理,可能两个人同时拿到炸弹

对这种只能一个人拿到的物品,可以通过后台确认

就是捡炸弹的同时,给后台发送一个请求,谁的请求先到达后台,则返回结果为谁拿到

3.4.12 状态会自动变化的环境--静态环境和动态环境

纠正动态环境的误差

  1. 所有NPC的相关信息都在一个终端处理
  2. 定时修正NPC位置
  3. 根据某些规则将NPC分组
    1. 根据仇恨值信息进行分组

4. (实践)C/S MMO游戏开发

6. 网络游戏的辅助系统

这里的功能很多属于常用的业务功能,觉得有点多余

6.2 交互/通信功能

6.2.4 聊天

聊天功能的基本处理

  1. cli(游戏客户端)向聊天服务器发送信息,并同时向需要的客户端发送
  2. 需要在1~2秒内将信息送达需要的客户端(Push)
  3. 和邮件不同,不需要给不在线的玩家发信息,所以不用保存信息
  4. 服务器不需要保存用户日志
© 404mzk all right reserved,powered by Gitbook该文件修订时间: 2017-04-06 01:42:56

results matching ""

    No results matching ""