经常有网友问我：我很喜欢玩游戏，可以从事游戏开发吗？开发游戏需要哪些技能？一款游戏的开发需要哪些人员参与？诸如此类的问题比比皆是。作者以10年游戏行业的从业经验做背书，为打算入坑游戏开发的朋友们答疑解惑。

首先要明确的一个概念就是网络游戏（或者叫在线游戏）其实也是一种互联网产品，因此，游戏的开发团队也就具有互联网产品开发团队的基本特征。比如，技术上分前后端，有产品经理，有美工等等。早期我在开发社交游戏的时候，团队组成和其他非游戏产品的团队几乎没有区别，因为这种需要嵌入在网页中的游戏和做一个功能性网页需要的人力和技术栈很类似。之后的十多年，网络游戏的复杂性和规模也越来越接近于大型的单机游戏，所以团队形式也从之前类互联网产品团队演变成为了制作人体制。

制作人简单来说就是全面掌握游戏设计、开发和运营的总负责人。你可以认为这个角色就是电影行业的导演+制片人。制作人体制，就是以制作人为核心打造的满足游戏开发的职能组织结构。在制作人体制下不同职能的员工都要汇报给制作人（这一点和互联网产品团队的汇报路线有所不同。比如我是开发人员，应该汇报给技术线的负责人例如技术总监，而不是产品的负责人）。

我们用一个图例来说明一下制作人体制下的团队层级关系。

首先你需要知道：一个游戏的最小核心职能成员只有3个：策划，美术，程序。因为游戏开发的几乎全部实体产出都是由这3个成员完成的。换句话说，组建一个最小的游戏开发团队只需要3个人。甚至说，有同时具备以上技能于一身的人的话，他1个人就行。这样的案例并不是没有，比如大名鼎鼎的《Minecraft》，或者是我非常喜欢的夫妻档开发的《Battle Heart》，以及许多在taptap上很成功的独立游戏。

策划其实就是产品经理，主要工作是设计游戏的背景、故事情节，功能模块等，并一一文档化。其中，内容（系统）策划一般做功能设计、故事情节等，类似电影制作里的编剧；而数值策划是游戏这种互联网产品特有的一种职能，游戏中有大量的数据化的工作，比如经济系统，角色成长系统，都需要有一定数学功底的人进行设计。其设计结果的合理性决定了游戏的一个要素：平衡性。平衡性对游戏的品质和生命周期都有很大影响。星际争霸能畅销20年，和其完美的平衡性有很大关系。有些游戏还设置了关卡策划，比如三消类游戏，不再赘述。

不客气的讲，策划谁都能做，因为这个工种是一个几乎不需要特定专业技能的工种（最多需要会Excel、Word）。一个有经验的游戏玩家，且善于总结和思考，就能够根据自身经验给出一个基本设计。但是话说回来，要想成为一个优秀的策划，难度非常大，对人员素质也有很高要求：创造性，合理性，完整性，平衡性，其工作内容是思维的产物，且极难量化。毫不夸张的说，一个游戏的成功与否，和策划团队的能力有最直接的关系。

我个人认为国内游戏行业优秀的策划人员非常少，这也就是我们很少能看到令人惊艳的国产作品的原因。

策划人员通常是美术和程序共同的敌人，需求变更会导致其他人做无用功或者无休止的加班。一个功能自己都没想明白就让程序去开发，改来改去成了家常便饭。所以不合格的策划特别不受码农的待见。

美术主要的工作是对游戏内容进行包装和艺术化。根据游戏类型的不同，一般分为原画、2D、3D、动画等。原画美术主要负责过场画面，为3D提供原型，角色设计等。一个游戏推向市场时各种炫酷的海报等都是来源于原画。2D主要负责界面的总体风格和布局设计，游戏中道具、武器等部件的绘制。3D顾名思义，就是做3D场景、角色。动画一般是做游戏中需要的动态效果、特效，属于锦上添花，比如技能释放时的动画，角色战斗中的动态等等。

在早期，功能比较单一的小游戏或者社交游戏，团队里通常没有固定的美术人员，而是由统一的美术部门进行支持。比如互联网公司的美工需要负责页面的设计，游戏部门有需要就调派美工进行支持。对复杂的游戏来说，美术的工作量是非常大的，而其产出又是阶段性的，完成后不需要维护，所以养一个庞大的美术团队成本上不划算。因此，美术外包是业界比较流行的做法。也有美术团队作为独立部门存在的情况，会同时负责多个游戏，进组干活，完成后再去其他组。

美术是促成游戏成功的另一个主要因素。优秀的美术风格甚至有扭转乾坤的能力。比如我之前参与开发的卡牌游戏《灵异阴阳录》，有大量的忠实玩家是为了收集画师的作品而持续的进行时间和金钱的投入，使得游戏的生命周期也得以延长。

美术人员只和前端程序有交集，和后端程序完全没交集，没有利益冲突，通常情况下都比较融洽。

码农大家都很熟悉了。现在绝大部分游戏都要联网，所以有前后端之分。前端主要负责页面端、App端的展示逻辑，或者是和展现相关的物理特性处理逻辑，如寻路、碰撞、同步插值计算等等。后端主要负责业务逻辑，但其实无非是对数据进行操作和读写而已。有些逻辑的责任方并不明显，可以选择写在前端或者后端，一般要根据性能、实现难度等情况去判断，保证合理性。

我个人认为，程序的好坏，不能决定游戏的成功，只能决定游戏的失败。代码质量的区别，只有性能、健壮性、扩展性的区别，在功能覆盖点上是一致的。游戏上线初期用户量很小，程序质量的好坏很难被检验，用户完全不知道程序写的是优雅高尚还是狗屎一坨，因为他不能直观的看到。而一旦游戏成功了，DAU全面飙升，程序的重要性才逐渐显现出来。烂代码会导致大量的bug、并发能力弱、游戏响应慢等问题，这些因素一旦超过一个阈值，就会让游戏走向失败，或者加快用户流失率，缩短游戏的生命周期。一个很好的例子就是《我叫MT》在恰当的时间点推出而大获成功，而后才暴露出服务端代码在大用户量时并发处理上的问题，CEO本人居然在微博上告诫玩家不要在高峰时期登录。不去鞭策团队优化性能，而建议玩家改变游戏行为，实在让人贻笑大方。

