网页游戏架构与开发入门

《网页游戏架构与开发入门》由会员分享，可在线阅读，更多相关《网页游戏架构与开发入门（26页珍藏版）》请在金锄头文库上搜索。

1、1 2 3 列举几个例子： 一，策划类似于设计师，比如一位设计师要求一位木匠师傅给其打造一款具有 流线型的架子（木匠问：何为流线型），比如设计师画出汽车平面图要求木匠 师傅打造按平面图打造汽车模型（结果木匠确实按平面图打出了汽车模型，不 过只有两个轮子，另外两个轮子因为看不到）。 二，昨天策划提到需要开发一个功能，打开人物面板，鼠标点击人物空缺的装 备位置，可以为玩家立刻装备背包中一件评分最高的装备， 等服务端接口写好后，策划又说，还要补充下，因该是鼠标放上去没点，匹配 的评分最高的装备就已经显示在鼠标TIP中了，类似神仙道那种，各种崩溃。 三，列举咖啡机的例子，我们一起来开发一款自动咖啡机系

2、统吧，策划提出需 求，想喝咖啡者，只需点击桌面一个按钮， 计算机自动遍历在8楼楼层获取到咖啡机位置，然后把杯子放到咖啡机下，自动 点击第二个按钮，出咖啡，咖啡自动送到订咖啡者座位上。系统就这么简单 的实现了，这个世界因此而美好了。 但是用户使用下来发现，每次点击桌面获取咖啡按钮后，咖啡送到位置上需要3 分零5秒，很多用户无法接受这个时间，太慢了，汇报到策划这边，策划找来 程序查明原因，发现咖啡机出咖啡和送到预订者位置一共也就花了5秒钟，但是 计算机自动遍历8楼楼层的咖啡机却用了3分钟，这个差距太大了。 于是优化，策划表示可以直接定位咖啡机位置，告诉计算机咖啡机就在楼梯口 附近哪个坐标位置，于是

3、速度一下提升，以后预订咖啡只用5秒。 后期故障问题：咖啡机没水了，咖啡机没咖啡豆了，打补丁解决，崩溃的故障， 咖啡机在有水有豆的前提下，有时能出咖啡，有时不能出咖啡。 4 网页游戏其实就是用浏览器玩的游戏，它不用下载客户端，只要一台能上网的电脑就可以进行游戏。 有人按下载客户端来划分是否网页游戏。 有人按是否在浏览器中玩的游戏来划分是否网页游戏。 有人按用户来划分是否网页游戏。 个人较认可定义：基于浏览器，拥有片段游戏时间的用户进行的网络游戏称为网页游戏。 下面我们主要针对这类游戏架构与开发进行探讨。 网页游戏可以看作是网站和游戏的结合体，因此它具备了这两类系统的特性。 我们不但可以把网页游戏

4、看作是一个网站，也可以把它看作是一个网络游戏。 网站是B/S结构，网络游戏则是C/S结构，网页游戏则是这两者的结合。 5 转场 6 网站是B/S结构。 以上是经典的MVC设计模式：浏览器通过HTTP协议发送数据请求，由控制器接 受请求，通过路径委托给数据模型处理，模型通过与逻辑层和持久层的交互， 把处理结果反馈给控制器，控制器根据结果组装视图，并最终反馈给客户端浏 览器。 和传统的C+网络游戏编程有些不一样，客户端网游在服务端会实例化玩家对象， 当客户端玩家属性发生变化时，服务端对应玩家对象属性也会发生变化。 而页游HTTP协议更偏向于网站方式，不可能在服务端实例化出一个完整的玩家 对象并进行

5、保存，而当客户端发起请求时，只是获取客户端需要的用户数据并 返回给客户端。 7 以上是一段经典的互联网网站架构发展史： 图1：最开始，由于某些想法，于是在互联网上搭建了一个网站，这个时候甚至有可能 主机都是租借的。吸引了部分人访问，逐渐你发现系统的压力越来越高，响应速度越 来越慢，而这个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也 很容易出现问题，而数据库出问题的时候，应用也容易出问题，于是进入了第一步演 变阶段：将应用和数据库从物理上分离，变成了两台机器，这个时候技术上没有什么 新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住 了更高的流量，并且不会

