网络游戏英文为Online Game，简称网游。又称“在线游戏”。必须依托于互联网进行、可以多人同时参与的游戏，通过人与人之间的互动达到交流、娱乐和休闲的目的。单从中文字面上理解，任何有联网功能的游戏，似乎都称得上是网络游戏，而实际上网游的概念相对要狭窄一些，换句话说更贴近Online Game的本意，只有完全依靠在线形式、不具备单机游戏功能的游戏才算是真正的网游。2016年12月5日晚，文化部发布《关于规范网络游戏运营加强事中事后监管工作的通知》，首次明确规定网络游戏虚拟货币、虚拟道具不能兑换法定货币。

网络游戏(Online Game)，又称“在线游戏”，简称“网络游戏”，它是指以网络为传输媒介、以游戏运营商服务器和用户计算机为处理终端、以游戏客户端软件为信息交互窗口的旨在实现娱乐、休闲、交流和取得虚拟成就的具有相当可持续性的个体性多人在线游戏。

网络游戏英文为Online Game，简称网游。又称 “在线游戏”。必须依托于互联网进行、可以多人同时参与的游戏，通过人与人之间的互动达到交流、娱乐和休闲的目的。

按游戏产品的不同，网络游戏可分为大型角色扮演类网络游戏、休闲游戏、网页游戏以及手机游戏。

据《中国网络游戏行业商业模式创新与投资预测分析报告前瞻》统计数据显示，截止2011年12月份，全国上网用户5.13亿，占人口比例38.3%;网络游戏用户3.24亿，占网民比例63.2%。

在网络游戏用户中，互联网游戏用户2011年的总数突破1.6亿人，同比增长33%;其中，网页游戏用户持续增长，规模为1.45亿人，增长率达24%。移动网下载单机游戏用户超过5100万人，增长率达46%;移动网在线游戏用户数量达1130万人，增长率达352%。相对于互联网游戏用户数量增长速度的放缓，移动网游戏用户数量出现了高速的增长，这表明移动互联网正逐渐成为网络游戏市场迅速增长的力量。

网游从早先的一种免费PC游戏形式，经过若干年的发展，时至今日已成长为一个相当成熟而庞大的游戏产业。

单从中文字面上理解，任何有联网功能的游戏，似乎都称得上是网络游戏，而实际上网游的概念相对要狭窄一些，换句话说更贴近Online Game的本意，只有完全依靠在线形式、不具备单机游戏功能的游戏才算是真正的网游。

一、第一代网络游戏：1969年至1977年

网络游戏发展史图册

背景：由于当时的计算机硬件和软件尚无统一的技术标准，因此第一代网络游戏的平台、操作系统和语言各不相同。它们大多为试验品，运行在高等院校的大型主机上，如美国的麻省理工学院、弗吉尼亚大学，以及英国的埃塞克斯大学。

游戏特征：1、非持续性，机器重启后游戏的相关信息即会丢失，因此无法模拟一个持续发展的世界；2、游戏只能在同一服务器/终端机系统内部执行，无法跨系统运行。

商业模式：免费。

第一款真正意义上的网络游戏可追溯到1969年，当时瑞克·布罗米为PLATO（Programmed Logic for Automatic Teaching Operations）系统编写了一款名为《太空大战》（SpaceWar）的游戏，游戏以八年前诞生于麻省理工学院的第一款电脑游戏《太空大战》为蓝本，不同之处在于，它可支持两人远程连线。

PLATO是历史上最为悠久也是最著名的一套远程教学系统，由美国伊利诺斯州厄本姆的伊利诺斯大学开发于上世纪60年代末，其主要功用是为不同教育程度的学生提供高质量的远程教育，它具有庞大的课程程序库，可同时开设数百门课，可以记录下每一位学生的学习进度。PLATO还是第一套分时共享系统，它运行于一台大型主机而非微型计算机上，因此具有更强的处理能力和存储能力，这使得它所能支持的同时在线人数大大增加。1972年，PLATO的同时在线人数已达到1000多名。