程序员是整个团队中最苦逼的一群人，班加的最多，黑锅背的也最多，出了问题也是第一个要出来解决的。前端码农通常比后端好一点，游戏打包完成就没什么事了，而上线之后后端的噩梦才刚刚开始。你在地铁上，公交上，马路上，席地而坐处理线上问题的一定是后端码农。尽管后端没法决定游戏成功，但一不小心就能毁掉一个游戏甚至是整个公司，工作风险极大，需要有强大的心理素质。

支持部门的工作职能相对独立，有可能是由多个团队共享的，比如QA，可以为公司多个游戏开发团队进行测试工作，而不仅仅服务于某个团队。支持部门也会根据游戏的复杂程度和团队规模做一些裁剪。不能说这些职能可有可无，但相对比较灵活。

项目经理（Project Manager）：项目经理不管人，管项目，比如进度、成本、质量、各组之间协调等等。不是必须存在，有些公司或团队省略了这个角色，由制作人兼任。

音乐音效（Audio）：这部分其实也是游戏实体的一部分，好的音效锦上添花的作用很明显。一般都是外包。比较大的公司有自己的音效师在各团队间共享。

测试工程师（QA）：测试常驻开发团队的情况有，但比较少，除非是公司就只有一个游戏项目。游戏和其他的互联网产品不同，很难进行完善的自动化测试，大量的功能点需要人肉测试，比如跑地图。另外，因为游戏产品存在大量功能交错和耦合的特点，单个功能点正常的情况下，组合后就容易出现问题。QA是游戏质量保障最重要的环节，我很难想象没有完善测试的游戏在玩家手中会是个什么样子。前阵子腾讯仓促上线的吃鸡游戏就因为bug太多不得不回炉重造，这种例子在以前单机和主机游戏上也时有发生。QA也是比较苦逼的一个工种，每个release前基本上都是连轴转，夜里报bug，白天码农来修，难兄难弟。

运营（LiveOps）：运营活动是让游戏利益最大化的重要手段。没有合理的运营活动，游戏在收入上会停滞不前。页游时期有这样一种运营人员，俗称托，假装是个大R玩家，在游戏初期领跑，等当前服的生态和用户稳定后立即退出。我在做页游运营支持的时候就干过这样的事。运营人员主要的工作是设计活动内容，拉新或者老用户召回等。通常节假日的活动都是收入的高点。而合理的运营行为也是保证游戏留存、降低流失、延长生命周期的重要手段。

另外，数据分析的相关工作一般也划入LiveOps，他们主要是根据已有的BI数据，分析和给出各个指标，比如DAU、首日、7日、30的留存，收入，充值、道具消耗等等，对运营工作和决策提供参考。

运维（TechOps）：很多小公司是没有运维的，反正就是服务器、工具维护，后端码农就兼职干了。国外游戏公司一般会细分出来，让后端更focus在业务逻辑开发上。

市场（BD）：BD的作用也不能小视，谈渠道，谈植入广告，有时候抓住机会就能拯救一个团队。

这里要讲的开发流程不是指搭建开发环境、写代码、提交代码的这个过程，而是指整个团队如何从0开始开发一款游戏需要经历哪些阶段。严格讲这其实算是软件工程方法学的范畴。我们不可能把各种方法学铺开来一一介绍，那样恐怕开个专栏都不够。这里只聚焦在适合游戏开发的软件工程过程。

推荐一种我认为非常适合中大型游戏开发的方法：裁剪过的（对Scrum还不了解的读者可以阅读官方文档）。为什么是裁剪过的？因为游戏这种产品对变更和故障的响应速度要求很高，很多时候需要跳过各种繁文琐节，快速处理问题。尽管Scrum本身就是敏捷开发方法，但有时候依然不够快，需要裁剪。

我们先从宏观上了解一下一个游戏从无到有的产生过程。

一开始，制作人会给出一个愿景，定义需要做一个什么类型的游戏，大概的设计思路是什么。这就好比电影导演说想拍一个电影，它主要的故事梗概是什么，风格是什么。接着，策划团队领会了领导精神，开始细化游戏的需求，并文档化。技术团队根据游戏的类型等信息，可以开始技术栈的准备。比如需要做MMO类型的游戏，那就需要前后端有长连接的通讯方式，并以此来选择和搭建开发框架。前端根据需要选择2d还是3d的引擎。美术团队也可以准备原画了，定义整体UI风格、角色等，3D建模工作也可以开始。

准备工作搞定后，进入具体开发阶段。程序员、美术根据需求文档进行开发、联调、集成等。同时测试团队也可以介入，编写测试用例，demo开发出来后进行简单的测试。测试通过并且bug修复后开发工作算告一段落，可以进行打包和部署并发布。新版本上线后运营团队收集BI数据进行决策分析，上线运营活动、道具、功能等等。

注意，除立项和前期的准备工作外，整个开发周期都是一个迭代过程，每次阶段性发布都有这样的迭代。

接下来我们了解一下，Scrum是如何运行的，以及如何针对游戏项目进行裁剪。

在Scrum方法中，会把所有的需求细化成一个个的backlog，并形成一个总的产品backlog，其实就是任务列表。然后根据需求的优先级，在Planing（就是安排当前阶段做什么事的会议）中把这些任务划分到各个Sprint（开发迭代周期，时间根据情况长短不一，一般是1-2个月）。接着开发团队就可以根据sprint backlog领取任务开始工作。通常每天都有一个daily meeting，每个人讲述自己昨天干了什么今天要干什么，遇到了什么问题，需要什么资源等等。一个Sprint结束时会有一次review，同时还会有一个Retrospective（说白了就是批评与自我批评，表扬与自我表扬，逼逼这个开发周期那些地方做的好，哪些做的不好）。最后增量的发布这一迭代周期的产品，进入下一个迭代周期。

根据团队、项目大小的不同，甚至是人员特性的不同，每个公司都有自己特有的开发流程，完全教条的遵从某种方法学是不可取的，通常都要根据自身情况进行裁剪。

游戏这种需要快速响应变化的2C产品，应尽可能的压缩事务性工作和流程性工作，专注在产品开发本身才是最重要的。

首先，游戏团队不需要遵从Scrum的团队角色构成。游戏开发人员的职能分工相当明确，PO、Master这样的角色没有太大必要。策划专注在需求的细化和准确度上，及时和开发团队沟通即可。其次，减少事务性的工作。task的建立、分配等工作可以交由项目经理并由Lead协助完成；daily meeting可以降低频度，但一周必须至少有一次。程序员不需要编写详细设计文档（也要分情况而定，复杂的功能模块做详细一些的设计很有必要），描述清楚思路，确定设计方案，定义清楚接口就可以。Review是很有必要的一个环节，整个团队坐在一起检验完成情况，需求实现是否偏差、是否有明显bug等等。而Retro环节可以只involve 各team的lead参加，汇总问题即可。

