【2017年整理】网页游戏架构与开发入门

《【2017年整理】网页游戏架构与开发入门》由会员分享，可在线阅读，更多相关《【2017年整理】网页游戏架构与开发入门（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.LoginSe

10、rver主要功能验证玩家账号是否合法，并生成一个登录凭证 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那里购买一件装备，在玩家发出这个指令后，玩家的金钱减少，背包中增加了所购买的装备，这一切都在玩家发出指令后瞬间完成。

14、17 例如 RPG游戏里玩家鼠标点击地图上某个怪物迚行攻击。这个攻击过程就是一个非瞬时过程，它有了一个战斗的过程，这个过程需要消耗一定的时间，在这个战斗过程结束后，才会对玩家数据迚行修改，也需要在该战斗结束后才能发起下场战斗请求。早期包括目前很多页游战斗还是采取战报方式，即当前端发起一个战斗请求，服务端会有运算迚程一次性运算完，推给前端，前端迚行播放战斗劢画。 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网页游戏中常见