游戏试玩：https://kkdt0fxrav.feishu.cn/drive/folder/JCtSfUqM9llJ3ndqX4ScQgb6njc
B站游戏区：https://www.biligame.com/detail/?id=110605

游戏截图

Cover1

游戏介绍

背景设定

这是一款基于光和电转换的解密游戏。在游戏中，玩家需要通过操作不同的元件装置，实现光和电的相互转换，解开各种远古文明遗留的谜题，找到通往遗迹深处的路径。

在游戏中，玩家需要利用光的反射、折射等特性，将光线引导至正确的位置，以触发电路，解开谜题。同时，玩家还需要根据电路的连接方式，利用电流的传输规律，操控各种电路设备，借助它们探寻真相。

游戏设有多个关卡，每一关都按照难度曲线设置了多样化的挑战，需要玩家不断思考、尝试，以找到完成试练的最优解法。

在该游戏中，玩家将扮演一名古老部落的传承者，他在命运的驱使下踏上旅程，前往探寻两个失落已久的文明留存的知识。玩家在逐步解锁古代文明的机关与遗址后，将发现其背后与灾厄、毁灭、拯救有关的深邃秘密。

基本信息

平台：PC；

类型：3D解谜；

玩法简介

WASD移动，空格跳跃；

E交互，右键伸出火把；

游戏内可以更改键位。

分工

组内一共有五位同学：我、Perhacept、指定龙场、Barrucade、ppppp

我：程序、技术美术、PM；
Perhacept：策划，程序；
指定龙场：3D美术；
Barrucade：策划；
ppppp：2D美术、UI；

前期产品分析设计

与Game Jam等短时间内的游戏开发不同，对于这种较大型游戏项目开发，在正式投入生产制作之前，单独花费时间进行产品设计分析、程序框架架构设计是非常必要的。主要需要做的分析及设计有：

确定游戏的目标受众和核心玩法，以更好地了解游戏的目标受众以及整体风格和氛围。这些因素将在整个开发过程中影响所有的设计决策，因此确定它们是至关重要的。

确定技术需求，进行程序框架和架构设计。这将在整个开发过程中指导开发人员的技术决策，并且可以在设计前期就为游戏的后期发展打好基础，方便后期进行拓展开发。

作品系统分析

在作品系统分析阶段，主要对游戏的玩法以及核心机制进行分析，并据此设计技术路线以及初步实现思路。

作品玩法

本作品为PC端3D关卡类解谜游戏。解谜游戏要求使用较为单一的操作或者机制组成多种多样的关卡，而关卡类游戏要求在开发后期的量产阶段可以迅速产出新关卡。

因此，本作品的程序设计必须具有极强的可拓展性和复用性。

可拓展性体现在于，可以迅速在原有框架内添加新玩法元素；复用性体现在，可以使用有限的玩法组件迅速搭建出各种新关卡。

核心机制

本作品的核心机制主要由火、光、电三种元素组成。为了降低玩家的学习成本，这三种元素应各自成一套较为相似体系。同时，为了具有较强的可拓展性，应使用接口进行通信。

因此，在程序设计方面，三套系统应各自使用一套解耦的体系，通过对应的接口实现体系间通信。

作品风格分析

美术风格

本作品的美术风格为治愈风格，类似吉比特画风。整个画面应该较为干净，色彩鲜亮。

因此，在渲染以及材质方面，应不使用真实渲染，并对细节进行控制，只保留必要细节，防止细节过多导致的杂乱。同时使用后处理等方法控制整体场景的色彩。

画面干净减少细节

用户体验设计

本作品重交互体验，因此对于某个场景元素，必须可以让玩家在短时间内分辨出其的性质，如能否交互，可如何交互等。其次，由于本作品有多个较为独立的系统，系统的边界必须是清晰可辨的。

因此在场景色彩设计中，可以使用自发光效果提升可交互元素的辨认度。每个系统可以有一个特定的、与其他系统明显不同的特征颜色，以此明确系统边界。

对于火光等光线设计，可以为其添加摇曳、明暗闪烁等效果，以提升沉浸度。

可交互物体的特征色

程序架构设计及应用

游戏框架

UE引擎自带一套Epic的游戏框架，是较为一套较为成熟的管理游戏逻辑的类和组件，主要包括游戏模式（Game Mode）、玩家控制器（Player Controller）、玩家角色（Pawn）等。直接使用其提供的框架可以更为便捷地开发。

游戏模式 Game Mode

游戏模式用于设置和实现游戏的规则，比如游戏的胜利条件、游戏暂停逻辑等，同时还控制着游戏的不同阶段，比如等待开始、进行中、结束等。每个关卡只能有一个游戏模式，可以根据不同的游戏类型或场景来创建不同的游戏模式子类。

在本作品中，设计一个游戏模式基类，其包含一些未实现的虚函数，如：暂停函数，切换关卡函数，玩家按任意键函数，保存游戏等。在子类中，根据具体关卡对其进行重载，实现对应功能。