另一个需要注意的是，游戏产品每次迭代更新都需要看到较明显的变化，这就意味着sprint不能设置的过短。否则一是产品变化不明显发布的意义不大且增加更新风险，二是周期缩短后事务性工作会占用更多时间。通常建议一个迭代周期以6-8周比较合适。

这部分推荐的开发流程并不是唯一标准，只是笔者经过多年的积累和实践后，认为比较科学、操作性强、行之有效且能很好的把控进度和质量的一种方法。上面已经解释过，方法千变万化，只有适合自己团队的才是最合理的选择。感兴趣的读者可以去下载一份Valve公司（没错，就是那个大名鼎鼎的开发半条命的公司，也是Steam平台所属的公司），了解一下Valve的开发流程，相信一定会给你耳目一新的感觉。

使用工具可以帮助你高效的完成工作，这里推荐和scrum流程完美匹配的JIRA，以及几个辅助开发和部署的工具。

几乎成了敏捷开发的标配工具，你的公司不使用JIRA进行项目管理你都不好意思和人打招呼。无论是任务分配、项目追踪还是Bug汇报，都和Scrum结合的天衣无缝。加上Confluence做wiki，基本上软件开发周期中需要追踪和文档化的东西都齐活了。

代码管理必备，现在是个码农就没有不会用Git的。Git基本上已经一统天下了，列出SVN的原因是游戏项目中的美术资源，甚至是一些大项目的前端代码，因为占用空间太大的原因并不适合用Git去管理，SVN更加适合。

另外推荐一款Git的可视化工具，用它做命令行的辅助，很多使用场景下简单又高效。

也已经成DevOps的标配了，CI/CD的重要集成工具。使用它可以高效的完成代码的打包部署工作。

是一个代码质量管理工具，能帮助你消除代码中的缺陷和坏味道，保证代码质量并帮你建立良好的编码习惯。

Google的这三个套件并不是必须的，完全可以找到对应的替代品。但当你基于它们进行团队的沟通和信息交流时，你会发现十分的好用，特别是对游戏开发团队。无论邮件，内部的IM，PPT、Word文档的共享，一个链接就能搞定一切，省去了传来传去且版本变化后不一致的问题。墙裂推荐这套工具作为公司的信息交互平台，当然前提是需要科学上网。

也叫客户端开发。随着10多年网络（在线）游戏的变迁，前端技术栈的变化相对后端要更大一些。最早我们做社交游戏的时候是用Flash嵌入在网页中，开发人员主要使用的语言和工具是ActionScript、Flash Air。而页面部分需要掌握HTML、CSS、JavaScript等技术。页游要看载体，大部分还是Flash，一些Mud类的游戏只需要JavaScript做处理就够了。

手游的前端技术就大为不同了。对于2D游戏来说，cocos2d是主要的开发工具。严格讲它是一个游戏引擎，以及围绕它构建的一整套开发环境和工具，并不局限于某种语言。通常使用C++进行iPhone版本的开发，使用Java开发Android版本。

随着3D游戏的普及，Unity3D成为主流引擎替代了cocos的位置。Unity的功能非常强大，几乎可以发布全平台的游戏，也就是所谓的开发一次，发布多次。我参与的一个3D项目就是用Unity同时打包出iPhone和Android版本。U3d主流开发语言是C#。作为一个后端开发，我不得不吐槽几句。Unity确实强大，但启动缓慢，占用内存极大，内嵌的代码编辑器Mono Developer用起来那叫一个蹩脚，不说了，满满的都是泪。

除了这些专属于前端的技术外，计算机基础知识也非常重要，比如算法、设计模式。前端需要和后端进行通讯，网络及协议相关的知识要很熟悉，比如HTTP、socket、web socket、RPC等。另外，部分数据可能需要存储在客户端本地，文件存储的知识也是必须的。前端开发的一大难点要属性能优化了，手游在各个渠道发布的时候通常会对安装包的大小做限制，这就需要你在游戏加载、资源质量上做文章；而游戏过程中帧数高低、效果的渲染导致的CPU占用率问题也是主要要面对的性能问题。

后端又叫服务器端。网络游戏的大部分业务逻辑都是在后端完成，但实际上游戏的成败和后端的关系比较小，因为它离用户最远，几乎对用户透明。一个看不见摸不着的东西自然不会对用户的评判有影响。好的服务器端就是让用户感觉不到它的存在，好像在玩一个单机游戏一样，没有网络延迟，没有卡顿。什么时候服务器端变得不透明了，让用户感觉到了，就是需要优化的时候了。

既然要完成大部分的业务逻辑，首先需要学会一门功能比较完善的综合性语言。在业界主流的后端开发语言是C++和Java。使用C++是因为它高效的网络处理能力和性能。使用Java是因为它的综合实力和低门槛（和C++比）。我个人更偏向于Java作为后端语言，一是生态圈更加成熟完善（Spring可能是所有语言的框架中最完善最流行的，而各种大数据工具也多是基于Java平台）；二是相对纯粹的面向对象能力进行建模也更加容易；三是Netty这样的网络框架也能弥补性能上的不足，使开发人员聚焦于业务。C++太过强大不易掌控，一旦使用不当反而会出现性能问题，对开发人员的要求也更高。除此之外，游戏圈也不乏有其他语言作为后端开发的语言，常见的有PHP、Node.js、Golang等。

既然是服务器端开发，就要和服务器打交道，Linux系统知识、命令、shell这些东西是必备的技能。它能使你的开发工作更加高效和流畅，是语言外最重要的辅助技能。网络和协议也是必须要掌握的，前后端如何通讯是一大主 题，需要根据游戏特性选择合理的通讯方式。一个比较复杂的游戏，一般长短链接是都要具备的，协议方面使用gRPC（protobuf）、Thrift是不错的选择，即高效又简洁。也有自己定义二进制协议的，但维护起来相对麻烦。

除语言外，另一个重要的技能就是持久层知识。本质上，前端的工作就是展示数据，后端的工作就是读写数据。几乎所有的所谓业务逻辑，无非就是读出数据攒一个前端需要的扔过去，或者把用户行为产生的数据保存下来。后端是数据的持有者，如何高效的读写数据就成为后端开发中的重点和难点。所以，对持久层的理解深度就决定了一个后端开发人员水平的高度。首先，要对使用的主要存储有深入的了解，避免出现使用上的低级错误或性能问题。其次，要学会对不同的业务场景使用不同的存储媒介，合理的存储能极大的简化开发难度。比如排行榜这种业务直接使用Redis的zset会比你自己实现高效的多。

