一、前言

首先，推荐一本书，名为《妙趣横生的游戏制作之旅》，你在本文中看到的大部分名词都能在这本书中一一找到对应解释，这本书能帮助你对整个游戏制作流程有一个初步的认识，这篇文章或许也能算是这本书的读书笔记。

其次，本文面向的群体主要是学生以及准备入门或刚入门的萌新，所以会写的尽量“短小精悍”，希望这篇文章能对你有一定的指导作用，也希望这能够帮助你在游戏行业中更好地施展你的才华。另外这篇文章也会更多的讲到策划部分，一方面因为策划是一个团队中的绝对核心，另一方面程序和美术对项目经历的需求一定程度上要小于策划(但不会提及更专业的内容，这些理论知识去看书可能学到的会更多)。

最后，何为长周期，个人认为对学生而言，3个月及以上即可称作是长周期，如果从目前的一些GameJam类型来分的话，大致就是(假设用1年时间做一款游戏)：

48~72H快速完成玩法原型验证(可以有多个原型，然后挑一款最好玩的原型继续打磨)
1~2周打磨原型(让它有至少5mins的体验流程，并且美术表现不能太差)
3~6周出Demo(至少有1个表现和逻辑称都得上“完整”的关卡可供外部玩家体验)
2~3个月出alpha版本(特性完备)
3~4个月出beta版本(内容完整)
最后1~2个月持续优化迭代并准备正式发布的相关事宜

但是在此之前，如果你是刚入门的策划，那么最好先熟悉一下游戏制作流程，然后在1个月内花上多个1~2周自己solo3款不同类型的游戏出来，了解清楚其中的难点后，再尝试去组队，不然你可能会因为不清楚其中的技术难点和你的队友争吵，最后不欢而散……

二、为什么要熟悉流程？

简而言之，即便一开始不去熟悉流程，后续自己在实践的过程中也会慢慢总结出来，而这些流程大多也是前人总结的，所以……不如先看一下他人的总结，然后自己在实践中慢慢去体悟，甚至打造出一套专属于自己团队的流程。

不过流程不一定要完全遵守。这可能与你的认知相悖，但事实就是，制作游戏是一种创造性的行为，而这种行为难以被约束，就像你没法给一个画家定KPI一样，所以就需要保证一定的“松散性”，流程在这里更多的是用来“保底”，以及让大家知道现在正在做什么，下一步该干什么，或者用来找到现在的工作卡在哪个流程无法继续推进。

三、为什么推荐做长周期的游戏？

如果你想继续深耕游戏行业，制作长周期的游戏大抵是不可避免的，因为制作周期越长，要遇到的问题也会越多(长度有一定上限，临近上限后，遇到的问题就开始大同小异了)，比如制作流程和制作规范，这在短周期的游戏中几乎用不上，设计能力和制作能力需要经年累月的练习，但解决问题的能力可以快速锻炼起来：这也是为什么实习经历比项目经历更吃香的原因之一。因为在实习中你会需要和更多不同角色的人合作，并有机会遇到一些前所未有的问题，而制作长周期游戏会让你离实习经历中需要掌握的技能和经验更近一些，另外如果游戏取得了一些成果，你收获到实习offer的概率也会更大。

当然，项目经历无法替代实习经历，最根本的原因就是：你没法拉着你的同学去做商业化项目(有DAU、付费率、转化率、留存率等指标)，并成功解决商业化项目中独有的问题。如果你做到了，那么恭喜你，你或许已经不需要offer了，因为你已经成功地迈入了创业地段，准备好给其他人发offer并进入市场激情厮杀吧😉。

四、如何开始制作长周期游戏？

在开始之前，最好像前言说的那样，花上不止一个48~72H做多款原型，并且原型越多越好，因为“你做的前十个游戏都是垃圾，所以赶紧做掉吧。”也就是说，

你可以在1~2个月中，用很多个48~72H来验证你的很多个原型是否有足够的拓展深度和广度，并且它还要足够好玩；
挑选出你认为最有潜力的原型，并开始打磨它，直到它有至少5mins的体验流程；
接着优化它的设计和视听表现，再适当地拓展现有的玩法深度，让它看起来足够“完整”，体验足够“丝滑”；
这之后，让它越来越完整吧。

4.1 前十个游戏都是垃圾，这对吗？

对的。

引号中的名言来自《游戏设计艺术》这本书，至于为什么是名言，大抵是因为这句话争议比较大，而争议点大概就是“前十个游戏”和“赶紧做掉”这2个地方。

首先，根据游戏制作时长、游戏类型的不同，这“前十个游戏”的范围就显得尤为模糊，1个月做10个游戏是做，10年做10个游戏也是做，因此重点要放在“赶紧做掉”。