那些年里，PLATO平台上出现了各种不同类型的游戏，其中一小部分是供学生自娱自乐的单机游戏，而最为流行的则是可在多台远程终端机之间进行的联机游戏，这些联机游戏即是网络游戏的雏形。尽管游戏只是PLATO的附属功能，但共享内存区、标准化终端、高端图像处理能力和中央处理能力、迅速的反应能力等特点令PLATO能够出色地支持网络游戏的运行，因此在随后的几年内，PLATO成了早期网络游戏的温床。

PLATO系统上最流行的游戏是《圣者》（Avatar）和《帝国》（Empire），前者是一款“龙与地下城”设定的网络游戏，后者是一款以“星际迷航”为背景的网络游戏。这些游戏绝大多数是程序员利用业余时间编写并免费发布的，他们只是希望自己的游戏能获得大家的认可。当然，也有一些开发者通过自己的游戏获得了收入，但通常每小时只有几美分，并且还得在若干作者之间进行分配。

PLATO在游戏圈内并未获得其应有的荣誉和地位，但这并不能抹杀它对网络游戏以及整个游戏产业所做出的贡献。PLATO上的不少游戏日后都被改编为了游戏机游戏和PC游戏，例如《空中缠斗》（Airfight）的作者在原游戏的基础上开发了《飞行模拟》（Flight Simulator），80年代初，这款游戏被微软收购并改名为《微软飞行模拟》，成为飞行模拟类游戏中最畅销的一个系列。1974年推出的《帝国》是第一款允许32人同时在线的游戏，这一联机游戏模式成为现代即时策略游戏的标准模式。1975年发布的《奥布里特》（oubliette）是一款地牢类游戏，大名鼎鼎的角色扮演游戏《巫术》（Wizardry）系列即源于此。

有趣的是，1969年也正是ARPAnet（Advance Research Projects Agency Network）诞生的年份。大家知道，ARPAnet是美国国防部高级研究计划署研制的世界上首个包交换网络，它的成功直接促成了互联网以及传输控制协议（即TCP/IP）的诞生。

二、第二代网络游戏：1978年至1995年

背景：一些专业的游戏开发商和发行商开始涉足网络游戏，如Activision、Interplay、Sierra Online、Stormfront Studios、Virgin Interactive、SSI和TSR等，都曾在这一阶段试探性地进入过这一新兴产业，它们与GEnie、Prodigy、AOL和CompuServe等运营商合作，推出了第一批具有普及意义的网络游戏。

游戏特征：1、网络游戏出现了“可持续性”的概念，玩家所扮演的角色可以成年累月地在同一世界内不断发展，而不像PLATO上的游戏那样，只能在其中扮演一个匆匆过客。2、游戏可以跨系统运行，只要玩家拥有电脑和调制解调器，且硬件兼容，就能连入当时的任何一款网络游戏。

商业模式：网络游戏市场的迅速膨胀刺激了网络服务业的发展，网络游戏开始进入收费时代，许多消费者都愿意支付高昂的费用来玩网络游戏。从《凯斯迈之岛》的每小时12美元到GEnie的每小时6美元，第二代网络游戏的主流计费方式是按小时计费，尽管也有过包月计费的特例，但未能形成气候。

1978年在英国的埃塞克斯大学，罗伊·特鲁布肖用DEC-10编写了世界上第一款MUD游戏——“MUD1”，这是一个纯文字的多人世界，拥有20个相互连接的房间和10条指令，用户登录后可以通过数据库进行人机交互，或通过聊天系统与其他玩家交流。

特鲁布肖离开埃塞克斯大学后，把维护MUD1的工作转交给了理查德·巴特尔，巴特尔利用特鲁布肖开发的MUD专用语言——“MUDDL”继续改进游戏，他把房间的数量增加到400个，进一步完善了数据库和聊天系统，增加了更多的任务，并为每一位玩家制作了计分程序。

1980年埃塞克斯大学与ARPAnet相连后，来自国外的玩家大幅增加，吞噬了大量系统资源，致使校方不得不限制用户的登录时间，以减少DEC-10的负荷。80年代初，巴特尔出于共享和交流的目的，把MUD1的源代码和盘托出供同事及其它大学的研究人员参考，于是这套源代码就被流传了出去。到1983年末，ARPAnet上已经出现了数百份非法拷贝，MUD1在全球各地迅速流传开来，并出现了许多新的版本。如今，这套最古老的MUD系统已被授权给美国最大的在线信息服务机构之一——CompuServe公司，易名为“不列颠传奇”，至今仍在运行之中，成为运作时间最长的MUD系统。