后端是数据的生产者，很多数据的消费方都依赖于它，比如BI。掌握一定的大数据处理工具能让你的技术栈更全面。

第三个重要的技能就是应用服务器本身了。后端程序通常都是以webserver为容器部署的，所以你需要对常用的容器非常了解，比如Nginx、Tomcat、Apache等。另外云服务器的相关使用也需要掌握，现在基本上鲜有部署在实体机房的应用，PaaS平台是主流。和国内的云服务提供商相比，AWS有很多自己特有的服务，需要一定的学习曲线。随着Kubernetes的普及，docker容器的知识也是后端人员需要掌握的。

最后说说架构设计能力。一方面是设计模式在功能模块中的使用。游戏的业务场景中有大量可以使用设计模式的地方，用好模式可以事半功倍。另一方面是系统架构的设计。网络游戏必然是一个分布式系统，分布式系统的特性和问题游戏都一样存在。比如弹性设计、性能设计、服务治理、监控等等。这方面的内容是一个巨大的课题就不展开讲了。一个后端开发工程师要想过渡到架构师就必须具有架构设计的能力。

总结一下后端开发人员的技能树：

• 精通一门综合性语言，最好是面向对象语言；
• 持久层知识，深入了解常见的存储系统，比如mysql、mongodb、redis等，学会用合理的存储系统组合降低业务开发复杂度；
• 服务器相关的知识，包括linux系统及命令、webserver、云服务器、容器等；
• 系统架构的设计能力，分布式系统、微服务等。

根据游戏的类型、需求不同，服务器端架构也会不同。我个人认为一个比较完善的服务器端架构需要具备下面的功能：

• 网络通讯及协议：确定游戏使用HTTP短连接还是Socket长连接和前端交互，协议数据格式使用二进制还是JSON；
• 共享数据同步：通过引入分布式缓存等机制实现世界Boss这类功能；
• 通知推送（发布、订阅）能力：任务系统、消息系统等功能需要推送更新；
• 消息队列：通过它实现数据的异步处理能力；
• 定时任务系统：每日任务刷新、日更排行榜、奖励、CD重置等，游戏中大量功能需要定时系统去触发；
• 逻辑分区；根据时区、地区、用户属性等进行分服、合服的能力；
• 后台管理：包括玩家信息查询、运营管理、策划数据管理、发布维护等等；
• 大数据处理：用户行为会产生大量的BI数据，用来进行决策和运营活动，大数据处理能力必不可少。包括日志采集、收集汇总，报表等；
• 灰度发布、A/B Test：游戏中为验证某功能的好坏常常需要进行灰度发布，系统应具有这样的能力；

作为2C的互联网产品，游戏有几个非常重要的特点需要考虑到：

• 可伸缩性：整个系统是弹性的，可伸缩的，且最好能做到自动化。高峰时增加服务器，低谷时减少服务器（AWS的auto scaling可实现这种能力）；
• 安全性：其一是游戏本身的安全性，即防外挂防作弊，玩家触发的数据都要经过后端验证，且设置警戒线，超过警戒线的数据必然是作弊行为；其二是数据安全性，存储的数据应该有备份，且能够快速恢复；
• 性能：高并发情况下容易出现性能瓶颈，而游戏通常的瓶颈都在持久层。分库分表、读写分离、多级缓存等是解决持久层性能的主要手段。当然，大前提是代码不能写的太烂，否则神仙都救不了。

下面介绍几种不同划分方式下的架构模型。

即通过HTTP进行前后端的通讯。前端发送请求，后端把response结果返回给前端。这种模式其实和大部分互联网产品没有本质区别，通讯层比较轻量级，一个逻辑上的webserver就可以搞定，易于维护和扩展。基本上可以满足弱联网游戏的需求。比如社交游戏、部分页游、非实时对战的卡牌游戏等。

短连接的情况下前端获取数据都需要用拉（pull）的方式，所以无法将消息主动从服务器推送（push）给客户端。服务器和客户端之间也无法维持状态。所以，对实时性要求高的游戏，就必须要用长连接的方式了。

即服务器和客户端维持一个连接不中断。通常底层的通讯协议是socket。实时性要求高的游戏都必须用长连接进行通讯，因为前后端需要实时的进行数据交互，数据即可以从前端拉取，也可以从后端推送。比如MMO类型的游戏，或者是有实时对战功能的游戏，比如炉石传说、皇室战争；再或者有数据推送的需求，比如全服的广播等。

看上去长连接的能力更强，但也有缺点。因为服务器要和客户端一直保持连接，对系统资源的消耗更大。一台标准配置的服务器能支撑左右的连接就算很不错了；用户量越大，服务器集群规模远大于短连接架构，成本也越大。另外技术实现上也相对复杂，处理不当比较容易出现性能问题。

一个完善的架构会同时具有长短连接的通讯能力，在对应的场景下使用合适的通讯方式。

值得一提的是，有一些功能是2种连接都可以实现的。比如每日任务，即可以通过长连接的方式主动推送刷新任务到前端；也可以使用短连接方式，当用户进入任务系统界面时发送HTTP请求获取任务列表。这样的例子有很多，使用哪种方式需要考虑实现成本。

顾名思义，游戏只有一个公共的入口，所有进入游戏的玩家都在同一个服，或者说都可以看到、交互。这在早期社交游戏时代是非常普遍的，比如Zynga的CityVille，你就只能通过Facebook这一个入口进入，所有的玩家都可见或产生交互。

随着不同的平台、网络环境的增多，全球同服的概念被弱化了，比如Android和iOS平台下数据是不互通的，再比如中国版本和国际版本也不能互通（原因你懂）。但这种情况本质上也依然算是同服。

分区（zone）一般指的是按照一定属性对数据进行逻辑分离，最常见的就是地区分区，比如暴雪的游戏炉石、星际争霸II，分了台服、国服、美服等；或者根据网络运营商分区，比如电信区、网通区等等。

典型的分服起源于页游时期，同一套游戏程序，不断的部署到新开的服中，服务器之间独立，数据也不互通。通常的策略是一个服的生态较为稳定了，收入也饱和了，没有多少新增就开新服。在同一个渠道的一组服通常服务器物理上也在一起，和分区的部署不一定相同（分区模式要根据地区选择最优的网络节点）。