6、因为数据库和应用形成互相的影响。 图2：好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因， 发现是访问数据库的操作太多，导致数据连接竞争激烈，所以响应变慢，但数据库连 接又不能开太多，否则数据库机器压力会很高，因此考虑采用缓存机制来减少数据库 连接资源的竞争和对数据库读的压力，这个时候首先也许会选择采用squid 等类似的机 制来将系统中相对静态的页面进行缓存（当然，也可以采用将页面静态化的方案）， 这样程序上可以不做修改，就能够很好的减少对webserver的压力以及减少数据库连接 资源的竞争，于是开始采用squid来做相对静态的页面的缓存。（squid：代理服务器软 件

7、，网页服务器的前置cache服务器缓存，不仅支持HTTP协议，还支持FTP、gopher、 SSL和WAIS等协议） 图3：增加了squid做缓存后，整体系统的速度确实是提升了，webserver的压力也开始 下降了，但随着访问量的增加，发现系统又开始变的有些慢了，在尝到了squid之类的 动态缓存带来的好处后，开始想能不能让现在那些动态页面里相对静态的部分也缓存 起来呢，因此考虑采用类似ESI之类的页面片段缓存策略，OK，于是开始采用ESI来做动 态页面中相对静态的片段部分的缓存。（ESI：一种数据缓冲/缓存服务器，部分地缓冲 网页，使用基于XML的标记语言，指示想要缓冲的页面部分。）此处可

8、合理使用AJAX， 进行缓存页面上局部动态数据的加载。 8 图4：在采用ESI之类的技术再次提高了系统的缓存效果后，系统的压力确实进一 步降低了，但同样，随着访问量的增加，系统还是开始变慢，经过查找，可能 会发现系统中存在一些重复获取数据信息的地方，像获取用户信息等，这个时 候开始考虑是不是可以将这些数据信息也缓存起来呢，于是将这些数据缓存到 本地内存，改变完毕后，完全符合预期，系统的响应速度又恢复了，数据库的 压力也再度降低了不少。 图5：好景不长，发现随着系统访问量的再度增加，webserver机器的压力在高峰 期会上升到比较高，这个时候开始考虑增加webserver，进行负载均衡方案。

9、在解决了这些问题后，终于是把webserver增加为了两台，系统终于是又恢复到 了以往的速度。 享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这 次又是什么状况呢，经过查找，发现数据库写入、更新的这些操作的部分数据 库连接的资源竞争非常激烈，导致了系统变慢，因此考虑分库策略，分库也就 意味着要对原有程序进行修改，一通修改实现分库后，不错，目标达到了，系 统恢复甚至速度比以前还快了。 9 10 1.LoginGate主要负责在玩家登录时维护客户端与LoginServer之间的网络连接与通讯，对 LoginServer和客户端的通信数据进行加密、校验。 2.LoginServe

10、r主要功能验证玩家账号是否合法，并生成一个登录凭证SESSIONKEY。 3.GameGate主要负责客户端与GameServer之间网络连接和通讯，对客户端请求和发送数据做简单分析。 4.GameServer主要负责游戏逻辑处理，包括战斗系统、任务系统、角色系统、地图系统等。 5.DBServer主要负责游戏数据缓存，包括玩家游戏属性数据，降低数据库压力。 6.Mserver负责一组服务器中对多台GameServer之间数据转发和广播。 7.Mysql负责数据持久化存储。 11 注：目前也开始采用在一台超级实体服务器上装多个虚拟机，一个虚拟机搭建 一个游戏区。目的是可节约服务器机房托管成本、

11、运维开服时间成本。 一台24核CPU、40G内存的服务器上可以考虑装4个虚拟机，搭建4个游戏区。 12 用户通过浏览器访问服务器的时候，首先是访问WEB服务器，通过WEB服务器， 获取CACHE层数据，如需执行业务逻辑，再去访问游戏逻辑层，通知游戏逻辑层 执行玩家操作，并从游戏逻辑层里获得游戏数据。 网页服务器的特点是触发执行，及当有用户访问网页的时候，才会执行该网页 的程序代码。而我们常见的WebGame实际上是需要24小时不间断执行的，因此网 页服务器的执行方式并不完全适合做游戏。因此我们另外需要一个应用程序来 执行这些24小时不间断要做的事情。 这也就是我们需要增加游戏服务器设计思 路的

