引子
经常有网友问我：我很喜欢玩游戏，可以从事游戏开发吗？开发游戏需要哪些技能？一款游戏的开发需要哪些人员参与？诸如此类的问题比比皆是。作者以10年游戏行业的从业经验做背书，为打算入坑游戏开发的朋友们答疑解惑。
开发团队构成
首先要明确的一个概念就是网络游戏（或者叫在线游戏）其实也是一种互联网产品，因此，游戏的开发团队也就具有互联网产品开发团队的基本特征。比如，技术上分前后端，有产品经理，有美工等等。早期我在开发社交游戏的时候，团队组成和其他非游戏产品的团队几乎没有区别，因为这种需要嵌入在网页中的游戏和做一个功能性网页需要的人力和技术栈很类似。之后的十多年，网络游戏的复杂性和规模也越来越接近于大型的单机游戏，所以团队形式也从之前类互联网产品团队演变成为了制作人体制。
制作人体制
制作人简单来说就是全面掌握游戏设计、开发和运营的总负责人。你可以认为这个角色就是电影行业的导演+制片人。制作人体制，就是以制作人为核心打造的满足游戏开发的职能组织结构。在制作人体制下不同职能的员工都要汇报给制作人（这一点和互联网产品团队的汇报路线有所不同。比如我是开发人员，应该汇报给技术线的负责人例如技术总监，而不是产品的负责人）。
我们用一个图例来说明一下制作人体制下的团队层级关系。
团队职能划分
首先你需要知道：一个游戏的最小核心职能成员只有3个：策划，美术，程序。因为游戏开发的几乎全部实体产出都是由这3个成员完成的。换句话说，组建一个最小的游戏开发团队只需要3个人。甚至说，有同时具备以上技能于一身的人的话，他1个人就行。这样的案例并不是没有，比如大名鼎鼎的《minecraft》，或者是我非常喜欢的夫妻档开发的《battle heart》，以及许多在taptap上很成功的独立游戏。
策划（designer）
策划其实就是产品经理，主要工作是设计游戏的背景、故事情节，功能模块等，并一一文档化。其中，内容（系统）策划一般做功能设计、故事情节等，类似电影制作里的编剧；而数值策划是游戏这种互联网产品特有的一种职能，游戏中有大量的数据化的工作，比如经济系统，角色成长系统，都需要有一定数学功底的人进行设计。其设计结果的合理性决定了游戏的一个要素：平衡性。平衡性对游戏的品质和生命周期都有很大影响。星际争霸能畅销20年，和其完美的平衡性有很大关系。有些游戏还设置了关卡策划，比如三消类游戏，不再赘述。
不客气的讲，策划谁都能做，因为这个工种是一个几乎不需要特定专业技能的工种（最多需要会excel、word）。一个有经验的游戏玩家，且善于总结和思考，就能够根据自身经验给出一个基本设计。但是话说回来，要想成为一个优秀的策划，难度非常大，对人员素质也有很高要求：创造性，合理性，完整性，平衡性，其工作内容是思维的产物，且极难量化。毫不夸张的说，一个游戏的成功与否，和策划团队的能力有最直接的关系。
我个人认为国内游戏行业优秀的策划人员非常少，这也就是我们很少能看到令人惊艳的国产作品的原因。
策划人员通常是美术和程序共同的敌人，需求变更会导致其他人做无用功或者无休止的加班。一个功能自己都没想明白就让程序去开发，改来改去成了家常便饭。所以不合格的策划特别不受码农的待见。
美术（artist）
美术主要的工作是对游戏内容进行包装和艺术化。根据游戏类型的不同，一般分为原画、2d、3d、动画等。原画美术主要负责过场画面，为3d提供原型，角色设计等。一个游戏推向市场时各种炫酷的海报等都是来源于原画。2d主要负责界面的总体风格和布局设计，游戏中道具、武器等部件的绘制。3d顾名思义，就是做3d场景、角色。动画一般是做游戏中需要的动态效果、特效，属于锦上添花，比如技能释放时的动画，角色战斗中的动态等等。
在早期，功能比较单一的小游戏或者社交游戏，团队里通常没有固定的美术人员，而是由统一的美术部门进行支持。比如互联网公司的美工需要负责页面的设计，游戏部门有需要就调派美工进行支持。对复杂的游戏来说，美术的工作量是非常大的，而其产出又是阶段性的，完成后不需要维护，所以养一个庞大的美术团队成本上不划算。因此，美术外包是业界比较流行的做法。也有美术团队作为独立部门存在的情况，会同时负责多个游戏，进组干活，完成后再去其他组。
美术是促成游戏成功的另一个主要因素。优秀的美术风格甚至有扭转乾坤的能力。比如我之前参与开发的卡牌游戏《灵异阴阳录》，有大量的忠实玩家是为了收集画师的作品而持续的进行时间和金钱的投入，使得游戏的生命周期也得以延长。
美术人员只和前端程序有交集，和后端程序完全没交集，没有利益冲突，通常情况下都比较融洽。
程序（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本身就是敏捷开发方法，但有时候依然不够快，需要裁剪。
我们先从宏观上了解一下一个游戏从无到有的产生过程。
一开始，制作人会给出一个愿景，定义需要做一个什么类型的游戏，大概的设计思路是什么。这就好比电影导演说想拍一个电影，它主要的故事梗概是什么，风格是什么。接着，策划团队领会了领导精神，开始细化游戏的需求，并文档化。技术团队根据游戏的类型等信息，可以开始技术栈的准备。比如需要做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...