从UE3到UE4采取“生命是奇怪的”

来自黑风基金会(Black Wind Foundation)的才华横溢的开发人员谈到了将屡获殊荣的冒险游戏从台式机和游戏机引入移动平台的一些技术挑战。

将项目从UE3传输到UE4

将项目从UE3转移到UE4可以与转换到新引擎进行比较,因为几乎所有内容都不同:编程语言(虚幻脚本与C ++),逻辑创建系统(Kismet与蓝图),内容组织(资产包与单独的资产) ),甚至单位的尺寸都已更改(2厘米对1厘米)。 您可以在这里找到更多信息。

总而言之,一个人不能简单地将一个UE3 / UDK项目变成一个UE4项目。 对于“奇异人生”,我们已经开发了用于转移地图,资产,逻辑等的工具集。此外,我们的程序员不得不手动转移代码,因为由于移至另一个平台而不得不对其进行优化和清理。 此外,由于灯光系统,后处理参数和材料系统的差异,我们必须修改UE4才能将参数调整为UE3。 这使我们能够保持游戏独特的视觉风格而不会造成任何中断。

最后但并非最不重要的一点是,原始游戏的引擎在许多方面也进行了重大修改。 但是,由于使用了开源代码并将C ++用作UE4中的主要编程语言,因此我们能够对移动版本的引擎实施所有必要的(甚至额外的)修改。

视觉效果

移植的主要目的之一是将原始游戏的独特视觉风格保持在与上一代游戏机(PS3)接近的质量水平上。 移动设备的制造商喜欢将其产品描述为具有“与控制台相似的性能”。 但是,事实并非如此。移动平台具有更多的局限性和由平台决定的其他特定功能。 RHI和ES3.1的发布改善了这种情况,但这根本不是普遍的补救办法。

此外,原始游戏中使用了特殊的着色器和灯光系统。 因此,我们必须添加新的着色模型,例如Blinn Microfacet和SSS,并“使其在移动设备上起作用”。 另外,我已经提到我们已经进行了很多工作,以便“调整”灯光系统和后处理程序,使其适应原始游戏中使用的系统。

纹理是一个单独的挑战。 游戏充满了高度详细的超大纹理。 传统的PVRTC格式不支持此类纹理,这会导致图像尺寸过大,并且在压缩期间会对其造成很大损害。

同样,我们使用了在Apple设备上支持ASTC压缩的Metal RHI和在Android设备上支持ETC2压缩的ES3.1。 提及的压缩类型支持以任意长宽比纹理化4的倍数,并允许在压缩后获得良好的图像质量和文件大小。

拍照模式

我们已自行开发了适用于“奇异人生”的照片模式,并考虑了所需的功能,引擎的更改以及与平台的集成,以支持本机保存和共享。

照片模式看起来不像是“繁重的”功能。 但是,它有很多陷阱。 例如,在拍摄时,游戏应为“冻结”状态。 但是,应该具有控制摄像机,角色的位置和服装的功能。 播放器还应该能够在后期处理和屏幕效果的帮助下更改图像。 从照片模式切换回后,游戏应从初始状态继续。 许多事情可能出错。 遗忘或破坏物品的风险很高。 此外,每个平台在保存和共享图像方面都有自己的方法和权限,这带来了额外的麻烦。 尽管如此,结果值得付出努力。

工作流程

这不是我们移动平台的第一个端口(而且我敢肯定不是最后一个端口)。 每个类似的项目都需要特定的方法和工作组织。 在该项目下,主要挑战是创建和使用从UE3到UE4进行项目转移的工具集,以及对项目的逻辑,播放和视觉表示进行持续控制的移动平台优化。 另外,不要忘记控件和UI的适应性,因为移动设备在交互体验方面有很大差异。

建议:预留时间进行研究,以确定可能的风险/挑战并找到克服/解决它们的方法; 定义平台并指定支持的设备范围; 连续控制每个设备的性能; 要有耐心和冷静-您的道路艰难而充满挑战。 没有准备好? 然后,只需致电专家-与我们联系)。

黑翼基金会Yuri Denisyuk

基里尔·托卡列夫(Kirill Tokarev)的访谈

寻找更多关于80级的文章。