12、原因。 13 玩家浏览器发送HTTP请求到WEB服务器（控制层），通过DB层和CACHE层获取 玩家数据和游戏基础数据。 因游戏基础数据，是由策划配置不变的数据，例如游戏中的场景信息、NPC和怪 物数据、任务描述数据、装备道具信息等。 所以可以考虑多区公用，设置为公共数据库层，并生成缓存，便于管理和更新。 战斗逻辑运算服务器，可考虑采用运算服务器群，多区共用。 Client - Job - Worker Client：请求的发起者。 Job：请求的调度者，用来负责协调把 Client 发出的请求转发给合适的 Work。 Worker：请求的处理者，进行战斗运算，运算后返还战斗数据。 我们通过增

13、加更多的 Worker，可以很方便的实现应用程序的分布式负载均衡架 构。 方案一： 这里每个区的WEB服务器可以充当Client，通过向Job调度服务器发起战斗运算 请求并获取战斗结果数据，这里Job调度服务器需要备机，防止当机失去调度层。 Job层作为负载均衡调度最空闲的Worker服务器进行运算。 方案二: 这里每个区的WEB服务器既充当Client，又充当Job层，好处节约Job层服务器 开销。 14 转场 15 16 玩家从NPC那里购买一件装备，在玩家发出这个指令后，玩家的金钱减少，背 包中增加了所购买的装备，这一切都在玩家发出指令后瞬间完成。 17 例如RPG游戏里玩家鼠标点击地图

14、上某个怪物迚行攻击。这个攻击过程就是一个非瞬时过程，它有了一个战斗的过程，这个过程需要消耗一定的时间，在这个战斗过程结束后，才会对玩家数据迚行修改，也需要在该战斗结束后才能发起下场战斗请求。早期包括目前很多页游战斗还是采取战报方式，即当前端发起一个战斗请求，服务端会有运算迚程一次性运算完，推给前端，前端迚行播放战斗劢画。 18 还比如策略游戏中的军队战争，瞬时事件是当前村庄的士兵减少，非瞬时事件是减少的士兵移劢到需要攻击的村庄，结果是，两个村庄开打了。 19 前面说了瞬时事件和非瞬时事件的概念，当WebGame24小时运行的时候，系统就会产生大量的非瞬时事件，通常把这些非瞬时事件统一拿出来，按

15、事件的结束时间进行排序，并组成一个队列（事件队列）。再通过一个触发器，在事件设定的结束时间到达的那一刻执行对应的事件。 游戏中的事件队列会比较多，体现在数量和类型上。各种各样的事件队列。 SLG游戏中： 1.城池建造建筑。2.城池间战争。3.城池造兵。4.研究科技。 RPG游戏中： 1.战斗打怪或PK。2.连续打怪挂机。3.修炼挂机。4.技能修炼。 LINUX消息队列存储的优势在于降低了PHP进程对数据库查询压力，缺点是服务 器宕机，内存中存储的消息事件队列将会丢失，RPG打怪事件队列丢失影响不大， 只是当前打的这个怪物无效，但是其他类型的事件队列丢失话有可能影响巨大， 还有查询到期事件的效率

16、问题。数据库内存表存放，虽然重启服务器，内存表 中数据会被清空，但数据库二进制日志中可以找回。 20 运算结果详细战报保存到硬盘文本中，战报索引存入DB中并保存战斗奖励，并将战报索引借劣IM推送到客户端，客户端通过战报索引调取服务端静态战报数据迚行播放。（详细战报存文本便于发送战报外部链接） 避免玩家重复发起战斗事件，可以在服务端通过玩家ID验证是否有正在战斗的战斗队列，可将战斗结束时间保存在MEMCACHE中，再次发起的战斗时间需要大于MEMCACHE中上次战斗结束时间。 PHP处理战斗运算进程可以扩展出战斗运算分布式服务器。 21 SLG网页游戏中常见的建筑建造倒计时、策略战争队伍行军倒计时、资源储备按 秒产量时间递增。 RPG网页游戏中连续怪物攻击、强化、挂机、学习技能等功能。 倒计时表现在前端，服务端只用记录上次操作时间，当前端发起相关操作请求 后，即获取服务端时间进行更新客户端定时器。 客户端定时器长时间运行后和服务端时间会有时间差，因此为保证客户端CD定 时器的准确性，需要客户端定时1或2分钟定时发送一个请