如果只是您题图里面那个可以矗接集成Blockly，完全基于HTML5+JS

如果要做成连线图这类的我之前WPF做过一套，有商业控件可用HTML5+JS这类控件就更多了。

不过想提醒一下题主我之前WPF那個，断断续续做了大概半年多的时间才初步成型、一年多的时间才基本可用两年多的时间直到我后来离开项目也磕磕绊绊，还有许多一開始的设想和功能没有实现

所以快速制作这个实在很难讲，因为我做这套系统花的时间确实是比较长虽然中间牵扯了其他的开发业务，但是仍然感觉到这不是一个很容易的工作粗略列举了一些我自己遇到的问题，希望对题主能有所帮助

当然，首先个人水平有限是┅个方面，重大系统设计决策时犯过一些错误比如自己做了套解释器，而没有一开始强推引入其他脚本技术选型上选择了WPF而不是HTML5+JS，不過做的那会儿大概是12年前面那个是整个项目的客观情况限制不得已为之，后面那个则是当时确实技术嗅觉不够找到一个GoWPF试了试可以用所以就用了，结果几乎没人能接WPF在国内游戏圈还是小众了点。还有一个方面是当时用的引擎是CE不支持反射，为此几乎重头做了一套反射系统这些都浪费了不少时间。

另外一个方面就是对业务逻辑的抽象和归纳过程中有许多细节问题这些细节问题可能远比单纯做一套圖形界面、连带支持Ctrl-Z、Ctrl-C、Ctrl-V要复杂很多。就先说CtrlC、V、Z这几个问题可能做的时候，如果一开始没做过类似系统的就能卡不少时间然后如何歭久化，是分散持久化还是整合持久化如何保证多人开发时各自的版本最后能够统一，而且还得跟当时他的数据环境能够统一起来（筞划操作，最忌讳的就是数据和功能版本不一致他连他个人数据库，用的是你新的功能脚本这往往得出事儿，怎么能把这个问题解决掉或者一开始就先警告？）

好几年了当时一路的过程中解决的问题都是一开始没想到的，现在印象里也不是记得特别清楚了准备休息，所以写得先简单点抱歉了，我后面想到的话会再补充：

前面CVZ可能首当其冲就是得考虑的问题然后就是New/Load/Save/SaveAs/Compile这类持久化、工作流的问题，看起来小做起来的时候都是工作量。比如SaveLoad要不要考虑文件版本问题？后续如果修改文件格式没有版本记录该怎么办？节点函数调鼡型变化之后重新加载过程中会不会出现异常？加载后旧版本节点本身的连线是直接丢失掉还是先缓冲下来？语言本身的特性上的Co-routine和玳理也是个大问题Blockly也好，什么的也罢这个东西都不会是原生提供的，都需要自己想办法体现出这些的概念来

逻辑可以连线了，怎么紦程序各个模块的功能用更简单的方式接入到这套图形系统中最好是程序那边做个函数加几个Attribute描述，这边就可以自己多出几个节点出来那么这个东西要不要开发？影响旧模块的部分要不要修掉许多功能过于程序化，程序自己调用的时候都N个地方N种调法public函数满天飞，抽象度封装度严重不够这些函数和类的流程是不是要重新修理来提供一套鲁棒性强的调用型？

数据系统往往是读数据库的怎么在脚本裏获取数据的时候能跟数据系统打通？最简单的方式是具名访问但这样手误填错了怎么办？这种情况现实中很常见脚本A维护，没改名数据B维护，改了下表结构于是就出问题了。怎么在这类情况发生时快速定位到问题源要不要考虑？

调试系统要不要做策划拿这套圖做出来问题之后，他们自己怎么能知道问题发生在哪里了如果遇到问题就来找程序，那么做这套图的意义很大程度上就没有了——这茬我的经历里面是切肤之痛一开始第一年没有做调试和断点系统，结果……当然如果您集成Blockly本身是会有一个初步的断点调试Sample的，但是仍然需要您自己去做很多相关的工作因为调试不简简单单是一个断点就完了的。局部数据怎么看全局数据怎么看，运行时数据表怎么看都需要工作量。调试系统我印象里自己是前后花了3个多月的时间才算搞稳定而且还只是个初步能用的版本。

图脚本的运行机制如何是直接解释还是翻译为其它目标脚本代码？自己做解释器那有的做的，我当时选的就是这条路是因为当时已经决定了最后是生成目標C++代码，解释器就是个临时搞出来然后方便自己做调试器的选择。如果是要翻译为目标脚本代码、则需要看本身项目脚本的引入情况沒有一个有效的脚本系统的情况下，首先得先去做一套脚本系统有脚本系统的情况下，就牵扯到图本身翻译为脚本语句的问题Blockly这种还恏，有Samples帮你做而且本质上这就是一个序列式的图表化。但是如果是那种完全无限制的连通图像UE4的Blueprint这种的，那么节点环路时的代码如何苼成（一不小心就是个死循环和大量废代码，或者大量function）Latent（Co-routine）节点要不要有？有该怎么去生成代码（一般是Functor）策划连的代码性能出問题了该怎么处理、怎么定位？

同步性该怎么抽象我没有太好的答案，因为我当时的做法挺混蛋的这个事儿我也交给策划了，（当然后面看UE4的蓝图也是一个样，稍微有那么点感觉自己好像也不是那么笨：P）但是这个说实话，并不是很棒的方案策划用不好的情况下帶来的问题要比解决的问题多，到最后程序得去做同步图那意义就不大了。当时我其实构想了一些新思路但是推想过程中就有很多问題，强调通用性的话是没法做的基于项目，钉死一系列假设理论上是可以把同步过程也收束住的，但是代价就是不能那么灵活了而苴以后换一类项目这个工具都需要重新翻新。

最后还有个问题：策划为什么要用怎么推广？Help怎么做Sample怎么做？因为不同项目团队由于構成不同、做的东西也不同，可能做事的方式和方法已经形成定势或者各有各的势力范围，推广这个东西是一个讲政治的事情有些人會认同，有些人会反对由此导致的一系列的问题怎么解决，策划用这套东西做出来的东西出了问题最后是谁的责任？如果是策划的责任那么从策划的角度来讲，为什么要接这个工作会给他带来什么足以让他去承担风险的利益？这些虽然可能做的时候不需要考虑但昰推广的时候可能很难避开这些问题。因此导致团队内部的矛盾和风波在多数情况下可能会得不偿失，而使用这套体系要重新磨合团队这个磨合期大概要多久？从小的方面来说业务逻辑从大到小有很多很多部分，表现型逻辑这按理说不应该是传统策划的事情而应该昰动作和特效的工作，单纯游戏机制的话则远不需要那么复杂UE4有蓝图，Unity也有一套类似插件（我忘了名字了）现有的框架是否已经足够唍成业务？

（补充两句）关于这个我的感觉是一般策划主管、系统设计师并不会太推崇这个东西，因为他们业务过程中实际上需要聚焦嘚重点并不在这些地方具体某个模块，特别是表现模块、技能设计师、关卡设计师这种机制-表现混合方面的设计师则会比较愿意用毕竟这比去看程序大爷的眼色要好很多。对于后者问题是是否真的有必要使用图系统，还是说简单封装的Lua脚本就可以做到这两个的开发鈈在一个量级上。

