为什么靠服务器才能发布网站一定要租服务器呢,还有,怎么才能架设一个手游

手游页游和端游的服务端本质上沒区别区别的是游戏类型。

类型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

用户使用 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。随着游戏内容的越来越复杂架构变得越来越吃不消了,各种负载问题慢慢浮上水面于是有了我们的第二代游戏服务器。

类型3:第②代游戏服务器 2003

2000年后网游已经脱离最初的文字MUD,进入全面图形化年代最先承受不住的其实是很多小文件,用户上下线频繁的读取写叺用户数据,导致负载越来越大随着在线人数的增加和游戏数据的增加,服务器变得不抗重负同时早期 EXT磁盘分区比较脆弱,稍微停电容易发生大面积数据丢失。因此第一步就是拆分文件存储到数据库去

此时游戏服务端已经脱离陈旧的 MUDOS体系,各个公司在参考 MUDOS结构的情況下开始自己用 C在重新开发自己的游戏服务端。并且脚本也抛弃了 LPC采用扩展性更好的 Python或者 Lua来代替。由于主逻辑使用单线程模型随着遊戏内容的增加,传统单服务器的结构进一步成为瓶颈于是有人开始拆分游戏世界,变为下面的模型:

游戏服务器压力拆分后得意缓解但是两台游戏服务器同时访问数据库,大量重复访问大量数据交换,使得数据库成为下一个瓶颈于是形成了数据库前端代理(DB Proxy),遊戏服务器不直接访问数据库而是访问代理再有代理访问数据库,同时提供内存级别的cache早年 MySQL4之前没有提供存储过程,这个前端代理一般和 MySQL跑在同一台上它转化游戏服务器发过来的高级数据操作指令,拆分成具体的数据库操作一定程度上代替了存储过程:

但是这样的結构并没有持续太长时间,因为玩家切换场景经常要切换连接中间的状态容易错乱。而且游戏服务器多了以后相互之间数据交互又会變得比较麻烦,于是人们拆分了网络功能独立出一个网关服务 Gate(有的地方叫 Session,有的地方叫 LinkSvr之类的名字不同而已):

把网络功能单独提取出来,让用户统一去连接一个网关服务器再有网关服务器转发数据到后端游戏服务器。而游戏服务器之间数据交换也统一连接到网管進行交换这样类型的服务器基本能稳定的为玩家提供游戏服务,一台网关服务1-2万人后面的游戏服务器每台服务5k-1w,依游戏类型和复杂度鈈同而已图中隐藏了很多不重要的服务器,如登录和管理这是目前应用最广的一个模型,到今天任然很多新项目会才用这样的结构来搭建

人都是有惯性的,按照先前的经验似乎把 MUDOS拆分的越开性能越好。于是大家继续想网关可以拆分呀,基础服务如聊天交易可以拆分呀,还可以提供web接口数据库可以拆分呀,于是有了下面的模型:

这样的模型好用么确实有成功游戏使用类似这样的架构,并且发揮了它的性能优势比如一些大型 MMORPG。但是有两个挑战:每增加一级服务器状态机复杂度可能会翻倍,导致研发和找bug的成本上升;并且对開发组挑战比较大一旦项目时间吃紧,开发人员经验不足很容易弄挂。

比如我见过某上海一线游戏公司的一个 RPG上来就要上这样的架构我看了下他们团队成员的经验,问了下他们的上线日期劝他们用前面稍微简单一点的模型。人家自信得很认为有成功项目是这么做嘚,他们也要这么做自己很想实现一套。于是他们义无反顾的开始编码项目做了一年多,然后就没有然后了。

现今在游戏成功率不高的情况下一开始上一套比较复杂的架构需要考虑投资回报率,比如你的游戏上线半年内 PCU会去到多少如果一个 APRG游戏,每组服务器5千人嘟到不了的话那么选择一套更为贴近实际情况的结构更为经济。即使后面你的项目真的超过5千人朝着1万人目标奔的话相信那个时候你嘚项目已经挣大钱了 ,你数着钱加着班去逐步迭代一次次拆分它,相信心里也是乐开花的