MUD1是第一款真正意义上的实时多人交互网络游戏，它可以保证整个虚拟世界的持续发展。尽管这套系统每天都会重启若干次，但重启后游戏中的场景、怪物和谜题仍保持不变，这使得玩家所扮演的角色可以获得持续的发展。MUD1的另一重要特征是，它可以在全世界任何一台PDP-10计算机上运行，而不局限于埃塞克斯大学的内部系统。

1982年，约翰·泰勒和凯尔顿·弗林组建Kesmai公司，这家公司在网络游戏的发展史上留下了不少具有纪念意义的作品。Kesmai公司的第一份合约是与CompuServe签订的，当时约翰·泰勒看见了CompuServe打出的一则名为“太空战士”（MegaWars）的广告——“如果你能编写一款这样的游戏，你就能获得每月3万美元的版税金”，他便把同凯尔顿·弗林一起开发的《凯斯迈之岛》（The Island of Kesmai）的使用手册寄了一份给当时在CompuServe负责游戏业务的比尔·洛登，洛登对此很感兴趣。《凯斯迈之岛》的运行平台为UNIX系统，而CompuServe使用的是DEC-20计算机，于是Kesmai公司重新为CompuServe开发了一个DEC-20的版本。这款游戏运营了大约13年，1984年开始正式收费，收费标准为每小时12美元。同年，MUD1也在英国的Compunet上推出了第一个商业版本。

1984年，马克·雅克布Mythic娱乐公司的前身），并推出游戏《阿拉达特》（Aradath）。雅克布斯在自己家里搭建了一个服务器平台，安装了8条电话线以运行这款文字角色扮演游戏，游戏的收费标准为每月40美元，这是网络游戏史上第一款采用包月制的网络游戏，包月制的收费方式有利于加速网络游戏的平民化进程，对网络游戏的普及将起到重要作用。遗憾的是，包月制在当时并没有成长起来的条件，1990年AUSI公司为《龙门》（Dragon’s Gate）定的价格为每小时20美元，尽管费率高得惊人，但仍有人愿意每月花上2000多美元去玩这款游戏，因此在80年代末90年代初，包月制并未引起人们的关注。

1985年，比尔·洛登说服通用电气公司（GE）的信息服务部门投资建立了一个类似CompuServe的、商业化的、基于ASCII文本的网络服务平台，这套平台被称为GEnie（GE Network for Information Exchange）。GEnie于10月份正式启动，其低廉的收费标准在用户中间引起了巨大反响，也令一向有着强烈优越感的CompuServe感受到了竞争的压力。GEnie系统实际上是利用GE信息服务部门的服务器在夜晚的空闲时间为用户提供服务，因此收费非常低廉，晚上的价格约为每小时6美元，几乎是CompuServe的一半。

同年11月，Quantum Computer Services（AOL的前身）毫无声息地推出了QuantumLink平台，这是一个专为Commandore 64/128游戏机玩家服务的图形网络平台，费率仅为每月9.95美元。这一收费标准完全可以成为网络游戏发展史上的一个重要里程碑，但由于当时的Commandore 64/128游戏机已步入衰退期，因此这项具有革命意义的收费标准如同雅克布斯的“家庭作坊”一样，未能引起人们的重视，否则网络游戏的革命很可能会提前来到。

无论如何，更多运营商的介入令网络服务业的竞争激烈了起来，费率的下调已成必然趋势。这一阶段的美国网络游戏业如同现阶段国内的网络游戏业，运营商与游戏商在网络游戏身上大赚了一笔。1988年，Quantum从TSR手中购得“龙与地下城”的授权，三年后，第一款AD&D设定的网络游戏——《夜在绝冬城》（Neverwinter Nights）诞生，这款游戏运营了若干年，尽管所采用的图像技术陈旧不堪，但仅在它生命周期的最后一年，即1996年，它就为AOL带来了500万美元的收益。

相比于我们常见的数据中心的普通web服务器，游戏服务器（如英雄联盟，魔兽世界）有什么特别的地方?

朋友里有一位服务器大牛做过类似的总结，我征得他的同意把当时的资料分享一下。大量删节。

