建筑师解构游戏关卡——游戏研发中的场景需求
曾经参与的项目上线了，特别看了玩家的各方评价，虽然对于个人关注的内容上少有评价但根据游戏截图也能评断些许。对于当时项目的美术需求工作流仍不断反思，当前游戏研发的作业流程分工细腻而繁复，然而这样过于细腻的流水线与KPI绑定时则产出了异端却人之常情的工作心态。
现代工序的专业分工将以往众多工项由单一雇员凭借经验累积所能完成的过程，拆分为众多工项分别由众多雇员单一专职完成，以此大幅降低多任务项经验门坎且专精于单一工项的技术累积。工作流本身的理念没有问题，问题在于如何实践工作流，中间产生了多样态的可能性，也会凭借着各团队不同的条件限制而有着不尽相同的匹配模式。在管理学中有着系统思考的课程，专门藉以工作的状态以问题核心本身提出适合的解决方式，管理学所衍生出来的学门众多然而实践上仍相当考验性格与观念。
总归而言，我认为当时所运作的美术需求工作流程拥有许多阻力，导致「一群跑车跑起来像蒸汽火车一样」，举个例子也是曾经参与某个项目发生的状态，实际的内容就是《游戏研发的设计规范03》这篇文章。这篇文章的内容是没有被采纳的方案，乃因于当时的部分人员认为工作量巨大以及包体巨大。当时就知道这两问题都不存在的，一是结果论来说工作量是极度缩减，顶多起步需要多些累积，或者对方的担忧是工作被取代了，而实际上为了满足多样性仍然有适量且技术含量的工作需要推进；二是当时所运用U3D而言这样的制作流程并不会增其包体大小甚至大幅缩减，何况当时为2.5D游戏模式，以制作流程来说总美术资源包体可以降至一半以上都绰绰有余。最终无法推行的原因自然而然是前述所提及的「异端却人之常情的工作心态」，于是我只能让步了，导致后来工作进度推展一直受限于资源匮乏而迭代缓慢，每每想起这些过往都只能闭目思索曾经学习项目管理课程的彭湃然后轻轻叹息。
场景需求规范
通常项目中的策划提出场景需求是具有规范的，然而部分中大型厂商会额外设置美术中心的部门统一着手多项目的资源需求时，我认为美术需求规范的标准格式理当由美术中心发起，乃因于个别项目的美术需求不尽相同但对口于美术团队分工却是一致的，比如原画、模型、UI或特效等等。由个别游戏研发团队各自发起，糟糕的状况是有多少个策划就有多少种需求规范；正常的状况是有多少项目就有多少种需求规范，当然针对不同游戏项目的特殊需求也需要具有一定的开放性，但起始的需求标记理当是统一规范的，否则对于美术团队都具有一定程度的理解成本，导致好似专业分工了，个别工项的进度也有显着的效率，但时间通通被沟通成本稀释了，次数一多就会发现原先个别工项的高效进度也渐渐失效，而后「螺丝钉」言论就会洒满了全项目组，这时候最糟糕的形式大致就是开始打鸡血吧，因为治标不治本更导致人心涣散。
对于小团队而言，好处就是沟通成本并不算高，虽然前述上线的项目也是小团队，但糟糕的工作流仍然发生了，初始问题也正是流程规范乃自于绑定KPI引发的劣化状态，实际上研发的工作繁多也并非每种类型的工作出现的延迟或偏差就会导致研发失当，依然可以倚靠其他优势弥补，工作中失误很正常的，踩坑后学习并成长并汇整经验，可能比起不曾踩坑来得更可贵。当然也有听过相当规范的工序，多发生在运营已久的项目以及目前的项目(富强、民主、文明、和谐、自由、平等、公正、法治、爱国、敬业、诚信、友善)。
参考与类型组构
以下内容是早上制作的，藉此论证《游戏研发的设计规范03》中所提及的部分内容，先引用偶像的名言做为开场「巨大的建筑，总是由一木一石叠起来的，我们何妨做做这一木一石呢？我时常做些零碎事，就是为此。」
魔鬼桥，引用自百度图片
想制作一个金拱门式的场景需求，于是乎寻找了金拱门的参考图片，曾经在欧洲拱结构的桥梁被称之为「魔鬼桥」，因为当时的人们不知道拱结构的力学原理而怀疑这是魔鬼的力量，拱结构在部分古文明中都有类似的纪载，当时的建筑技术多半为垢工，乃自于拱结构的运用改变了承重墙的限制，建筑的出发点终究是优先于满足功能的，当然有部分老百姓不明所以，以为建筑设计就只是美美的。然而悲惨如我，寻找的参考图都是当代混凝土的建筑因应造型本身而制造，也或许是百度图片实在不给力。
根据偶像的名言，想利用这些参考图制造出场景白模进去走走，因此将所寻找到的参考图片解构为可用的一木一石，我们何妨做做这一木一石呢？所以零碎事通常都是我来做，我就根据参考图中的拱结构大致区分为几个可用的对象，为了满足这些对象可以通用，所以改变了些尺寸比例，当中自然可以发现伊东的多摩艺术大学图书馆的结构方式较为繁复，并不适用于此次的内容，因此有了较多的简化。
叁考图与场景物件
运用参考图所分析出的类型进行简单的排列组构，这里可以根据不同游戏类型的需求可以有进一步的规范以满足玩法上的规则限制，这里就不多讨论。当排列组构完成可以导入引擎中往前走走，或者一开始就将各对象导入引擎中搭建场景，理论上这才是较为严谨的作法。在初始定义尺寸比例时便应该相当规范，才足以保证后续各类型对象量产时都通用，而制定规范通常各类型游戏即使是换皮游戏都应该有套自身量身订做的基准表，毕竟研发条件及水平其实都有不小的差异，这些初始内容也没打算详加说明。
叁考图到白模规划
引擎中体验与优化
虽然前文强调着制作规范的重要性及工作流程中的影响，但是实际研发过程中也很有可能是不断迭代更新的过程，自然有时候会因为初始设计的限制而窒碍难行，这也是每每设计过程考虑后续发展及扩展性对于经验与技术积累的重要性。因此快速体验并迭代可以有效避免隐性的失误，这时候搭建模型走走便是有效的方式之一，如果可以让搭建的流程精简而高效时，也许可以多少减少《彩虹六号：围攻》中谜之裂缝的产生，将场景对象类型化的优势在于快速捕捉部分误差的成因。
引擎中运行走走
引擎中运行走走
UE4在不同软件中转换上提供了相当良好的插件，以减少了转档中可能遇到的问题，实际上良好的研发流程是所有雇员在相同工项中所运用的软件及版本皆为相同是较为良善的方式，否则工作流也可能产生转档或操作过程许多难以避免的失误，这问题看似边缘实则影响巨大，如果将版权议题纳入将相当能体现出软件与操作平台一致性的重要性。
因此在引擎中运行走走，看看一木一石怎么迭起来的，藉此可以论证草稿上的假说，修正理解并优化规范内容，随着研发过程与规则的日渐明确也会有诸多调整，但理当都能保有定质的产出。
引擎中运行走走
结论
当代工作中的专业分工本身是整体社会飞速进步的要素之一，但是这是对于客体而言如此，也就是工作容器本身。对于雇员而言，专业分工的目的是服务于工作，而非个人成长，因此往往会产生画地自限的思维，这是对自我最大的鄙视，甚至产生专业鄙视链，这都是相当糟糕的结果，更可怕的是专业分工的思维是至上而下的推行。
前文所提及的项目的状态是预研期时研发团队与美术是分开作业的，导致当场景需求推导出的制作规范在初期等于是闲置状态，理论上需求与制作是密不可分的，否则都可能有其中一方完全返工。因此在研发初期对于参考乃自类型组构中都应该是迅速的团队参与后迭代，好让沟通成本降低，否则一旦蒸气火车开始奔跑了，很多时候已经承受不起太大幅度的改善了。
来自专栏：“巫师的游戏场域”
地址：
https://zhuanlan.zhihu.com/p/103349983
相关阅读：
建筑师结构游戏关卡——以等角视图探讨《Block’hood》
稿件合作：一元（微信：smallkisshe）
商务合作：Amber（微信：lcxk6876767）
投稿邮箱：[email protected]