设计一个枚举值EGameState来管理游戏状态，其包含游玩中、暂停中、玩家死亡、播放过场动画等游戏状态。在功能实现时可以根据游戏状态对同样的操作做出不同反应。

玩家控制器 Player Controller

玩家控制器用于接收和处理玩家的输入，并根据具体情况，将其转换为对Pawn的控制。玩家控制器还负责管理玩家的视角、摄像机、HUD等。一个玩家对应一个玩家控制器，可以根据不同关卡和需求来创建不同的玩家控制器子类。

在本作品中，设计一个玩家控制器基类，包含一些虚函数，如：按任意键、按确定键，按退出键等。在子类中发送到对应游戏模式的对应函数。

玩家控制器负责管理玩家的UI，其中实现如弹出的提示UI与确认窗口等。

除此之外，控制器中还要负责控制音频聆听者位置的设置。一般来讲，对于第三人称游戏，音频聆听者位置位于摄像机与角色之间，靠近角色的位置，沉浸感最强。

游戏实例 Game Instance

游戏实例是在当前游戏的实例中运行的逻辑，一般用于存储和同步游戏的状态和数据，比如玩家的设置、存档、成就等。游戏实例在整个游戏过程中都保持存在，不会因为地图切换而销毁。

在本作品中，其主要负责储存游戏和储存玩家设置等。

碰撞以及检测通道

UE的自定义通道可以用于控制不同的物理形体之间的碰撞和检测响应。可以自定义两种类型的检测通道：对象通道（Object Channel）和检测通道（Trace Channel）。

在本作品中，对于交互机制，创建新对象通道Interactive对象，用于管理可交互物品的交互体积；此外，使用新对象通道Plate管理可以压下压力板的物体。

对于光线相关机制，创建对象通道Reflective和检测通道Light，用于光线的发射和反射相关逻辑的编写。

角色框架

基于UE自带的Character类进行拓展编写。

角色状态

使用枚举值ECharacterState管理角色的状态，根据玩家操作和状态进行切换，同时只能存在于一种状态中。

状态	枚举值	描述
站立	Stand	角色站立
移动	Run	自由走动或跑动
交互	Process	交互过程中
钩索	Hook	正在使用钩索
搬	Hold	正在搬东西
推	Push	正在推东西
休息	Rest	正在休息
程序移动	MoveTo	程序控制的移动
死亡	Die	死亡

玩家输入与角色反馈

一般来讲，要想增加玩家交互的爽快度，玩家应该可以使用少量输入对应大量不同反馈。

因此，在本项目中，对于玩家相同的输入，根据角色状态会产生不同的反馈，比如在玩家点击交互键时，如果没有火把角色会直接走过去交互，但如果有火把，角色会在走过去的同时收起火把。

根据角色状态对相同输入做出不同反应

角色动画及动作行为

UE的动画系统较为复杂，由动画蓝图，状态机，动画蒙太奇，混合空间等组成。其中动画蓝图控制着整个动画逻辑，状态机和混合空间控制玩家的状态动画，动画蒙太奇控制只播放一次的动作。

在本项目中，移动，推动，搬起等循环状态动画使用状态机控制；去交互、脱离交互、收起拿出火把等短时间内只播放一次的动作动画通过动画蒙太奇控制。整体通过动画蓝图进行统筹，并使用骨骼蒙版进行混合。

动画IK

IK可以通过给定的骨骼末端位置计算出前端骨骼的旋转值。

在本作品中，使用UE5的新功能Control Rig，在玩家移动时，通过射线检测，将人物双脚通过IK实时贴合地面，以防止在斜坡上角色悬空或穿模等视觉问题。

双脚吸附在地面

火相关玩法元素

火系统介绍及设计

火系统主要包括火把、篝火、易燃物等。主要机制为热量的传递，在到达燃点后燃烧，在燃点下会持续降温。

综上，本作品选择使用一个基类实现可以复用的功能函数，并通过接口传递热量。

基类设计

基类包含一些基本的状态变量，如：是否在燃烧、燃点、每秒向外传递热量等。同时还实现一些通用函数，如：向其他可燃物传递热量、接受其他燃烧物的热量等。

同时还需要实现一些音频播放、火焰特效播放、火焰摇曳等功能。

接口设计及通信

设计接口IFlammable，可以通过其中的HeatConduct函数传递热量。对于可以接受热量的物体，只需要实现此函数即可，扩展性强。

光相关玩法元素

光系统介绍及设计

光系统主要包含光线、反射镜等。主要机制为光线在普通表面停止传播，在反射镜表面反弹并继续传播。

综上，本作品选择使用射线检测进行光线传播，通过Light检测通道进行射线检测，有结果后根据检测点的碰撞类型决定光线行为：如为Reflective则继续反射，其他则停止反射。

光线击中不同物体的不同反应

接口设计及通信