文章里说游戏服务器比较多，没怎么说web服务器。但是看了之后你就明白Web和游戏服务器在并发性方面根本性的不同了。

游戏服务器架构通识

· 前言

· 我们将从游戏服务器发展的简单历程出发，鸟瞰一下目前大多数的游戏服务器架构。

· 这里尽可能的避免陷入细节的技术问题，而是从技术进化的结果状态，反推原始问题是什么。希望能通过这个过程，解释清楚游戏服务器是在解决什么问题，痛点到底在哪里。

· 一、早期网游服务器。

· 蛮荒时期的游戏服务器框架我们一笔带过，那时的游戏服务器和一个小Web服务没有区别。

· 蛮荒时代的服务器只负责存储玩家账号、数据、转发场景内其他玩家的行为。很多移动、使用技能等关键逻辑在服务器上根本没有。随意就能用变速齿轮改变游戏速度。

· 从传奇的时代开始，游戏服务器就不再是简单的上传存档、下载存档、访问页面而已。游戏服务器内部出现了游戏逻辑，既能用于同步每个玩家看到的世界，又能让逻辑与客户端分离，避免早期的网络游戏那种毫无防范的逻辑体系（对外挂防御能力为0）。

· 这种架构奇怪的地方是处理网络连接数据传输的压力和逻辑处理的压力在同一个服务器上（存储模块可能也在同一个进程），就算逻辑处理压力为0，承载人数也高不到哪去。

· 二、早期游戏服务器的改进版本

· 当开发者们有了初步经验以后，新作品的开发，自然而然的过渡到了如下的形式：

· 游戏逻辑服务依然是在一台服务器上，单进程（逻辑处理本身肯定是在一个线程中，可以有子线程负责内网通信）。但是我们自然的想到，存储负载和网络连接负载可以从逻辑服上拆出来。

· 由于连接服务器本身没有时序性，很容易做分布式的（其实大部分游戏还是只用一个连接服），存储服务不要求高实时性，高峰期存盘间隔可以稍长一些，不会对游戏服造成影响。

· 三、成熟形态的服务器框架（这节是重点）

· 1、逻辑服务器的负载均摊方法一：按照功能划分多个服务器进程

· 2、逻辑服务器的负载均摊方法二：按照场景划分多个服务器进程

· 难点在逻辑的设计上，要像做手术一样把本来是一体的功能切开，并抽象出若干个API来保持联系（服务器之间是TCP连接）。

· 在分解时，要找联系相对最薄弱的环节入手，比如场景和场景之间分开、单独抽出聊天服务、组队服务、好友服务。

· 无论如何分解，最终结果只能是有限个服务。而且分解的越细，开发难度就越大。因为跨服务器逻辑是把简单的同步逻辑变成了异步Callback逻辑，而且容易出现时序问题等不易测试的问题。

· 单个场景服务几乎是无法分解的。分解单个场景难度巨大以至于出现了BigWorld引擎来专门的解决场景分割问题，后面会谈到。

· 这种成熟形态的游戏服务器已经能满足现实中99%的频繁交互类网游需求，是大型MMO端游、页游的主流形式。

· 对比Web服务器

大致只说一点：由于数据库的存在以及HTTP请求的特性，Web服务器天生就是并发的，也一直在高并发的路上越走越远。

· 附：开房间式的网络游戏

· 开房间式的网络游戏也是游戏的一个重要分支，英雄联盟、DOTA、很多手游例如皇室战争、王者荣耀等等。

· 这种游戏房间之间几乎没有交互，只有大厅内有交互，可以理解为原始形态的游戏服务器的平行扩展。

· 房间式游戏扩展难度较小，只是需要根据玩家数量动态扩展游戏房间的数量、服务器数量。很像网站的架构。

· 这种游戏架构最最适合放在云平台上，设计合理的话，它可能遇到的问题和大型网站几乎一模一样。不需要特别的讨论它们。

· 只是，毕竟游戏不都是开房间的玩法。

· 小结：游戏服务器框架特点

· 1、真正的数据都在内存中，数据库性能不那么重要

· 注：很多大型游戏采用了共享内存，避免宕机时损失过大。

· 2、单CPU性能比CPU数量重要的多。