所以对于这句话，我的理解是：在不熟悉游戏基本的制作流程、基础的游戏设计能力不足的前提下，花一段时间制作几款原型，每做完一款后就让自己和其他人体验一下，体验过后收集反馈，再根据自己的体验和反馈，复盘一下这款原型做的好与不好的地方(比如：“我喜欢……我希望……，如果……”)，然后促成一个正循环，以实现对基本制作流程的熟悉和基础设计能力的快速提升……简而言之，就是“尽早失败、快速失败、经常失败”(当然最重要的还是要复盘，否则这些提升免谈)。

至此，你或许就具备了制作长周期游戏所需的基本技能。

4.2 我需要团队合作吗？

这需要看个人目的，如果仅仅是为了实现一下梦想，其实自己一个人慢慢做会更好(再加上现在的AI技术也比较成熟了，更别说之后的AGI还能做成更多事)，那么你可能就不需要这些长篇大论；但如果你希望进入游戏行业，并想要做一个出色的Game Designer，那么在你求学生涯中组建一个长期稳定的团队或许必不可少，最少也需要策划、程序、美术各3个人(如果再有一个单独的音乐就更棒了)。

当然，也不是人越多越好，这还要看你的游戏体量、具体需求量、队友能力以及他们所掌握的垂直技能是否能满足这个项目的需求。

此外，你或许可以从一些GameJam中找到队友，但找队友也是门技术活，并且有一定的运气成分，就像黑暗森林法则，双方都不确定对方的目的，并且每场GameJam都会出现队友中途失踪或不欢而散的情况，这你需要特别注意，因为这2种情况大都是一些开发者厌恶甚至害怕团队协作进而成为独狼的根本原因。另外下面列出了一些参与GameJam的人群中可能存在的几种目的，你可以参考一下，欢迎补充：

什么都不懂只是来玩的
来立人设拍素材
新手入门来熟悉流程
来实现梦想
想从繁重的工作/学业中解放一下
来验证点子
来刷简历
想拿奖
把Demo拿出来看反馈
来扩列
来找队友

至于如何识人并且如何应对，这需要大量经验，但总之，保持一颗赤诚之心吧。

4.3 接下来沟通能力会很有用

这个沟通能力并非单指说话，它背后所包含的意思是：

能把自己的想法清晰地传达给他人
能准确地理解他人的想法
能正确地消除歧义

要做到这些其实并不难，只需要分别做到这些事：

说明需求后，给美术/音乐发参考，和程序一起拆解需求(需求拆解可以了解一下WBS方法)
双方多问一句：“我的理解是xxx，你看看是不是这个意思。”
记得验收

4.4 怎么写策划案/需求文档？

这是一个问题，但也不是问题。一些策划或许会说每个策划写案子的风格都不同，只要“能让人看懂就行”，但怎么才能让人看懂也是一门学问。你或许可以借鉴一下互联网行业中“产品经理”这一职业写PRD时的规范和标准，这或许有助于你更好的输出一份“能让人看懂”的策划案，当然，记得第4.3节中提到的参考图/参考曲、需求拆解以及需求验收，这些能辅助对方正确地理解你的需求。

五、项目管理

大多数独游/学生团队对项目管理都不太重视，甚至没有项目管理意识，认为小团队甚至是个人并不需要项目管理，其实这是非常错误的想法，制作游戏作为一个“项目”就应该要有一个截止日期，不能永无止境，否则最后的结果大都是放弃。即便是《火山的女儿》制作团队，都曾遇到过许多项目管理问题，所以这是一个非常常见且容易被萌新忽视掉的严重问题。

文章来源：https://mp.weixin.qq.com/s/RRxasLk2rbYVMB1kjon1Fg

5.1 项目管理应该包含哪些东西？

项目管理铁三角、瀑布流、敏捷开发、里程碑、版本、迭代、进度控制、立项启动规划执行监控收尾……等等，或多或少你可能已经听过这些名词，也可能没有，但正如前所述，这一节注定也不会出现过多的专有名词。简单来说：做项目，要有目标、要有人。

首先是目标，分为项目目标、里程碑目标、版本目标、迭代目标，其中项目目标>里程碑目标>版本目标>迭代目标，版本由多个迭代组成，里程碑由多个版本组成。总之，它们关系如下图所示：

你可能会疑惑为什么每个迭代→版本→里程碑不是一一对应的关系，这是因为目标不同，比如里程碑1的目标是制作Demo，因此分了v1.0版本实现玩法原型和v1.1版本世界观设计，但世界观设计没法像原型那样快速验证，它需要持续不断地打磨，而制作Demo对世界观设计是否完整的依赖性并不高——我现在还在救公主的路上，怎么救到的公主那就是后话了。因此，就会出现跨里程碑的情况——跨版本的迭代也是如此。