本作品设计使用光能板可以将光能转化为电能，因此设计接口ILight在这两个系统间通信。其包含LightHit函数，射线检测对象只要实现了此函数就可以接受光能，保证了拓展性，降低了耦合度。

电相关玩法元素

电系统介绍及设计

电系统主要包含电池、电容、电线、开关等。主要机制是用过联通电路进行电能储存、传输与消耗。

综上，本作品使用接口在各个用电器间通信，传输电能并返回消耗的能量。并且设计一个电器基类，管理可以通电的玩法元素。

基类设计

基类包含一些基本的电量元素，如：现有电能，最大电能，消耗电能速度等。同时实现一些常用功能函数，如：充电，每秒消耗电能和向目标传输电能等。

接口设计及通信

设计接口IElectronic负责电能的传输，其中包含Conduct函数，输入电能和电压，返回消耗的电能。通过此，可以实现电容的充电和放电功能，需要添加新的电器元素只需要实现此接口即可。

交互相关玩法元素

交互系统介绍及设计

交互元素主要包括拉杆、开关、旋转台等。交互种类有默认交互（Process）、推（Push）、搬（Hold）等，通过枚举值EInteractType控制。在玩家角色中，玩家通过接口获得当前交互类型，并做出对应反馈。

通过碰撞检测通道控制交互响应

所有可交互体积都为Interactive物体通道，玩家只对此类型碰撞体产生交互反馈，以节省碰撞检测性能。

接口设计及通信

设计接口IInteract负责交互通信，其中的部分函数如下：

函数	介绍
CheckCanInteract	获取能否交互
GetInteractTipInfo	获取交互提示字
GetMoveToInfo	获取交互点位置及旋转
Interact	开始交互，返回交互种类
StopInteract	停止交互，返回停止交互种类
······	······

通过此接口的设计，如果需要添加新可交互物品，只需要全部实现接口函数即可，后期拓展十分方便。

音频框架

UE音频介绍

UE引擎的音频系统和框架是一套强大而灵活的工具和功能，用于创建和播放游戏内声音。包括音频类、Sound Cue、音频衰减、音频混合器、音频效果等。

音频类设计

音频类的作用是对游戏中的音频进行分类管理，以实现不同的音频行为和效果，如统一调节音量、混响、并发等。

在本作品中，在主音频类下分为三个子音频类：UI、音乐和音效。这三个大类可以在设置界面分别调整音量，同时一些混响设置应该只应用于音效，而不应该影响UI和音乐。

在音效类下，还细分为更多子音频类，用于分组微调音量、音高等。

音频类层级树

混响与脉冲响应函数

UE引擎自带的混响是一种算法混响，它使用延迟缓冲、滤波器和其他DSP拓扑来模拟声音在不同空间中的反射和衰减。

脉冲响应函数（IR函数）混响是一种卷积混响，它使用来自物理空间的音频样本来模拟混响。

这二者的区别在于，前者是基于算法的，后者是基于数据的。算法混响通常更灵活和高效，但不够真实和沉浸。数据混响通常更真实和沉浸，但可能更耗资源和复杂。

在本作品中，由于性能瓶颈在GPU，所以在CPU端可以使用一些较为复杂的资源，因此本作品使用的是更为真实的脉冲响应函数混响。

音频特效

音频特效主要是各种滤波器、回声等。主要有在衰减函数中应用的基于距离的特效以及子混合特效。

在衰减函数中，可以基于距离应用低通滤波器，模拟空气对于高频音波的吸收。子混合则可以更灵活地应用各种效果，将子混合预设应用到对应音频类上就可以根据音频类控制特效。

结论及展望

遇到的问题及解决方案

Git同步大文件的问题

在使用Git进行版本管理过程中，出现了部分地图、贴图等非文本文件过大导致（超过100MB）导致无法提交的情况。

经过资料的查阅，最终使用了Git的Large File Storge（LFS）扩展解决了问题。Git LFS可以用来管理大文件，比如音频、视频、数据集、图形等。

不过最佳方案是在制作阶段就尽量避免大文件的出现，尽量避免将无关文件提交至云端、提前压缩贴图文件、或是拆分大文件等。

优化问题

在后期打包测试时，打包出的文件出现了帧率过低卡顿的问题，但在编辑期内测试并无卡顿迹象，需要定位性能瓶颈并进行优化。

首先，使用UE自带的stat unit定位出性能瓶颈为GPU，然后观察运行时任务管理器曲线确定瓶颈为显存不足，由此推断场景内贴图过大导致显存不足，最终拉低帧率。

定位可能的问题点后，尝试通过压缩贴图解决显存问题，主要方法如下：

方法	原理	适用范围
降分辨率	直接降低图片分辨率	远超所需精细度的贴图
合并单通道贴图	将多个单通道贴图分通道合并为一个多通道贴图	单通道且分辨率相同的贴图
修改压缩方式	对于单通道贴图，只储存一个通道的颜色值	无法合并的单通道贴图