· 3、目前有很多游戏，特别是手游，使用Redis读写代替内存读写，甚至也有用Mongo的。

· 4、开新服、旧区合服的情况，非常适合云平台。

· 先进服务器框架

1、BigWorld。理念过于超前，把并发性做到极致，开发友好度弱到极致，已废。

2、Skynet。本人强烈推荐，谁学谁知道，除了必须要用lua语言，没有什么缺点。

· 聊聊十万行代码

· 游戏服务器开发速度受美术资源制作速度、客户端开发速度制约。近几年我猜测服务器方面并不会有大的技术革新。

· 游戏开发未来的趋势是多元化、低门槛化、大众化。很长一段时间内BigWorld这种大怪兽级别的引擎不会再崛起。

· 分布式框架的崛起时间点，无论如何，也在VR技术成熟之后了。

 

一般的网站应用程序，是典型的Request-Response模式，通过tcp和服务器建立一次链接，而请求数据和影响数据通过http协议进行组装，当完成一次交互的时候，服务器端和客户端tcp链接就会释放，把服务器端socket资源留给新的客户端。通常web程序是比较好扩展的，通过硬件负载均衡和添加web服务器来实现，这一套方案业界都已经比较成熟了。网游比较特殊，最大的特点在于客户端和服务器端是要进行长连接的，客户端和服务器端基本上一直要保持连接，不是典型的Request-Response模式，Client会主动给Server发送数据，Server也可能主动往Client发送数据，生命周期比较长，一次发送的数据量比较小，但是数据交互发送比较频繁。由于要进行长连接，服务器端的socket就不能进行复用，单台服务器处理请求是会有限。用web的方案解决扩展问题，也不太适用。在web程序中，客户端之间的数据是没有交互的，所有的数据都是通过web服务器响应给客户端，但是网游服务器中，每个客户端的数据的变化，都要通过服务器端广播给其他客户端。所以客户端会有上限，这也就是为什么服务器要进行分区，一个区里面同时在线人数会有限制。

数据库服务器

数据库服务器其实就是专门利用一台服务器进行数据库的读写操作。这点特别是在大型的网络游戏里尤为重要。因为在大型网络游戏里，要处理玩家的数据量非常大，如果不利用专门的服务器进行处理，很有可能会拖累这个服务器组。

计费服务器

通常在商业的网络游戏里出现，用于记录玩家在线的时间，给收费提供依据，同时也是整个服务器组里最重要的部分，一旦出现问题，运营商就不用赚钱了。

聊天服务器

在游戏里的聊天功能是属于一种瞬时动作，理论上是放在逻辑服务器里进行处理。不过在大型网络游戏里，因为这个部分功能与游戏里的其它部分联系并不紧密，因此可以独立出来做一个功能服务器。

服务器的集群设置

在大型游戏的应用过程中，实际需要处理的玩家数量可能过万，一台普通的服务器是无法完成所要完成的工作，因此，在实际应用的时候，通常是由一组多台服务器共同完成一个功能。
例如地图服务器，可以根据需要，把游戏里所有的地域进行划分，划分为N个区域，然后让这一个区域里发生的事件都用一个特定的服务器进行处理。这样做的目的是减少一个服务器所承担的计算量，把整个系统组成一个分布式的网络。
不过这样做的同时会造成一个麻烦：当一位玩家从区域1，移动到区域2。这个时候，就必须先在服务器1里把玩家删除，然后再在区域2里加入玩家。同时需要由服务器1向服务器2转移玩家的数据信息（因为服务器组在工作的时候，玩家的信息只能保存在当前所在区域的服务器里），也就是说一旦玩家发生服务器间区域移动，服务器端就不可避免的造成数据通讯。因为这种移动并不是有规律的，玩家所在的服务器都有可能到达其它服务器。这样，如果服务器组里有N台地图服务器，那么，每个服务器都可能向其它N－1台服务器产生连接，总共就可能产生N×N个连接。如此数量连接如果只是使用普通的socket设计，就很有可能会给服务器通讯间的各种问题所困扰，为此，在商业网络游戏的服务器之间，通常都使用成熟的第三方的通讯中间件，如ACE，ICE等作为网络连接的传输层。

