游戏设计（46）

10:32:44 上传
　　文/曹政
　　几个月前在上海，去拜访了一个特别成功的游戏制作人， 他问了我挺尖锐的一个问题，说你看这些游戏开发团队，有些技术好，有些技术不好，但游戏做出来都差不多，技术好和不好，对游戏公司来说，究竟差别是什么？
　　这个问题问的特别好，我觉得我回答的更好，分享一下，游戏公司，技术好与不好的典型差异就是，发行能不能更轻松。
　　那么，我们回过头来看一下，就会发现，所有的技术问题，最终都会体现在发行上。既包括自己发行，也包括合作发行。
　　典型技术问题如下
　　1、安全性你安全不好，被盗号，外挂横行，代码泄露，私服横行，发行哭了吧。
　　2、负载支撑能力你性能不行，扛不住用户量，发行哈皮的做一个推广运营活动，然后服务器崩了，哭不哭。
　　3、数据压缩和文件大小控制你游戏 300M，和你玩法类似，目标用户群相同的产品，包体 100M，但是在视觉效果上和你没啥差距，你觉得这有啥，流量值几个钱，这还真不是流量值几个钱的问题，这直接影响了用户的转化率和买入成本，竞争对手单位用户转化效率比你高 30%，同样游戏人家就可以多 30%的 CPM 采购单价砸你，你以为你会少 30%的流量？你运营会少 90%的流量，因为竞价硬拼不过！
　　4、热更新支持，活动平台方案配置支持。人家游戏随时跟随热点搞活动，你这边，运营计划出来了，技术人员说，等等啊，等我更新一个版本啊，等苹果审核啊，发行哭不哭。
　　5、开服合服支持发行商开新服，旧服合并，好的技术架构，运营人员设置时间，然后到时间自动开启，技术人员不用过问，全程自动化；坏的技术架构，运营人员，商务，烧香祈求这次开服顺利，合服愉快； 运维和研发半夜停服做数据处理，代码迁移，然后烧香祈求一次上线顺利不出 bug。
　　6、联运和多平台发布支持好的技术架构，快速发布更新不同的联运版本，甚至通过一些第三方的跟踪模块实现单一版本的多渠道跟踪和转化分析。
　　坏的技术架构就疲于应付，接一个合作商，技术负责人埋怨，等等啊，我们最近四五个不同版本发布，人手不够，忙不过来啊啊啊啊。很多推广资源就此错过时机。
　　7、多语言支持，多时区支持
　　简单一句，全球手游巨头，SuperCell，所有产品天然多语言版本，欧美巨头很多产品都是这样设计，图片和文字严格分开，语言包单独独立扩展，非常好的结构。
　　中国绝大部分游戏都是把文字弄到图片里，很多设计师自以为这样很好看，那么做海外发行的时候就头大的厉害，多语言你要不要？泰文你做不做？印尼文你做不做？越南文你做不做？西班牙文你做不做，葡萄牙文你做不做？ 进入新市场的成本就高。
　　当年成都有个小团队好像叫游魂，做了一款帝国舰队的游戏，其实挺简单的游戏，开发成本也不高，但是人家设计天然多语言版本，几个人的团队，发行到东南亚，台湾，日本，数据反馈都很不错。很多大公司的产品，做多一个语言版本要折腾好久，我看着就是好多地区市场有钱他们都没法赚。
　　8、素材资源独立化本土化，本地化运营，需要对当地的一些素材和资源做调整。比如伊斯兰国家，对裸露身体的产品是有限制的，以及对猪的形象也是有限制的。再比如欧美和日韩的画风是非常不同的，如果产品的素材资源可以独立，发行商就可以根据当地特色做本地化的图形素材匹配，发行工作就可以更容易贴近当地市场，而且减少一些运营风险；如果不独立，那么改动的工作量，就是巨大无比了！
　　其他还有，比如对社交分享的支持能力，比如数据分析和用户行为分析能力等等，比如对多种支付方式的支持等等，但这些都可以通过第三方的工具来实现，就不再罗列在内了。
　　简单总结一下，技术，包括研发的架构，运维的架构，其好和坏，最终的市场表现就是，能不能让发行商更轻松，更低成本的发行和运营游戏；可能你说一个游戏的好坏要看美术设计，要看策划，从游戏本身来说，技术好坏并不是那么一目了然；但是对于游戏发行来说，技术好坏往往就决定了发行的难易程度和成本。而这对游戏的持续盈利能力，显然是有非常直接的相关作用。
　　我前几天给合作方分享，我也强调，说是不是今天分享完，大家技术就提升了，这个做不到，毕竟只是一些简单的概念，但是我希望每个技术负责人，每个技术的管理者，有这个意识和目标，你的工作任务，你的技术选型，你的技术架构，你的技术优劣，直接对发行产生影响，你做的好，发行工作很轻松，产品就容易推；你做的不好，发行就很辛苦，其实到最后技术自己也很辛苦，因为你也疲于应付发行的各种需求。 把这个意识贯彻下去，到具体的研发和运维中，能够真正去理解发行的问题和困扰，然后作为技术的重点方向，很多问题其实都并不是很难解决；
　　我们所遇到的大部分技术问题，并不是这个技术有多难，而是技术人员压根就没望这个方向考虑过。
via：caoz的梦呓
相关阅读：
声明：游资网登载此文出于传递信息之目的，绝不意味着游资网赞同其观点或证实其描述。
扫一扫获取行业消息
扫一扫获取最新产品信息
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1590479次
积分：16371
积分：16371
排名：第677名
原创：44篇
转载：570篇
评论：207条
本博收藏大部分文章为转载，并在文章开头给出了原创作者及原文出处，如有再转，敬请保留相关信息，这是大家对原创作者劳动成果的自觉尊重！！
早期遗留的部分文章未能及时给出相关原创信息，在此谨致歉意，后续会尽全力予以纠正。如为您带来不便，请于本博下留言，谢谢配合。
(5)(1)(6)(4)(1)(7)(2)(18)(17)(17)(5)(3)(8)(11)(8)(6)(11)(3)(1)(13)(16)(10)(8)(15)(12)(4)(8)(3)(5)(1)(1)(1)(4)(2)(1)(4)(5)(3)(9)(18)(5)(1)(2)(2)(9)(3)(4)(1)(4)(3)(2)(1)(2)(1)(1)(6)(14)(1)(22)(4)(1)(13)(7)(9)(7)(4)(26)(10)(22)(9)(15)(12)(11)(1)(4)(3)(4)(1)(10)(7)(3)(12)(17)(1)(9)(17)(18)
(window.slotbydup = window.slotbydup || []).push({
id: '4740887',
container: s,
size: '250,250',
display: 'inlay-fix'后使用快捷导航没有帐号？
　论坛入口：
　　|　　　|　　　　|　　　|　
web服务端和游戏服务端的区别
04.jpg (227.95 KB, 下载次数: 31)
11:15 上传
　　最近几天在技术交流群里讨论到游戏服务端的一些技术细节，小说君发现有些做服务端的同学因为没有接触过游戏服务端，所以对游戏服务端产生了一些误解。因此今天的文章就从web服务端和游戏服务端的区别说起，简单介绍下游戏服务端。
　　首先下个定义，我们讨论的「服务端」是什么？引用一下wiki对Server的定义：
　　In computing, a server is a computer program or a device that provides functionality for other programs or devices, called &clients&. This architecture is called the client–server model, and a single overall computation is distributed across multiple processes or devices.
　　说得比较笼统，client-server模型，分布式提供服务等等，这点对于服务端程序员来说就是日常工作。
　　然后是wiki对Server的分类：
　　Typical servers are database servers, file servers, mail servers, print servers, web servers, game servers, and application servers.
　　其他几种Server我们都比较清楚了，跟unix差不多同时诞生。另外三种，则是程序员日常开发所接触的Server类型，为了确定下文章接下来的讨论范围，我们不妨先给三种Server划定下范围。
　　Web Server，典型例子是淘宝。
　　特点：所有流程均由客户端发起，客户端发个请求，服务端返回个响应。而且，根据客户端访问的服务不同，客户端可以向不同的具体服务端节点发起请求。
　　Game Server，典型例子是魔兽世界。
　　特点：有一个肉眼能感觉到的连接握手的过程，建立连接后，流程有可能是服务端发起（比如给你展示周边玩家），也有可能是客户端发起（比如你移动了一下）。
　　同时，如果你手边有抓包工具，可以看到，如果你选中了某个玩家，在该玩家的头像框消失之前，一直是同一个场景服务器在跟你通信。
　　Application Server，典型例子是QQ。
　　特点：介于Web Server和Game Server之间，看着像一个web服务器，但是又有游戏服务器的特点。
　　接下来正文的对比部分，Web Server就特指第一类，Game Server就特指第二类，App Server不再拿来参与对比。
　　对比之前，小说君先概述下服务端在client-server模型中的扮演角色。
　　服务端，在物理上表现为一或多台主机，在逻辑上向客户端暴露一组host:port二元组，接受客户端连接，为每个客户端连接维持连接会话（Session）。客户端与服务端借助连接会话传递消息，消息按一定的协议序列化与反序列化，客户端与服务端的逻辑模块由消息的内容驱动运转。
　　不论是Web Server，还是Game Server，在运作流程上都大体相同。而在流程中的细节上，有共同点，也有不同点。下面就分开说道说道。
　　首先是共同点。
　　共同点1：都是为客户端提供多种服务。
　　比如淘宝既提供搜索服务，又提供商品页查询服务。
　　魔兽世界既提供登录服务，又提供让你在场景里战斗、走跑跳的服务。
　　共同点2：都需要连接会话的概念。
　　会话是建立在连接之上的概念，其实本质上是服务端为某个特定客户端维持的数据结构与状态信息。
　　游戏自不必说，玩家登录之后，服务端需要有一个专门的全局服务器维护玩家状态与玩家的部分较热的存档信息，玩家进入到某个场景，场景服务器还需要专门维护一份玩家的场景相关的状态信息。
　　而对于Web Server，连接会话同样存在，最直观的理解是淘宝登录之后服务端会为客户端保持一个会话上下文。
　　共同点3：服务端的每台物理机服务多个客户端。
　　这是服务器的诞生基础，发展到现在，已经没人再讨论是异步IO还是多路复用，现在成熟的解决方案已经不存在孰优孰劣的问题，完全是哪个网络库用的顺手就默认接受这个网络库底层的IO模型。
　　共同点4：都具有分布式结构。
　　架构的演化总是相似的，Web服务端与游戏服务端在发展过程中相互学习相互演进，目前形成的主流架构基本都了解至少应该将专门管连接的、专门管逻辑、专门管存储的做一定程度的物理隔绝。
　　可以像skynet一样，利用luaState做隔绝；可以像Erlang一样，利用actor做隔绝；也可以最简单的，按进程隔绝。只要能保证其中之一挂掉不会产生连锁反应导致其他都挂掉就可以了。
　　共同点5：开发语言。
　　实际上也是近几年手游开发火起来之后开发语言才趋于统一的。web开发一直是百家争鸣，而游戏开发在以前是C++一家独大。
　　但是现在，客户端的逻辑层已经基本见不到C++的影子了，服务端纯用C++的也越来越少了。lua、python、java、C#、Erlang、js甚至ruby的工业级游戏服务端框架都有出现，web服务端和游戏服务端的开发语言已经趋同。
　　然后是不同点。
　　不同点1：会话的存在形式。
　　这一点是web服务端与游戏服务端最本质的区别。
　　web服务端的客户端与客户端之间交互非常有限，因此，服务端可以将会话保存在外部存储服务，比如一些缓存中间件、文件系统中间件，然后等再用到的时候再拿出来就可以了。
　　而游戏服务端的客户端与客户端之间交互非常频繁，比如，同场景的其他玩家会不停做不规律移动，战斗时一个技能就会对复数个玩家造成影响。
　　这时如果将会话状态保存在外部，会造成频繁的状态存取，严重影响服务器吞吐量。因此对于游戏服务端来说，会话通常保存在进程内。
　　不同点2：交互频率与数据流向。
　　web服务端的频率低，而且数据的流动是由客户端驱动的，流向通常是客户端请求了，服务端才返回。
　　而游戏服务端的频率高，数据的流动一部分由客户端驱动，一部分由服务端驱动。流向除了服务端对客户端请求的响应，还有服务端的主动推送。
　　不同点3：通信协议基础。
　　通信协议基础就是客户端和服务端通信的协议所依赖的协议基础。
　　按常识理解的话，web通信的基础在应用层是http协议。由于小说君对web开发并不太熟悉，所以不太清楚目前私有协议在web开发中的应用，但是想必即使是私有协议，也一定是套在http协议的某些字段里面的，这跟游戏的客户端服务端通信有本质区别。
　　游戏通常会实现私有的序列化协议，可以简单理解为应用层定义协议包结构平铺成字节流或者是串行序列化字节流。如果要支持一定程度的协议版本兼容，会用二进制json或者protobuf来实现协议序列化，但是通信协议本身是没有「基础」可言的，纯私有化协议，不具普适性，也没有必要定义成一种专门的协议。
　　不同点4：对第三方组件的依赖程度。
　　web服务端发展速度快，从业者多，同技术栈的从业者交流更深入更频繁。因此，web服务端出现、并且还会出现越来越多的第三方独立组件。web服务端的从业者甚至只需要在自己的技术栈不同层次上选择不同的第三方组件，黏合起来，就能形成一整套的解决方案，非常方便。
　　游戏服务端正相反，比较封闭，基本上每个项目组要么是从头到尾重写，要么是从其他项目组拿来整套技术栈直接改改。基本不存在第三方独立组件的情况，在技术开放氛围好些的公司还好，毕竟大家可以复用同一套框架，否则的话，公司内的框架多种多样，各种造轮子出来的，各种空降团队从原来公司带过来的，技术无法复用，团队成员流动更是一大难题。
　　公众号：gamedev101「说给开发游戏的你」新开通，专注日常开发技术分享。
相关阅读：
关注我们官方微信公众号
下载我们官方APP-游戏行
关注手游动态微信公众号
说的什么JB玩意
罗列那么多，那么楼主的结论呢？
AppStore大图推荐，轻策略《月圆之夜》上线对“大逃杀”类游戏总局业务主管部门的基本咪咕发布独代手游《时之扉》全IP实施计划盛大游戏李阳：龙之谷服务器设计没有“棋”的棋牌游戏市场iOS单机探险一年流水400万+,7人成团《城堡
微信扫一扫关注我们→微信加我：[ tourmusic121 ] 这里有，你明白....资源后使用快捷导航没有帐号？
　论坛入口：
　　|　　　|　　　　|　　　|　
游戏服务器技术交流
评论数: 138
Re:游戏服务器技术交流
很有奉献精神,让我等小辈大开眼界. 希望前辈继续无私奉献出自己的经验!感谢前辈
Re:??蚍?掌骷夹g交流
老大 是epoll不是epool ????`??e人喔
Re:游戏服务器技术交流
这个论坛里面做图文混排不方便,建议楼主发表在blog里,方便大家拜读
Re: Re:??蚍?掌骷夹g交流
hamk: Re:??蚍?掌骷夹g交流
老大 是epoll不是epool ????`??e人喔
虚心接受批评&&[em17]
Re:游戏服务器技术交流
服务器方面我有两个问题，可能的话请楼主在后续篇章里解答一下吧：
1。网络协议的设计问题。作为一个外行我一直不清楚这是否有一定的方法和技巧或者规则和约定。就我个人而言，目前我只是掌握了单个数据包的传送和解析，单个数据包在网上的格式是“len-type-data”。但是我发现很多时候，对于一个事务，它在逻辑上是一个整体，但是却需要在服务器和客户端之间有多次的数据往返才能完成，目前我的做法是某一端在处理某个数据包时如果认为需要有进一步的通信就往对方发出一个数据包，但是我发现这样的话在逻辑上是整体的一个事务需要设计多个数据包，而且这个事务的处理流程会分散在多个数据包的处理函数里，这样的代码就很不清晰，维护更新也很麻烦。不知道业内在做的时候有什么方法没有？
2。持续运行的问题。有没有什么办法，使得服务器端有所更新时能尽量减少服务器端需要重新启动的概率？
Re:游戏服务器技术交流
len-type-data　大都是这样，一个业务逻辑要分散在我个消息码中处理，也大都这样，当然你可以用状态机的方式，进入一项业务的时候就是一个状态，这样使得该业务的逻辑只在一个状态中
减少服务器重启，比较好的就是通过脚本了，简单实用，至于ACE的那个配置框架，可以支持组件的热插拔，好像没见人用过，多一事不如少一事，万一插出毛病来了，得不偿失
至于wow最近在国外测试的热重启，还不清楚他采用的什么技术
服务器公共组件实现 -- 消息队列
　　既然说到了消息队列，那我们继续来稍微多聊一点吧。
　　我们所能想到的最简单的消息队列可能就是使用stl的list来实现了，即消息队列内部维护一个list和一个互斥锁，putMessage时将message加入到队列尾，getMessage时从队列头取一个message返回，同时在getMessage和putMessage之前都要求先获取锁资源。
　　实现虽然简单，但功能是绝对满足需求的，只是性能上可能稍稍有些不尽如人意。其最大的问题在频繁的锁竞争上。
　　对于如何减少锁竞争次数的优化方案，Ghost Cheng提出了一种。提供一个队列容器，里面有多个队列，每个队列都可固定存放一定数量的消息。网络IO线程要给逻辑线程投递消息时，会从队列容器中取一个空队列来使用，直到将该队列填满后再放回容器中换另一个空队列。而逻辑线程取消息时是从队列容器中取一个有消息的队列来读取，处理完后清空队列再放回到容器中。
　　这样便使得只有在对队列容器进行操作时才需要加锁，而IO线程和逻辑线程在操作自己当前使用的队列时都不需要加锁，所以锁竞争的机会大大减少了。
　　这里为每个队列设了个最大消息数，看来好像是打算只有当IO线程写满队列时才会将其放回到容器中换另一个队列。那这样有时也会出现IO线程未写满一个队列，而逻辑线程又没有数据可处理的情况，特别是当数据量很少时可能会很容易出现。Ghost Cheng在他的描述中没有讲到如何解决这种问题，但我们可以先来看看另一个方案。
　　这个方案与上一个方案基本类似，只是不再提供队列容器，因为在这个方案中只使用了两个队列，arthur在他的一封邮件中描述了这个方案的实现及部分代码。两个队列，一个给逻辑线程读，一个给IO线程用来写，当逻辑线程读完队列后会将自己的队列与IO线程的队列相调换。所以，这种方案下加锁的次数会比较多一些，IO线程每次写队列时都要加锁，逻辑线程在调换队列时也需要加锁，但逻辑线程在读队列时是不需要加锁的。
　　虽然看起来锁的调用次数是比前一种方案要多很多，但实际上大部分锁调用都是不会引起阻塞的，只有在逻辑线程调换队列的那一瞬间可能会使得某个线程阻塞一下。另外对于锁调用过程本身来说，其开销是完全可以忽略的，我们所不能忍受的仅仅是因为锁调用而引起的阻塞而已。
　　两种方案都是很优秀的优化方案，但也都是有其适用范围的。Ghost Cheng的方案因为提供了多个队列，可以使得多个IO线程可以总工程师的，互不干扰的使用自己的队列，只是还有一个遗留问题我们还不了解其解决方法。arthur的方案很好的解决了上一个方案遗留的问题，但因为只有一个写队列，所以当想要提供多个IO线程时，线程间互斥地写入数据可能会增大竞争的机会，当然，如果只有一个IO线程那将是非常完美的。
服务器公共组件实现 -- 环形缓冲区
　　消息队列锁调用太频繁的问题算是解决了，另一个让人有些苦恼的大概是这太多的内存分配和释放操作了。频繁的内存分配不但增加了系统开销，更使得内存碎片不断增多，非常不利于我们的服务器长期稳定运行。也许我们可以使用内存池，比如SGI STL中附带的小内存分配器。但是对于这种按照严格的先进先出顺序处理的，块大小并不算小的，而且块大小也并不统一的内存分配情况来说，更多使用的是一种叫做环形缓冲区的方案，mangos的网络代码中也有这么一个东西，其原理也是比较简单的。
　　就好比两个人围着一张圆形的桌子在追逐，跑的人被网络IO线程所控制，当写入数据时，这个人就往前跑；追的人就是逻辑线程，会一直往前追直到追上跑的人。如果追上了怎么办？那就是没有数据可读了，先等会儿呗，等跑的人向前跑几步了再追，总不能让游戏没得玩了吧。那要是追的人跑的太慢，跑的人转了一圈过来反追上追的人了呢？那您也先歇会儿吧。要是一直这么反着追，估计您就只能换一个跑的更快的追逐者了，要不这游戏还真没法玩下去。
　　前面我们特别强调了，按照严格的先进先出顺序进行处理，这是环形缓冲区的使用必须遵守的一项要求。也就是，大家都得遵守规定，追的人不能从桌子上跨过去，跑的人当然也不允许反过来跑。至于为什么，不需要多做解释了吧。
　　环形缓冲区是一项很好的技术，不用频繁的分配内存，而且在大多数情况下，内存的反复使用也使得我们能用更少的内存块做更多的事。
　　在网络IO线程中，我们会为每一个连接都准备一个环形缓冲区，用于临时存放接收到的数据，以应付半包及粘包的情况。在解包及解密完成后，我们会将这个数据包复制到逻辑线程消息队列中，如果我们只使用一个队列，那这里也将会是个环形缓冲区，IO线程往里写，逻辑线程在后面读，互相追逐。可要是我们使用了前面介绍的优化方案后，可能这里便不再需要环形缓冲区了，至少我们并不再需要他们是环形的了。因为我们对同一个队列不再会出现同时读和写的情况，每个队列在写满后交给逻辑线程去读，逻辑线程读完后清空队列再交给IO线程去写，一段固定大小的缓冲区即可。没关系，这么好的技术，在别的地方一定也会用到的。
Re: 游戏服务器技术交流
　　对于如何减少锁竞争次数的优化方案，Ghost Cheng提出了一种。提供一个队列容器，里面有多个队列，每个队列都可固定存放一定数量的消息。网络IO线程要给逻辑线程投递消息时，会从队列容器中取一个空队列来使用，直到将该队列填满后再放回容器中换另一个空队列。而逻辑线程取消息时是从队列容器中取一个有消息的队列来读取，处理完后清空队列再放回到容器中。
　　这样便使得只有在对队列容器进行操作时才需要加锁，而IO线程和逻辑线程在操作自己当前使用的队列时都不需要加锁，所以锁竞争的机会大大减少了。
对于第一条，如果网络IO线程长时间填不满一个队列，那么这个队列的消息是不是就无法放回容器中？假设你的网络线程和逻辑线程的处理能力是一样的，那么实际上每次网络线程在处理消息的时候，逻辑线程总是取不到有消息的队列。
锁碰撞的机会并不取决于你加锁的队列有多长，是一个还是十个，而在于你加锁和解锁之间代码执行的时间，尽管你只有一个队列，队列有一百个消息，但是如果只是在其中的几行代码加锁，碰撞的机率依然很小。
对于第二条，你的前提是逻辑线程和网络IO线程本身是各自同步执行的，但实际上就拿网络线程来讲本身就有可能有多个线程在同时处理网络消息，那么他们都会去你所谓的容器中寻找空的队列，这本身就是资源竞争，更不用说其它的逻辑数据了。
我个人认为锁的频繁程度并不是系统所能控制的，但是加锁执行的代码却是可以控制的。
我们可以为长时间处理的代码所需要的资源创建一个副本，当我们复制副本的时候，可以将原信息加锁，复制完成即刻解锁，而不必要在整个处理信息的时间全部加锁。
Re:游戏服务器技术交流
每次取一个空队列出来后就从容器里拿掉，IO线程自己保存着使用，不是每次要写数据都去取队列
至于队列未满不会主动放回容器的问题，逻辑线程可以在容器中所有队列都为空的时候给IO线程发消息，要求所有的IO线程都立即调换队列
AppStore大图推荐，轻策略《月圆之夜》上线对“大逃杀”类游戏总局业务主管部门的基本咪咕发布独代手游《时之扉》全IP实施计划盛大游戏李阳：龙之谷服务器设计没有“棋”的棋牌游戏市场iOS单机探险一年流水400万+,7人成团《城堡
微信扫一扫关注我们→}