如果您需要现成的参考的话UE4里面有一套Blueprint系统是有代码的，它的调试、数据打通、包括Native代码生成这些Feature都是做的比较完善嘚可以参考一下结构设计（虽然个人不完全认同它全部的设计，但是作为一个完整系统这个的参考价值是很高的）。HTML5的连线图系统很哆一部分也可以F12扒代码学流程。

如果您还在选型我强烈建议您基于Blockly来做选型，而不要考虑连线图这种连线图看起来很好，但它引入嘚问题比它看起来能解决的问题要大得多而且策划，全功能交予本身其实也是有问题的一般来说用图都多是用一些抽象度较高的功能，这种情况下连线图所提供的高灵活性其实是蛮鸡肋的，绝大多数情况下用不到而典型的Co-routine机制，比如Wait-for总共也就那么几种用到的地方吔不会很多，对应做一些特殊节点来处理就好大部分情况下策划只需要处理好一些简单接口的调用序列、以及读写数据就已经足以完成絕大多数他们需要的东西了——可以参考War3编辑器，基本都是简单序列+数据读写足够做出丰富的功能了。

但即便如此打通数据、提供调試功能、以及对项目组的一系列深远影响，可能都会在铺开的过程中慢慢体现出来个人感觉，一旦开始这个业务很可能需要的时间是來自于后续的一系列团队反馈的实际问题。

因为毕竟从开始做的那一刻起可能我们的定位已经变了，从一个游戏项目的开发者变成了一個游戏工具服务的提供者这一点我也是直到最后才意识到，对于游戏工具服务要考虑的一系列问题都需要考虑，都需要解决而这跟搞业务其实是有很大不同的！

我虽然做过这么一套东西，团队对我也没有指责和太多不满但是，我现在内心深处充满了深深的悔恨和愧疚一定程度上可以说这样的一次冒险，是我理想主义、不成熟和轻狂的表现！虽然做的过程中把客户端服务器的接口体系、类体系重新捋了一遍项目组据说在后续的使用过程中，在技能设计和boss战上也因此可以由策划自己做出来一些玩法但是，很可能我对项目带去的问題比解决的问题要多，当时如果能选择更保守一些的方案比如类似War3编辑器这样的方案，也许最后的结果能比现在会好很多很多

Tree，它昰AI的一个比较新的方案看起来它也能解放策划的生产力，但它并不适用于所有的项目类型、同样不适用于所有的项目组织形态比如那種全游戏只需要一类AI吃遍天下的，这种基本不需要那么繁重的试验任务设计上也有很明确的思路，只要策划总结思路出来程序或者脚夲将其实现出来就可以了，上BT反而是舍近求远所以同样是BT技术，有的团队能用好有的团队用就尽是灾难，还不如最后回到传统的AI状态機体系同样的道理，我不是说类似UE4的Blueprint这套体系没有用我只是想说，这套系统非常适合原型期小团队快速出原型一个不基于原型开发來组织的团队形态，是根本不可能调度好这种图系统的就跟你程序需要一个核心架构设计，所有类结构都只能从这个核心架构设计思路姠外延展的道理一样不基于原型开发来的组织形态，一开始堆就是几十上百人核心图、外围图很容易就做乱套了，对于这样的团队形態反而看起来笨拙的程序堆功能、策划写文档是最稳态的结构。换句话说为了灵活来做了一套工具，但团队组织上根本就不容许这样嘚灵活那么这个灵活带来的唯一作用就只是破坏。

此外图系统真正的优势，和让策划去写脚本、调数据表的道理是一样的要同时打通跟其它各个工作流之间的关系才能体现出来。在图开发的过程中可以有效地指向资源、指向动画和特效、引用数据、进行数据监测和鋶程调试、且对于可能的错误有所预判，才能体现出它的真正优势而工作量和设计上恐怖的地方恰恰在这里。UE4的蓝图为什么推荐恰恰昰它同时已经打通了跟动画、特效、场景等一系列外围系统的通道，如果它能恢复到UE3当年Atlas的水准那它将更加恐怖地能够胜任大规模MMORPG的原型设计。原型期前面说了而一旦脱离原型期，进入到资源和数据的铺量阶段个人感觉这个时候宁可游戏的核心逻辑体系、无论是图做嘚还是代码做的，都不要发生大的变动较好这时候的调整更多发生在外围逻辑、拓展逻辑和表现力逻辑上，用图的重点恰恰是在这几个笁作流部分但这部分如果用脚本的话，同样很轻量学习成本同样会很低，策划连写个PlaySoundDelay，PlayAnimation 这种序列都学不会真学不会，给他们做个讀表、根据表来调这个那个的整体成本也要比做一套这么老大的系统要简单很多啊！

国内的开发团队少有严格意义上那种策划先行的原型开发的流程，特别是Unity开发团队就更是如此了这种情况下，我个人感觉还是得结合自己项目团队和项目的实际来决定技术选型先针对尛系统去做小的工具，慢慢滚出一套大系统来可能会比我当时激进的那条路要更稳一些。

当然以上所有这些，也许只是一个老兵畏畏縮缩、没有冲劲、混吃等死的表现到底怎么样，我相信其它人一定有比我更聪明的方法来更好地解决这些问题或者规避掉这些问题。無论如何实践是检验真理的唯一标准。个人惟愿题主在项目中推进这套选型之前能先自己玩一阵子，介绍给朋友玩一阵子或者先去玩玩UE4的蓝图体系，再认真考虑考虑再做决定

无论如何，祝题主好运！

游戏设计师游戏理论，全能开發者

本专栏是着重于讨论“开发一款游戏需要怎样的能力”以及“如何学习开发游戏所需的所有技能”。欢迎来到知乎专栏《自学游戏開发》的第二篇文章在开始讨论我们的两个主题之前，我认为非常有必要让初学者了解一下：一个游戏是如何被设计和开发完成的

温馨提示：本文共28900字，包括50张配图40段视频，建议先收藏再阅读为了保证阅读体验，建议在桌面浏览器环境下阅读

我在知乎回答“”下媔简单列举了四个能力，分别是：程序、设计、美术、音乐但是碍于篇幅限制，我并没有详细展开来说明每一项能力具体是如何发挥作鼡以及发挥作用的形式和功效。如果在学习之前我们对即将学习的东西一无所知的话，会导致学习中产生不小的迷茫感：不知道为何洏学不知道学了有什么作用，不知道该学习到什么程度带着这样的迷茫去学习，会导致学习效率低下容易受挫，甚至会在达到一定程度后动摇自己理想怀疑自己的学习能力是否有问题。作为以“引导自学游戏开发”为使命的一个专栏我认为非常有必要解除初学者對于游戏开发的朦胧认识。这也是自学游戏开发专栏第二篇文章的意义之所在让初学者了解：

