《action script大型网页游戏开发》读书笔记

【 关于安全 】

1）最小化接触面。让用户能够接触到的信息最小化。

2）晦涩不等于安全。不要以为加了密就是安全了，应该保证即使黑客确切知道了程序算法也不能破解，这样才真正安全。

3）一概不信。不要相信客户端的验证，一定要在server端也进行验证，防止黑客绕过客户端验证机制。

4）验证一切。客户端和服务端都需要一套验证机制，互不信任对方的信息，一定要用一套规则先进行验证，通过了才相信。

5）诱捕一切。应该在server端做一个日记系统，记录所有不寻常的数据。通过分析这些数据，可以猜到黑客在尝试如何攻击你的系统，并根据需要修补或加固系统。

6）非需则删。如果某些文件或代码是可有可无的，那么就删掉它们，越多东西暴露，就给黑客越多攻击的目标。

7）不授人以柄。记录和调试信息对于我们来说非常重要，便如果没黑客拿到了，会给他们提供非常多的信息，所以无论如何都不能让黑客得到他们。

8）防火墙。对于保证互联网应用程序的安全来说，正确配置防火墙是关键的。

 

【 关于聊天 】

1）聊天分为“公开聊天”和“私密聊天”两类。 其中公开聊天会在同一房间内的用户间发生，某个用户的发言会广播给房间内的其他所有用户。而私密聊天指用户直接发送给一个或多个其他用户的一种消息，发送私密消息的用户可以不必在房间中。

2）聊天模式可以分为“自由进入式”和“基于列表式”。自由进入式，用户可以自己随意输入文本，而基于列表式用户只能从预设的句子里挑选，不能自己输入文本。

3）聊天过滤。过滤可以基于白名单或黑名单。需要注意的是聊天过滤对性能的影响可能超过你想像，有时甚至耗费了越过50%的计算资源。由蛮力匹配转变成基于特里结构的匹配方案会极大地节省执行时间。

 

【 关于房间 】

1）房间大体上可以分为动态型和固有型。 动态型房间当人数为0时，会自动销毁，而固有型房间，当人数为0时也不会自动销毁。

2）房间是用户的集合，大厅是房间的集合，区也是房间的集合。

3）加入房间的方法有两种，一种是join(roomid)，另一种是create(roomid)。 join用于加入一个已经存在的房间，如果房间不存在，则报错。create用户创建或加入一个房间，如果房间存在，那么加入，如果不存在，那么创建一个，不会报错。

4）关于房间相关的设置：

    <1> 是否接收用户列表更新。 有用户进入或退出时，是否提醒用户。（可以在加入房间时由用户自己设置，也可以在新建房间时，由房主设置，两重设置）

     <2> 房间容量。房间所有容纳的最大人数值。（房主设置）

     <3> 隐藏。如果设为隐藏，则此房间不会出现在区的房间列表上。（房主设置）

     <4> 插件。可以为此房间挂上定制的插件，其作用域为该房间。（房主设置）

 

 【 客户端权威型和服务器端权威型 】

1）如果是制作单机游戏，所有的逻辑处理全在客户端，不存在同步问题。但如果制作多人联机游戏，就涉及到一个同步的问题，关键逻辑是写在客户端还是服务器端需要权衡。

2）所有信息都是已知的回合制游戏最有可能适合采用客户端权威型模式，信息处理不存在偶然性和隐含性。符合这些标准的游戏包括国际象棋、跳棋、四子棋和落袋桌球。 多数实时类游戏（不存在回合的游戏）自动归属于服务器端权威模式。

3）如存在疑问，则最好把游戏逻辑交付服务器端裁决。但需要注意的是，如果不影响游戏结果的修饰性的操作，就可以完全由客户端进行操控。

 

【 socket 】

1）socket和ajax不同，socket连续发送多个请求至server端的时候，可以保证这些请求的次序不变。因此你可以放心大胆地连续快速发送给服务器端数个消息，它们会以同样的次序被服务器端接受并处理。

2）为缓解客户端和server端的通信压力，最好不要过于频繁地发送消息，无论是客户端至server端，还是server端至客户端。最好的解决办法是“消息集成”，将多个零散的消息打包在一个较大的消息包里发送，而不是发送单个消息。尽量保持客户端每秒处理5个或更少的消息。

 

【 响应控制 】

1）由于需要同步多个客户端，所以客户端是不能擅自移动它的角色的。由此引发的一个常见的错误就是：用户进行操作之后并不会立即让角色进行响应，而是发往服务器端，等服务器端进行了逻辑判断之后，将响应结果返回客户端，客户端接收到返回结果后才开始移动。如此一来，会有一个网络延迟，如果在本地网络中，这种延迟还可以接受，但到了互联网上运行的话，这确实是个问题。

     假如游戏是基于时间同步的，而且客户端认为应该可以避免服务器端对运动与碰撞进行验证，那么最好的用户体验就是让客户端立即响应用户的输入，就好像服务器会同意这样做一样。如果后来服务器同意了（几乎都会同意），那么客户端和服务器端也就达成了同步。假如万一服务器拒绝了运动请求，那么客户端就应该对之前的操作予以修正，在此过程中会导致跳动的现象发生（以前玩泡泡堂经常让我走了白走，跳来跳去原来是这么回事啊— — ||）。这种罕见的跳动是可以接受的，因为从总体上来盾，响应还算令人满意，用户体验也还不错。

 

【 路径 】

1）对于“抽筋式”运动，即第一人称射击类或赛车类，角色随时可能会以非常快的速度改变方向的运动，如果实时地通过更新“位置”来同步状态，玩家很难收到足够多的信息来平滑且合理地渲染出所有的游戏对象。

    对于这种类型的运动，最好不要基于“位置”来同步状态，而是基于“向量”——时时更新用户的速度和方向，而不是位置。在收到新的向量以前，用户保持当前向量移动。这也可以称之为“预测运动”，也就是说，在接收到更多最新的服务器响应之前，它能让你的游戏对象在最合理的方向上继续运动。

 

 【 视线 】

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

2）游戏中的人工智能（AI）使用视线来确定它所能看到的场景内容，就好像它也是游戏玩家中的一员一样。

3）视线有助于我们确定期望路径或尝试路径是否有效。

 

【 关卡编辑器 】

一般来说，游戏地图都是一些格式化文件，例如json或XML，如果手动去做写这些文件会非常辛苦。更好的办法是做一个关卡编辑器，可以载入地图文件，生成、编辑、保存地图文件，产出物为json或XML。

 

【 卷屏 】

当你把鼠标放到距离程序上下左右边界10像素以内时，屏幕就会卷动。

 

转载于:https://www.cnblogs.com/cly84920/archive/2010/12/31/4426630.html