最大的区别是，web服务器每个client都是独立的，游戏服务器不同client是有交互有状态，会实时地互相影响。这导致很多设计上的差异。
并发架构的影响
在高并发下，对client请求进行负载均衡并不如web那么简单，因为client状态会互相影响，并且可能共享写数据甚至有时序依赖。大型mmorpg通常是长连接，并发服务数通常要远小于web服务器 。根源就是实时性和强交互性的限制，两者要求越低的游戏，并发就可以做得越高。
web服务运算较少，io密集，读多写少。游戏服计算和io都密集，读写都频繁

对代码风格的影响
比如开发web服务，基于nginx的openresty就很好用，利用了Lua的协程和异步io，写起来很流畅而不失性能。但用来做游戏服务器，协程却可能是个坑，因为游戏依赖很多上下文环境，当协程被唤醒时，上下文环境改变，协程的代码风格很容易用了旧变量导致逻辑错误。

类型1：卡牌、跑酷等弱交互服务端

卡牌跑酷类因为交互弱，玩家和玩家之间不需要实时面对面PK，打一下对方的离线数据，计算下排行榜，买卖下道具即可，所以实现往往使用简单的 HTTP服务器：

登录时可以使用非对称加密（RSA, DH），服务器根据客户端uid，当前时间戳还有服务端私钥，计算哈希得到的加密 key 并发送给客户端。之后双方都用 HTTP通信，并用那个key进行RC4加密。客户端收到key和时间戳后保存在内存，用于之后通信，服务端不需要保存 key，因为每次都可以根据客户端传上来的 uid 和 时间戳 以及服务端自己的私钥计算得到。用模仿 TLS的行为，来保证多次 HTTP请求间的客户端身份，并通过时间戳保证同一人两次登录密钥不同。每局开始时，访问一下，请求一下关卡数据，玩完了又提交一下，验算一下是否合法，获得什么奖励，数据库用单台 MySQL或者 MongoDB即可，后端的 Redis做缓存（可选）。如果要实现通知，那么让客户端定时15秒轮询一下服务器，如果有消息就取下来，如果没消息可以逐步放长轮询时间，比如30秒；如果有消息，就缩短轮询时间到10秒，5秒，即便两人聊天，延迟也能自适应。

此类服务器用来实现一款三国类策略或者卡牌及酷跑的游戏已经绰绰有余，这类游戏因为逻辑简单，玩家之间交互不强，使用 HTTP来开发的话，开发速度快，调试只需要一个浏览器就可以把逻辑调试清楚了。

类型2：第一代游戏服务器 1978

1978年，英国著名的财经学校University of Essex的学生 Roy Trubshaw编写了世界上第一个MUD程序《MUD1》，在University of Essex于1980年接入 ARPANET之后加入了不少外部的玩家，甚至包括国外的玩家。《MUD1》程序的源代码在 ARPANET共享之后出现了众多的改编版本，至此MUD才在全世界广泛流行起来。不断完善的 MUD1的基础上产生了开源的 MudOS（1991），成为众多网游的鼻祖：

MUDOS采用 C语言开发，因为玩家和玩家之间有比较强的交互（聊天，交易，PK），MUDOS使用单线程无阻塞套接字来服务所有玩家，所有玩家的请求都发到同一个线程去处理，主线程每隔1秒钟更新一次所有对象（网络收发，更新对象状态机，处理超时，刷新地图，刷新NPC）。游戏世界采用房间的形式组织起来，每个房间有东南西北四个方向可以移动到下一个房间，由于欧美最早的网游都是地牢迷宫形式的，因此场景的基本单位被成为 “房间”。MUDOS使用一门称为LPC的脚本语言来描述整个世界（包括房间拓扑，配置，NPC，以及各种剧情）。游戏里面的高级玩家（巫师），可以不断的通过修改脚本来为游戏添加房间以及增加剧情。早年 MUD1上线时只有17个房间，Roy Trubshaw毕业以后交给他的师弟 Richard Battle，在 Richard Battle手上，不断的添加各种玩法到一百多个房间，终于让 MUD发扬光大。