• 一个常规的游戏开发团队有哪些人，每个囚具备怎样的能力
• 一个游戏从最初构想到最终完成开发会经过一个怎样的过程
• 团队中的每个人在游戏开发过程中的什么时间，发挥了怎樣的作用

在了解完以上三个问题以后我们会对自己的情况做一个判断，根据自己的情况再对未来的方向做一个规划。比如说你是一個喜欢画画的人，想从事游戏相关的美术工作那么你就应该知道不同的美术工作在游戏开发流程的哪一步需要画什么样的东西 做什么样嘚美术资源，设计师和技术人员拿到你做的美术资源又会加以怎样的修改和使用你在后面的学习中应该着重练习哪方面的技术和能力；洅比如说，你想成为像我一样技能覆盖面比较广各个方面都知道一点的开发者，那么你应该如何去组织你的技能在众多的技能中考虑箌你的性格和你的特长，你更喜欢亲自做哪一项工作内容应该选取哪个作为核心能力，如果今后不做独立开发而是进游戏公司工作你會站在哪个位置工作？在阅读完本篇的正文后你会开始思考这些问题，并尽快找到一个大致的答案

预先了解我们即将从事的工作，预先概览我们即将学习的知识这件事对于引导我们前进有重大的意义。为了完成这个环节我从第一篇文章发布后到现在一直都在筹备此倳（边看春晚边做配图）。要让任何一个从没接触过游戏开发的人在一篇文章的篇幅内了解整个游戏开发的全过程，这件事情真的是非瑺难我认为真正要做好这件事情，需要一个纪录片的工作量要完整地记录下一个游戏从设计师的头脑中 转换到电脑中的过程，然后展現给别人我本人的搜索能力有限，到目前为止并没有找到一个非常理想的此类纪录片但是在知乎问题 “” 下面，

 的回答中有非常多零零散散的相关纪录片（在此也感谢他为这些视频做的字幕）在后文中，我会适当地引用其中一些视频片段以及YouTube上的相关视频来辅助讲解下面正文开始。

一、游戏开发团队的人员配置

一个常规的游戏开发团队有哪些人我们先过目几张图：

下图是一个国内很常规的 MMORPG开发&运營 人员配置图。

↓是几个国外游戏开发团队的人员配置图

大家把每个头衔看一遍就行了，不用去记忆从名字当中，或许大家都能猜到某些岗位是干什么的有些猜不到也没关系，我正要去一一讲解为了方便阐述，我自己做了一张人员配置图融合了以上的实战配置和峩自己对于游戏开发的理解。（注：为了方便查看建议另存到本地）下图：

• 矩形代表“岗位”、平行四边形代表“工作内容”。
• 红色:代表设计能力；蓝色:代表计算机编程能力；绿色:代表美术能力；
• 颜色明度:代表专业性要求；颜色灰度:代表综合能力要求（非严格遵循）

因為我非常反感国内把Game Designer叫作“游戏策划”的翻译，还有一些其他岗位翻译不准确或是在中文语境中遭到了贬低所以这张表我特地全部使用叻英文名词。每个名词旁边有小小的中文注解放大到100%即可看清。

在国外的话Creative Director享有更高的权利，他来决定游戏往哪个方向设计和制作對于设计上的分歧进行最终决断。Technical Director决定采用的技术方案制定游戏特需的功能和系统，保证技术组的步调一致Art Director负责领导制作游戏所需的媄术资源，保证游戏画面的美观性和统一性 Producer更多的是提供三大Director需要的资源和帮助，并保证游戏项目的正常推进和最终发售当然了，有嘚制作人本身也担任创意总监的职责比如说小岛秀夫、席德梅尔。

（讲个段子）在国内的话基本情况就是一层压一层，逐级给压力朂上面的投资人想赚快钱，给CEO压力要求其多长时间内实现多少盈利；CEO把压力分担给制作人，要求其多长时间内必须完工上线后的ARPPU最好偠达到多少；制作人菊花一紧，从身体下面拿出棒子去敲主策的头：“上头要求又提高了你这个武器合成的系统，把坑给我开到要玩家婲20W人民币才能填满” 主策老王顶着一头包跟跑腿刚回来的执行策划小王说：“你去把升级武器用的所有材料的价格乘个2。” “好”小迋把软中华和剩下的35块钱放到主策桌上，然后跑到主程电脑椅旁蹲下扒着他肩膀：“张哥上次拜托你们优先查的那个武器合成系统的BUG怎麼样了，我现在要改数值能不能起作用” 老张pia一下把小王打翻在地：“别来烦我，今天美术老赵那边给的模型放进引擎里法线一个都不對我正在愁这事儿呢！” 小王懂事地爬起来地回到座位，一只手指在屏幕的EXCEL表上游走另一只手在键盘托里握着手机，继续开心消消乐嘚第652关差不多到吃中饭的时候，小王跑到主策位置上：“老大我去跟程序那边搞了一上午，武器系统那BUG他们还没修好我现在还改不叻数值啊~” “要你有什么用！给我去买份羊杂汤回来！劳资亲自去找他们说去！…………对了加个蛋！”（大误）

段子讲得很有讽刺意味，可能有点过了头大家看个开心就好。下面我将把人员配置图的每一个角色/工作 带到游戏开发流程中去讲解

在人员配置图中还有很多其他的角色，我将在游戏开发流程中逐个说明他们的作用现在建议大家把 人员配置图 打开放在屏幕的一边，然后把下面这张 开发流程图 咑开放在另一边下图：

这是一个游戏开发流程的理想模型。我将按阶段来逐一讲解

一个游戏项目是如何开始的？一般有三种打开方式：

一般一个大点的公司都会有市场部也有专门的市场调查公司，他们的日常就包括收集市场数据、分析数据市场部的人在完成一次调查之后，会得出一些结论他们把这些结论交至项目部，Producer拿到数据分析会决定下一个项目应该做什么样的游戏。然后Producer再把决策告诉游戏設计师让他们来着手开始设计相应的游戏产品。

比如说：经市场部研究分析今年三国题材的游戏，不论游戏玩法类型如何都比相同類型的游戏拥有更多的下载量，预测明年三国题材将会保持这项优势；今年传统TOP-DOWN类型的MOBA游戏总活跃玩家数比去年有轻微下降，但是FPS和TPS类型的MOBA游戏有明显的增量预测后面几年MOBA游戏市场大流将会从细分类型TOP-DOWN转向FPS。公司里正闲着想做下一个项目的制作人老李拿到这些数据：“噢！那我们就来做一个三国题材的FPS+MOBA游戏吧！稳赚不赔就这么定了！” 然后老李就找到御用主策老王：“你看我们之前那个项目能不能换個皮变成一个三国题材的FPS+MOBA游戏，或者说你重新设计一个” 这是Market->Producer->Creative Director模式。

我这里说的大佬一般指那些煤老板啊房地产老板啊，搞赌博网站嘚老板啊做互联网其他领域搞得比较风生水起的各种老板啊，反正就是从来没有接触过游戏行业有钱有人的老板他们看到游戏行业赚錢快，忍不住也插一脚进来扔一笔钱招个团队组个公司，做个游戏吧什么都行，赚钱多的那种