和全球同服的模式相比，分区分服模式下各个区、服的数据都是隔离的，不可见的，你是一区的老大，我是二区的老大，互不影响。这也就促成了一种所谓“洗用户”的赚钱方式：一服玩家差不多了，开新服，继续拉新赚一波，循环往复，这就是为什么能看到很多页游有上百个服的原因。

举例：一个微服务游戏架构

游戏的业务模块和技术模块相对容易分离，非常适合微服务架构。早在微服务流行前，游戏业界的后端架构已经有了模块化的实践，比如分了登录、游戏服务、场景服务、网关服务、聊天服务等等。下面是我绘制的，并且个人认为比较完整、合理的服务端游戏架构。

• 通讯层：用来和客户端进行通讯，支撑长短连接，长连接使用gRPC方式；
• 业务层：具体的游戏业务逻辑层，每一个模块都是一个服务，在微服务架构中以独立的进程或者集群方式存在。这里列举了一些常用的公共业务，比如登录服务，用户系统，奖励系统，排行榜、战斗系统等等。
• 中间层：也可以叫基础服务层，为实现业务模块提供必要的技术层面的支持。比如HTTP server，socket框架，分区系统，搜索引擎，消息队列，后台任务，定时任务等等；
• 持久层：具体的数据存储，包括本地、分布式缓存，数据库（可以是关系型或NoSQL），CDN等；
• 支撑系统：为整个架构系统提供公共的支持服务，比如负载均衡、访问控制、配置管理、日志、统计、监控服务等。

前端代码打包后就发布到各个渠道了，没有太多后续工作。这里要讲的是后端代码的上线流程。一个比较合理的上线流程应该包括本地环境、开发环境、测试环境、预演环境和生产环境这几个阶段。

• 本地环境（Local）：程序员自己的本地开发环境，主要完成功能的开发和单元测试；
• 开发环境（Development）：通常是给前后端集成、联调使用的，本地环境并不稳定，需要有这样一个中立的环境进行集成，或者是demo演示；
• 测试环境（Testing/QA）：Dev环境主要的使用者是前后端程序员，在集成过程中很可能频繁改动，所以如果测试人员使用Dev机器进行测试的话，很有可能影响测试的准确率。比如本来是正常的功能后端重启的服务而QA并不知情，就出现了一个不存在的bug。所以对于一个有正规测试流程的团队来说，测试环境很有必要。如果是很小规模的团队或者是小的游戏，测试环境也可以和Dev环境合并；
• 预演环境（Staging）：一个在架构上和线上环境完全一致的环境，唯一的不同就是集群规模、机器性能、数据量等。线上的架构都是分布式的，而Dev这样的环境因为便捷性的考虑都是一个all in one的模式，很多在分布式系统中存在的问题没法在Dev环境下测试出来。Staging是上线流程中最后的一环，相当于守门员，不可或缺。
• 线上环境（Producation）：最终的生成环境，交付给用户使用。

保证上线流程的完整性非常重要，它能以一个渐进的方式逐步提高代码质量直到交付阶段，是保证游戏尽可能不出现问题的重要手段。

代码安全一方面是物理上的安全，即代码是否会被泄漏，被人copy走。这方面每个公司都有自己的做法，比如机器没有外网环境，不能使用U盘等（我个人非常唾弃这种缺乏信任的做法）。这里主要讲逻辑上的安全，即团队协同开发模式下代码在进行merge时不会丢失、被覆盖、被删除的问题。

借助Git的分支管理能力可以最大限度的保证代码合并的安全性。下面是我比较推荐的一种分支管理方式。

首先，我们有一个master主线分支，每个开发周期开始，从它checkout出dev分支；负责不同功能模块的程序员基于dev分支再打出自己的feature分支进行开发；有需要集成和依赖时merge回dev分支；整个开发周期的开发任务结束并准备上线时，从dev分支打出release分支，此分支即为线上环境运行的代码，并merge回master。如果遇到了bug需要临时修复，就从master拉出一个hotfix分支，更新后再merge回master。

通过这样一个科学的分支管理方法，基本上就可以避免代码merge上的绝大部分问题。

数据可以说是互联网产品最宝贵的资产，特别是用户产生的数据（UGC）。抛开黑客攻击这种问题不谈，我们只讲如何避免操作失误造成的数据丢失问题。

给大家讲一个真实的例子。2010年左右我还在某SNS网站做社交游戏，我们当时有一款品质非常好的农场类游戏，几千万用户，百万级别的DAU，各方面数据都很稳定。有一次有个新来不久的同事为了做一些验证测试，打算把自己线上的用户金币数进行调整，于是他在mysql终端中写下了这样的代码：

不知道是疏忽了还是当时迷糊了，在没有加where条件的情况下就回车执行了。对于一个千万量级的表来说这样的更新操作是很慢的，由于经验不足他也没有对半天都没响应的情况深究，转头去忙别的事。最终的结果，所有的玩家金币被更新成了一样的数量，游戏的经济系统和生态完全崩溃。更倒霉的是数据库的备份是按周而不是按天，只能回滚到一周前的数据。对于这种数据级的游戏，一周时间在数据上的gap是巨大的。整个团队没合眼花了三天两夜通过log等各种方式进行数据修复，但结果并不理想。从此之后这款游戏的各项数据指标一路下滑，提早的结束了生命周期。

这样严重的事故告诉我们，需要在以下几个方面建立完善的制度和流程：

• 权限管理：服务器和数据库的访问权限需要层层设置，逐步收敛到最终负责人；
• 数据库操作：避免对线上数据的直接操作，如需要可使用从库（slave）替代；重要的写操作需要有人review；
• 备份机制：备份的间隔在容许的范围内尽可能短，主从两台是不够的，master的误操作也会被同步到slave，还需要单独的backup做增量备份（这一点可以参考mongoDB的3台为一组的shard结构）；
• 日志系统：完善日志，对关键数据的变更进行记录（change history），保证数据可追踪。

这部分简单介绍一下游戏的更新、新代码部署上线的问题。早期实体服务器没什么特别，老老实实一台台的更新。云服务器下就有了更多选择，主要有2种：

• 滚动式更新：和实体机时代类似，在当前的实例上进行更新操作，通常要依靠脚本进行。这种方式没有实例切换的风险，实例相对稳定；但如果是热更新的话需要新老代码的兼容，保证请求的幂等性。否则的话要么需要停服维护，要么就没法使用这种方式。
• 替换式更新：即完全启动一套新的实例，运行新的代码，集群建立完成后通过负载均衡进行网络切换，把流量打到新的集群，完成更新后老集群再terminate掉。这种方式需要先准备好一套新的实例，新实例的稳定性也需要多关注。相对滚动更新来说不容易出错或遗漏，也不用考虑兼容的问题。

