HTML5 vs Adobe Flash Player：网页游戏开发的双雄对决，你更爱谁？

阅读 所做概括性笔记。

第一章：网页游戏概述

1.1 多人游戏适合的领域

1.1.1 典型目的

1. 从广告中获取收益

通过广告展示获取收益。尽可能多地吸引网民来访问你的网站，并且使他们驻留的时间更长，从而给你的站点带来更多的广告曝光次数。

2. 使站点更具吸引力

非游戏网站会通过引入一些游戏以让访客逗留更长的事件。

3. 市场营销

（多人互动）游戏常被用来宣传推销电影、电视节目和体育赛事等。

4. 推动下载

通过免费的轻量级网页游戏（目标推销游戏的精简版）来推销他们可下载游戏产品。

5. 教育

通过教学和游戏结合起来使得枯燥的教学变有趣。

6. 提供订阅价值（不明所以）

通过支付包月费用，用户给可以定期获得新特性和新内容。

7. 因为我能

开发者展示个人作品。

小结： 以上的典型目的其实主要都是提高网页与用户的互动性，让用户觉得有趣有价值。

链接用户

2.1 链接技术

2.1.1 P2P（Peer-to-Peer 对等网络） 架构

两个或多个客户端不经过服务器而直接通信的架构。信息只在客户端间传送，不需要服务器的介入。可能会首先使用服务器以让客户端之间能查找到对方，但此后就不再需要了。

优点 ：

1. 延时小。比C/S少了消息从客户端到服务器的传递时间。( C/S: C -> S -> C, P2P: C -> C )
2. 不需要服务器。较少了维护服务器的成本（时间 + 金钱）。

缺点 ：

1. 游戏的可扩展性差。适用于游戏客户端比较少的情况。游戏客户端比较多的时候，每个客户端都需要维持大量的开放链接，网络负担大。
2. 争议解决机制不健全，没有中心逻辑的决策者。游戏状态判定会出现争议或者冲突。例如： A、B玩家都残血，到最后互相发了一个必杀技，那么谁先倒下？

解决缺点？ ：
可以通过设定其中一台客户端充当主机，让他决策所有带来争议的逻辑。但是这样的话的就丧失了P2P的优势（延迟低），而且也存在巨大的安全隐患（充当主机的客户端在争议逻辑上具有决定权）。这样还不如使用C/S架构。

2.1.2 轮询（不建议使用的链接技术）

客户端定时给服务器发送请求以检查信息更新的过程。

缺点 ：

1. 可扩展性差。客户端数量大的时候，每次轮询的流量巨大，对服务器的消耗巨大。
2. 网络延迟大。每次轮询消耗的时间大，不适用于实时要求高的游戏。
3. 客户端断线处理延迟。客户端离线，只能通过服务器主动去"注意到"客户端已经没有发出轮询请求。

2.1.3 Socket服务器

网络上的两个程序（S-S，C-S，C-C）通过一个双向的通信连接实现数据的交换。

本质 : socket 的原意是“插座”，在计算机通信领域，socket 被翻译为“套接字”，它是计算机之间进行通信的一种约定或一种方式。通过 socket 这种约定，一台计算机可以接收其他计算机的数据，也可以向其他计算机发送数据。

优点 ：

1. 双向通信。
2. 节约资源。
3. 实时，延迟小。

第三章 安全

3.1 逻辑安全

为参与到玩家打造一个安全（信息隐藏、过滤）的虚拟世界。

3.2 物理安全

在实践中防止黑客盗取数据、毁坏程序和扰乱他人的用户体验过程。

3.2.1 问题与解决方案

1. 最小化接触面（全局）

努力使得黑客所能接触到的系统区域（代码、服务器、数据、客户端操控区域等）最小化。

2. 晦涩不等于安全

晦涩复杂的加密算法不等于安全。应该保证即使黑客确切地知道了程序的算法也不能破解。

3. 一概不信

与其信任客户端的验证不如让服务器对聊天消息进行验证。让服务器帮助验证或处理数据。

4. 验证一切

不要相信客户端（反之亦然），验证一切客户端发送给服务器的东西，以确保它永不破坏规则造成麻烦。

5. 诱捕一切

假设客户端在错误的时间发送数据，或者发送的数据格式不正确。你应该在服务器端诱捕这些错误并可能详尽的记录下错误的信息。有助于你根据需要修补和加固系统。

6. 非需则删

与上述的最小接触面原则相似的。不需要的工具、代码，输出等都不能暴露给用户。