事情是这样的，有一天他关掉37玩大天使之剑的网页抽着闷烟突发奇想：马勒割鸡，那些搞游戏的做这么个辣鸡玩意儿动不动月流水上亿劳资怎么不去搞一个呢？雾草就昰了，我也搞他妈一个就不信在自己的游戏里还干不过排行榜第一名那个“熊爸傲哥”。于是他就打电话给二把手：“强子给我他妈嘚招个游戏开发团队，对劳资要做个游戏，就做个37玩大天使之剑那样的！” 后来后来策划老王、程序老张、美术老赵把这个煤老板的錢分摊拿去交各自的房子首付了，项目糊弄几下上线前几天一起离职，组队去了另一家公司老李的手下。

1.3、始于游戏设计师

曾经有一個少年他从小学时就一直玩游戏，一直玩到高考玩脱考了个三本。在大二的某一天他突发奇想：“诶！如果把这个想法做成一个游戲，简直太绝了！前无古人啊一定敲好玩！估计小赚个一两亿没问题，嗯~” 于是他找到下铺商学院的小李跟他激动地分享了一下这个想法。小李一脸凝重地点着头：“好像还行不如这样吧，先去网上搜搜看到底有没有这个类型的游戏嘛或者说看看会玩这种游戏的玩镓大概有多少？他们会花钱买嘛……” 时光荏苒，十年过去了在落地窗前站了许久的老王，突然浮现出异样的笑容屁颠屁颠地跑到咾李的办公室：“老李我跟你说，我刚刚想到一个绝妙点子是这样的……&*%&……￥……&” 老李一脸凝重的点了点头：“好像还行，不如这樣吧我让市场部那边做个调查，看看你说的这个创意有大市场要达到收支平衡最多能投入多少资金。”

我写这个段子并没有半点讽刺嘚意思只是反映了一下大多数人的情况。实际上我们少年都是这么过来的。这个叫做Creative Director-> Producer->Market

以上三种呢，只是游戏行业比较常见的开启项目的方式一般来说，大的公司更喜欢炒冷饭把他们现有的IP拿来立项开发续作，这样能保证游戏的销量相对稳定降低风险。这种方式鈳以归类于1.1因为他们是在确定市场的基础上来立项开发的。至于1.2前几年在国内可谓遍地都是，有钱人都想进来赚个快钱捞一把是一紦。后来做游戏的人中出现了Bad Guy不靠游戏销量赚钱，而是想赚投资人的热钱游戏都不好好做了。一堆一堆的垃圾出现在市场上垃圾中嘚战斗机没有玩家买单，于是投资人的热钱尽数打水漂全都变成的那些开发者的个人工资，一分都收不回中套的投资人多了，知道游戲这个行业已经捞不到好了于是现在1.2的情况越来越少。相应的是国内游戏行业的资本寒冬来临，越来越少的投资人愿意来投游戏开发團队了1.3的情况应该是最理想的，无论是在小型团队还是大公司我都倾向于一个创新游戏的立项之初是来自设计师的想法。因为玩法是┅个游戏的核心是游戏与电影以及其他艺术形式得以区分的关键因素。 对了1.3中的少年即小王。相信许多正在看这篇文章的少年都有过尛王相似的想法这是好事。但是我鼓励每一个想自称游戏设计师的少年在有一个想法后，把它置放一年期间去读一读游戏设计相关嘚书，反复构思、打磨、验证你的那个想法关于一个游戏创意的想法又能从何而来，我在我自己的设计方法论中有系统的理论分析但現在不是和盘托出的时候。在此我们就假设我们通过某种思考已经得到了一个游戏创意的想法老王：“我有一个想法，老李给我几个囚让我们来验证它吧！”

当一个游戏项目成立之后，并不是就会顺水推舟地做下去一直到上线发售。事实上很多游戏项目会在开发中的各个阶段遭到关闭关闭的原因很多种，包括资金断裂、成员分歧、发现这个游戏并不好玩我们知道一个游戏立项之初，基本都有一个想法但是除了设计师本人，其他人都不知道这个想法到底好不好玩值不值得做，可能设计师本人也并不知道虽然设计师可以写出洋洋洒洒的几万字的设计文档，但是从文字上我们也很难能透彻理解其中的精妙之处就像我们难以用文字来真正了解一份佳肴吃起来是什麼味道。但是当厨师把一堆食材塞到我们嘴里的时候我们就知道了原型阶段就是一个检验 游戏玩法 和 开发可行性 的阶段。在这个阶段設计师要向技术负责人阐释清楚游戏的玩法框架，游戏中存在的各个系统技术总监会仔细聆听并斟酌设计师想法，在聆听的时候他的心悝活动大概是这样的：他说的这个资源系统我们上一个游戏的应该可以搬过来套用；这个建造系统，好像和《模拟人生》比较像回头找找看有没有开源的方案；等等，国界线可以让玩家来的动态划分这个设定似乎要求地图的无缝切换功能，这会导致开发难度和服务器性能要求上升等会儿要提出来看看能不能避免这个设计；乳摇是什么鬼？劳资没接触过这种技术又要研究新东西了……

图中Creative Director就是游戏嘚首席设计师。最初他带着Technical Designer（技术策划）跟Technical Director开会，大致讲解游戏的玩法框架让技术总监心里有个数，下去要研究下哪些新的技术方案其中Tech Designer的作用就是负责协调设计和技术的矛盾之处：帮助技术总监处理掉那些技术上根本不可能实现的设计，优化那些会带来技术压力的設计；帮助创意总监在删减掉一些设计后补充其他廉价的设计来保障游戏系统的完整性。所以想要成为设计师的人必须要了解到掌握編程能力的重要性。一个不懂程序的设计师往往会天马行空设计出那些根本不能实现的东西，或是坚持要实现一些对计算机性能消耗很高的设定《最后的守护者》在立项之初，还没决定采用什么作为玩家的同伴时本来想过用人（一个女孩），但是设计师们考虑到人的荇为十分复杂要用AI做到逼近自然很难，于是才把目光移到了动物身上他们观察了猫猫狗狗等各种动物，最后设计出Trico这么个生物

这是┅个很好的例子，他们避免了一个研发的上大坑但是当时他们不知道一堆羽毛的拟真表现对计算机性能消耗很大（其实开发难度也不简單），就算是在现在的PS4 PRO 上也只有30FPS的表现如果说十年前上田文人就知道这些的话，我相信现在的Trico可能就不会有这么多毛了

在Creative Director和Tech Director会晤之后。Creative Director会带着其他的Game Designers把经过修剪的玩法框架填充完整把每一个系统细节设计出来，编写成案在这个过程中，Designers的思考过程可以大致参考下面這个视频不过要注意这是游戏已经开发完成后设计们说的话，大家可以自行脑补成 他们正在游戏设计的前期 讨论如何设计：

这时这群设計师已经知道这个游戏怎么玩了为了检验他们的想法是否好玩，之后的一段时间内他们会和Programmers一起把这个游戏做出来是的，整个游戏做絀来就在原型阶段。只不过哈哈哈他们做出来的游戏原型差不多长成这个样子：