另外需要注意的是，热更新，即不停服情况下，一定要注意服务的上下兼容问题；如果是停服更新，避免生硬的强行把用户踢下线，应尽可能做的友好，提前通知，快要停服前进行重复间隔性通知。

软件系统出现故障是难免的，本篇最后再介绍一下如何处理故障。

• 重启：重启一般不能根本性的解决问题，但有些情况下确实可以作为一个缓冲之计，为修复争取时间。
• 回滚：包括代码和数据层面的回滚。快速、简单，解决新上线问题的备用方案，但缺点是会给人带来比较大的挫败感。
• 降级：暂停出问题的模块，停止服务并告知用户。我们在LOZ项目中就使用了降级来保证模块可以switch off，效果不错。
• 紧急更新： 大多数正规公司都有繁琐的上线流程。而紧急更新需要勇气和魄力，还需要有强大的自动化部署工具做支持。我个人非常支持这种打破常规的hotfix，这是把事故影响范围降低到最小的最快方法。所谓特殊情况特殊对待，和破坏流程的hotfix可能带来的潜在风险相比，不更新是否会导致产品生命周期结束甚至公司蒙受巨大损失？两相权益取其轻。

• 故障演练：这个不多说了，去搜索一下Netflix的Chaos Monkey你就知道有多牛逼，以及你自己的公司有多low逼。
• 灰度发布：指先小范围的发布，等稳定后再逐步扩大更新范围，减少受影响用户的范围，降低更新风险。有一种是分地区分布，还有一种是AB Test，根据用户属性对不同的用户执行不同的更新策略甚至是不同的业务逻辑。比如要上线一个新道具，对尾号单双数的用户使用不同的价格策略，通过收集到的BI数据分析哪种定价更加合理。这在游戏行业非常常用。

出现故障是需要复盘的，不能解决完了就完了，要对故障进行分析总结。一般的复盘步骤如下：

• 找出问题的根源（Root cause），分析出现原因；
• 总结故障解决步骤，并文档化；
• 提出改进策略，避免同类问题再次发生。

最后说一下故障的惩罚机制。惩罚和故障本身是没有任何因果关系的，对责任人的惩罚也许根本无法弥补公司受到的损失，带来的后果则是大范围的恐慌情绪，进而影响员工的积极性。做事就会犯错，为了不受罚，那我干脆不做事打酱油好了。如果员工都抱着这种心态，恐怕公司也没有存活下去的希望了。所以，对于开发人员，故障并不可怕，只要积极面对，避免同样的错误发生，通过故障不断学习成长才是最重要的。

我们通过一个漫长的篇幅，从游戏的开发团队构成讲起，介绍了开发流程，游戏开发人员所需要的技术知识体系；接着介绍了游戏的服务器端架构的选型，并用一个示例说明；最后一部分是作者10多年游戏行业开发的一些经验分享。相信看到这里，你对游戏开发已经有了一个初步的理解和认识。欢迎随时和我进一步沟通交流，祝想入坑游戏行业的工程师们都能开发出自己喜欢的游戏！

腾讯在2019年底正式引进了任天堂Switch游戏主机，目前在国内的出货量已超100万台，成为国内最大的主机销售商。

根据腾讯Switch官方消息，国行Switch今日上线一款全新的体感游戏——《马力欧网球:王牌》，目前已经在e商店上线，同时在京东、天猫等官方授权店铺也已同步上架，售价299元。

《马力欧网球:王牌》国行版上线 售价299元

据介绍，《马力欧网球:王牌》中汇集了30名来自马力欧系列的经典角色，玩家可以通过手柄的体感操控，来控制这些角色展开针锋相对的网球对决。

游戏最多支持4人同时游玩，不论是本地联机还是联网对战，都可以让大家便利体验多人同乐的游戏乐趣。

玩家可通过体感操控进行网球对战

《马力欧网球:王牌》还拥有“在线锦标赛”线上联网模式的，目前首个赛季已同步开启，赛季每月更新，在赛季期间积累一定分数，就能获得角色的限定服装或配色等奖励。

另外，马力欧限定主机套装国行版近日也同步上线了，该版本以“超级马力欧”为主题，采用马力欧的主题色红X蓝进行特别设计的限定版主机套装，还附赠了马力欧主题的便携包和屏幕保护膜。

马力欧限定版主机套装开启预售 售价2099元

目前马力欧限定版主机套装已在京东、天猫等各大电商平台上线预售，售价2099元，将于2月12日正式发售。

封面图来自于Best Buy和Gamestop官网，版权属于原作者

每到假期，Switch就成为了寒假、春节期间亲朋聚会、活跃气氛的利器，因为任天堂独有的可拆卸手柄Joy-Con可以分享给多人带来的游戏快乐，很适合朋友、家人、亲子间的互动，一起体检游戏的乐趣。聚会，开派对，这些游戏瞬间使气氛燃起来，下面就来一一为大家介绍。

产品特点：无中文、有实体

发布日期：2017年3月3日

售价为$49.99，售价也为$49.99，点击平台名称直达产品页面。

《1 2 Switch》是任天堂游戏公司出版发行的体感游戏。2017年3月3日登陆Nintendo Switch平台为其首发护航，制作人河本浩一。它最大特点是利用NS主机的新功能与设备特性，通过Joy-Con控制器让玩家摆脱屏幕享受游戏乐趣。玩法是双人对战，每人手持Joy-Con手柄一部分，一局游戏的时间大概在3~5分钟。

这是一个含28个体感游戏的合集，最少需两名玩家分别持握Joy-Con的左、右手柄进行对战。在这款游戏中，玩家间的对战不需要像以前一样聚精会神地盯着屏幕，而是盯着对方!玩家需要观察对方的动作并采取行动。 

玩家进入游戏后只需通过左右拨动摇杆就可在主页面切换游戏，每一个都有着极简的规则与场景，只需停在游戏标题画面不进行任何操作约5秒钟，系统会自动播放该游戏的规则介绍视频，也就是此前官方通过其各个渠道放出来的那些真人模特演示， 还有相应的文字说明，基本上只要看过一次之后就能对游戏的玩法和获胜方式了然于胸。

图片来自于Best Buy官网，版权属于原作者

省钱秘籍：可先，（ 新用户注册立享$20的迎新奖励！）通过Extrabux链接去（最高6%的超级返利），（最高0.5%的超级返利）下单，即可获得对应的现金返现。（支持）