用户使用 Telnet之类的客户端用 Tcp协议连接到 MUDOS上，使用纯文字进行游戏，每条指令用回车进行分割。比如 1995年国内第一款 MUD游戏《侠客行》，你敲入："go east"，游戏就会提示你：“后花园 - 这里是归云庄的后花园，种满了花草，几个庄丁正在浇花。此地乃是含羞草生长之地。这里唯一的出口是 north。这里有：花待 阿牧（A mu），还有二位庄丁（Zhuang Ding）”，然后你继续用文字操作，查看阿牧的信息：“look a mu”，系统提示：“花待 阿牧（A mu）他是陆乘风的弟子，受命在此看管含羞草。他看起来三十多岁，生得眉清目秀，端正大方，一表人才。他的武艺看上去【不是很高】，出手似乎【极轻】”。然后你可以选择击败他获得含羞草，但是你吃了含羞草却又可能会中毒死亡。在早期网上资源贫乏的时候，这样的游戏有很强的代入感。

用户数据保存在文件中，每个用户登录时，从文本文件里把用户的数据全部加载进来，操作全部在内存里面进行，无需马上刷回磁盘。用户退出了，或者每隔5分钟检查到数据改动了，都会保存会磁盘。这样的系统在当时每台服务器承载个4000人同时游戏，不是特别大的问题。从1991年的 MUDOS发布后，全球各地都在为他改进，扩充，退出新版本，随着 Windows图形机能的增强。1997游戏《UO》在 MUDOS的基础上为角色增加的x,y坐标，为每个房间增加了地图，并且为每个角色增加了动画，形成了第一代的图形网络游戏。

因为游戏内容基本可以通过 LPC脚本进行定制，所以MUDOS也成为名副其实的第一款服务端引擎，引擎一次性开发出来，然后制作不同游戏内容。后续国内的《万王之王》等游戏，很多都是跟《UO》一样，直接在 MUDOS上进行二次开发，加入房间的地图还有角色的坐标等要素，该架构一直为国内的第一代 MMORPG提供了稳固的支持，直到 2003年，还有游戏基于 MUDOS开发。

虽然后面图形化增加了很多东西，但是这些MMORPG后端的本质还是 MUDOS。随着游戏内容的越来越复杂，架构变得越来越吃不消了，各种负载问题慢慢浮上水面，于是有了我们的第二代游戏服务器。

首先大概介绍一下运营商的概念，或者换个现在更常用的说法，“渠道”。
因为如果对国内手游产业不是非常了解的话，可能不是很能理解国内手游产业中“渠道”的角色。
传统的单机游戏行业，开发商负责整个游戏的研发，而真正的纯单机游戏并没有“运营”的概念，所以只有所谓的“发行商”，负责对游戏进行包装、营销和发售。例如《暗黑破坏神2》在中国的发行商是奥美，《伊森疯狂赛车》在中国的发行商是天人互动。最后的营收则是由开发商和发行商按一定的比例瓜分。
而传统的PC网游（俗称“端游”），由于有开发大型端游能力的公司往往也同时具有强大的运营能力（包括营销推广、维护服务器、客服等等），因此开发商与运营商往往是同一家公司（如网易、完美、腾讯、西山居等等）。而国外的网游如果要在中国市场运营，则往往会委托中国的公司来进行运营活动（也就是俗称的“代理”）。而最后的营收同样由开发商和运营商进行分成。例如《魔兽世界》与网易、《龙之谷》与盛大、CF（我就不打书名号了）与腾讯等等。也有极少数国内网游由别家的国内公司进行运营。例如盛大也曾经运营过西山居的《剑网三》。然而这些游戏由于往往是国外的公司全权委托给国内公司进行代理，因此往往账号登陆和游戏本身还是要通过同一家公司的服务器。
而到了手游时代，整个产业的运作方式进行了一次大洗牌。所谓的“渠道”如今承担了更重要的角色。因为这个时代的“渠道”商往往是几年前霸占了更多用户流量资源的公司。例如有微信和QQ的腾讯、有贴吧等等的百度、有自己的手机平台的小米等等。由于拥有更多的用户资源，这些平台往往比传统的自研游戏大厂本身的推广能力要强上几个数量级。许多端游大厂在转型手游的过程中对于“渠道”的认识严重不足，往往都付出了惨痛的代价。如今“渠道”+开发商的模式已经成为常识。
需要指出的是，APPSTORE和国外的GOOGLEPLAY也是“渠道”的一种。APPSTORE的首页推荐几乎是苹果平台上最有力的推广手段。