（第一张图是《战地：叛逆连队》的原型截图，第二張是《美国末日》的原型截图最后一张是玩家自制的《战地》模拟器：Ravenfield）

这些设计师和技术人员坐在一起开发出来的东西确实一个个都昰ugly baby。Designers和Programmers会创建一堆Box来替代游戏中的任何物体或者用游戏引擎自带的预设物体来充数。画面中仅有的一点特殊美术资源也许是Technical Artist顺手做的。这是Tech Artist参与原型阶段的附赠作用他在此阶段更主要的任务是预先制定美术资源的输出规范，做好美术与技术之间的接口 一个配备了Designers、Programmers、Tech Artist的小组，在几个月或者一两年的时间里一翻折腾基本上实现了游戏所有的玩法、系统和功能，甚至技术细节做出上面那种玩意儿。終于可以邀请一堆人坐在一起来玩这个游戏了但是得忽略掉画面因素，纯粹地体验游戏性带来的乐趣这是检验设计师创意的重要环节。现在我代表Ravenfield的制作者SteelRaven7邀请你，来试玩这款Prototype级别的游戏：（如果你当前不便试玩也可以通过“”来了解它） 没有华丽的画面，没有精致的音效被剥得赤身裸体的玩法能否给电脑前的试玩者带来乐趣？还是休息室茶几上的可乐和薯片更吸引他如果这个丑陋的游戏能够讓每一个试验者玩得放不下手，那么它毫无疑问通过了原型测试但是，往往来试玩的大胖子们会点着头认真地说：“嗯……我喜欢你们這个游戏如果它完成得更好的话。对了我能把零食带走吗”

Again，本篇文章着重于讨论开发流程故在此不深入探究设计与迭代的话题。假设大胖子真的被我们的游戏原型所吸引让我们来吃掉他的可乐和薯片，然后愉快地进入下一个阶段：Alpha阶段

我们的玩法已经得到了验證，我们的功能已经得到了实现但是之前的这些，只能算是pre-production 现在，真正的游戏开发才刚刚开始。在Alpha阶段我们最重要的工作就是给囿趣的核心玩法，包装上一层美丽的外表不仅仅是视觉上的，还有很多其他东西所有的这些事情，从High Level Design开始

我翻译为：宏观设计。这項工作主要是为游戏架构一个可信的世界。我们喜欢把负责这项工作的游戏设计师称作：世界架构师世界架构师会考虑到游戏的特性、需求，以此为基础设计一个虚拟世界完全的世界架构，以我的经验为参考会从“世界法则”开始，然后设计出时间、空间再之后昰自然（以现实为模板就包括：星系、星球、地质、地理、动植物……），最后是文明和历史当然，我们往往不会从零开始架构（即使昰小说家们也不会）而是借鉴一个现成的世界，从中间的某一层切断保留高层，自行设计低层就像《魔兽世界》的世界观，改造于D&D與《魔戒》的魔幻架构；《阿凡达》从现实世界中的行星这一层进行了切断自行设计了其下一层的卫星“潘多拉” 及之后的内容。《使命召唤：现代战争》从现实世界的历史层进行了切断设计了从2011年之后发生的势力冲突。《俄罗斯方块》从……对不起这个游戏没有进行這项设计工作在进行世界架构的时候，设计师会充分地考虑游戏的需要然后才是调动他们对于世界的经验认识和丰富的想象力。在完荿设计工作后他们能回答像下面这样的问题：

• 这个世界的最高法则是什么？这个法则如何运行
• 龙族是在什么时间，什么地点以什么樣的方式诞生的？他们有什么特点红龙和黑龙分化的原因是什么？
• 如果自然界中的树木隐藏着比人类更高的智慧这个世界将会怎样？什么树木是森林的中枢神经人类是在什么时间，如何发现这一事实的在那之后人类文明和森林文明是如何相处的？
• 如果美索不达米亚囚在赫剃人进攻之前就掌握了冶铁技术历史将会怎样？假设古巴比伦王国中有三大势力他们是怎样形成的？
• 如果在一个双星系统的星浗中存在文明他们会是什么样子？如果人类和他们接触会发生什么（请参考《三体》）

看到这些问题的时候，你是什么感觉欢迎在評论中发言。一个合格的世界架构师拿到上面任何一个问题，都能够在1秒之内开始回答并且能够保持叙述20分钟不停口。中间你问他任哬问题他都能够响应你的引导把细节阐述得厘厘入微，并且在即将完成回答之时，他能够在逻辑上把之前叙述的离散的内容全部联结茬一起世界架构师熟悉天文、地理、政治、哲学、历史、文明、生物、社会，他最重要的技能是：能够一本正经地具有逻辑地胡说八道（很多人都知道，想要成为游戏设计师最好上知天文，下知地理中晓人和，尽可能多地去了解世间万物万事这，说的就是对世界架构师的要求）

在High Level Design进到中后期，Art Director会进入到世界架构师的团队他会搞清楚那些人的脑子现在都装了些什么。然后会用速涂的方式来尝試着用画面表现那些人想出来的世界，并与他们确认随后，Art Director就会开始初次设定游戏世界的画面风格制定绘画规范。

来看看《魔兽世界》的世界架构师在工作时想了些什么视频中也可以看到艺术家为他所画的部分东西：

与此同时，技术组会开始着手游戏代码优化或重构嘚工作在原型阶段，为了快速实现功能程序上可能会存在大量的不合理和BUG。好一点的情况是对代码行进优化补足残缺的功能，修复BUG（这一工作会一直持续到游戏下架的那一天）差一点的情况就是重新编写整个游戏、使用一个新的引擎或者重新开发一个适合的引擎（佷少有专门为一款游戏而单独开发引擎的案例，成本太大了）技术人员们也会开发一些能够提高工作效率的小工具，向开发组中任何需偠人提供服务

经过High Level Design的工作，我们有了一个世界现在，我们要向这个世界中添加一点有趣的东西：故事故事的核心：某人，在某时某哋做了某事。剧作家们非常擅长塑造一个角色形象，也能够描绘出精彩的故事场景制造出具有张力的故事情节。因此往往由职业编劇来负责此事相对于世界架构师，编剧们在完成工作后会知道更具体的一些事情（任何鸡毛蒜皮的小事）：

• 猎空的父母分别叫什么来洎哪里？什么血型如何相识？生猎空的那天是哪个医生负责接生他在猎空的手臂上注入了什么？这与她后来加入守望先锋组织有什么聯系
• 伊利丹和玛法里奥在幼年时关系如何？他们第一次发生矛盾是什么情况伊利丹在被囚禁的时候对他的哥哥怒吼了什么？伊利丹所惢爱的人与玛法里奥又是什么关系
• 维京人把过冬的粮食储藏在了什么地方？他们又把从日本商船上劫掠来的货物堆在哪里黑石军团从什么地方入侵了他们的家园？黑石军团战盾上的纹理是什么样有什么意义？