另外，全球部分电商都与Extrabux返利网有合作，购物之前先去Extrabux搜索你需购物的网站，通过Extrabux去购物，可以白拿高达30%的现金返还！邀请新人注册并在任一网站成功下单消费的话，还可获得额外$5的奖励返到你的账户中。爱网购的小伙伴们千万别错过~~

产品特点：全区中文、有实体

发布日期：2018年10月5日

《超级马力欧派对》几乎是你这一两年中能够在主机平台上玩到的最佳线下多人同屏游戏了！

《超级马力欧派对》是近两代任系主机上最好的聚会游戏，它继续移除了一些（但不是全部）迟缓的要素，玩家将能体验到一大堆杰出的小游戏。然而Joy-con本身的一些缺陷以及与星星相关的随机性也依旧是个问题。不过它们也很难成为你游戏途中的障碍，因为本次的《超级马力欧派对》——特别是其中的组队模式，在具备竞争性和策略性的同时，也能带来无穷的乐趣。

图片来自于Best Buy官网，版权属于原作者

产品特点：全区中文、有实体

发布日期：2017年4月28日

平台售价为$59.99；平台售价也为$59.99。

本作除了收录所有『马里奥赛车 8』以及追加下载的内容外，还有新角色、对战赛道以及车辆等等，做为系列作收录内容最多的『马里奥赛车』，可说是不愧对豪华版之名。而且，『玛利欧赛车 8 豪华版』当中的「对战模式」更是丰富！虽然与传统的赛车游戏不同，但是卡通的画面，简单的操作，配上热闹的道具互怼，使它成为一款非常轻松的聚会佳作。

但是稍微深入玩下去，就会发现它也具有很强的专业性，典型的易上手，难精通，在赛车游戏凋零的今天，属于难得的佳作。总体来讲是一款游戏性和技术性并存的游戏，这款游戏在switch上可以说是销量很好的游戏之一，在多人聚会的时候，只要水平差距不大，“道具互坑”的派对玩法就能瞬间感受到其乐趣。

图片来自于Best Buy官网，版权属于原作者

产品特点：全区中文、有实体

发布日期：2018年12月7日

平台售价为$59.99；平台售价也为$59.99。

2018年任天堂第一方收关大作，今年的E3直面会上引起了老外们的“集体高潮”，将众多任天堂旗下的当家明星汇集至此，大致风格和前作类似，此系列的特点是不再有传统格斗游戏的“血条”，取而代之的是“伤害百分比”，也不是将对手打倒，最钟目标是将对手打出舞台。

本次游戏收录了系列所有曾出现的角色供玩家使用。它可以说是一款在自身游戏类别里无限接近完美的游戏。游戏最大支持本地8人同屏共斗，各种角色招数充满屏幕聚会游玩相当的热闹。

本作集合了任天堂作品中的众多经典角色，主打爽快、夸张的极限多人派对风格，朋友们联机对战会带来各种的欢乐和热闹，是任天堂游戏爱好者不可错过的一款聚会游戏。同时本作也是游戏史上任系游戏元素最丰富的作品，堪称任天堂游戏博物馆，模式丰富耐肝，游戏系统也绝对值得深入研究，易上手、难精通的特质更容易让身边的朋友加入战局。

图片来自于Best Buy官网，版权属于原作者

产品特点：全区中文、有实体

发布日期：2018年6月22日

《马里奥网球ACE》作为一款网球游戏，除了基本的各种击球以外，还加入了能量槽，技巧接球，狙击，格挡等等设定，十分好玩。如果你的朋友是运动型，爱接触球类，这款游戏无疑是最好的选择。

马力欧网球ACE给人留下的印象更多的是受苦且硬核，无论是其难度较高的故事模式，还是即便在出师后（通关故事模式），同样高手云集的线上模式，不过一旦来到派对游戏的场景下，这个时候马网的娱乐性就体现出来了。和好友们一起挥动球拍，感受双打的乐趣，对于休闲玩家来说，绝对比单打来的快乐得多。

另外一款动感游戏是：，这款不支持多人同时游玩，但是支持可以增加多账户，存档轮流玩，其实在聚会也是可以考虑选择的。

图片来自于Best Buy官网，版权属于原作者

产品特点：全区中文、有实体

发布日期：2019年11月5日

平台售价为为$39.99，和平台售价为$29.99。

《舞力全开2021》是舞力全开系列的最新一作，为了欢庆《舞力全开》系列的十周年，诸多玩家喜爱的游戏特性即将回归《舞力全开2022》，更有超过40首全新歌曲为玩家带来更多兴奋的舞蹈体验。《舞力全开》系列玩家们俗称“尬舞”，Switch的体感模式与之完美匹配，一经推出就是玩家聚会必玩佳作，游戏方式很简单，看着画面上的卡通人物模仿舞蹈的动作，跟着音乐节奏“舞”起来就行了。

系列作品有着丰富的曲库，各种魔性的音乐，简单的操作也可以瞬间让男女老少都能在这款游戏里展现出属于自己的舞姿，这里不求谁跳的最好，只求谁跳的更尬。

图片来自于Best Buy官网，版权属于原作者

产品特点：全区中文、有实体

发布日期：2017年6月16日

《ARMS》是一款由任天堂企划制作本部开发的3D格斗游戏，玩家将在一个固定场景中进行拳击对战，一局游戏可以最多有4名角色一起对战。 《ARMS》中的角色通常都有可以伸缩自如的双臂，并以此作为攻击的主要手段；不过一些角色会因著體質特性，而使用可伸缩的头发或机甲进行战斗。 

游戏最大的亮点就是体感操控的玩法，玩家可以通过Joy-Con的摆动来控制角色的攻击和防守，此款游戏的双人模式的玩法还是想当的丰富，体感出拳体验起来也非常的热闹！

这款游戏拿着手柄按键操作并不会感受到游戏的乐趣，这款游戏的真正精髓是体感操作，左右手各持一个手柄，两人利用体感模式相斗，感受乱拳打死老师傅的快感。游戏还是有一些技巧的，新上手要熟悉一下操作，但是上手之后，手柄的HD震动就会打的非常的带感，还是要注意一定要带好Joy-Con腕带，而且相互打斗的同时要离电视远一点，否则电视就要换新的了。

图片来自于Best Buy官网，版权属于原作者

产品特点：日版中文、有实体

发布日期：2017年5月25日

