什么是游戏服务端？

是服务器上的游戏程序。我们所有的角色信息都是由服务器控制的，而我们自己电脑上的客户端是用来和服务器联系，显示各种动作的。服务器上没有客户端这样的美术资源。他们只是运行一些数据，然后向客户端发送一些数据代码。客户端收到数据后，会从本地机器调出相应的美术资源(各种动作和地图)并显示在客户端。因为服务器上没有美术资源，所以程序规模不会太大，但它是一个大数据库，要响应上百个客户端发来的数据，所以对网络和机器的性能要求很高。如果有服务器端的程序，自己搭建服务器是违法的，非法搭建私服是违法的，侵犯了游戏的知识产权。

游戏的服务端指的是什么

服务器端是让所有远程客户端连接到服务器上玩游戏。(概念是把国内所有玩家集中在一个地方玩同一个游戏。)每个网游都有一个服务器端，需要1-N个服务器。不同的游戏有不同的安装方式！以上是游戏服务器的视图。另外，我们可以打开自己的网络连接。一般来说，我们可以在详细信息中看到一个服务器IP，对吗？那个服务器IP，通俗的解释就是你所在的IP部门。也就是你的IP其实是它庞大的IP体系集合中的一部分。比如你家买了新房，你家房子是客户端IP，服务器IP是你家房子所在的小区。所以你应该明白吧？换句话说，服务器IP实际上是对一个IP段的管理。另外服务器有说明，就是你租的FTP空间等。假设你租了一个FTP个人空间，那么给你提供空间的公司或者网站就是你的服务器，相对来说，你就是它的客户端。一般来说，服务器端的意思是提供服务。

做游戏服务端开发这个有前途么。。。

。

技术是国产游戏的瓶颈。努力工作，它有一个光明的未来。

以后就靠你做技术总监了，还有项目分红。

端游，手游服务端常用的架构是什么样的