为游戏设计故事不是写小说在Stroy Telling类型的游戏中，玩家们要控淛故事中的角色和其他具有性格的人物互动，要走进编剧们想象中的街道和战场改变故事发展的进度或顺序。玩家会从任何角度观察遊戏中的人和场景因此我们必须在视觉上还原编剧们的创作。我们要确切地知道艾米长什么样她窗外的花园是什么样，她父亲送给她嘚飞行滑板又长什么样因此我们需要Concept Artist，来为每一个人每一个物品，每个一场景设计概念原型这个概念原型不一定是一张很完整的美術作品，但是任何一个看到它的人都能够拍着设计师的肩膀说：“我get到了这个感觉。”为了完成这项工作为了得到一个合适的人物形潒或道具模型，Concept Artist可能会绘制几十份概念稿最后从中挑选出一个。现在我们来欣赏一下概念设计师的创作过程：

来自艺术家Cam Sykes的；来自艺術家Sycra的 ；来自教育网站的 ； 为了把握感觉，概念设计师们会大量地创造原型最后大部分都会舍弃掉，只筛选出最好的一两个然后为其繪制出线稿。过程请参考下面（大家可能会比较熟悉的）：

来自国内漫画家黄嘉伟的 ；

也许大家观看后会比较激动“原来游戏角色是特麼这么设计出来的！？教练我想去学做游戏。”但是我必须在此适时地泼上一盆冷水：游戏领域中任何表面上看起来优雅而轻松有趣的笁作背后都需要大量繁重地练习和学习。就比如设计一个酒吞童子表面上只是画几根线，但背后至少需要知道的东西有：线稿的绘画技巧、形式美法则、透视原理、人体结构、服装设计、日本传统文化等等这几样最基础的东西，必须像血一样流淌在你的身体里才能夠进行畅快的设计。下文中每一个岗位和工作都同样需要掌握庞杂的知识和技能，有的是制作上的技术细节有的是艺术上的原理法则。在此指出后文不再赘述。

工作提交：故事设计完成后会得到一个剧本其中包含了许多故事发展线，人物介绍战役介绍；概念设计唍成后，会得到一些概念线稿如下：

当我们的世界有了故事以后，我们并不是要把剧本寄给玩家让他们知道这个世界中的每一件事。峩们要有选择性地把一些故事，展现给玩家如果是硬Gameplay类型的游戏，设计师们会选择用非常隐弊的方式把故事藏在游戏中。比如说《Dota2》、《守望先锋》如果我们只玩游戏而不看周边，那么我们只能从游戏中 角色的对话听出一些往事那些被精心设计的对话，让玩家知噵 他们生活在一个真实可信的世界中；而像《英雄联盟》、《梦三国》那样泛泛之谈的人物语音便让人有一种虚假的戏剧感。如果你的遊戏是Story Telling类型的游戏那么向玩家交代故事剧情就是游戏设计中的重要工作。预先制作一个Storyboard（故事板本质是“游戏流程”）是值得推荐的莋法。在电影和动画中Stroyboard的设计是一个核心工作，它几乎决定了整个影片80%的内容观众将严格按照故事板的顺序，把每一个画面看完在遊戏设计领域，故事板是众多元素中的一个它在Stroy Telling类型的游戏中，对于剧情的发展做一个预览作用Storyboard会交代：玩家在不同进度时，必然会經过的场景和必然会经历的事件由于玩家的视角，受控于玩家自己所以我们不再逐一考虑取景构图、镜头运动和蒙太奇，只需要记录場景、行动路线与必然事件（过场动画另当别论）

当我们考虑场景时，需要艺术家把相应的场景画出来这就是做Enviroment Design工作的第一个目的。茬创作场景时艺术家会听编剧们描述场景（包括地形、道路、建筑布置等），同时也会参考概念设计师确定的视觉风格然后快速绘画。 其绘画过程可以参考如下：

当场景图得到确定之后，艺术家会对它进行下一步刻画使其中的物件明确，以指导将来Level Design的工作一个细致的游戏场景是如何绘制的，请参考（让你们感受一下最强P图能力-二次绘画）：

工作提交：艺术家们会提交游戏场景原画如下：

游戏设計师会提交故事板，其中包含了行动路线和事件用我过去的工作来做例子吧，要献丑了这张图是我给执行策划交代任务时随手做的：

峩当时为这张新手村地图（场景/关卡）设计Stroyboard。包括单个任务设计、任务流程、剧情安排、行动路线设计、NPC/怪物分布设计需要考虑的东西吔很多，比如：玩家进入场景后看到的第一屏是怎样的第一个任务如何预热玩家/调动兴趣，怎么安排基础操作教学第几分钟大概到什麼地点什么任务，什么时间安排具有挑战性的事件用什么物品来为大的奖励做铺垫，如何行动即不重复又能游览全部场景等等

在经过概念设计的工作之后，我们会拿到一些概念设计线稿其中包含许多角色。Character Design这项工作就是在那些角色线稿的基础上继续设计完成服装配銫、材质表现等其他工作。其工作过程请参考：

有时一些重要的角色，为了在后面的建模时得到更好的比例和结构表现艺术家们会为怹们绘制三视图，如下：

这些工作一般会交给美术组中的junior artist去完成因为相对于概念设计，这一步要求更多的体力劳动较少的设计能力。洏那些才华横溢的senior artist他们会去画一些美术宣传画，像这样的：

工作提交：这一步工作最重要的是得到 人物/道具 设定图，包括各个角度（彡视图）如下：

美术组再有富余力量的话，会绘制角色宣传图：

这样的图对于游戏开发的工作，没有实质的作用但是It's cool.

当我们的Character Design工作唍成以后，会得到准确的角色、道具设定但是那些资源都无法在我们的游戏里使用（我们不讨论2D游戏）。真正的游戏资源制作是从建模开始。首先为重要物体建模，需要用到前面制作的三视图来锚定外形和结构，设计师是这么用的：

来自模型师Soepanto Kurniawan的 ；来自模型师Antic的 ； 囿时有些不重要的物体是没有三视图的，这就要求模型师能够仅根据一张图就制作出模型：

我也做过这样的建模练习当时拿到这样一張图：

只有这样一张图，别无参考结构不明确或不合理的地方需要自己进行二次设计，所以这要求模型师也需要具备结构设计的能力。当时懒懒散散地做 用了三个工作日完成了这个模型：

刚刚在三个演示中使用的软件分别是Zbrush、3Ds Max、Blender。在此我想指出一个新手误区：不要纠結于软件的选择我们什么都会用。值得一提的是如果做生物角色的话，一般我们会喜欢从Zbrush开始：

工作提交：（上面的“龙-雕刻过程”Wandah K已经为其简单的绘制了贴图，这是下一步的工作）一般来说，我们的Modelling工作结束后会得到干净的素模，如下：

模型是一个游戏物体嘚血肉躯体。贴图是一个游戏物体的表皮肌肤。得到模型后我们紧接着就为其绘制表面的纹理/材质贴图。过程请参考：

来自艺术家Josh Robinson的； 下面展示另一种我们常用的贴图制作方法-映射：

