游戏研发的设计规范（三）：场景类型化制作

文/暴走的巫师

这篇想从场景类型化探讨场景制作的方式，当然主题是说明场景制作的设计规范，自然根据不同的游戏功能或表现形式而言，会有着截然不同的场景设计规范原则。因此本篇所提及的设计规范方式仅是由曾经的项目经历的原则，而这种规范性的内容往往取决于团队的研发能力，只有适合的制作方式没有唯一的解决方法，以至于不见得通用于各类型的项目。

关卡设计的内容是相当贴近于玩家游戏体验的，以ARPG项目来说场景美术资源的表现实际上是要规范于游戏系统或玩法之内(卡牌类、回合制RPG游戏的限制就相对少)，才能够确保游戏体验在符合玩法下产生最好的游戏效果。有些游戏项目多半都是初期对于美术资源毫无规范、姿意创作，一旦到了中后期发现游戏包体巨大才开始想办法优化内容，实际上都已经为时已晚或必须付出巨量的时间成本(可以参考「价值工程」的内容)，这就体现出游戏项目在预研期的重要性，但也听说过很多项目是不存在预研期的过程，这会让研发后期相当乏力且效率低下，回归题旨「设计规范真的很重要」。

攻击范围

场景设计规范的拟定与游戏玩法是直接影响的，比如上篇讨论过的话题MOBA游戏中角色的攻击范围，这就与玩法、角色大小产生重要关联。研究过几款MOBA游戏的场景与角色攻击范围、移动、镜头等影响游戏体验的细节，便可以知道游戏在设计规范程度上的差异。

场景规范的基础尺寸

以2.5DARPG的场景地图而言，由于固定视角的关系许多场景对象的高度就需要受到因应视角所产生的规范，而场景的平面尺寸更受到了角色单位参数的影响，比如角色本身的尺寸、角色动作、角色位移速率等等。藉由这些拟定好的基础设定后才足以推展场景的设计规范。图一的内容是设定场景的基础单元尺寸，且藉由这类尺寸推算出角色在场景格中的估算位移时间，以控制游戏副本在场景移动上的体验时间以及场景大小的规范(小型副本、中大型副本)。场景的基础单元定义了各种通用性的路径，以便后续的排列组合运用(基础原则可以参考《空间类型演译:以平面图探讨彩虹六号:围攻》)，这里为了满足游戏功能而没有设置所谓的囊底空间，会藉由编辑器配置的方式生成。这些基础单元尺寸使得路径有着统一的宽度衔接，之后得以快速而多样的扩展场景内容，至于复杂性的变化可以交给编辑器的参数配置生成，这篇就不多讨论。

暴走的巫师：空间类型演译：以平面图探讨《彩虹六号：围攻》

图一

路径类型

场景类型的分组

图二，同样的L型转角路径其实可以倚赖场景装饰物妆点产生不同的场景氛围，即使都是相同的路径功能也可以区分多元的类型，且将其分组为Corner01、Corner02、Corner03等资源以待后续调用。由于ARPG的关卡场景复用率难以与卡牌游戏或回合制RPG游戏相比，因此制作独一无二的场景在部分类型的游戏系统中是缺乏意义或研发成本较高的作法，比如《永远的7日之都》、《轮回诀》这类多副本推进的游戏类型。因此藉由场景类型化的方式产生多样路径的关卡场景成为相对有效率的方式之一，当然只是制作方式的一种选择。

图二路径类型分组

场景类型的组构范例

配合各类型路径以及各规模广场的搭配即可产生多样态的关卡场景，当然由于游戏机制的关系，这里并未使用基础单元格直接生成关卡。图三，而是比较倾向Roguelike类型的伪随机的地图组构，产生二级的路径类型来使后续匹配更适用于游戏玩法的需求，比如BOSS战需求开放的广场或根据各副本的剧情、挑战需求产生特殊路径形式等等。其实有些探讨Roguelike的文章和模型未来有机会可以方想。

图三

场景对象的组构

其余许多的场景类型对象根据游戏玩法所产生的需求额外配置，这就符合多数编辑器的配置规则内容就不特别说明，场景对象的类型分类的原则其实也可以通用基础单元尺寸的概念规范，最大的优势在于清晰好配置，而且可以让放置于场景中的美术资源的规范得当满足每个场景的运用，也就是在《空间类型演译:模拟游戏地图探讨》中所提及网格系统的规范但不体现于玩家的视野中，但底层设定的网格系统却可以有效率的控制着各种需求的单位UI按钮。这种概念同样适用于三转二的场景制作方式，下次会以海绵宝宝的三种二等角视图继续探讨三转二的场景制作，参考《空间类型演译:等角视图探讨战棋关卡制作》。

https://zhuanlan.zhihu.com/p/74086307

场景类型化

场景类型框架

结语

场景类型化的制作方式并不通用各种2.5D的ARPG游戏项目，但藉由前期有场景设计规范的制作可以让后续资源利用或修正较为高效率，因此设计规范的拟定可以使项目步入正轨。初始的基础尺寸必须有效的定义好，若中后期大改游戏玩法等底层的规则依然会制造许多困难，当然这种大改游戏玩法的研发项目基本上本身就已经产生巨大的问题了。

下次想要分享项目管理的内容窗体分类及执行的议题，如何从数以百计的工作进程窗体中拟定设计规范并有效链接各窗体工项，当然这只是个提案并非实际操作的内容。因为就是项目操着相当不人性化的项目管理窗体而想根据这议题进一步讨论，其后在追根源头探讨项目整体规划到项目工作的窗体落实，从下而上的推演。

来自知乎专栏“巫师的游戏场域”
专栏地址：
https://zhuanlan.zhihu.com/p/77290164