上面这些类型基本都是从拆分 MUDOS开始,将 MUDOS中的各个部件从单机一步步拆成分布式虽然今天任然很多新项目在用上面某一种类似的结构,或者自己又做了其他热点模块的拆分因为他們本质上都是对 MUDOS的分解,故将他们归纳为第二代游戏服务器

类型4:第三代游戏服务器 2007

从魔兽世界开始无缝世界地图已经深入人心,比较鉯往游戏玩家走个几步还需要切换场景每次切换就要等待 LOADING个几十秒是一件十分破坏游戏体验的事情。于是对于 2005年以后的大型 MMORPG来说无缝哋图已成为一个标准配置。比较以往按照地图来切割游戏而言无缝世界并不存在一块地图上面的人有且只由一台服务器处理了:

每台 Node服務器用来管理一块地图区域,由 NodeMaster(NM)来为他们提供总体管理更高层次的 World则提供大陆级别的管理服务。这里省略若干细节服务器比如传統数据库前端,登录服务器日志和监控等,统统用 ADMIN概括在这样的结构下,玩家从一块区域走向另外一块区域需要简单处理一下:

玩家1唍全由节点A控制玩家3完全由节点B控制。而处在两个节点边缘的2号玩家则同时由A和B提供服务。玩家2从A移动到B的过程中会同时向A请求左邊的情况,并向B请求右边的情况但是此时玩家2还是属于A管理。直到玩家2彻底离开AB边界很远才彻底交由B管理。按照这样的逻辑将世界地圖分割为一块一块的区域交由不同的 Node去管理。

对于一个 Node所负责的区域地理上没必要连接在一起,比如大陆的四周边缘部分和高山部分嘚区块人比较少可以统一交给一个Node去管理,而这些区块在地理上并没有联系在一起的必要性一个 Node到底管理哪些区块,可以根据游戏实時运行的负载情况定时维护的时候进行更改 NodeMaster 上面的配置。

于是碰到第一个问题是很多 Node服务器需要和玩家进行通信需要问管理服务器特萣UID为多少的玩家到底在哪台 Gate上,以前按场景切割的服务器这个问题不大问了一次以后就可以缓存起来了,但是现在服务器种类增加不少玩家又会飘来飘去,按UID查找玩家比较麻烦;另外一方面 GATE需要动态根据坐标计算和哪些 Node通信导致逻辑越来越厚,于是把:“用户对象”從负责连接管理的 GATE中切割出来势在必行于是有了下面的模型:

网关服务器再次退回到精简的网络转发功能而用户逻辑则由按照 UID划分的 OBJ服務器来承担,GATE是按照网络接入时的负载来分布而 OBJ则是按照资源的编号(UID)来分布,这样和一个用户通信直接根据 UID计算出 OBJ服务器编号发送數据即可而新独立出来的 OBJ则提供了更多高层次的服务:

  • 对象移动:管理具体玩家在不同的 Node所管辖的区域之间的移动,并同需要的 Node进行沟通

  • 对象消息:通用消息推送,给某个用户发送数据直接告诉 OBJ,不需要直接和 GATE打交道

整个服务器主体分为三层以后,NODE专注场景OBJ专注玩家对象,GATE专注网络这样的模型在无缝场景服务器中得到广泛的应用。但是随着时间的推移负载问题也越来越明显,做个活动远来鈈活跃的区域变得十分活跃,靠每周维护来调整还是比较笨重的于是有了动态负载均衡。

动态负载均衡有两种方法第一种是按照负载,由 Node Master 定时动态移动修改一下各个 Node的边界而不同的玩家对象按照先前的方法从一台 Node上迁移到另外一台 Node上:

这样 Node Master定时查找地图上的热点区域,计算新的场景切割方式然后告诉其他服务器开始调整,具体处理方式还是和上面对象跨越边界移动的方法一样

但是上面这种方式实現相对复杂一些,于是人们设计出了更为简单直接的一种新方法:

图12 基于网格的动态负载均衡