端游和手游服务器的共同架构是什么？第一类：弱交互的服务器端卡牌跑酷类，如卡牌、跑酷等。因为互动性弱，玩家之间不需要实时面对面的PK。可以打对方的线下数据，计算排行榜，买卖道具。所以实现往往使用简单的HTTP服务器：登录时可以使用非对称加密(RSA，DH)。服务器根据客户端uid、当前时间戳和服务器私钥计算哈希得到的加密密钥并发送给客户端。此后，双方使用HTTP进行通信，并使用该密钥执行RC4加密。收到密钥和时间戳后，客户端将其保存在内存中，以供以后通信使用。服务器不需要保存密钥，因为每次都可以根据客户端上传的uid和时间戳以及服务器自己的私钥来计算。模仿TLS的行为保证多个HTTP请求中的客户端身份，通过时间戳保证同一个人的登录密钥两次不同。每个游戏开始的时候，访问它，请求等级数据，完成后再次提交，检查是否合法，获得什么奖励。数据库可以使用单一的MySQL或者MongoDB，后端的Redis可以作为缓存(可选)。如果你想实现通知，那么让客户端定时轮询服务器15秒。如果有什么消息，记下来。如果没有消息，可以逐渐延长轮询时间，比如30秒。如果有消息，将轮询时间缩短到10秒或5秒，即使两个人聊天，延迟也可以自适应。这种服务器实现一个游戏的三国攻略或者卡牌和酷跑绰绰有余。这类游戏逻辑简单，玩家之间的互动性不强。如果是用HTTP开发，开发速度快，只需要一个浏览器调试逻辑。第二类：第一代游戏服务器。1978-1978年，英国著名金融学院埃塞克斯大学的学生罗伊特鲁布肖(Roy Trubshaw)编写了世界上第一个MUD程序《MUD1》。1980年埃塞克斯大学接入阿帕网后，增加了很多外部玩家，甚至是外国玩家。055-79000程序的源代码在ARPANET共享后出现了很多改编版本，于是MUD风靡全球。在MUD1不断完善的基础上，开源的MudOS(1991)应运而生，成为众多网络游戏的鼻祖。MUDOS是用C语言开发的，因为玩家之间有很强的互动性(聊天，交易，PK)。MUDOS使用单线程非阻塞socket为所有玩家服务，所有玩家的请求都发送到同一个线程进行处理。主线程每秒更新所有对象(网络发送和接收，更新对象状态机世界是以房间的形式组织的。每个房间有四个方向：东南，西北，可以搬到隔壁房间。由于欧美最早的网络游戏都是地牢迷宫的形式，所以场景的基本单位叫做“房间”。MUDOS使用一种叫做LPC的脚本语言来描述整个世界(包括房间拓扑、配置、NPC和各种情节)。游戏中的高级玩家(巫师)可以不断修改脚本，为游戏添加房间和剧情。早年MUD1上线时只有17个房间。毕业后，罗伊特鲁布肖把它交给了弟弟理查德巴特尔。在理查德巴特尔的手里，他不断给100多个房间添加各种游戏，终于让MUD兴盛起来。用户使用Telnet等客户端，用Tcp协议连接MUDOS，用明文玩游戏，用enter分割每条指令。比如1995年，中国第一个MUD游戏是《MUD1》。如果你输入“向东走”，游戏会提示你：“后花园——这里是云庄的后花园，长满了花花草草，一些庄丁正在浇花。这是含羞草生长的地方。这里唯一的出口是北边。在这里，有“华木”和“两个庄丁”。然后，你可以继续用这句话来查看阿木的信息：“看阿木”。系统提示：“花木”是的弟子，被分配到这里照顾含羞草。他看上去30多岁，眉清目秀，得体大方，一表人才。

他的武功看起来[不高]，招式看起来[极轻]”。那么你可以选择打他得到含羞草，但是如果你吃了含羞草，你可能会中毒而死。在网络资源匮乏的早期，这类游戏的代入感很强。用户的数据存储在文件中。每个用户登录时，所有用户的数据都是从文本文件中加载的，所有操作都在内存中进行，不需要马上刷回磁盘。如果用户注销，或每5分钟检查一次数据更改，社交盘将被保存。在当时这样的系统，每台服务器承载4000人同时玩游戏，并不是特别大的问题。自从1991年MUDOS发布以来，全世界都在为它改进、扩充和退出新版本。随着Windows图形功能的增强。997游戏《侠客行》在MUDOS的基础上增加了人物的x，y坐标，每个房间的地图，每个人物的动画，形成了第一代的图形网游。因为游戏内容基本可以通过LPC脚本定制，所以MUDOS也成为了第一个名副其实的服务器端引擎。引擎一次性开发，然后制作不同的游戏内容。国内的后续游戏如《UO》，像《万王之王》都是直接在MUDOS上二次开发，包括房间的地图，人物的坐标。这种架构为中国第一代MMORPG提供了坚实的支持，直到2003年，游戏都是基于MUDOS开发的。虽然许多东西是在后期的图形中添加的，但这些MMORPG后端的本质是MUDOS。随着游戏内容越来越复杂，架构越来越不堪，各种负载问题慢慢浮出水面，于是有了我们的第二代游戏服务器。类型三：2003-2000年后，第二代游戏服务器，网游已经脱离了最初的文字泥巴，进入了综合图形时代。我首先不能忍受的，其实是一大堆小文件。用户登录和离线，频繁地读取和写入用户数据，导致负载不断增加。随着在线人数和游戏数据的增加，服务器变得不堪重负。同时，早期的EXT磁盘分区比较脆弱，稍有停电，就容易出现大规模的数据丢失。因此，第一步是将文件拆分并存储在数据库中。此时游戏服务器已经脱离了旧的MUDOS系统。参考MUDOS结构，各家公司开始用c重新开发自己的游戏服务器，而且脚本也抛弃了LPC，换成了扩展性更好的Python或Lua。由于主逻辑采用单线程模式，随着游戏内容的增加，传统的单服务器结构成为瓶颈。于是有人开始对游戏世界进行拆分，就变成了下面的模式：拆分后游戏服务器的压力得到缓解，但是两台游戏服务器同时访问数据库，大量的重复访问和数据交换使得数据库成为下一个瓶颈。于是就形成了数据库前端代理(DB Proxy)。游戏服务器不直接访问数据库，而是访问代理，然后代理访问数据库并提供内存级缓存。早年MySQL4之前没有提供存储过程。这个前端代理一般和MySQL运行在同一个舞台上。它将游戏服务器发来的高层数据操作指令进行转换，拆分成具体的数据库操作，在一定程度上替代了存储过程：但这种结构并没有持续多久，因为玩家在切换场景时经常要切换连接，中间的状态很容易混淆。而且游戏服务器多了，相互之间的数据交互会变得更加麻烦，于是人们把网络功能拆分出来，独立设置了一个网关服务闸(有的地方叫Session，有的地方叫LinkSvr，名称不同):把网络功能单独提取出来，让用户统一连接一个网关服务器，然后网关服务器把数据转发给后端游戏服务器。游戏服务器之间的数据交换也连接到网络管理进行交换。

这类服务器基本可以稳定的为玩家提供游戏服务。一个网关服务10000-20000人，以下游戏服务器每个服务5k-1w，视游戏类型和复杂程度而定。图中隐藏了很多不重要的服务器，比如登录和管理。这是目前应用最广泛的模型，直到今天，许多新项目都将采用这种结构。人都有惰性。根据以往的经验，似乎MUDOS分割越开，性能越好。于是我们继续认为网关可以拆分，聊天交易等基础服务可以拆分，web接口可以提供，数据库可以拆分，于是我们有了下面这个模型：这个模型好用吗？确实有成功的游戏使用了这种架构，并充分发挥其性能优势，比如一些大型MMORPG。然而，有两个挑战：状态机的复杂性可能会随着服务器级别的增加而加倍，从而导致R&D和bug发现的成本增加；这对开发团队来说是一个巨大的挑战。一旦项目时间紧张，开发人员经验不足，就很容易挂掉。比如我见过上海某一线游戏公司的RPG就想出了这样的结构。我看了他们团队成员的经历，问了他们的上线日期，建议他们用更早的稍微简单一点的模型。人们非常有信心成功的项目做到这一点，他们也想这样做，他们真的想实现一个。于是他们毫不犹豫地开始编码。项目做了一年多，然后，就没有了。目前游戏的成功率并不高。一开始，更复杂的架构需要考虑投资回报。例如，你的游戏在半年内会卖到多少PCU？如果一款APRG游戏每组服务器不能达到5000人，那么选择更接近实际情况的结构更经济。就算你的项目后面有5000多人往一万人的目标跑，我相信你的项目那时候已经赚了不少钱了。你数着钱加班加点一步一步迭代，一次次拆分。我相信你心里会幸福的。以上类型基本都是从MUDOS的拆分开始的，MUDOS中的各个组件都是从单机一步步拆分到分布式的。虽然时至今日，很多新项目还在使用上述类似结构中的一种，或者自己拆分了其他热门模块。因为它们本质上是MUDOS的分解，所以被归类为第二代游戏服务器。类型四：第三代游戏服务器2007从魔兽世界开始，无缝世界地图已经深入人心。相比过去，游戏玩家走几步就需要切换场景，每次切换都要等待加载几十秒，这是一件非常具有破坏性的事情。因此，无缝地图成为2005年以后大型MMORPG的标准配置。与过去靠地图切割的游戏相比，无缝世界没有一张地图，只有一台服务器处理：每个节点服务器用来管理一个地图区域，NodeMaster(NM)为它们提供整体管理。更高层次的世界提供大陆层次的管理服务。这里省略了服务器的一些细节，如传统的数据库前端、登录服务器、日志和监控等。全部由ADMIN汇总。在这样的结构下，玩家从一个区域移动到另一个区域需要一个简单的过程：玩家1完全由节点A控制，玩家3完全由节点B控制，而处于两个节点边缘的玩家2则同时由A和B服务，2在从A移动到B的过程中，玩家会同时向A请求左边的信息，向B请求右边的信息。但2号选手此时仍属于A管理层。直到玩家2完全脱离AB边界，才完全由b管理，按照这个逻辑，世界地图是分区域的，由不同的节点管理。对于一个节点负责的区域，没有必要进行地理上的连接。比如大陆周边边缘部分和高山部分人口较少，可以由一个节点统一管理。然而，没有必要在地理上连接这些块。

一个节点管理哪些块？可以根据游戏实时运行负载，在定期维护时更改NodeMaster上的配置。所以第一个问题就是很多节点服务器需要和玩家通信，需要问管理服务器特定UID的玩家在哪个门。以前这个问题对于场景切割的服务器来说不大，问一次就可以缓存，但是现在服务器种类增加了很多，玩家又会四处浮动。用UID找玩家比较麻烦；另一方面，GATE需要根据坐标动态计算与哪个节点进行通信，导致逻辑较粗，因此从负责连接管理的GATE中切出“用户对象”势在必行。于是就有了下面这个模型：网关服务器再次回归到精简的网络转发功能，而用户逻辑则由按照UID划分的OBJ服务器承担，根据网络访问负载分配网关。OBJ是根据资源的编号(UID)来分配的，因此在与用户通信时，可以根据UID直接计算OBJ服务器号来发送数据。新独立的OBJ提供更高层次的服务：对象移动：管理特定玩家在不同节点管辖区域之间的移动，与需要的节点进行通信。广播：节点可以为每个用户设置几个标签，然后通知对象主根据标签进行广播。对象消息：一般的消息推送，发送数据给一个用户，直接告诉OBJ，不需要直接处理GATE。与朋友聊天：直接通过OBJ/OBJ大师在角色之间聊天。整个服务器体分为三层后，NODE侧重场景，OBJ侧重玩家对象，GATE侧重网络。该模型广泛应用于无缝场景服务器。但是随着时间的推移，负载问题越来越明显。当你进行一项活动时，远离活动的区域变得非常活跃。靠周维护来调整是比较繁琐的，所以有动态负载均衡。动态负载平衡有两种方法。第一种方法是节点主根据负载在固定时间内修改每个节点的边界，而不同的玩家对象按照之前的方法从一个节点迁移到另一个节点：图11动态负载均衡节点主定期在地图上寻找热点，计算新的场景切割方法，然后告诉其他服务器开始调整。具体处理方法还是和上面的对象越界移动一样。但上述方法的实现相对复杂，于是人们设计了一种更简单直接的新方法：图12。基于网格的动态负载均衡优于基于网格的动态负载均衡，或者将地图按照标准大小均匀切割成静态网格。每个网格负责一个特定的节点，但可以根据负载情况实时迁移到其他节点。迁移分为三个阶段：准备、切换和完成。这三种状态由节点主机维护。在准备阶段，新节点开始同步旧节点上方网格的数据，完成后告诉NM；NM确认OK后，也通知新旧节点完成切换。切换后，如果Obj服务器仍在与旧节点通信，旧节点将对其进行纠正，纠正后的OBJ将纠正其自身状态，并与新节点通信。很多无缝动态负载均衡的服务器都号称支持不限人数，但并不代表MMORPG游戏的最大人数真的可以无限扩展，因为这样的系统会受到网络带宽和客户端性能的限制。带宽决定了同一个区域的最大播放限制，客户端性能决定了同一个屏幕上可以画多少个角色。自从无缝地图引入分布式对象模型后，就完全脱离了MUDOS系统，成为了一种新的服务器端模型。随着动态负载均衡的引入，无缝服务器更加强大，容纳了比上一代游戏服务器多几倍的上限，提供了更好的游戏体验。我们称之为第三代游戏服务器架构。

从大型多人角色扮演开始，RPG网游一度长期占据90%以上的份额，使得基于MMORPG的服务器架构蓬勃发展。然而，随着玩家对RPG的厌倦，各种非MMORPG游戏如雨后春笋般出现在人们面前，并受到市场的欢迎。第五种：Battle.net游戏服务器经典的Battle.net服务器和RPG游戏有两个区别：RPG是分区域的，京广两地的用户永远合不来。而Battle.net，虽然每场游戏通常是8人以下玩，但全国只有一套服务器，所有玩家可以一起玩，玩家和玩家之间通过P2P连接形成一个游戏：玩家使用配对服务器，通过创建、加入、自动配对、邀请等方式形成一个游戏。服务器会选择一个人做主机，其他人连接到主导玩家P2P。STUN是一个帮助玩家建立P2P的牵引服务器，而且由于P2P连接性只有75%左右，无法真正连接的玩家会通过Forward来转发。大量相连的战斗，体育游戏采用类似的结构。有P2P网状模型(所有玩家相互连接)和星形模型(所有玩家连接到一个主玩家)。复杂的博弈状态在网状模式下很难保持一致，所以星型P2P模式经受住了历史的考验。除了游戏数据，支持语音的Battle.net还会将每个人的语音数据发送到玩家负责的机器上，通过混音、重编码、重编码的方式返回给所有用户。战网游戏以体育、运动、动作等类型游戏为主。慢节奏的RPG(包括ARPG)本质上是不同的，激烈的游戏过程必然导致比RPG复杂得多的同步策略。这样的同步机制往往会导致很多游戏结果被客户端直接计算，那么在到处破解的今天，如何保证游戏结果的公平性呢？主要方法是投票。所有客户端都会独立计算，然后传递给服务器。如果结果相同，记录将被更新；如果结果不一致，将通过投票决定最终结果。同时，记录下这个游戏的所有输入，如果可能的话，再找一个空闲的游戏客户端，查看整个游戏是否是结果。并记录下经常涉嫌作弊的用户，可以作为运营商封号时的参考。类型七：休闲游戏服务器休闲游戏类似于战斗。net服务器，所有这些都有一个全区域架构。不同的是有房间服务器和特定的游戏服务器。游戏主体不再由P2P玩家玩，而是连接到专门的游戏服务器进行处理。如同战斗一样。net，全区域架构，用户数据不能像分区的RPG一样一次性加载到内存中，然后直接在内存中修改。在区域架构下，为了应对一个用户同时玩几个游戏，用户数据需要区分基础数据和不同的游戏数据，而游戏数据需要区分分数数据和文档数据。胜败等点可以直接提交进行增量修改，而比较常见的文档数据需要提供读写令牌。只有一个写令牌和许多读令牌。在两台电脑上同时玩同一个账号的同一个游戏，第一个启动的游戏获得一个写令牌，可以操作任何用户数据。之后第一局除了提交输赢分的增量变化，还用只读的方式保证游戏可以运行，但是会提示用户游戏数据被锁定。类型八：现代动作网游从早期的韩国动作游戏开始，传统的Battle.net动作游戏和RPG游戏开始尝试融合。简单动作游戏玩家容易疲劳，留存没有RPG高；而单纯的RPG战斗又慢又无聊，无法满足很多玩家激烈对抗的期望，于是两者开始融合成新一代：动作小镇模式。玩家在镇上集合，然后几个人一式两份出去，通过玩动作游戏来完成各种RPG任务。它本质上是一套RPG服务器复制服务器。

因为每个副本中人物可以控制在8人以内，所以可以获得更实时的游戏体验，玩家玩起来也更爽快。说了这么多类型的游戏服务器，都差不多了。其余类型其实也就这样。

游戏服务端架构的设计方式，MMORPG和社交了游戏有什么不同

两个服务器还是有一定区别的。端游服务器一般比较重，长连接的tcp连接比较多。手游服务器要考虑很多弱网，短连接比较多。所以在后台服务器的选择上，端游服务器一般都是用C语言开发的，手机游戏的选择范围很广，有java和php，也有直接用C开发的，另外，在移动互联网时代，手机游戏在的强烈影响下加入了SNS社交元素。在支付层面，也会使用和支付，iOS会使用苹果支付。在存储模块中，手游多采用KV存储，端游多采用关系数据库mysql。其他方面也差不多。不管你用什么框架进行开发，只要你注重服务器性能的优化，不妨在游戏开发过程中或者上线前找个压力测试工具压一压。推荐一款腾讯游戏专用服务器压力测试工具WeTest质量测试平台(/gaps)，高并发，实时性能报告，专家级性能优化建议，上百万机器人，让你知道你的服务器能不能撑得住。