游戏开发入门如何点亮技术树？

经常有知友问我，我很喜欢玩游戏，可以从事游戏开发吗游戏需要哪些技能游戏的开发需要哪些人员参与此类的问题比比皆是。

本场 Chat 老司机带你弯道超车，以 10 年游戏行业的真实背景和经验为实例，为打算入坑游戏开发的朋友们答疑解惑。你可以学习到：

1. 游戏开发团队结构
2. 开发人员技能树及侧重点
3. 常见的开发流程和工具
4. 游戏类型及架构选型
5. 经验教训与建议

引子

开发团队构成

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

制作人体制

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

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

策划（Designer）

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

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

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

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

美术（Artist）

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

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

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

程序（Programmer）

码农大家都很熟悉了。现在绝大部分游戏都要联 ，所以有前后端之分。前端主要负责页面端、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 还不了解的读者可以阅读官方文档）。为什么是裁剪过的游戏这种产品对变更和故障的响应速度要求很高，很多时候需要跳过各种繁文琐节，快速处理问题。尽管 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 & WIKI

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

Jenkins

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

Gmail & Gtalk & Google Doc

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

程序开发人员技能树

前端开发（Frontend）

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

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

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

服务器端架构选型

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

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

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

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

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

按通讯方式划分

短连接通讯

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

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

长连接通讯

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

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

混合型

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

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

按 络模式划分

全球同服

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

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

分区分服

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

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

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

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

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

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

代码安全

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

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

文章知识点与官方知识档案匹配，可进一步学习相关知识C技能树首页概览114982 人正在系统学习中 相关资源：Wikka高速可伸缩性软件v1.3.1-其它代码类资源-CSDN文库