还是将地图按照标准尺寸均匀切割成静态的網格每个格子由一个具体的Node负责,但是根据负载情况能够实时的迁移到其他 Node上。在迁移分为三个阶段:准备切换,完成三个状态甴Node Master负责维护。准备阶段新的 Node开始同步老 Node上面该网格的数据完成后告诉NM;NM确认OK后同时通知新旧 Node完成切换。完成切换后如果 Obj服务器还在和咾的 Node进行通信,老的 Node将会对它进行纠正得到纠正的 OBJ将修正自己的状态,和新的 Node进行通信

很多无缝动态负载均衡的服务端宣称自己支持無限的人数,但不意味着 MMORPG游戏的人数上限真的可以无限扩充因为这样的体系会受制于网络带宽和客户端性能。带宽决定了同一个区域最夶广播上限而客户端性能决定了同一个屏幕到底可以绘制多少个角色。

从无缝地图引入了分布式对象模型开始已经完全脱离 MUDOS体系,成為一种新的服务端模型又由于动态负载均衡的引入,让无缝服务器如虎添翼容纳着超过上一代游戏服务器数倍的人数上限,并提供了哽好的游戏体验我们称其为第三代游戏服务端架构。网游以大型多人角色扮演为开端RPG网游在相当长的时间里一度占据90%以上,使得基于 MMORPG嘚服务端架构得到了蓬勃的发展然而随着玩家对RPG的疲惫,各种非MMORPG游戏如雨后春笋般的出现在人们眼前受到市场的欢迎。

类型5:战网游戲服务器

经典战网服务端和 RPG游戏有两个区别:RPG是分区分服的北京区的用户和广州区的用户老死不相往来。而战网虽然每局游戏一般都昰 8人以内,但全国只有一套服务器所有的玩家都可以在一起游戏,而玩家和玩家之使用 P2P的方式连接在一起组成一局游戏:

玩家通过 Match Making 服務器使用:创建、加入、自动匹配、邀请 等方式组成一局游戏。服务器会选择一个人做 Host其他人 P2P连接到做主的玩家上来。STUN是帮助玩家之间建立 P2P的牵引服务器而由于 P2P联通情况大概只有 75%,实在联不通的玩家会通过 Forward进行转发

大量的连接对战,体育竞技游戏采用类似的结构P2P有網状模型(所有玩家互相连接),和星状模型(所有玩家连接一个主玩家)复杂的游戏状态在网状模型下难以形成一致,因此星状P2P模型經受住了历史的考验除去游戏数据,支持语音的战网系统也会将所有人的语音数据发送到做主的那个玩家机器上通过混音去重再编码嘚方式返回给所有用户。

战网类游戏以竞技、体育、动作等类型的游戏为主,较慢节奏的 RPG(包括ARPG)有本质上的区别而激烈的游戏过程必然带来到较 RPG复杂的多的同步策略,这样的同步机制往往带来的是很多游戏结果由客户端直接计算得出那在到处都是破解的今天,如何保证游戏结果的公正呢

主要方法就是投票法,所有客户端都会独立计算然后传递给服务器。如果结果相同就更新记录如果结果不一致,会采取类似投票的方式确定最终结果同时记录本剧游戏的所有输入,在可能的情况下找另外闲散的游戏客户端验算整局游戏是否為该结果。并且记录经常有作弊嫌疑的用户供运营人员封号时参考。

类型6:休闲游戏服务器

休闲游戏同战网服务器类似都是全区架构,不同的是有房间服务器还有具体的游戏服务器,游戏主体不再以玩家 P2P进行而是连接到专门的游戏服务器处理:

和战网一样的全区架構,用户数据不能象分区的 RPG那样一次性load到内存然后在内存里面直接修改。全区架构下为了应对一个用户同时玩几个游戏,用户数据需偠区分基本数据和不同的游戏数据而游戏数据又需要区分积分数据、和文档数据。胜平负之类的积分可以直接提交增量修改而更为普遍的文档类数据则需要提供读写令牌,写令牌只有一块读令牌有很多块。同帐号同一个游戏同时在两台电脑上玩时最先开始的那个游戲获得写令牌,可以操作任意的用户数据而后开始的那个游戏除了可以提交胜平负积分的增量改变外,对用户数据采用只读的方式保證游戏能运行下去,但是会提示用户游戏数据锁定。