其次是人，如果说目标是让你清楚现在以及将来需要做什么事，那么人则是促成这件事的关键对象。人员管理及其背后所包含的沟通问题、进度管理、方向一致性、成本控制、质量管理、风险管理等讲起来十分繁琐，推荐过一遍《项目管理基础》这本书，这里只讲个人得出的结论：

以人为本
注重信息互通
团队成效不好80%是管理者的问题
要做好目标管理
复盘思维很重要
明确开会目的
学会识别关键路径
分清优先级

5.2 为什么游戏项目大都使用敏捷开发？

因为游戏行业变化很快，因此打着“积极响应变化”口号的敏捷开发由此脱颖而出。如果你是新手，那么我其实更推荐你先用2~3遍瀑布流来制作Demo，这能让你更清楚这一步做完后下一步该做什么，直接上手敏捷开发反而可能会打乱你的开发节奏，导致延期的可能性大大提高。以下是瀑布流的示例，下图和“瀑布模型流程图”结合着看，仅供参考。

前文的Demo对应这里的预制作阶段

瀑布模型流程图

5.3 如何进行敏捷转型？

首先需要明确一点，敏捷并非单独使用，一定是敏捷+其他结合使用，至于+的是什么，则要看你团队的实际情况和你自身的项目管理经验。一般来说是敏捷+瀑布(也就是混合式开发)，因为游戏制作涉及策划、程序、美术、音乐，一些大体量项目还会牵扯到多条管线+多个团队+大量数据，虽然是在做游戏产品，但这个产品里却有着大量内容。

其次，进行敏捷转型首要的是转变思路，将瀑布流时的阶段性思维转变为敏捷“短平快”打法的迭代思维(也可以了解一下Scrum这种较为常用的敏捷项目管理)。纯文本解释起来稍费口舌，可以通过以下图例来说明：

迭代循环

显然，“短平快”的重点在于"计划"流程中的“拆分任务”，拆出来的任务量以及是否是可执行的任务直接决定了Sprint循环能否跑起来。因此，如果你不知道怎么拆分任务，可以尝试拉上专业人士一起拆，因为这会影响到接下来的Sprint流程顺畅与否。

此外，敏捷需要可持续交付有价值的交付物，不仅要让外部的玩家清楚某一阶段的产品形态，团队内部也需要时刻能够看到游戏的整体形态——松散的、未能将所有素材和逻辑拼接成整体的游戏会让人怀疑自己是否真的在做游戏，或者说，会让人怀疑是否真的能做出游戏。

5.4 混合式开发怎么用？

很简单，举个例子：里程碑1的目标是制作一个Demo(Demo的产品形态应该如何前面已经说明，不再赘述)，分3个版本实现：

v1.0版本：玩法原型产出

迭代1：原型1
Sprint1：关卡设计
任务1
任务2
任务3
Sprint2：3c实现
Sprint3：xx功能实现
迭代2：原型2
Sprint1：……
迭代3：打磨原型1

2. v1.1版本：美术概念设计

3. v1.2版本：资源整合

5.5 项目管理工具

Jira、PingCode、TAPD、禅道等等，你可能听说过这些项目管理工具，但学习如何使用这些工具也需要一定成本，在熟悉如何管理项目之前先学习这些工具如何使用属实有点本末倒置，所以不妨先回归最简单的工具——Excel来进行最基础的项目管理。

说到最基础的项目管理，学会如何排期作为入门可能再合适不过，但不太推荐从前往后排期，因为最后大概率会延期，常用的一种排期方法是“倒推法”，再结合前面的瀑布模型+任务拆解，其实排期这块就不需要讲太多内容了。

最后，项目管理的各种方法和工具只是辅助，关键还是在于人，在于如何激发人的主观能动性。由于PM没有实际产出，所以PM在团队中只能打辅助，然而辅助也很重要，总不能说主程在这个项目中清的单子最多，评分13.0；PM在这个项目中没做什么事，评分3.0；所以主程是MVP，PM是躺赢狗吧。

六、市场调研

此时，你对制作流程比较熟悉了，也有了一定的设计能力，手握几个有足够拓展潜力的原型，并且组建了一支长期稳定的团队，对如何管理项目也比较熟悉了，那么就该考虑正式开始制作长周期游戏前的市场调研环节了。

可能你会觉得市场调研会污染你的天才设计，但其实恰恰相反，游戏做出来是给玩家玩的，因此需要找准你的游戏类型对应的是哪些玩家群体，以及在这些群体中，哪些是核心的资深玩家，哪些是较为边缘的玩家……为什么要这么分？因为这个品类下核心的资深玩家能清楚的知道你的游戏哪里做的好与不好，并能给到你精准的反馈，这对你后续改进设计和体验相当重要。