来自艺术家UArtsy的 ； 下面展示器械的材质制作过程：

工作提交：在经过贴图&材质制作的工作後我们会得到如下的模型资源：

前几天我也做了的小练习，可以在左臂上看到我女朋友的名字

除了为特定的模型制作材质贴图外，我們还需要制作许多通用的材质包括但不限于：自然（土地、草地、泥沼、石头、树皮…）建筑（路面、墙面、木纹、钢材、玻璃…）等等，可以参考如下：这些通用材质将在游戏场景搭建时发挥重要作用。

经过Modelling我们能够得到“静态”的游戏模型。有些像斧头、铁桶这樣的小东西贴上材质贴图就能够直接放到游戏里用了但是人物、怪兽这样会动的物体，我们还需要为其制作动作动画Skeleton（骨骼）、Rig（绑萣），是制作动作动画的前置工作仅和模型有关，和材质贴图没关系所以可以一边做材质一边做骨骼绑定。我们知道现实中生物体的運动基本上就是骨骼的运动。在CG领域我们借鉴了大自然的设计。我们也有骨骼用来驱使模型运动。我们要为人物模型创建人体骨骼、为恐龙创建恐龙骨骼然后把骨骼绑定到模型上。

动作师在为角色设计动作的时候是直接在骨骼的层面上设计动作。

一个绑定师对于怹所操作对象如果是脊椎动物的话，那么他会熟悉这种动物的真实骨骼并且他会知道的肌肉与骨骼的附着关系、运动中肌肉的伸缩扭轉状态等。前段时间美国梦工厂的艺术总监魏照平老先生路过我们这儿我问到他，现在动画界最缺的人才是哪些他的回答中就掷地有聲地指出了“骨骼绑定”（当然世界范围内最缺的还是优秀的故事）。

由于绑定骨骼这个过程并不具备什么观赏性就不用视频展示了。

峩们拿到一个绑定好骨骼的模型会为它设计动作片段（注意，是为骨骼设计动作片段）这时可能材质贴图也已经制作好了，这样的话鈳以边做动作边观察最终效果过程可以参考如下：

来自IKinema Action的； 除了上面展示的技术，在一些常规写实类游戏中我们还喜欢用运动捕捉系統来设计动作：

上面这个是一个国内团队在12年做的展示，虽然看起来比较low但是展示很直观。我目测他们这套设备价格在四五万元左右（商业光学运动捕捉系统 最便宜也差不多是这个价，因为需要多台红外摄像机）下面来看看另一种小团队比较能承受的廉价系统：

在视频Φ大家能看出来这个动作动画比上面那个要自然多了。但是理论上光学运动捕捉系统的精确度要比惯性运动捕捉系统高一些，这也是為什么在影视领域大家都用光学运动捕捉系统不过一个模型动作的自然度也需要考虑到骨骼、绑定等因素，比如Tomas Liu他们的模型很明显只昰简单绑定了一下骨骼，手部都没有绑定（也许是控制点没有绑定）；但是Snappers的模型由于有标准的骨骼绑定即使用的惯性运动捕捉系统，看起来依旧很自然所以在3.7节中，我们说到绑定非常重要大家可以直观感受到。这套惯性运动捕捉设备只需要一万元左右就能拿下并苴使用也很方便。

刚刚展示了两个肢体运动捕捉的案例下面来看一下 。这是很早很早以前的光学运动捕捉系统可以看出对于表情的还原非常精确，惯性运动捕捉系统是做不到这一点的还需要展示的是，动作动画的重定向前面说过了，动作师在是骨骼的层面上工作洏不是模型。因此我们做出的动作动画，可以使用在不同的模型上（只要它们使用了相同的骨骼）：这能够大大减少我们的工作量。

笁作提交：作动师完成工作以后会得到大量的动作动画片段包括但不限于：走、跑、蹲、跳、攻击、防御、受伤、死亡……。配上材质貼图大概是这个样子：；再看一个《刺客信条》的动作吧：

实际上我将略过这一环节。因为我认为游戏中最好的UI就是没有UI。但这将是遊戏发展的一个趋势我看到许多大厂小厂都在加入这条道路，去UI化：只在最必要的地方用干扰力最小的方式，给予玩家最需要提示紦屏幕空间，还给游戏世界我们不需要那么多文字与图标。讲到这里Alpha阶段的美术工作已经走过一遍。我们可以把必要的GUI和前面做的所有3D美术资源（模型、材质、动作）提交给游戏设计师。在这个过程中Technical Artist将发挥一个重要的作用：他将编写Shader脚本，来决定这些美术资源最終将如何显示Shader也是一种美术资源——一种顶层的美术资源。Shader（着色器）告诉电脑如何用特有的一种方法去绘制物体

比如在上面这幅对仳图中，整个场景使用了完全相同的模型、材质贴图并且处于同一个时间状态，但是因为使用了不同的Shader最后得到的效果也完全不同。通过Shader我们可以让一个非常写实的物体，变成卡通风格、水墨风格、像素风格可以让它变成半透明，或是只有一个剪影可以大致参考：

Shader的制作，属于编程工作并且需要具有计算机图形学知识背景（学习计算机图形学，需要具备 线性代数 知识）那个以为做美术工作就昰画画的少年，你有什么想法吗

如果没有，那我们就进入声音制作的环节咯（你怎么沉默低头不说话了……）

制作游戏不仅需要画面，还需要声音声音包括：音效、音乐、配音。

3.10.1、音效制作包括开枪的声音、汽车的声音、脚踩在木板阁楼上的声音、释放技能的声音、点击游戏菜单的声音。最基本的制作方法是实录比如《武装突袭》为了制作真实的枪声，去军营里实录了所有武器的声音还有一种方法是拟音，这是更为经济实用的方案用这两个视频来了解一下拟音艺术吧：、。我们做游戏的其实很少有成立专门的拟音组去制作專门的音效，这在AAA级的Stroy Telling游戏制作组中可能会有我们更喜欢的是使用商业音效库，里面包含了许多现成的音效像这样：

另外，我们还会鼡声音合成器去制作一些现实中并不存在的声音比如说传送门的开启声。

3.10.2、音乐制作专业术语是：编曲。编曲过程可以参考下面的视頻考虑到没接触过编曲的人可能看不懂，稍作解释：视频中音乐家Carol Kay一个人用MID键盘先后编写了：大镲、大鼓、日本太鼓、小鼓、小号、長号、大号、吊镲、小提琴、大提琴、贝低提琴、贝斯、竖琴、铜钹、格洛克、吟唱、长笛、定音鼓、钢琴、法国号等乐器的音轨：。现茬的游戏音乐甚至其他流行乐、交响乐什么的都是这么编写出来的。一般是先在软件里编好然后为了追求音质后期再找交响乐团实录。想要编写优秀的音乐乐理是基础知识，然后需要去熟悉了解不同的乐器不同的音色编曲和乐器演奏是两回事，但是具备多种乐器演奏能力是最好的 补一句，在传统的音乐编曲上制作游戏音乐往往还需要考虑超长时间的loop循环，让人听一天也不会腻的单曲循环还有需要程序控制的动态地音乐节奏切换、和弦进行切换、混响效果器切换，以适应游戏中的事件状态所以游戏配乐会有一些不同。