===================
介绍完渠道的概念后，再来理解为何要把登陆和游戏服务器分开就很容易了。因为在手游时代，是个网游都是要接入渠道登陆功能的，因此在开发游戏的初期就应该把接入渠道的工作纳入开发计划之中。
一般运营的游戏实际负责保存游戏数据和执行服务端逻辑的服务器由开发商进行部署和维护，而负责登陆的服务器则由渠道负责部署和维护。由于渠道往往拥有很多现成的用户，以及各种方便快捷的登陆方式（例如微信的自动登录），而这些登陆方式不同平台往往差别很大，而渠道间的竞争也很激烈，因此大多数渠道都会通过给出现成的登陆模块（SDK）和统一接口的方式供开发商进行接入。
不过要指出的是，这里的“登陆”应该是只单纯的用户名密码、游客账号等等单纯的“验证身份”的模块。事实上，开发商在自己的游戏服务器中也会有单独的登陆功能模块。
举个例子，现在有个由“NETHARD”的公司开发的叫《枕头大战》的游戏在小米的平台上进行运营。
有个叫小A的玩家是小米的用户，账号是13854389438，昵称是“巭孬嫑莪”。
然后他玩了小米上的《枕头大战》，用了小米的账号进行登陆。
然后进入游戏后他建了个叫“伊藤诚”的角色。
在普通玩家看来，这整个一套是一个非常简单的登陆流程。但其实这里面有三套可以称之为“账号”的系统。
首先是小米平台的账号（13854389438 - 巭孬嫑莪）。这套账号保存在小米的服务器上。
在登陆了“巭孬嫑莪”后，NETHARD公司获取了小米提供的身份验证信息，如果这个身份是第一次在NETHARD的服务器上登陆，那么NETHARD的服务器会为该用户分配一个NETHARD内部的用户身份，例如“13854389438%%MI”，并将这两个身份进行映射。而每次“巭孬嫑莪”在用“13854389438”的账号登陆《枕头大战》时，NETHARD的服务器上也会自动通过“13854389438%%MI”的账号进行登陆。
最后，存在NETHARD游戏服务器内的角色“伊藤诚”则相当于第三重账号。由于现在的手游网游往往在同一个账号下的角色不共享货币（如常见的“元宝”、“钻石”等等），因此在NETHARD的服务器内，“伊藤诚”则是一个独立的身份。而NETHARD的账号系统则会将“伊藤诚”和“13854389438%%MI”再一次映射起来。

====================
最后需要指出的是，在上述的流程中其实是有三台服务器存在的。分别是小米的登陆服务器、将小米账号“13854389438”和NETHARD账号“13854389438%%MI”进行映射的服务器以及将“13854389438%%MI”和“伊藤诚”进行映射的服务器。而最后那台服务器往往才是真正的游戏服务器。
至于为什么要将第二台服务器和第三台服务器分开？因为除了“登陆”功能外，手游还有“计费”模块。
NETHARD公司自然不会只有《枕头大战》一款游戏。而NETHARD公司还有自己独立的财务、审计，那么玩家花的每一块软妹币，最后都是要通过第二台服务器的流水的。
当“伊藤诚”在游戏里消费“￥100”买了一瓶“妹汁”时，首先第三台服务器会生成一张订单，告诉第二台服务器“玩家13854389438%%MI买了道具No8989，订单号XXX”。第二台服务器则会告诉小米的服务器“你的那个玩家13854389438买了道具No8989，订单号XXX”。然后小米在自己的服务器上查了下，道具No8989的售价是￥100（这个信息是游戏在平台上发布前事先注册好的信息），然后在获得“伊藤诚”的确认后，小米和支付宝进行了一系列肮脏的交易，最后小米获得了￥100，然后告诉第二台服务器“已收到13854389438的赃款，可发放No8989，订单号XXX已完成”，第二台再把该信息传达给第三台服务器，最后第三台服务器（也就是游戏服务器）在游戏里把妹汁发放给了“伊藤诚”先生。
当然这事儿还没完，在月底时，小米会把￥100中应该分成给NETHARD的那一部分给NETHARD，然后两家公司再各自给自己的临时工们发了饷，大家就各回各家各找各妈了。