You are here:
火溶CEO王伟峰:Unity3D手机网游开发
GameLook报道 / 11月2日下午，GameLook游戏开放日活动在上海正式举行，此次会议gamelook邀请到2013年多款明星手游产品操盘手现场分享推广、运营、研发经验。同时，北京站GameLook开放日活动即将于11月10日下午在3Wcoffee举行（很抱歉的通知：门票第一天已被抢光）。
在此次活动上，上海火溶网络CEO王伟峰以其第一款3D手游产品《啪啪三国》为例，着重讲解了Unity3D手机网游开发的经验，其中涉及了团队组成、人员要求、常见的Unity3D开发遇到的坑及解决办法。在演讲中，王伟峰也贡献了《啪啪三国》开发过程中总结的各种经验，从优化、插件库、服务器架构、SDK等很多细节进行了讲解。值得一说的是，王伟峰现场演讲十分幽默，冷笑话段子不断爆出，让在场观众在连续的笑声中听完这个特别的技术演讲。
以下是王伟峰现场演讲实录：
王伟峰：非常感动，大家等这么久的时间，就是来听我讲Unity3D的是吧？开个玩笑。
先说点小感慨，我很意外、也很荣幸洪涛（gamelook总编）请我来给大家作技术方面的讲解。提到手游，我自己从事技术这多年，作为藏在符号背后的人是有很多话要讲的，就结合我们产品开发的过程来谈一下我的感受。
我们这个产品可能大家还不太熟悉，就看一下我们的视频吧。
简单介绍一下我的游戏经历，之前做过端游，现在跟两个老家伙一起在做《啪啪三国》。介绍一下我们团队的构成，我们目前为止一共有18个人，其中策划6个，美术3个，程序8个，测试1个。我今天讲技术，可能这些职位是我重点介绍的，一个是引擎程序、服务器程序、和工具程序。我主要以程序为主来讲解。
服务器程序员
它的知识技能和职责，我就不仔细说了，说细了有一点像招聘启示。他的主要职责虽然负责技术，但是也给产品决策和方向提供一些决策。他最主要的考核指标，就是经验很重要，最好主导或参与过一款网络游戏的开发。举个例子比如说两个程序员，一个是刚毕业于西太平洋大学，主攻方向是复杂电子稳定器。另外一个人可能在煤老板手下开发过一款游戏，虽然容量不大但游戏可以承担3000人，我肯定是选跟煤老板干过的人，这是我对服务器程序员的认识。
引擎程序员
说到Unity3D我这里有一个引擎程序员的说法，他要懂3D引擎。你怎么判断这个引擎程序员合格不合格呢？你问他看什么书？他如果说我在看《21天学会Unity3D》这是无法做引擎程序员的。这是一个引擎程序员的书架，看过哪些书呢？《游戏编程精粹》，《GPU精粹》系列，《ShaderX》系列等，哪怕你出去找工作，你跟老板谈我读过这个，也至少看上去象个样，即使没看过，至少眼界得开阔，Unity3D之所以用不好，因为有这么多书要看。如果说你经常上Unity3D学院的网站，这个是不管用的。所以说只看《21天学会Unity3D》是学不会Unity3D的。
引擎程序员我讲讲核心的要点，他首先是要了解3D引擎工作的原理，优化起来有的放矢，出了问题才知道如何救火。如果你开始没有把握好项目的标准的话，一不小心就跳进大坑。这一块做不好的话最要命的是我，比如人物做了50套，如果一旦不行，你们推倒重来，那你这个美术资源就打水漂了。真正找到靠谱的Unity3D的人，那就是“妈妈再也不用担心我用Unity3D做手游了。”
一句话证明你用过Unity3D
普通群众的评价是：Unity3D坑真多。专家会说？创业团队用Unity3D做手游必死。
讲到这儿我想大部分的人就是想听听Unity3D有什么坑。
Unity3D的坑我觉得最严重的坑就是没有懂3D的程序员，把Unity当成Office用。
Unity发展这么多年，已经是很强的引擎了。我就摘出来说一说我们遇到的坑，有点不是特别好用，就是第5条，它有一个多人协作的Asset Server偶尔会有时候不靠谱，我们现在改用SVN来做版本管理。然后有一个坑，就是很多团队很少进行真机测试，屌丝开发商可能连iphone都没有，一旦测试发现游戏根本跑不动。还有就是第10条，在IOS下无法更新C#代码，更新就下100M这不是Unity的错，是IOS的错。我们做《啪啪三国》的时候也是不知道IOS的限制，负责当初应该规划一下做成脚本更新。最后简单说一句，因为现在Windows phone也很热了，要做WP的有要尽早测试。经鉴定Unity是群众喜闻乐见、发家致富的好引擎。
然后是经验分享，“绝密”，我们是怎么做《啪啪三国》的。说之前，我表达一下我对我们两个创业合伙人的感谢，这些都是绝密，一般人是不轻易说的。现在Unity大家用起来是有一定的门槛，但是也许三个月也许半年后，大家熟悉这些工具以后，们团队的价值就体现出来了。我们程序员就是做好后勤。
先说一下我们程序的工作环境，首先是小黑屋，程序员工作环境不能太敞亮了。我们在硬件设施上是不计成本的，比如说右边这个高端大气上档次的巨屏双显，i5CPU+Win7 64，8G内存，SSD固态硬盘。为什么要用这么好？很多程序员招聘的时候都会问，你们公司是不是双显啊？从我们关心生产力的角度来讲，这套“神机”可以大大提高Unity3D的开发效率。Unity3D在整个程序员开发的过程当中，它其实很多的工作是需要很多读盘操作的，你有这么一套神机的配置，程序员的工作效率我估计应该会有5—6倍的提高，这个是实话实说。如果你们还像我们一样高端大气的话，你还应该配一个Macbook Pro的匹配。
然后讲我们效率优化的一般方法。当然我们讲这些方法其实建立在一个方法上，就是你熟读我前面的50本书你就融会贯通了，我说什么你就一目了然了。
第一个排除法，怀疑哪里就屏掉哪里。这是最基础的一个方法，也是最有效的。
第二个就是用数据说话，善用Unity4强大的Profiler工具，我现在感觉有点水平的程序员，依靠Unity4强大的Profiler工具，没有理由做不出一个跑不起来的游戏，因为这里面设计的性能分析和统计是相当详细和相当有作用的，它可以统计你CPU的占用率，又可以统计你每个模块、每个函数，每个执行的时间。还有一个就是说CPU的效益，然后我们知道还有显卡，还有GPU，GPU就是它有一个很直观的图，你渲染了多少三角面。内行人一看就知道了。
最后再强调一点就是真机制测试，经常发布到手机上跑跑，如果是屌丝团队，你没有IPhone手机的话还是赶紧买吧。
说说我们的方法，draw call太高怎么解决。
3D渲染东西，一个人和一百个人是不一样的。你一百个人就要渲染一百次，怎么讲呢？想让效率提高的话，最优先的办法就是看draw call高不高，高的话就降低一下。最快的渲染，就是不渲染。这块就涉及到我们在这个屋子里，屋子外面是看不见的，但是计算机是可以看到的，你就不要渲染出来，或者是我背后有谁，如果有两个人我就把它删掉。还有土办法就是手动配置可见范围列表。
然后第二个就是物体太多，可以考虑将多个物体合成一个，这个可以由美术来做，也可以由程序来做。我原来是一片树林，起码有20多棵树，我们让美术合并一下，把这20多个树合并成一个物体，看起来是一个树林，另外一个就是让程序来做的，你看我们战场西面，因为我们有攻兵，一个队伍有30多人一人射一支箭这就就要300多个，就让程序把所有的动态合并成三个。包括影子，就是动态合并所有的影子。
理解所使用Material的实现原理，不滥用Material。前面有人讲过，Unity跟玩游戏一样的，你发现后面跑不动了，就要有一个明白人给你做一个规划，你有没有这样的效果，如果有的话你要怎么实现。我们用什么样的Shader，是不是还有高低配。给大家看一下，左边这个小菜单是我们自己写的部分材质的效果，上面也是包括人物和效果。
第三个优化方面，就是模型面数太多。
这个从显卡上看是一个人，但是它其实是由三角形组成的。比如说你的人物三角面形特别多？那怎么办？就减。渲染很多兵的时候我们就用右边的这个没腿的，其实做游戏，游戏视觉就是蒙人。
一键搞定所有平台的安装包。因为大家知道你现在渠道接这么多，你出个版本一个键，比如说你有十个渠道，你没有我们那个神机的话，那打包一个渠道就得半小时。这是我们安卓渠道的出包工具，排名不分先后（全场哄笑）。
因为我做了这么多年的技术，我对工具这个东西非常看重的，包括程序员要有利用工具解放自己的手。
服务器的结构
这是一个典型的端游结构，前面一个是连接服务器，它的作用就是说我们游戏是一个长连接的游戏，一台物理机承载服务器承载是有限的，我们是要有很多台，然后后面就是路由服务器，还连接了两台和多台的服务器。后面这个红色的是游戏服务器，再后面就是数据库服务器，提供一个高速的缓冲。选择这种服务器结构原因是易于拓展
第三个就是我们游戏的小秘密，我们这个战场的整个战斗的核心是C++写的。这样的一好处就是一次编写多次运行，更进一步地好处我后面会讲，缺点就是开发速度慢，调试困难。
这是防外挂，防外挂有几个原则，就是只信任服务器，所有玩家数据都存在服务器。战斗结果由服务器进行验证。因为我的战斗模块是C++写的。
然后就是数据分析这块，现在都讲究大数据这一块，其实三、四年前我们就做这样的东西。游戏里面玩家所有的行为，在服务器上都有日志产生，每天程序收集这个海量的数据，然后放在数据库进行分析。
接下来就是疯狂的SDK了，我们现在的情况是IOS10来个，安卓40+，确实挺多，但是这没有什么不好。
但是有两个原则要注意，一个是与游戏代码的关联性小，第二个要方便调试和测试。这样的话，我们接SDK的时候，就用工具，用SDK的程序员就可以了解。同时开发商也可以把SDK交给别人去接，不会产生泄露游戏代码的一个尴尬和担心。事实证明我们安卓渠道的代理商非常给力，我们所有安卓渠道的SDK都是他们帮我们接的。
我想办法就是两个办法，一个是客户端的，从第一个标准接口，然后服务器这块我们引入了一个SDK转接的服务器，我们游戏的接口相当于通过一个桥梁进行对接。我用一个稳定的服务器就够了。能够给工程师测试和调试。这个也能提高工作的效率，他不用整天去熟悉你游戏的关卡。
接下来就是一个插件/库，这是我们用到的第三方的东西，一个是NGUI，这是Unity做UI比较靠谱的，也是没得选择的选择。
第二个和第三个就是Protobuf，这是我们用于客户端和服务器之间传递消息包的一个库，这个库不错比较稳定，的是一个国外吃饱了撑的程序员做的，它支持很多的平台，像安卓、IOS等都有。
接下来是UnityVs，这个东西是Unity代码调试的插件，这个用起来不错，可以远离Unity本身提供的MONO工具。
最后一个是Prime Storekit，这个是搞定正版苹果的支付。你买了之后你这个苹果有多少坑就一一而过了。
我这块的建议就是慎用第三方代码库，可能会给跨平台发布带来麻烦。
再接下来就是我们主角光照，三点式光照方法，我们把它引用到游戏里面，左边的这个角色就是光照模型下来的效果，右边是普通的，大家看一下可以看出区别，左边的更立体。然后是主角的制造，我们这个主角也是花了大价钱，虽然是屌丝公司，但是我们省吃俭用不发工资，我们请了龙将的概念美术给我们做了一个设定，可以看到从原画到3D模型，还原度很高。
然后讲一下我们场景的做法，因为场景是一个基础的效果，做出来干巴巴的，想增加一点模式的话就Unity提供的光照效果。后面就是我们一些场景的欣赏，这是我们的一个小村子，汉献帝最早流浪的地方，这是我们主城荆州城。
最后就是我们的卡片，我们的卡片也都是请高手花的，光这个成本都超过一千多。
最后我就用这张图片来作一个结束，这是我们去年5月我们三个创始人在一个民房里面，三个人三台电脑，三个创始人在做《啪啪三国》的情景。
面对这张照片，我每次看都挺有感慨，什么力量支持三个屌丝，在去年5、6月份的时候，页游还如日中天，那时候还没有人讲手游。包括你跟投资人谈手游，投资人根本不理你。但是那个时候三个人为什么胆子这么大，就敢立项这么一款产品，包括游戏的玩法，包括整个的方式，当时定了就没有改过。是什么支持我们下这样的决定，坚持一年零六个月做下来。我总结就是因为我们一直做游戏，我们是游戏人。源于我们对游戏的热爱和对游戏的敬畏之心，谢谢大家！
& 2016 . All rights reserved.开发者详解：端游及手游服务端的常用架构
招聘信息：
整理自知乎，文/手游页游和端游的服务端本质上没区别，区别的是游戏类型。类型1：卡牌、跑酷等弱交互服务端卡牌跑酷类因为交互弱，玩家和玩家之间不需要实时面对面PK，打一下对方的离线数据，计算下排行榜，买卖下道具即可，所以实现往往使用简单的 HTTP服务器：登录时可以使用非对称加密（RSA, DH），服务器根据客户端uid，当前时间戳还有服务端私钥，计算哈希得到的加密 key 并发送给客户端。之后双方都用 HTTP通信，并用那个key进行RC4加密。客户端收到key和时间戳后保存在内存，用于之后通信，服务端不需要保存 key，因为每次都可以根据客户端传上来的 uid 和 时间戳 以及服务端自己的私钥计算得到。用模仿 TLS的行为，来保证多次 HTTP请求间的客户端身份，并通过时间戳保证同一人两次登录密钥不同。每局开始时，访问一下，请求一下关卡数据，玩完了又提交一下，验算一下是否合法，获得什么奖励，数据库用单台 MySQL或者 MongoDB即可，后端的 Redis做缓存（可选）。如果要实现通知，那么让客户端定时15秒轮询一下服务器，如果有消息就取下来，如果没消息可以逐步放长轮询时间，比如30秒；如果有消息，就缩短轮询时间到10秒，5秒，即便两人聊天，延迟也能自适应。此类服务器用来实现一款三国类策略或者卡牌及酷跑的游戏已经绰绰有余，这类游戏因为逻辑简单，玩家之间交互不强，使用 HTTP来开发的话，开发速度快，调试只需要一个浏览器就可以把逻辑调试清楚了。类型2：第一代游戏服务器 19781978年，英国著名的财经学校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。随着游戏内容的越来越复杂，架构变得越来越吃不消了，各种负载问题慢慢浮上水面，于是有了我们的第二代游戏服务器。类型3：第二代游戏服务器 20032000年后，网游已经脱离最初的文字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进行沟通。数据广播：Node可以给每个用户设置若干 TAG，然后通知 Object Master 按照TAG广播。对象消息：通用消息推送，给某个用户发送数据，直接告诉 OBJ，不需要直接和 GATE打交道。好友聊天：角色之间聊天直接走 OBJ/OBJ MASTER。整个服务器主体分为三层以后，NODE专注场景，OBJ专注玩家对象，GATE专注网络。这样的模型在无缝场景服务器中得到广泛的应用。但是随着时间的推移，负载问题也越来越明显，做个活动，远来不活跃的区域变得十分活跃，靠每周维护来调整还是比较笨重的，于是有了动态负载均衡。动态负载均衡有两种方法，第一种是按照负载，由 Node Master 定时动态移动修改一下各个 Node的边界，而不同的玩家对象按照先前的方法从一台 Node上迁移到另外一台 Node上：图11 动态负载均衡这样 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人以内，因此可以获得更为实时的游戏体验，让玩家玩的更加爽快。说了那么多的游戏服务器类型，其实也差不多了，剩下的类型大家拼凑一下其实也就是这个样子而已。游戏服务端经历了那么多结构上的变迁，内部开发模式是否依然不变？究竟是继续延续传统的开发方式？还是有了更多突破性的方法？经历那么多次架构变迁，后面是否有共通的逻辑？未来的发展还会存在哪些困难？游戏服务端开发如何达到最终的彼岸？请看下节：技术的演进。技术的演进（待续）
微信扫一扫
订阅每日移动开发及APP推广热点资讯公众号：CocoaChina
您还没有登录！请或
点击量16272点击量10875点击量8664点击量8017点击量7488点击量7063点击量6588点击量6497点击量5716
&2016 Chukong Technologies,Inc.
京公网安备89