7. 不授人以柄

自定义错误代码（err code）即便让用户看到也无法轻易理解他们的原意。

3.2.2 防火墙

限制访问、阻断没有开发的的访问，保护服务器运行环境。

3.2.3 常见黑客行为

1. 利用游戏行为（游戏漏洞）
2. SQL注入
3. 跨站脚本执行
4. 数据包注入
5. 修改消息
6. 内存变量攻击

第五章 聊天

用户可以发信息给他人，对方可以立即看到该信息。用户可以用这种方式来了解彼此、插科打诨，或者在团队游戏中进行战略配合。

5.1 概述

5.1.1 聊天能见度

公开消息 ： 用户在知道某范围内的其他用户将看到此消息的情况下发送给服务器的一种消息。一般情况下，公开聊天会在同一房间内的用户间发生。房间中的任何一个用户都可以直接往在该房间发送公开聊天消息，然后此消息就会被广播给该房间中的所有用户。

5.1.2 聊天类型

**自由进入式: ** 用户可以自由地用键盘来输入他们想说的话，尽管在输入话语的时候可能会存在一些语言过滤，但在大部分情况下是不受约束的。

**基于列表式（类似于快捷消息）: ** 让用户从一个分级列表中选择聊天词组来进行聊天。

5.1.3 概念

房间概念

房间是Socket服务器领域中的一个常见的概念，它指的是用户的集合。

• 固有型房间：即使其内没有用户也将一直存在下去的房间。
• 动态型房间：为单次使用所创建的房间。如果此类房间内的用户数目降为0，则表明所有用户都已经离开了该房间，那么该房间将被系统摧毁。

区的概念

区指的是房间的集合。主要被用来组织管理服务器上众多的房间。区内的每个房间都必须有唯一的名称。区内房间中的每个用户都能获得本区中房间列表。每当房间列表变动时，用户都能自动订阅到更新后的房间列表。

第六章 游戏逻辑决策位置

6.1 概念

6.1.1 客户端权威型

多数重要的游戏逻辑在客户端上裁决的游戏类型

所有信息都是已知的回合制游戏最可能适合采用客户端权威型模式。“所有信息都是已知”指信息处理不存在偶然性与隐含性
例如： 桌球、棋类、等回合制游戏

6.1.2 服务器权威型

多数重要的游戏逻辑在服务器上裁决的游戏类型

多数实时类游戏（不存在回合的游戏）自动归属于服务器权威型游戏。另外，在游戏信息处理上存在偶然性或者尚未透明的某些回合制游戏也应该用服务器权威型来处理。
例如： 多人坦克大战、赛车、德州扑克等棋牌类游戏。

6.1.3 何时采用何种模式

• 对于这种问题是没有什么万灵药的，只能根据游戏需求去做定制。
• 所有信息都是已知的回合制游戏最有可能适合客户端权位型模式，“所有信息已知”指信息处理不存在偶然性与隐含性。符合这些标准的游戏包括国际象棋、跳起、四子棋还有落袋桌球。
• 多数实时类游戏（不存在回合的游戏）自动归属于服务器端权威型游戏。另外，在游戏信息处理上存在着偶然性或者尚未透明的某些回合制游戏也适宜用服务器端权威型来处理。例如：德州扑克、塔克大战、斗地主等
• 当然部分游戏时会存在着客户端权威型部分也存在着服务器端权威型部分。通常这种混合方式处理方法中，客户端权威型的作用无关轻重（不会直接影响游戏结果）。

7 实时运动

7.1 响应控制

客户端立即响应用户的输入，如果服务器同意该操作，则客户端和服务器端也就达成了同步，如果不同意，则客户端需要对之前的操作给予修正。这过程中会产生跳动现象。

7.2 路径类型

7.2.1 路点

路点： 游戏对象的目标位置。游戏对象会从其当前位置运动到该路点。

7.2.2 矢量/航向

通过运动对象的航向信息，可以执行预测运动。

7.2.3 视线

一个初始点，例如一辆车或者一把枪所在的位置。视线就是从初始点指向某个选定向外的方向（例如枪口所面对的方向）所引出的一条路径，并且最终当它碰到某个物体时就会停下来。

7.3 基于帧的运动

对象的位置会随着帧的刷新而不断变化。

由于硬件的帧速率都有所不同，这就造成了播放相同的动画，电脑慢的玩家比电脑快的玩家需要的时间长得多。
所以基于帧运动的通常适用于对时间同步要求不太高的多人游戏。

…待续

参考