【七夜：救赎】项目技术大纲
《七夜：救赎》项目是我们团队正在研发中的一款叙事类恐怖单机游戏，目前已经研发近两年。在这个过程中我们积累了一些经验和思考，有机会的话都会整理出来给大家分享。
这篇文章主要是把我们在研发中使用的技术方案进行汇总归纳，这些技术方案目前来看是适用于我们项目的，所以仅供参考。
1-引擎
因为七夜原作在当年的画面处于顶流的水平，作为续作我们也期望了一个较高的目标点，基于此目标我们选择了 UnrealEngine，我们对 UnrealEngine 做了大量的探索和研究，力图将引擎的能力发挥到极致。
UnrealEngine 包含了一套优异的基于物理的渲染系统，我们在此基础上制作了大量精美的材质来丰富游戏的观感体验，再配备影视级的后处理方案，让玩家获得观影的享受。
2-游戏性
工具
- 事件系统
在游戏性框架上，UnrealEngine 并没有提供足够好的工具来支撑七夜的开发，所以我们开发了事件系统并配备了对应的可视化逻辑编辑器，让策划能在一个友好的环境中高速迭代玩法流程。
编辑器完全基于C++开发，并集成了 json 的功能支持，使得事件脚本拥有了多人协作合并的能力，并且提供了运行时热更新功能，策划人员可以随时进行调整并立即生效，使得迭代更加快速高效。
我们还集成了脚本编程语言 lua，并自行集成了实时热更新和调试功能，并配备了完整的开发框架，且和脚本事件系统拥有深度的集成。
后续我们准备转移到更加具有工程属性的语言C#上进一步的提高性能和稳定性。
- 快照系统
为了进一步缩短了游戏迭代周期，我们还配备了游戏快照系统。
通过快照系统能够让开发人员记录任意时刻的游戏状态，并在开发人员之间共享，同时采用 Json 进行文本保存，策划可以根据需要修改存档，为验证功能、排查bug提供了便利。
- 房间管理系统
七夜的故事在一个古堡中发生，古堡中有上百个细节丰富的房间，也就是所谓的“室内大世界”，而 UnrealEngine 没有提供相关的支持，这带来了不少全新的挑战。我们为此开发了一系列的工具：
首先是描述房间属性和空间关系的图表：
由于 UnrealEngine 对于编辑器内浏览大场景内小部分子关卡的功能支持不完善，于是我们针对我们的项目开发了任意加载并编辑房间关卡的浏览器：
并且我们在游戏运行时也基于房间空间关系自定义了一整套房间的流式加载机制来提升游戏的性能表现。
- 调试系统
游戏开发过程中，策划经常需要在运行时获取信息，或对一些状态进行实时调整，同时，测试人员也需要使用这些功能节省测试时间。考虑到 UnrealEngine 的自带基于 Slate 的编辑器界面开发周期较长、代码较为复杂，最为重要的是不能够发布到打包版本中，而 Command 命令行对于测试人员又较为难记，且不够直观友好，经过讨论和商议，我们最终将开源的 ImGui 可视化调试界面接入 UnrealEngine。
经过努力，自行接入的 ImGui 调试界面也与 Lua 脚本完美对接，因此享有热更新能力，极大程度上降低了策划、程序的开发难度，使得开发效率及测试效率大幅提升。
3-UI
在用户界面方面，我们尝试了UMG+蓝图和UMG+Cpp+Lua的技术方案，效果都不尽人意，UMG带来的效率、迭代速度、控件功能都存在不少短板，在切换游戏世界时还会存在一些问题，所以当前我们在自研一套基于前端的UI技术方案。
在自研新的 UI 技术方案的同时，我们也很重视 UI 与 UX 设计方面的积累。在取得微软相关作者的许可后，我们翻译完善了资深 UI 设计师发表的一系列 UI 与 UX 设计相关文章。
4-3C
镜头方面，为了实现电影化的体验，我们采用了预编镜头和自由镜头共存的模式，分别实现了过肩镜头和丰富的可编程预编镜头。
相应的，我们还对预编镜头下的操控进行了优化，尽量的降低了这种镜头所被人诟病的方向感丢失的问题。
动画方面，我们调研了大量游戏的动画方案，包括但不限于生化危机，恶灵附身，量子破碎，古墓丽影，和 UnrealEngine 官方的 Paragon 等等，吸取了大量的技术点和经验。
基于 UnrealEngine 自带的工具和自己增加的一系列扩展，争取在视觉效果和操控体验之间得到一个平衡。
5-渲染
光照
由于“室内大世界”的特殊性，我们实现了一套自定义的的光照烘焙系统来克服巨大资产量的烘焙问题和大量房间之间光照的流式加载问题。
并且我们开发了房间灯光动态管理系统来对各个房间的灯光亮度进行控制，并当玩家处于不同房间时对体积光照图进行流式加载并切换。
后处理
受《战争机器》的启发，我们为后处理进行了一系列的扩展，使得灯光师能够在后处理中控制全局的灯光，雾效参数，让房间之间的环境更加丰富多变的同时保证过度的自然性。
工具
如今社区中存在大量的优秀素材，我们也使用了不少这些素材，但是在使用之前依然需要进行标准化以和我们已有的技术和美术完美融合，为此我们开发了一系列的工具：
- 贴图规格处理
- 模型材质处理
6-演出
定序器
为了配合策划快速开发 QTE 的交互式演出效果，我们为定序器添加了 UMG 扩展，使得 QTE 的界面可以直接在定序器中生成并设置关键帧驱动，让交互的开发非常直观。
我们还使用了 Control Rig 配合定序器在引擎中直接制作动画来完成快速原型验证和制作动作捕捉的动画变体。
动作捕捉方案
对比了多种动捕方案后，在项目前期我们选择使用 rokoko 的惯性动捕，因为
- 场地限制小
- 不需要花费太多时间在搭建设备上
- 动画师可以直接在工位旁边录制大部分动作
- 迭代快
- 通过 Live Link 可以直接在游戏运行时预览动捕效果
- 直接在引擎中录制成动画片段，然后可以通过 Control Rig 初步修正资源 ，就能直接实装到游戏中，整个过程都在引擎内完成，等验证完再导出到 Maya 细调
后期再使用光学动捕并聘请专业演员全方面提升动作效果。
7-音效
WWise
音效方面我们选择了 WWise 中间件作为开发工具，WWise 被业界广泛使用，拥有丰富的资料和插件，基本可以满足所有需求，我们深入研究了房间的空间音频效果，为每个房间都精心编排了环境音和混响环境，并且扩展开发了房间音效管理机制来减少声音的混杂，进一步的，我们将 WWise 的事件集成到了事件编辑器中以提供游戏进程相关的交互式沉浸音效体验。
Project Acoustics
为了追求比 WWise 自带的空间音频引擎更真实的浸入感，我们还调研了微软开发的 Project Acoustics 声波模拟引擎，使用 Project Acoustics 替换 WWise 的空间音频引擎能带来以假乱真的视听体验。
由于烘培一次成本较高，8核cpu运算一个探针需要800秒，考虑到巨量房间的相关性与复杂性，我们预估完整游戏约有3500个探针，烘培一次需要耗时约32天，迭代成本巨大。在后期游戏基本定型后，我们将考虑大批量租用微软 Azure 进行运算并集成到项目中。
