陌陌6.6.1版本，向用户推送了“玩小游戏才是真事”的首屏小游戏入口，一时间全班同学跳上跳下。 相信很多游戏开发者都心痒痒想要一探究竟。 明天我和王哲将从技术角度科普一下陌陌游戏的开发知识。 本系列文章来自于我们CocosCreator引擎团队与Momo团队合作过程的总结。 目前CocosCreatorv1.8编辑器已发布，支持一次性发布Momo小游戏版本。
明天的文章是介绍Momo小游戏开发系列文章的第一篇。
1、小游戏的生态特征
目前，陌陌小游戏已发布17款首发游戏，其中包括六款棋牌游戏，以及开心消消乐、爱情通关、坦克大战、冬瓜防御等休闲游戏。
从入口来看，目前陌陌小游戏的主要入口如下：
从技术角度来看，陌陌小游戏是在陌陌小程序的基础上增加了游戏库API。 小游戏只能在小程序环境中运行，因此小游戏既不是原生游戏，也不是完全等同于 HTML5 游戏。 但事实上，小游戏是针对HTML5游戏开发者的。 为了让HTML5游戏能够尽可能便宜地移植，小游戏尽可能地复用来自浏览器的WebGL、JavaScript和其他HTML5技术。 可以说，小游戏是一款采用HTML5技术打造的、具有原生体验的陌陌游戏产品。
小游戏采用这种模式的好处有很多，其中最大的好处就是稳定性和可控性。 与原版相比，Momo可以关闭Momo内部的游戏； 与纯HTML5相比，你不用害怕被游戏砍价、被广告付费。
与已经出现的其他运行形式相比，陌陌小游戏的运行环境有一个很大的优势，那就是“兼容HTML5生态”。 也就是说，无论你使用哪种游戏引擎来开发HTML5游戏，都可以轻松移植到小游戏中。 这使得陌陌小游戏能够直接受益于庞大的HTML5生态系统。
除了技术之外，陌陌对小游戏最有力的支撑就是社交。 借助好陌陌的社交生态获取新用户将在小游戏的设计中占据非常重要的地位。 我们可以看到，第一批16款游戏中，不仅是跳帧、掉帧的入口，其他小游戏的入口也隐藏得比较深，所以流量的来源并不是主要来自推荐榜，而是通过来自社会交往。 这与市面上大多数引导用户、清洗用户、滚动合并服务器的游戏设计思路不同。
陌陌开放的优质入口、庞大的用户基础、点击即玩和分享的特性将赋予小游戏巨大的潜力。 一切就看你们开发者如何抓住机遇，找到适合陌陌用户的游戏品类和形式。
2.以上API：打开好友游戏必备知识点
前面提到，小游戏的开发主要复用了HTML5技术栈，因此开发过HTML5游戏的开发者上手速度会快很多，甚至很多HTML5游戏都可以快速移植到小游戏平台上。 具体来说，陌陌小游戏的开发技术分为三个部分。
1. 底层技术
首先是开发语言。 陌陌小游戏仅支持JavaScript。 其实TypeScript和CoffeeScript都可以编译成JS，都可以作为开发语言。
其次是小游戏支持的游戏库API，主要包括HTML5 Canvas2D API和WebGL1.0 API。 游戏最重要的渲染功能可以使用任何API来完成，但不能混用。 另外，只有WebGL渲染模式可以支持3D渲染。
2.中间件：游戏引擎
事实上，直接使用Canvas2D或者WebGL来制作游戏是一个非常高的门槛，而且也非常耗时耗力。 你肯定不希望一个小游戏项目被推迟一年半吧？ 因此，虽然使用HTML5游戏引擎是一个非常明智的选择，但引擎封装的高层socket可以大大降低开发者的开发门槛，缩短项目周期。 目前国外三大主流引擎CocosCreator、Egret、Laya都支持小游戏的发布。 国内的HTML5引擎如Phaser.js、Three.js实际上并不支持直接发布。 经过一些定制，它们也可以在小游戏环境中成功运行。
3.陌陌SDK
此外，陌陌小游戏还提供了丰富的内部陌陌SDK供开发者调用。 利用该接口可以完成用户登录、转发、排名等常规社交功能。
但不仅仅是这种常规玩法，最让人欣慰的是玩家可以通过转动好友游戏来完成游戏中的组队或者战斗，再加上小游戏的即点即玩功能，游戏体验这些请战可以说是天衣无缝。
邀请好友组队，进行欢乐的坦克大战
好友可以点击转发链接直接进入游戏，完成组队
这些群组转发+点击播放的机制可能会带来非常有趣的社交玩法。
3、API下：了解小游戏底层技术框架
正如一开始提到的，小游戏既不是原生游戏，也不是HTML5游戏，它的开发环境实际上与两者密切相关。 和HTML5的关系是复用了HTML5的渲染socket，但是和原生游戏有什么关系呢？ 我们用一张图来解释一下：
小游戏的运行环境好像是Momo的原生环境。 游戏的JavaScript代码不是通过浏览器执行的，而是通过图中JSVM层的独立JavaScript引擎执行的。 Android平台使用谷歌的v8引擎，iOS平台使用苹果的JavaScriptCore引擎。
事实上，JS引擎只负责解释执行JS逻辑，并不支持渲染socket。 渲染套接字和众多Momo功能套接字是如何实现的？ 这就不得不提到脚本绑定技术，它可以将某种本机语言套接字桥接到脚本套接字上。 当脚本层调用socket时，会手动转发到native层调用native socket。 Momo小游戏环境就采用了这样的技术，将iOS/Android原生平台实现的渲染、用户、网络、音视频socket绑定到JavaScript socket中。 这就是图中Momo初级层模块到小游戏层模块的原理。 脚本绑定技术本文不再详细阐述。 如果有兴趣，可以了解一下CocosCreator的JSB绑定实现，这也是游戏引擎中唯一完全开源的绑定技术实现。
小游戏有了这样一套框架后，HTML5游戏在移植过程中会遇到无数的API兼容性问题。 最简单的就是document对象不存在，Image对象不存在。 为了增加移植成本，Momo团队提供了Adapter脚本来适配部分浏览器socket。
如上图所示，Adapter部分提供了大多数HTML5游戏所依赖的浏览器套接字。 该图也比较完整地描述了开发者在陌陌小游戏中可以使用的socket模块：
值得一提的是，Adapter脚本不再维护，因此额外的socket适配需要开发者自己完成，而大多数依赖DOM套接字的功能很难适应小游戏环境。
刚才我也提到，我推荐大家使用游戏引擎来打开好友游戏。 在小游戏环境的基础上，游戏引擎不仅封装了高层套接字，还尽量平滑浏览器和小游戏环境之间的差异。
从图中可以看出，如果不使用游戏引擎，开发者面对的是小游戏的底层API，而使用游戏引擎后，开发者面对的是引擎的API。
总结一下游戏引擎为开发者所做的工作，包括以下几个方面：
高层API封装，更方便游戏开发；
资源加载适配；
风暴处理适应；
音频播放适配；
窗口适应；
输入框适配；
添加了其他缺失的套接字，例如降低用于解析 TileMap 的 DOMParser。
优化节目美术策划协同效率；
一个好的游戏编辑器可以大大缩短开发周期。
优秀的游戏引擎提供较高的设备兼容性和稳定的运行性能；
跨平台游戏引擎提供了无缝发布HTML5、小游戏、原生平台的强大能力。
高效率的编辑器增加了开发成本； 低准入门槛降低劳动力成本； 兼容性高，性能稳定，降低维护成本； 跨平台/渠道带来强大的流量获取能力。 对于开发商来说，这是生存和盈利的保证！
4.开始调试小游戏
需要说明的是，截至本文撰写，陌陌公众平台尚未开放开发者申请游戏品类的权限egret游戏源码，因此只能通过小游戏的“体验小游戏”功能进行技术尝试。 - 游戏开发工具。 不过不用担心，陌陌团队应该很快就会开放游戏类别的申请。
1.陌陌开发者工具介绍
下图是陌陌开发者工具开发小游戏时的基本布局：
Momo开发者工具基本布局
上部是工具栏，包含最重要的编译、预览和配置细节； 右侧是模拟器窗口，显示游戏运行的效果； 右上部分是代码编辑器，可以查看项目中的文件列表以及编辑文本文件； 右侧下方是调试器窗口，其使用方式与ChromeDevtools完全相同。
2、Momo小游戏配置及入口文件
在陌陌小游戏项目中，首先需要添加project.config.json和game.json配置文件。 其中project.config.json可以定义你的小游戏appid、游戏名称、配置等。而game.json主要用于指定游戏方向和网络超时。
另外，小游戏不支持任何html文件。 入口文件是game.js。 您需要启动的引擎和游戏脚本应使用 require 函数导入到 game.js 中。 require函数的使用遵循node.js的require规范。
3. 编译和预览
Momo开发者工具将手动监听脚本和配置更改，并在发生更改时手动更新。 您还可以通过底部的编译按钮触发重新编译。 当您需要在手机上预览小游戏效果时，需要点击预览按钮生成二维码，扫码进入小游戏。 生成二维码的过程实际上就是将小游戏包压缩并上传到陌陌CDN，所以需要一些时间。
4. 详细配置
详细配置包含一些重要的配置选项，包括：
5、市场展望
最后，从市场角度来看，虽然小游戏青睐的HTML5技术栈蕴藏着巨大的机会，但已经有很多游戏引擎使用JavaScript来支持跨平台。 以CocosCreator为例，编写一套游戏代码就可以在编辑器中无缝发布HTML5手机页游、PC页游、手机原生游戏、小游戏。 我们可以做一个简单的估算。 据伽玛数据12月初的行业报告显示，2017年国外，原生手游1162亿款，PC端游648亿款，PC页游156亿款。 空间=1162÷648x156=每年280亿元。
如果进一步考虑到Flash宣布2020年停止更新，市场上大量的PC网页游戏已经开始采用HTML5技术来制作egret游戏源码，手机上也出现了大量的微端产品。 能够支撑的游戏市场规模应该是=280亿款手机页游+156亿款PC页游+部分原生手游≈每年500亿元。
500亿元只是国外的一个估计规模。 根据年中美国Newzoo的数据，中国游戏产业规模占全球的25%，因此HTML5技术理论上可以支撑全球的移动页游、手机原生、PC每年上限2000亿元的页游市场。
因此，掌握HTML5技术栈，掌握陌陌小游戏、QQ分米秀、FacebookInstantGames等新型“手机页游”平台上的社交游戏开发技术，洞察此类社交平台的用户特征，提出针对性的建议。游戏设计，对于想要进入这个领域的游戏开发者来说，是一个迫在眉睫的任务。
但目前普遍的看法是，随着资本的推进，手机页游的时间窗口应该只有1到1.5年。 将会有已经成功布局的主要原生游戏厂商，也会有新的开发商和发行商。 在游戏行业，这样的空缺平均五年才会发生一次。
关于作者：
凌华斌，CocosCreator主程序，GameJamer，玩家，曾负责Cocos2d-JS、热更新框架、JSB框架，现在主要负责小游戏的发布流程以及CocosCreator引擎的新渲染器架构。
王喆，Cocos Engine创始人兼首席客服。
网址：#rd
类型一：卡牌跑酷等弱交互服务器端卡牌跑酷
由于互动较弱，玩家之间无需进行实时面对面PK。 您可以查看彼此的离线数据、估算排名、买卖物品。 因此，常常使用一个简单的HTTP服务器来实现：
登录时可以使用非对称加密（RSA、DH），服务器根据客户端uid、当前时间戳和服务器公钥计算哈希得到的加密密钥奉献给客户端。 未来双方将使用HTTP进行通信，并使用该密钥进行RC4加密。 客户端收到密钥和时间戳后，将其保存在显存中以供将来通信。 服务器不需要保存密钥，因为可以根据客户端每次上传的uid和时间戳以及服务器自己的公钥来估计。 使用模仿TLS的行为来确保多个HTTP请求之间客户端的身份，并使用时间戳来确保同一个人两次拥有不同的登录密钥。
每场游戏开始时，访问并索取关卡数据，玩完后提交，检查是否合法以及可以获得什么奖励。 数据库可以是单个MySQL或MongoDB，前端Redis可以作为缓存（可选）。 如果要实现通知，让客户端调度一个 15 秒的协程到服务器。 如果有消息，它将被提取。 如果没有消息，可以逐渐增加寻址时间，例如30秒； 如果有消息，则缩短协程时间。 10秒、5秒，即使两个人聊天，延时也能自适应。
这样的服务器，实现一个三国策略或者卡牌、酷跑游戏是绰绰有余的。 由于此类游戏逻辑简单，玩家之间的互动性不强。 如果使用HTTP来开发，开发速度快，调试只需要一个浏览器就可以调试清楚逻辑。
类型2：第一代游戏服务器1978年
1978年，西班牙著名金融中学埃塞克斯大学的中学生Roy Trubshaw编写了世界上第一个MUD程序“MUD1”。 1980年埃塞克斯大学接入阿帕网后，加入了许多外部玩家，甚至包括美国玩家。 “MUD1”程序的源代码在阿帕网共享后，出现了许多改编版本，MUD才在全世界广泛流行。 基于不断建立的MUD1，开源的MudOS（1991）成为众多网络游戏的鼻祖：
MUDOS是用C语言开发的。 由于玩家之间的交互性比较强（聊天、交易、PK），MUDOS使用单线程非阻塞套接字为所有玩家服务，所有玩家请求都发送到同一个线程。 处理，主线程每秒更新所有对象（网络发送和接收、更新对象状态机、处理超时、刷新地图、刷新NPC）。
游戏世界以卧室的形式组织。 每个卧室都可以从西北到东南四个方向与隔壁房间相连。 因为欧美最早的网络游戏是地下城迷宫，所以场景的基本单位被称为“房间”。 MUDOS使用一种称为LPC的脚本语言来描述整个世界（包括卧室拓扑、配置、NPC和各种情节）。 游戏中的中级玩家（巫师）可以不断更改脚本以添加卧室并减少游戏情节。 早年MUD1推出时，只有17间卧室。 罗伊·特鲁布肖毕业后，将其交给了他的师兄理查德·巴特尔。 在理查德·巴特尔的手中，他不断为一百多个卧室添加各种玩法，最终让MUD推广中信。
用户使用Telnet等客户端通过Tcp合约连接MUDOS，使用纯文本进行游戏，每条命令均以回车符分隔。 比如1995年国外第一款MUD游戏《侠客行》中，你输入：“goeast”，游戏也会提示你：“侯家园——这是归云庄的侯家园，种满了花花草草，有几栋别墅丁在浇水，这里是猪笼草生长的地方，这里唯一的出口是北边，这里有：花岱阿木（Amu），还有两个庄丁（náo Ding）”，之后你继续用文字操作，查看阿木的信息：“lookamu”，系统提示：“花儿等待阿木（阿木）。他是陆乘风的弟子，受命照顾这里的猪笼草。他看上去三十多岁，相貌英俊，相貌堂堂。” 。大方，才华横溢。他的武功看起来[不是很高]，虽然他的出手[极轻]”。 之后你可以选择打败他来获得猪笼草，食用猪笼草后你可能会中毒而死。 在网络资源匮乏的早期，此类游戏具有很强的代入感。
用户数据保存在文件中。 每个用户登录时，所有用户数据都是从文本文件中加载，所有操作都在显存上进行，所以不需要立即闪回c盘。 如果用户注销，或者每5分钟检测到数据变化，就会将其保存到C盘。 这样的系统在当时每台服务器可以容纳4000名玩家同时玩游戏的情况下并不是什么大问题。 自1991年MUDOS发布以来，世界各地都为他改进、扩展、退出了新版本，同时也伴随着Windows图形性能的提高。 1997年的游戏《UO》在MUDOS的基础上增加了角色的x、y坐标，为每个卧室添加了地图，但为每个角色添加了动画，从而产生了第一代图形网络游戏。
由于游戏内容基本可以通过LPC脚本进行定制，MUDOS也成为了第一个名副其实的服务器端引擎。 《万王之王》等后续国外游戏很多都和《UO》一样，直接在MUDOS上进行二次开发，添加了卧室地图、人物坐标等元素。 第一代MMORPG提供了坚实的支持，直到2003年，游戏都是基于MUDOS开发的。 其实之前的图形已经减少了很多东西，这个MMORPG前端的本质还是MUDOS。 随着游戏内容越来越复杂，结构越来越难以承受，各种负载问题逐渐浮现出来，于是就有了我们的第二代游戏服务器。
类型3：第二代游戏服务器2003
2000年以后，网络游戏已经离开了原始的文字MUD，进入了综合图形时代。 虽然首先难以忍受的是大量的小文件，但用户上线下线，频繁读写用户数据，导致负载不断增大。 随着在线人数的减少和游戏数据的减少，服务器出现了不堪重负的情况。 同时EXTc盘前期的分区比较脆弱，如果断水一段时间，很容易丢失大面积的数据。 所以第一步就是分割文件并将其存储到数据库中。
此时的游戏服务器早已脱离了旧的MUDOS系统，各个公司开始参考MUDOS结构用C语言重新开发自己的游戏服务器。 而且，该脚本还放弃了LPC，代之以Python或Lua，扩展性更强。 由于主要逻辑采用单线程模型，随着游戏内容的减少，传统的单服务器结构进一步陷入困境。 于是有人开始将游戏世界分割成如下模型：
拆分后游戏服务器压力得到缓解，两台游戏服务器同时访问数据库，大量重复访问，大量数据交换，这让数据库陷入了下一个困境。 这样就创建了数据库后端代理（DBProxy）。 游戏服务器不直接访问数据库而是访问代理，然后代理访问数据库c 游戏服务端源码，同时提供内存级缓存。 早年，MySQL4之前并没有提供存储过程。 该后端代理通常与 MySQL 运行在同一平台上。 它将游戏服务器发送过来的中间数据操作指令进行转换，拆分为具体的数据库操作，一定程度上替代了存储过程：
然而，这样的结构并没有持续太久。 由于玩家在切换场景时经常会切换连接，因此中间的状态很容易出现混乱。 而且游戏服务器多了之后，彼此之间的数据交互会比较麻烦，所以人们将网络功能进行拆分，独立创建一个网段服务Gate（有的地方叫Session，有的地方叫LinkSvr等，名称不同） ）：
单独提取网络功能，让用户统一连接到一个网段服务器，然后网段服务器将数据转发到前端游戏服务器。 游戏服务器之间的数据交换也连接到网管系统进行交换。 这类服务器基本上可以稳定地为玩家提供游戏服务。 一个网段服务1-2千人，前面每台游戏服务器服务5k-1w。 这取决于游戏的类型和复杂性。 图中隐藏了很多。 不重要的服务器，例如登录和管理。 这是目前应用最广泛的模型，直到今天许多新项目都会采用这种结构建造。
人都是有惰性的，根据以往的经验，虽然MUDOS的分片越多，性能就会越好。 那么你继续认为网段是可以拆分的，聊天交易等基础服务是可以拆分的，也可以提供web socket，数据库也可以拆分，所以我们有下面的模型：
这样的模型有用吗？ 确实有成功的游戏使用了这样的框架，但是利用了它的性能，比如一些小型的MMORPG。 并且存在两个挑战：每减少一台服务器，状态机的复杂性可能会增加一倍，导致开发和查找 bug 的成本增加； 对于开发团队来说是一个比较大的挑战。 一旦项目时间紧张，开发人员经验不足，很容易出现困惑hang。
比如我看到北京某一线游戏公司的一款RPG就要采用这样的框架。 我查看了他们团队成员的经验，询问了他们的发布日期，并建议他们使用上面的更简单的模型。 他们非常有信心，觉得如果有成功的项目做到了这一点，他们也应该这样做，而且他们真的很想实现一套。 于是他们毫不犹豫地开始编码。 这个项目已经做了一年多了，之后就没有未来了。
现在游戏的成功率不高，一开始就需要考虑更复杂的框架的投资回报。 例如，你的游戏上线后六个月内，PCU 会达到多少？ 如果一款APRG游戏每组服务器无法达到5万人，那么选择更接近实际情况的结构更为经济。 虽然如果你的项目有5万人以上，正在朝着1000人的目标跑，我相信那个时候你的项目已经赚了很多钱了。 你数着钱，加班加点地逐步迭代，一次又一次的拆分。 我相信我的心也是快乐的。
里面的类型基本都是从MUDOS的拆分开始，将MUDOS中的各个组件从单机逐步拆解到分布式。 事实上，昨晚很多新项目仍然采用了与前一个类似的结构，或者做了其他热门模块的衍生。 由于它们本质上是MUDOS的分解，因此被归类为第二代游戏服务器。
类型4：第三代游戏服务器
自2007年《魔兽世界》问世以来，无缝世界地图就已经深入人心。 与往年相比，游戏玩家走几步就需要切换场景。 每次切换都要等待数十秒的LOADING，非常损害游戏体验。 所以对于2005年以后的小型MMORPG来说，无缝地图已经成为标准配置。 与往年游戏根据地图进行剪切相比，不存在地图中的人仅由一台服务器处理的无缝世界：
每个Node服务器用于管理一个地图区域，NodeMaster（NM）对其进行总体管理。 上级World提供台湾级别的管理服务。 这里省略了一些详细的服务器，比如传统的数据库后端、登录服务器、日志和监控等，都在ADMIN中进行了总结。 在这样的结构下，玩家只需处理从一个区域移动到另一个区域的问题：
玩家1完全由节点A控制，玩家3完全由节点B控制。位于两个节点边缘的玩家2号同时由A和B服务。 在从A连接到B的过程中，玩家2会同时向A请求右侧的情况，并向B请求右侧的情况。 而此时玩家2仍然属于A管理层。 直到玩家2完全远离AB的边界后，才完全交给B管理。 根据这个逻辑，世界地图被划分为多个区域，由不同的节点管理。
对于一个Node所负责的区域来说，在地理上没有必要连接在一起。 比如台湾的外围和山区人比较少，可以用一个Node来管理。 无需将它们链接在一起。 Node管理的区块是什么，您可以在定期维护时根据游戏的实时负载情况修改NodeMaster中的配置。 所以我看到的第一个问题是很多Node服务器需要与玩家进行通信。 您需要询问管理服务器特定UID的玩家在哪个Gate。 按照场景砍掉的服务器问题不大。 问过一次就解决了。 可以缓存，现在服务器种类减少很多，玩家又会飘来飘去。 通过UID查找玩家比较麻烦； 另一方面，GATE需要根据坐标动态估计与哪个Node通信，导致逻辑越来越厚。 所以当务之急是从负责连接管理的GATE中砍掉“用户对象”c 游戏服务端源码，所以我们有以下模型：
网段服务器再次回归精简的网络转发功能，用户逻辑由根据UID定义的OBJ服务器承担。 GATE是根据网络访问的负载来分配的，OBJ是根据网络访问的负载来分配的，这样与用户通信时可以直接根据UID估计OBJ服务器编号并发送数据。 新独立的OBJ提供更多高水平的服务：
GATE专注于互联网。 此类模型广泛应用于无缝场景服务器中。 而且随着时间的推移，负载问题也越来越明显。 当进行活动时，非活动区域非常活跃。 通过每周维护来调整比较麻烦，所以就有了动态负载均衡。 动态负载平衡有两种方式。 第一种是NodeMaster根据负载情况定期动态改变各个Node的边界，按照前面的方法将不同的玩家对象从一个Node迁移到另一个Node：
图11 动态负载均衡
NodeMaster定期搜索地图上的热点区域，预估新的场景切割方式，然后通知其他服务器开始调整。 具体处理方法与前面跨边界连接对象的方法相同。 而这些方法的实现都比较复杂，所以人们设计了一种更简单直接的新方法：
图12 基于网格的动态负载均衡
对于网格动态负载平衡，根据标准规范将地图均匀划分为静态网格。 每个条带负责一个特定的Node，并且可以根据负载情况实时迁移到其他Node。 迁移分为三个阶段：计划、切换和完成。 这三种状态由NodeMaster维护。 在规划阶段，新Node开始同步旧Node中网格的数据，完成后通知NM； NM确认OK后，通知新旧Node完成切换。 切换完成后，如果Obj服务器仍在与旧Node通信，则旧Node将对其进行纠正，纠正后的OBJ将纠正其状态并与新Node通信。
很多无缝动态负载均衡服务器声称支持无限数量的玩家，但这并不意味着MMORPG游戏的上限真的可以无限扩展，因为这样的系统会受到网络带宽和客户端性能的限制。 带宽决定了同一区域内的最大广播限制，客户端性能决定了同一屏幕上可以绘制多少个字符。
自从无缝地图引入分布式对象模型后，它就完全从MUDOS系统中分离出来，成为一种新的服务器模型。 而由于动态负载均衡的引入，无缝服务器如虎添翼，容纳了上一代游戏服务器数倍的上限，提供了更好的游戏体验，我们称之为第三代游戏服务器架构。 网络游戏以小型多人角色扮演起家，RPG网络游戏曾长期占据总量的90%以上，导致基于MMORPG的服务器架构蓬勃发展。 然而，随着玩家对RPG的厌倦，各种非MMORPG游戏就像雪后的生菜一样出现在人们面前，并受到市场的欢迎。
类型5：战网游戏服务器
经典战网服务器和RPG游戏有两个区别：RPG分为不同的服务器，上海地区的用户与上海地区的用户不互通。 至于战网，虽然每场游戏通常限制8名玩家，但全省只有一套服务器，所有玩家都可以一起玩，玩家与玩家以P2P的形式连接在一起，形成一个游戏：
玩家通过匹配服务器创建、加入、自动匹配、邀请等方式组成游戏。 服务器会选择一个人作为主机，其他人通过P2P方式连接到主机玩家。 STUN是帮助玩家搭建P2P的牵引服务器，而由于P2P电信情况只有75%左右，所以确实无法连接的玩家会通过Forward进行转发。
大量的联合作战和体育比赛都采用类似的结构。 P2P有网状模型（所有玩家都相互连接）和星型模型（所有玩家都连接到主玩家）。 复杂的游戏状态在网状模型下无法保持一致，因此明星P2P模型经受住了历史的考验。 除了游戏数据外，支持语音的战网系统还会将每个人的语音数据发送到负责的玩家机器上，通过混音、去重、重新编码的方式返回给所有用户。
战网游戏主要是竞技、体育、动作等类型的游戏。 节奏较慢的RPG（包括ARPG）则有着本质的不同，激烈的游戏过程必然会带来比RPG更复杂的同步策略。 ，这样的同步机制往往会带来很多游戏结果都是由客户端直接估算的，那么在裂痕遍地的世界里如何保证游戏结果的公平性呢？
主要方式是投票方式，所有客户端独立估算，然后传递给服务器。 如果结果相同，则更新记录。 如果结果不一致，将以类似于投票的形式确定最终结果。 同时，记录本次游戏的所有输入，如果可能的话，再找一个闲置的游戏客户端检查整个游戏是否是结果。 而且，经常涉嫌作弊的用户，在运营商封号时都会被记录下来，以供参考。
类型七：休闲游戏服务器
休闲游戏和战网服务器类似，都是全区结构，不同的是有卧室服务器和特定的游戏服务器，游戏的主体不再是与玩家的P2P，而是连接到一个专用的服务器上。游戏服务器进行处理：
和战网一样的全区结构，用户数据不能像分区RPG一样一次性加载到显存，然后直接在显存上更改。 在全域框架下，为了应对一个用户同时玩多个游戏，用户数据需要区分基础数据和不同的游戏数据，游戏数据需要区分点数据和文档数据。 胜、平、负等积分可以直接提交进行增量更改，而更一般的文档数据则需要提供读写令牌。 只有一个写令牌和许多读令牌。 当同一帐户和同一游戏同时在两台笔记本电脑上玩时，先启动的游戏将获得写入令牌，该令牌可以操纵任何用户数据。 此后开始的游戏不仅可以提交胜、平、负分的增量变化，而且对用户数据采用只读形式，保证游戏能够继续运行，并会提示用户游戏已开始数据被锁定。
类型八：现代动作网游
从早期的日本动作游戏开始，传统的战网动作游戏和RPG游戏开始尝试融合。 简单的动作游戏玩家容易产生疲劳，留存度没有RPG高； 而纯粹的RPG战斗则节奏缓慢、平庸，无法满足很多玩家对激烈对抗的期待，于是两者开始融合成新一代：动作+城镇模式。 玩家聚集在城镇中，然后几人以地下城的形式出去，以动作游戏的方式完成各种RPG任务。 本质是一套RPG服务器+副本服务器。 由于每个副本中的角色可以控制在8人以内，因此可以获得更加实时的游戏体验，让玩家玩起来更加爽快。
说了这么多类型的游戏服务器，虽然都差不多，但是剩下的你堆起来的类型也就这样了。
【今日Momo账号推荐】