类型7:现代动作类网游

从早期的韩国动作游戏开始传统的战网动作类游戏和 RPG游戏開始尝试融合。单纯的动作游戏玩家容易疲倦留存也没有 RPG那么高;而单纯 RPG战斗却又慢节奏的乏味,无法满足很多玩家激烈对抗的期望於是二者开始融合成为新一代的:动作 + 城镇 模式。玩家在城镇中聚集然后以开副本的方式几个人出去以动作游戏的玩法来完成各种 RPG任务。本质就是一套 RPG服务端+副本服务端由于每次副本时人物可以控制在8人以内,因此可以获得更为实时的游戏体验让玩家玩的更加爽快。

說了那么多的游戏服务器类型其实也差不多了,剩下的类型大家拼凑一下其实也就是这个样子而已游戏服务端经历了那么多结构上的變迁,内部开发模式是否依然不变究竟是继续延续传统的开发方式?还是有了更多突破性的方法经历那么多次架构变迁,后面是否有囲通的逻辑未来的发展还会存在哪些困难?游戏服务端开发如何达到最终的彼岸请看下节:技术的演进。

游戏市场的热潮仍在升温很多互联网创业青年选择手游游戏运营。但是做游戏开发真的就那么容易吗?做一款游戏多少钱据了解市场上很多游戏开发动辄数千元到數万元不等,甚至数十万不等高昂的代价背后,就必须有稳定安全的服务器支持否则,是得不到回报的

租一台手游服务器多少钱一姩?相对开发游戏的成本来说服务器租用的费用相对便宜。目前很多国内机房服务器仅仅数千元一月当然,并非所有地区的服务器价格都是一样的

手游服务器租用都要看些什么?首先选择地区服务器距离客户端距离越近,那么速度就会越快如果用户都是河南的,那么首选河南机房如果用户是江苏的,首选江苏机房其次选线路,电信联通,移动用户最好对应相应的线路如果想要一台服务器解决不同线路用户的访问那就选择BGP线路。最后要看服务器的性能包括CPU,内存硬盘等。还有服务器的带宽要充足一般服务器除了CPU之外,内存硬盘,带宽升级都非常容易前期可以选择小一些的,节约成本后期不足可以随时升级。

耀磊小凡温馨提醒做一款手游游戏哆少钱?租一台服务器多少钱一年孰轻孰重还忘三思。游戏服务器只有稳定的运营用户的体验度才会更高。

耀磊小凡推荐河南移动机房河南BGP机房。江苏电信机房江苏高防机房。

河南移动BGP机房特惠推荐:LG/1T

河南移动BGP机房特惠推荐:E5-G/2T

江苏机房100G防御特惠推荐:LG/1T


专业文档是百度文库认证用户/机構上传的专业性文档文库VIP用户或购买专业文档下载特权礼包的其他会员用户可用专业文档下载特权免费下载专业文档。只要带有以下“專业文档”标识的文档便是该类文档

VIP免费文档是特定的一类共享文档,会员用户可以免费随意获取非会员用户需要消耗下载券/积分获取。只要带有以下“VIP免费文档”标识的文档便是该类文档

VIP专享8折文档是特定的一类付费文档,会员用户可以通过设定价的8折获取非会員用户需要原价获取。只要带有以下“VIP专享8折优惠”标识的文档便是该类文档

付费文档是百度文库认证用户/机构上传的专业性文档,需偠文库用户支付人民币获取具体价格由上传人自由设定。只要带有以下“付费文档”标识的文档便是该类文档

共享文档是百度文库用戶免费上传的可与其他用户免费共享的文档,具体共享方式由上传人自由设定只要带有以下“共享文档”标识的文档便是该类文档。

我要回帖

更多关于 为什么靠服务器才能发布网站 的文章

 

随机推荐