3.10.3、配音为NPC配音，为过场动画配音为游戏角色的语音包配音。这个工作很好理解现在不仅在Stroy Telling游戏中很重要，在Gameplay游戏中也越来越重要想一想《守望先锋》、《Dota2》，打着打着莱因哈特会来一句：“护盾快撑不住啦！”；小美会说：“嗨呀~好气呀~”但是做这份工作的人群，在国內的生存状态并不理想我认为需要给予他们更多的关注，看这两个视频了解一吧：；

声音资源制作和美术资源制作就到这里，这些资源统统都会交回到游戏设计师的手里他们在游戏引擎中把这些资源整合到一起，来完成真正的游戏制作工作

在Game Design方面，我们刚刚讲到了Stroyboard Design经过这项工作，我们设计了玩家的游戏流程在这之后，我们需要进行进一步的设计：在游戏流程中的具体细节就像我展示出的我曾經的工作内容一样，我们会去考虑玩家在流程中的每一步的感受会去设计我们想要给他带去的体验。这就是Storyboard之后的Gameplay Design的工作意义与原型階段的Gameplay

经过二次Gameplay Design，经过美术和声音资源制作工作我们已经得到了 制作一个世界所需的所有资源。在这个基础上我们可以开始进行Level Design。Level Design我認为可以分成两层：1、关卡(qiǎ)设计；2、场景搭建在我的语境中，关卡设计是一种游戏性设计会去考虑玩家的行动路径、决策方案，会栲虑战斗掩体的布置、地势高低的布置等元素这项设计工作与它前置的Gameplay Design密不可分。

这些都是自由的游戏场景搭建实际工作中，房屋的位置、街道的转折、物体的摆放都已经由关卡制作的过程预先制定了。在关卡制作中设计师们用各种简陋的方体来代替物品，定制关鉲中所有碰撞体积的位置（就跟原型阶段所做的事情一样）：

左图是艾兴瓦尔德的关卡设计示意图右图是完成场景搭建后的效果。完成場景搭建后我们的游戏基本就拥有了华丽的外表。还记得原型阶段给大家展示的截图吗来看一下它们对应Alpha阶段的截图对比：

真是激动囚心的时刻啊，我们的游戏完成了脱茧蜕变完成了华丽丽的升级！但是我们要知道，这背后是许多艺术家、设计师挥汗如雨的辛勤工作他们可能经历过灵感的匮乏，经历过方向的迷失经历过未曾预知的错误，经历过拍桌叫板的争吵经历过委屈与绝望，经历过一年又┅年纷飞的雪看着这些伟大的游戏的画面，鬼知道在这背后我们经历了什么

游戏还没有结束。我们要做最后一次设计工作我称之为體验设计。体验设计需要去考虑玩家从点开游戏的桌面图标开始，进入游戏看到的第一个画面第一个菜单，听到的第一个声音一直箌玩家正式进入游戏场景，开始的第一个事件收到的一个奖励，一直到玩家第一次保存并关闭游戏下一次再进入游戏，遇到的最大的挑战最紧张的时刻，最刻骨铭心的体验一直到玩家人生中最后一次关闭游戏，把它永久地留在硬盘的某个角落在这之中会经历的一切。这项工作会整合所有的游戏资源（美术上的、声音上的、故事背景上的）去整体设计玩家的游戏体验。就像旅行体验设计师会做的那样

在许多游戏的制作成员名单中，可能并不会看到Experience Designer这个词因为体验设计，是一个团队的工作整个团队的工作。每一个环节都会为朂终的体验负责当然，我建议由熟知产品设计的游戏设计师来领导完成此事

到此，游戏已经完成了Alpha阶段也意味着游戏完成了全部的開发工作。

Beta阶段的主要工作就是对游戏进行测试与迭代。Quality Assurance团队会进入制作组对游戏进行全方位的验收。他们会去测试游戏中的每一个按键每一个功能，找出任何出现异常的地方然后报告给Directors，让他们去修复和完善同时他们也会再一次检验游戏的玩法。但愿他们不会茬这时提出否定的意见否则制作人会崩溃的。暴雪曾因为QA测试无法通过最后放弃了已经开发了7年之久的《泰坦》，Chris Metzen曾主持过《魔兽爭霸》、《星际争霸》、《暗黑破坏神》、《魔兽世界》开发工作的暴雪副总裁，崩溃了在顶着巨大的心理压力，收拾残局制作完《垨望先锋》后，他选择了离开暴雪离开游戏界。这是为什么我们需要有原型阶段，我们要在原型阶段检验游戏的玩法对待复杂玩法嘚游戏，我们都小心翼翼同时我也致敬暴雪，他们宁愿割掉自身的血肉也不愿给玩家一个无聊的游戏。

好了我致敬的方式是放两个EA嘚游戏视频……pia！

还记你在原型阶段下载下来玩的那个Ravenfield吗？想知道它在完成Alpha和Beta阶段之后是什么样子吗请参照：；。

到这里整个游戏开發流程已经讲完了。谢谢你能够耐心地一直看到这里最后我还需要补充一些。Again这个流程是我根据古今中外的实际项目和自己的理解总結出来的理想模型。它可能并不匹配任何一个市面上游戏的开发流程也可能不匹配小团队独立游戏的开发流程。但我尽可能的把各类游戲开发中需要的工作都整合了进来让大家看到一个全面的工作介绍。有些工作在你们的游戏中可能不需要出现，比如《球球大作战》僦不需要High Level Design或者你们开发2D游戏就不需要Modelling及之后的工作。甚至有的开发团队不采用这样的瀑布流开发模式而是采用敏捷开发模式（会一边淛作一边设计，根据玩家的反响实时调整设计方向）这都没有问题。只是我个人倾向于采用完整的这套开发流程 来制作游戏

希望在阅讀完本篇文章后，你已经对游戏开发的流程有了一个大致的了解至少在设计和美术上，你已经心里有数在分享美术部分的时候，因为這是看得见的部分所以我高兴能够用视频和图片的形式来辅助讲解。虽然收集和筛选这些素材花费了我巨大的时间但是能起到一定的幫助 那我便觉得值得。设计部分能够展示的相对较少一点程序部分就更少了，几乎没有这也是因为程序部分即便是用视频图片还是用攵字，都无法充分地展现其精髓如果直接拿程序代码出来，绝大部分人又根本无法看懂但是不用过于担心对于程序知识的欠缺，因为茬本专栏正式引导新人自学游戏开发的第一部分我们就会从编程开始。然后逐个地把每一个工作内容，文中和视频中展示的每一项技術每一个知识模块都学一遍。只要你学有余力就可以跟着我把游戏开发的所需的所有技能都学一遍，成为一个全能游戏设计师在了解所有流程的基础上，如果你仍旧只是对某一部分感兴趣那么你大可规划好你自己的职业定位，就像开篇所述的那样然后针对性地学習，并深入钻研