开放世界杂谈¶
开放世界(Open World) 是一个玩家可以在自由地实现目标的虚拟世界，而不是具有更线性和结构化游戏玩法的世界。其中的著名游戏包括《塞尔达传说》、《侠盗猎车手》、 《荒野大镖客》 、《上古卷轴》、《我的世界》，《艾尔登法环》...
开放世界的重点在于开放性，因此开放世界游戏一般在在内存上会动态且无缝的加载游戏世界，这类游戏的主要吸引力在于为玩家提供自主权，使得游戏进程可以按玩家预期的顺序和方式来推进，但不是在游戏中可以做他们想做的任何事情（这在当下的计算机技术几乎是不可能的）。
——摘自 《Wiki - Openg World》
关于开放世界的关卡设计，这里有一些非常优秀的文档：
笔者是一名入行不久的引擎工程师，本文主要用于记录和讨论，将以程序开发的视角去剖析开放世界，一些想法和思考方式可能过于片面，欢迎大家指正。
开放世界面临的挑战¶
在知乎上有一个相关的讨论：
有回答提到，开放世界的主要挑战是：
- 开发成本
- 游戏引擎
- 策划剧情
- 原画风格
- 硬件资源
- 游戏玩法
- 项目管理
- 版本管理
- 宣传推广
- 发行渠道
笔者是程序开发人员，对原画风格，策划剧情，宣传推广，发行渠道 这些问题了解不多，接触过一些相关人员，他们对这些问题有着优秀的解决方案，或许目前而言，这并不是太大的问题。
开发成本¶
这里的开发成本具体指的是 资金成本 和 时间成本
这里有一个关于资金成本的列表：
完整表单来自于：https://en.wikipedia.org/wiki/List_of_most_expensive_video_games_to_develop
从上述表单可以了解到，一些开放世界大作动辄就是千万甚至上亿美元，不过也存在像 我的世界（Minecraft）这样的异类。
关于具体的资金划分，可以参考：
开放世界大作与之类似，相比之下有着更大的体量，其不同之处，可能是还需要增加额外的场景管理人员
可以做一个简单的估算：
- 100人团队，每人平均20W/年，那么一年下来单纯员工薪资的开销就近3000w，再加上设备，福利，外包等一系列杂七杂八的费用，一年下来可能就差不多四五千万，按大部分大型游戏的开发周期为5年左右，再加上后期的营销和运营费用，也就是说，如果想开发一款大型的游戏，可能至少需要两亿人民币的预算。
而这还是在理想情况下，实际上我们还面临着更大的难题：
-
国内游戏行业起步较晚，很多方面的积累都不尽人意，打个比方，《塞尔达传说：王国之泪》，《艾尔登法环》的开发时间大约是4年，那么国内团队在资金充足的条件下，也能用四年制作出同样体量的游戏吗？对此我持怀疑态度，最有可能的情况是 —— 四年做了个看上去还不错的Demo 。虽然说这前文提到的两个开发团队花了四年的时间去制作游戏，但整个团队在游戏开发上的积累，却远不止四年，它们有着符合自身风格的游戏引擎，有着符合游戏玩法的场景规范，有着标准化的团队协作，有着长期积累的平台优化技巧，有着跟玩家长期打交道的经验，而我们，或许有不少的行业大牛，但与之相比，我们缺乏的是成熟的团队。
-
相信大部分开发者对游戏都怀揣着一些梦想，虽然赚钱不是我们的目的，但是却是我们必须要有的成果，投资人不是慈善家，员工不能靠爱发电。而谈到赚钱，这里有几个国内大型单机的数据参考（来源于网络），可以看出，如果除去各种抽成，宣发成本，大部分游戏都是不赚钱的：
| 游戏名称 | 开发时间/年 | 制作成本/千万元 | 当前单价/元 | 销量/万套 |
|---|---|---|---|---|
| 古剑奇谭三 | 4 | 3000 | 99 | 220 |
| 嗜血印 | 4 | 4000 | 79 | 146 |
| 紫塞秋风 | 5 | 5000 | 98 | 103 |
| 仙剑奇侠传七 | 5 | 6700 | 128 | 74.2 |
| 轩辕剑柒 | 3 | 3000 | 99 | 46 |
| 河洛群侠传 | 2 | 1000 | 88 | 45.8 |
游戏引擎¶
国内的计算机和游戏行业起步较晚，错过了引擎发展的黄金时期，技术探索缓慢，相关人员匮乏，所以当下大多游戏工作室都是依附于商业引擎上，如 Unreal Engine，Unity，Cocos，Godot，Cry Engine...，在一些中大厂，也有一些内部使用的自研引擎。
具体选择什么引擎，需要根据游戏项目的类型和体量来决定，具体可参考：
本文探讨的游戏类型是大型开放世界，而 Unreal Engine 5 提供了 开放世界项目 相应的工具集，使用它有着绝对的优势：
但 Unreal Engine 5 并不是万能的，它同样存在一些问题：
- Unreal Engine 5 提供的功能是易于使用，但不易于管理的，它保证了通用，而并非无所不能，因此需要有专业的引擎团队进行调校和扩展，项目才能持续推进，可目前而言，它的一些核心功能还在迭代，这种不稳定性会给开发团队带来很大的挑战。
- 熟练掌握UE5的（美术，策划，程序）人员是非常匮乏的，网络上散乱着各种零碎的文档和教程，这样培养出来的人往往很难在大型的团队协作中开展工作，在这种环境下，想要积累成熟的团队更是难上加难，不过好在近年官方花大气力攥写文档和技术博客，并开展了一系列培训，还有其他方面的一些协助，未来的形势会越来越好~
- UE 5.2 中文文档
- UE 技术博客
- UE 官方培训合集
- UE 开发路线图
- GAMES104-现代游戏引擎：从入门到实践
- Unreal Engine 是一个引擎技术的 供应商（Supplier） ，对于游戏中的图形要素（天空大气，地形，植被，场景模型，光照阴影，人物，布料，毛发，流体模拟...）的具体细节，并没有官方统一的标准参数或方案，UE默认是倾向于美术效果的，而在实际项目中，想要平衡项目的性能和美术效果是一件非常困难的事情。
游戏玩法¶
网络上有不少针对开放世界玩法设计的分析，笔者看过一些，给我的感觉是 ”逆向" 做的确实不错，但就有点像是：上学语文考试遇到的阅读题， 题目问“通过这段话，作者表达了什么情感？”，而我能做的，只是根据 结果 去编一个 让第三方看起来合理 的过程。
在 编辑器架构 这篇文章中，有提到：一个UI设计师会综合考虑界面的排版，色调，图标和布局去制作出精美的用户界面，但想要做好 组件化设计 ，却是一件非常困难的事情，因为艺术家们往往没有开发人员那么缜密的逻辑思维。
一个失败的组件化设计，将会增重用户的认知负担，并且让程序的扩展和维护变得困难。
而在游戏项目中，一个失败的玩法设计，将会增加玩家的上手难度，导致团队的工作量激增，成本飙升，管理混乱等。
硬件资源¶
在游戏中，大量采用了实时渲染技术，因为游戏平台的计算资源是有限的，高品质的美术效果往往伴随着很大的性能损耗，对于一个游戏来说，真正对玩家有吸引力的是游戏性，美术品质只是锦上添花，而非画龙点睛。
因此我们需要在不影响游戏性的前提下，再去思考如何提升美术品质，做出取舍是必然的，考虑 “取巧” 可以让“鱼和熊掌兼得”。
这里有一个当下软硬件的分布情况：
可以看出，目前主流的显卡依旧是 NVIDIA GeForce GTX 1650，而显卡的配置就代表了游戏图形的算力，甚至决定了某个美术效果能不能使用。
考虑到国内玩家群体的电脑配置普遍不会太高，游戏开发团队为了争取到更多的用户，需要做很多的优化工作和兼容方案，而这会带来巨量的试错成本。
项目管理¶
笔者并非专业的项目管理人员，跟一些业内的小伙伴有过沟通，发现一些团队或多或少都存在这样的问题：
- 工具链老旧，工作效率低下
- 团队之间的沟通协作，会在不经意间产生一个个小的信息茧房，人员的职责划分和版本的开发周期往往是很难明确的，而这些问题如果没有处理好，会逐渐导致项目的开发流程变得混乱，甚至失控。
- （编不动了0.0...）
省钱与偷懒¶
游戏在绝大多数情况下，是一种商品，它为玩家提供精神服务，开发团队通过它获取社会价值。
国内不乏优秀的游戏从业人员，完全有能力制作出高品质的游戏产品，实际上，我们面临的真正难题是游戏是否能盈利。
游戏项目的成本和营收，由诸多因素决定，成本方面，比如流程失控，人员变动，方向调整，很容易造成成本的飙升，营收方面，比如什么IP作者辱华，运营失误，盗版横行，BUG过多，优化太烂，稍有不慎，满盘皆输。
本文不讨论上述因素，仅从 技术人员 的角度，阐述一些对于 开放世界设计 基础建设 的见解，其核心思想是 优化流程，节约成本 ，其中主要围绕两个方面：
- 基于 Atomic 的玩法设计
- 基于 Meta 的开发流程
基于 Atomic 的玩法设计¶
开放的显著特征是 一定范围内 的自由，这种自由往往需要庞大的玩法体系来支撑，在上文我们提到，一个失败的玩法设计，将会增加玩家的上手难度，导致团队的工作量激增，成本飙升，管理混乱，那什么是一个成功的玩法设计呢？
本节通过《塞尔达传说：王国之泪》来做简单的分析。
王国之泪的核心角色玩法如下：
从上图可以看出，王国之泪的核心玩法并不复杂，它有着非常 低粒度 的结构设计，而上层玩法几乎是完全建立在这个 基础骨架 上，从而保证了高度的资源复用。
再看王国之泪的怪物体系：
怪物设计同样有着 低粒度 的结构设计，也是在上层高度复用，比如丘丘怪，有着普通丘丘，电丘丘，火丘丘，兵丘丘，它们分布在不同的地区。
与之相似的还有：
- 八爪怪：水八爪怪，森八爪怪，岩八爪怪，雪八爪怪，宝八爪怪
- 蝙蝠：普通蝙蝠，电蝙蝠，火蝙蝠，冰蝙蝠
- 岩石人：普通岩石人，熔岩人，冰岩人
- 魔法师：电击长袍魔法师，火焰长袍魔法师，冰雪长袍魔法师
- 古栗欧克：火焰古栗欧克，冰雪古栗欧克，雷电古栗欧克，古栗欧克王
- ...
还有根据怪物等级进行复用的：
- 波克布林：普通波克布林，蓝色波克布林，黑色波克布林，骷髅波克布林，白银波克布林
- 莱尼尔：普通莱尼尔，蓝鬃莱尼尔，白鬃莱尼尔，白银莱尼尔
- ...
详见：
再看烹饪玩法：
- 食品被划分为 水果类，蘑菇类，肉类，鱼类，蔬菜类，结合调料可以制作菜肴，怪物碎片和昆虫可以制作药材，开发者根据这些大类制作了 烹饪 模板（Template） ，比如任意
蘑菇类食品和水果类食品放一起烹饪，得到是水果拌蘑菇，然后取小类上的一些物品 生成特定（Specialize） 的菜肴，比如塔邦挞小麦+山羊奶油+生命鲑鱼=干煎鲑鱼，这类物品可以影响角色的状态（体力，精力，Buff...），甚至推进游戏进度的发展。
具体的烹饪公式，详见 塞尔达传说王国之泪料理配方大全一览
综上，不难看出，王国之泪的核心玩法是一种 自顶向下 的设计方式，就像是这样：
而上层玩法，则是在核心玩法的基础上， 自底向上进行组合 ，其中的重要手段是：在抽象级别制作 模板（Template） ，实例级别处理 特化（Specialize） ，就像是这样：
而这一设计理念，有点类似于UI设计中的原子设计理论，这里有一本非常非常非常好的相关书籍：
它的目录结构如下：
虽然这是一本介绍UI设计的书籍，但它的很多理念特别适用于开放世界的玩法设计。
遵循原子设计理念可以尽可能的复用项目资源，让开放流程更清晰直观，此外，还需要强调一点的是：
- 在开发初期，就应该明确开放世界的核心玩法设计
因为后续的场景规范和逻辑开发都是围绕着核心玩法进行的，还是以塞尔达为例，它的场景元素有：
在明确核心角色玩法之后，开发团队才能制定与之对应的 场景规范 ，确立 性能优化指标 ，并制作相应的 工具链 。
例如这样的规范：
- 根据角色的精力（游泳，攀爬，滑翔）机制，去定制地形高度，坡度和水体的规范。
- 根据通天术的技能要求，去定制地形规范。
- 根据究极手，余料建造，倒转乾坤这些技能的特性，去制作符合其要求的可交互物件。
- 武器（单手剑，双手剑，长枪，盾牌，箭）可以进行余料建造，在对应的插槽上进行特性绑定，来制定余料物品的规范。
- 已知角色的状态类别，可以去制作不同的场景效果，比如雷击，着火，寒冷，炎热，并为之提供相应的解决方案（服装 or 料理）。
- 在没有与核心玩法设计规范出现冲突的前提下， 制作左纳乌科技的玩法。
针对这些规范，引擎开发人员可以进行类似如下的开发工作：
- 定制
地形可攀爬高度，水体可穿越区域，通天术可使用区域的调试视图（如果UE支持不改源码，能以插件的形式扩展调试视图就很舒服）。 - 验证各种特效，场景效果的性能指数，调校效果与性能的平衡，并制作相应的管理和验收工具。
上述内容虽然不是游戏的重心，但如果这些 基础建设 没有做好，将会是流程混乱的开端。
基于 Meta 的开发流程¶
关于Meta，笔者在编辑器架构一文中有所提及，Meta思维在现代工业软件开发过程中可以提供极大的便捷度，它能完成一劳永逸的代码扩展方式。
关于 meta 思维的联想词有：
求导，高阶维度，上帝视角，... 详见： [ 知乎 ] bus waiter- 谈meta
假如将写代码比作盖房子，我们考虑的是如何盖好房子，那在Meta层面，我们考虑的是如何构建一台自动盖房子的机器，Meta思维让我们从一个工程问题转换成了另一个，虽然难度有所上升，但只要方法得当，它能带来无可比拟的收益。
在传统的开发流程中，我们思考的是 如何构建具体的产品 ，而Meta的流程下，我们思考的是 如何搭建产品的生产管线 ，其关键的思考维度是： 操作也是数据（Operation is also data） ，相较于具体产品， 管线是易于对比，积累和迭代的 。
Meta思维为工业化的流程提供了极大的便捷，试想一个这样的场景：
- 你是一个勤勤恳恳的UE小美术，某天，你突然收到一个大佬那边传来的一个需求：要为某个场景铺上植被。你一想，这我熟啊，立马整了几个植被模型，打开UE5的植被模式，用 画刷 咔咔几下，就把植被给刷好了，叫来大佬一看，大佬说：“你这不行啊，一点意境都没有，再改一版。”，然后你绞尽脑汁，废寝忘食，折腾好几天，终于是搞完了，前后一对比，确实好了不少，叫来大佬再看，大佬也是连连称赞，然后这事也就翻篇了，直到某个风雨交加的下午，一个自称是引擎开发工程师的小秃子带着质问的语气问你：“这片植被是你做的吗？”，你只得颤颤巍巍到：“是...是啊，怎么啦？”，“现在场景的复杂度变高了，植被这里的性能消耗很高，植被模型面数也比较高，并且刷得太密了”，然后啪啪摆出一堆性能测试结果作为证据，让你进行优化，可是如果要优化的话，就得重新再刷一遍，又是几天繁琐的工作量，于是你找到大佬，渴望大佬救自己于水火之中，大佬说：“改吧，注意形态效果要跟之前差不多。”，听闻此言，宛若晴天霹雳，但为了保住这份工，你无奈只能照做，浑浑噩噩几天，终于熬了出来，叫来小秃子一看，确实少了不少，于是它心满意足的离开了，结果第二天，这个*又回来了，说是优化的还不够，还得减，你一听，怒发冲冠，一脚踹在小秃子身上，看着它躺在地上嚎啕大哭的样子，你仰天大笑，笑着笑着睁开了双眼，挣扎着从电脑桌前支棱起来，擦去嘴角的口水，继续加班~
回顾两位主角，他们自身都存在一定问题：
- 美术人员 只关注艺术效果，对性能的关注度有所缺失。
- 引擎人员 没有提前定制好规范，对逐渐复杂的工程没有做好及时的管控。
但真的是他们的问题吗?
- 难道美术人员还需要深入了解图形学和计算机硬件？
- 引擎人员真的有能力第一时间把控整个团队的开发动向？
很显然，我觉得并不完全是他们的问题，因为这些问题已经超出了他们的能力范畴，但在流程上，我们可以通过一些工具和策略，来规避此类问题：
- 美术制作流程上的 程序化（Procedural）
- 引擎管控流程上的 自动化（Automation ）
程序化（Procedural）¶
程序化（Procedural）也叫过程化，它指特定问题的求解过程。程序化应用的本质上是将问题的求解过程当作是数据资产进行存储，从而保证后续开发能够依靠这些操作数据，进行复用，迭代等（在概念上，它就是一个程序，只不过是在程序中的程序）。
游戏行业当下对程序化的应用主要有：
而这些技术，其实已经逐渐渗透到了美术资产制作的日常当中，它的显著特征是： 通过编程来制作资产而非只有调参 。
以Unreal Engine为例，它有着优秀的程序化支持：
- Procedural Content Generation ：虚幻中用于PCG的工具集，它为技术美术师、设计师和程序员提供了构建快速、迭代工具和任何复杂性内容的能力，范围从资产（例如建筑物或生物群落生成）到整个世界。
- Meta Sounds ：支持进行用户自定义、第三方可扩展、图表重复利用，并提供了可以在编辑器中进行声音设计的强大工具。
- Geometry Script：虚幻插件，提供了一组使用蓝图和Python生成和编辑网格体几何体的，它可以在编辑器工具控件（ Editor Utility Widgets）中编写几何体脚本（Geometry Scripting）和 资产操作（Asset Actions）来创建自定义网格体分析函数库、处理和编辑工具，还可以在Actor蓝图中用它创建程序化对象并实现复杂的几何查询。
- Animation Blueprints：用于模拟或在游戏中控制骨骼网格体的蓝图，可以在其中混合动画，调整骨架，创建逻辑来定义每帧使用的最终动画姿势（Pose）
- Material Blueprint：用于定义场景对象表面属性的蓝图，可以使用各种图像（纹理），基于节点的材质表达式 以及 材质本身的固有属性 来定义 场景物体最终的表面属性。
对于PCG框架，笔者建议深入学习官方的 《Electric Dreams》项目，以及一些相关资料：
- 『UE5 PCG』官方公开课：深入研究Electric Dreams环境项目
- Electric Dreams PCG技术详解（一）——术语、工具和图表介绍
- Electric Dreams PCG技术详解（二）——沟壑、大型Assembly
- Electric Dreams PCG技术详解（三）——森林、岩石和场景背景
- Electric Dreams PCG技术详解（四）——远景、雾气、自定义节点及子图表
自动化（Automation ）¶
自动化（Automation ）描述了一系列减少流程中人为干预的技术，即通过预先确定决策标准、子流程关系和相关操作，以及在机器中体现这些预先确定。自动化可以通过多种方式实现，通常是组合使用。复杂的系统，例如现代工厂、飞机和船舶通常使用所有这些技术的组合。自动化的好处包括节省劳动力、减少浪费、节省电力成本，节省材料成本，并提高质量、准确性和精确度。
在软件系统开发中，自动化技术常见用法是：自动化测试与打包发布。
在游戏开发中，自动化的流程对中大型团队而言至关重要，它的优势在于 易于迭代和积累 。
在UE5开放世界项目中，自动化的有着很多的用武之地：
- 自动化的打包发布流程
- 性能和效果平衡方案的自动化测试（光影，HLOD，地形，植被等各种优化策略）
- 自动化验证和验收流程
- ...
在《Fortnite》的官方演讲中，简单提到了他们是如何通过自动化来探索出真正高效的树木策略。