这也是一款适合聚会暖场的小游戏，内置了《噗哟噗哟》和《俄罗斯方块》两种对战方式，使玩家可以任意选择自己喜爱的方式与朋友对战，支持2-4人本地或者网络联机，游戏规则虽然简单，但实际游玩体验非常紧张刺激。

图片来自于Best Buy官网，版权属于原作者

产品特点：有中文，有实体合集

发布日期：2017年5月25日

《煮糊了》，被很多江湖人称为：胡闹厨房、分手厨房、友尽厨房。《煮糊了2》画风基本没变，游戏难度依然是那个配方。（友情提醒：如果没玩过1的话也没有关系，两者没有剧情间的联系）。

《煮糊了2》这款游戏的玩法就是合起伙来下厨，一个人准备食材，一个人负责做菜，这是一款人越多越好玩的游戏，同样的，这也是一款越混乱越带劲儿的游戏，游戏最多支持4个伙夫在线发盘。

不要在乎它的爱称或者别名，如果你有情侣或者基友想要增近感情，那么一定要试一试这款情感大作。游戏主要需要玩家通过制作餐点、完成订单来获取金币通关，做饭分为切、煮、炸、烤等多种步骤需要玩家协作完成，游戏最大的乐趣是在因为默契不够而使整个任务陷入水深火热的境地，从而发生一些让人啼笑皆非的画面，绝对是增强情侣感情，培养基友情谊的佳作，是相当有趣的本地多人混战烹饪游戏。

图片来自于Best Buy官网，版权属于原作者

产品特点：全区中文、有实体

平台售价为$29.99；平台售价也为$29.99。

《你裁我剪》，又本称为《一起来剪吧》、《你剪我我剪你》，是一款由SFB Games开发并由任天堂发行在任天堂Switch上的益智游戏。玩家在游戏中可使用单个Joy-Con手柄，或使用多个Joy-Con手柄与朋友一起操控角色相互裁剪同伴的形状来解开谜题或达成要求的形状。游戏不仅考验玩家的操作和想象力，还需要玩家之间相互配合，合作解谜。

这款游戏简直是情侣的必备游戏，玩家可以操控两个贱萌贱萌的角色対剪，剪裁成各种形状进行解迷的游戏，Plus版比普通版新增了两个主题和40多个新关卡解谜挑战。游戏操作简单，但又需要一定的合作和交流，通过游玩很容易与妹子共同探讨解迷，相互深入交流，从咖啡馆玩Switch，变成在酒店里玩Switch。

图片来自于Best Buy官网，版权属于原作者

产品特点：全区中文、有实体

发布日期：2018年3月16日

平台售价为$49.99；平台售价也为$59.99。

作为比卡系列的正统续作，优秀的设计和有趣的细节让人十分愉悦，相较于单人游戏，其组队系统可谓本作中最为宝贵、有趣的体验，尽量和志趣相投的小伙伴一起玩吧。可爱的画风对于女性玩家有着足够的吸引力。适合2-4人游玩。

图片来自于Best Buy官网，版权属于原作者

产品特点：日、港版中文，有实体

发布日期：2018年2月11日

平台售价为$49.99；平台售价也为$49.99。

这款游戏是以日本传统乐器“太鼓”为媒介，可以用按键玩，也可以手持Joy-Con模拟鼓槌进行空敲，打出正确的节奏，适合孩子和妹子。外设厂商也推出了外设实体鼓，打起来会更有感觉，游戏还收录了20种不同的供多人游玩的派对游戏，诸如“沙滩排球”、“蜂蜜大作战”、“全垒打好手”、“吸吸荞麦面”等等。每种游戏过关后能解锁更高难度，同一个游戏游玩多次后，能在演奏游戏中解锁新演奏角色。

在这里没有紧张刺激的对抗，玩家们可以招呼亲友一起来玩充满乐趣的聚会模式。适合聚会的音乐节奏游戏并不多，《太鼓达人》是其中的佼佼者。如果你喜欢日式音乐，喜欢音游，喜欢和大家一起玩耍，那么《太鼓达人》就是你最佳的拍档。

图片来自于Best Buy官网，版权属于原作者

产品特点：全区中文，无实体

平台售价为$19.99；平台售价也为$19.99。

《九张羊皮纸》，是一款动作RPG 游戏，四名角色需要进行合作才能击败敌人。讲述的是魔法师学徒经历重重困难，逐渐成长将魔法学院丢失的九张羊皮纸找回的故事。画面确实相当精美，场景设计也颇具艺术性，支持4人协同操作。游戏的特色之一就是“友军伤害”的设定，毫无疑问，这使得游戏瞬间就充满了变数，所以这款游戏真正的恐惧往往不是来自于难啃的BOSS，而是身边不怀好意的队友，如果相较于通关，你更享受陷害队友带来的乐趣，那赶紧下手吧！

这款游戏一个人玩是新手难度，如果多人玩的话，就变成了地狱难度。游戏有“误伤”设定，队友间即可以互相伤害，又可以进行魔法组合，如果你有基友一同玩耍，这是个不错的选择，单人游玩则不太建议。

图片来自于Best Buy官网，版权属于原作者

平台售价为$59.99；平台售价也为$59.99。

《路易吉洋馆3》是一款由Next Level Games开发，并由任天堂于2019年10月31日发行的任天堂Switch专用游戏软件。本作为《路易吉洋馆》系列的第三部作品。

《路易吉洋馆3》在TGA2019上，拿到了年度最佳家庭游戏奖，所以说此游戏的家庭多人游玩的乐趣还是很高的！从一段游乐场的鬼屋体验后，后续的多人模式依旧是大有玩味，无论是剧情模式下，一人控制路易吉，一人控制“傀易吉”的双人合作玩法，还算本地最多支持8人联机的游乐园模式，和支持线上联机“人比鬼还多”的恐怖高塔，《路易吉洋馆3》都给玩家提供一个非常出色的多人打鬼体验，快入手吧，和你的小伙伴感受一场最欢乐的鬼屋冒险！

图片来自于Best Buy官网，版权属于原作者

这是属于70、80后的美好回忆，如今三两好友相聚，一起打打街机，不再在乎一币过关，只想重温那过去的时光。

游戏合集包含7款作品，分别为《三国志》、《名将》、《快打旋风》、《圆桌武士》、《龙王》、《装甲勇士》、《战斗回路》，有数字版，也有实体版。

图片来自于Best Buy官网，版权属于原作者

以上就是本篇所有的内容，更多Switch双人及多人，可前往下面文章查看：

以上图片来源于网络，版权属于原作者；若有侵权，请原作者及时与我们联系，本站将予以删除。