从unity引擎切换到虚幻引擎一个高水平的决定

     首先说我(和其他团队成员)仍然是unity的粉丝。我们团队已经使用unity从v3.X开始。(包括职业许可证)和CONTINUE继续使用各种项目。如果我今天开始一个项目,我仍会选择unity。

     我们取得了很大的进步在原型ExtroForge unity引擎上。大批的游戏元素设计和集成。我们繁荣丰富多样的资源存储包以及我们多年的在线文章、博客和教程。至少有两个15年的软件工程专业团队,我们在unity下是高效、熟练的。

     那就是说,我们必须获取unity引擎的一个点,一个方面成为一个至关重要的拦截器—多人网络。几个人的unity经验与unity建立多人项目——一个使用第三方与内置RakNet SmartfoxServer和其他功能。然而,Extroforge带来了一些特定需求。包括权威服务器逻辑,服务器端物理和逻辑碰撞和高性能(Extroforge FPS部分和RTS部分在许多方面)。我们原型多人使用内置的网络,与此同时,看着一些第三方的选项。我们热切期待着unity5 +网络——UNet的替代品。

     第一次迭代是令人印象深刻的。极其有限(失踪?)文档和古怪的(车吗?片状?)的性能。简单的复制动画模型(位置/旋转)非功能性或super-laggy。我们尝试。我们读论坛的帖子。我们等待着。没有官方unity教程。一些人做教程视频,我们跟着实际上放弃了,决定等到将来的版本中。然后unity路线图发表。与独立的仿真的实现服务器推到2016年3月(加上其他元素定义),我们决定去看看其他的选择。愉快的冲击是什么点燃unreal的启动项目,第一次看到小侧菜单下的“播放”按钮允许你自动启动不是一个专用的服务器,也尽可能多的“额外”玩家的客户你想。这是多人涅槃。

    注意,这不仅仅是一个决策基于多人功能构建到引擎。我们花了不少时间去世界/地形/叶/水里去找我们想要的方式。我们的团队/工作室负责人是谁负责的外观和感觉决定看一些其他游戏引擎,看他多快能达到期望的结果(我们使用unity结果看起来太卡通或太“粘土状的”)。

    看到CryEngine很美丽的“盒子”,他几乎哭了。但令人信服的团队到这样一个简易型、小型社区,高学习环境是行不通的。虚幻,所需的外观和感觉很快被创建和我们都更加适应用户社区,文档和工具集(包括图纸)。

    一旦我们确信（通过一些示例项目和原型阶段），我们可以得到我们想要的look-n-feel–与多人游戏的稳定性和可扩展性，史诗带来的表（在多人FPS空间）,官方决定跳。这是一个艰难的决定。我们有很多unity具体的代码和内容(包括我们的程序基于网格体素实现)。我们熟悉的unity方式做事——包括c#语言。蓝图和c++给我们超过片刻的停顿…但我们犯了。

c#和c++还有蓝图···

    ExtroForge团队有一些技术深度。高级工程师都在C和c++年前——尽管已经转移到管理自——沉重的Java和c#语言。团队的其他成员有复杂的经验不同的高级语言。我们经验丰富的面向对象和基于组件的设计。c#是一种简单的语言与unity合作和增加GameObject及其相关弟兄们带到桌上已经成为我们的第二天性。我承认蓝图的概念在虚幻的让我害怕。有趣的是,没有人做过任何视觉脚本之前,所以我们没有比较。我有一些不好的经历与有线预制在unity中,我们很容易失去很多重要的设置。我很习惯建立重要值和设置在代码。,恐惧,以及许多落后我们多年的软件开发经验,让我相信我们能/会的灰尘吹走我们的C + +技能和开始。我被鼓舞的是,大部分的起动器的示例项目,通过引擎可用下载/安装/编辑器有一个蓝图和c++版本。然而,鼓励是短暂的。不是声音贬低,而是因为“业余爱好者”,聚集大量的不真实,因为它的价格,有大量的教程,论坛帖子、视频等等与蓝图完成真实任务有关的土地。在c++有更少的土地。起初我不太担心。给我一个好的API文档(和引擎源码),我应该没事的。

是的,不是那么多。

    很难记住或研究的“正确”的方式做事情在一个陌生的语言,学习“虚幻”的方式做相同的事情有时太为我小的大脑。即使我有一点点成功的c++一侧(一些自定义结构/类来体现我们的体素世界),我无法让虚幻的允许使用这些自定义结构体/类在某些领域(如RPC调用)。哦,我可以通过编译错误通过添加适当的宏或适当的命名我的结构/类——但即使,RPC调用,使用一个自定义结构简单生产空结果另一边(我仍然没有想明白一个问题,所以我把东西在虚幻的具体结构和转换/ de-convert另一边)。这个问题不谈,我们生活在c++土地取得进展。我能够动态参考网格或材料在运行时(的名字),这样我就不会被任何脆弱线路损失,我经历了与unity。耶！直到我们尝试独立non-editor构建。然后在运行时动态技术来抓住这些资源下跌与丑陋的错误。我读过的所有文章和尝试了所有的技术,仍然发现自己不能在运行时()动态地获取材料或网状或蓝图的名字在c++运行时。所以我开始仔细看看图纸,看看他们会有所帮助。

一位资深团队成员已经开始连接一些蓝图的功能,增加骨骼第一人称角色BP与c++类的我一直在工作。创建小盒子…拖小电线…。所有的颜色! ! !我很着迷。大多数是输入/控制相关以及GUI元素/ UI的东西-我想可能是最好的使用蓝图。我开始涉足蓝图自己是材料的逻辑。我惊讶的东西我们可以很容易地在几秒钟内做材料了…的蓝图。在unity里面编写着色器代码。它很简单,它是快,(我敢说)令人满意��乐趣。虽然我的代码仍然牢牢在c++中,我们慢慢学会了暴露变量从c++,以便可以根据需要从这些输入/访问UI蓝图(还没决定如果你可以访问一个BP变量/函数从c++的一面,但它看起来是痛苦的)。我得知我可以创建重要的比赛的关键设置和初始化数组元素在c++中(non-binary-corruptible文件)是安全的,让它作为必要的蓝图。

排序的。

    有趣的是…枚举现在存在的我的克星。我喜欢举例：是一个巨大的风扇从黎明前的时间和使用他们在每一个高级语言,因为我是一个工程师。

    很多低层次的元素我们的游戏使用枚举底部来表示各种各样的东西,建筑类型,体素类型、资源类型、等等,等等,等等。我花了一点时间Unreal-ifying这些枚举,这样他们可以阅读适当和正确使用蓝图的土地(不真实更容易回到v4.7做了一些修改?你必须使用一些古怪的技术来处理)。核心和灵魂的事情,Blueprint-land并不知道枚举——但它知道8位字节,它对待(但你仍然可以引用它们作为Enum类型你精心设计的蓝图)。所有这一切放在一边,这个问题我们已经拥有(v4.9)是有时蓝图希望我们将枚举类型转换为一个字节,有时不是。有时蓝图的一部分,之前没有把一个字节,现在错误,需要它。AHHHGGGG。这不是不寻常的进行一系列的c++代码更改(与现有枚举)和蓝图编辑器编译后吓一跳,显示一万亿错误(所有相关Enum引用)。起初,我花了几个小时重建看似完美的节点有相同的输入和输出的错误。然后我学会了我就关闭编辑器和重新开放,一切都好。WTF ?没有一个好的工作流——但我们管理。这是可能的(或部分)是固定在4.91(几个枚举/ UEnum相关补丁的发布说明),所以我们将会看到。(更新-不-无论是4.9.1或4.9.2似乎已经固定这个…所以我们保持正念)。

    我们正在吸引越来越多的c++和蓝图一起,让c++函数蓝图,甚至创建自定义图纸节点。我知道我真的爱蓝图——以及他们的开发过程。他们代表一个完美的某些元素的游戏开发机制,我们感谢他们每天越来越多。大多数我们所做的和他们与玩家角色的行动——我们认为没有令人信服的理由让这些代码转移到c++的土地。不真实的——你的转换我! ! !

Asset Management

    Asset Management是一个非常成熟的东西。拖一个文件编辑器,将一个文件复制到文件夹的资源——这只是工作。将资源转移到不同的目录,只是拖拽。包的导入/导出功能(除了一些片状的依赖关系)是拔尖的。甚至有引擎功能暴露(通过编辑脚本),允许你代码各种neato-whizbang定制逻辑来管理你资源。我们的经历不真实,然而有些痛苦。其中一些是由于无知和缺乏经验在我们的,但一部分仍然是一个谜。试图迁移内容从一个项目转移到另一个不同的目录结构提供了许多浪费时间。试图迁移(使用工具提供的不真实)蓝图基于c++类是一个彻头彻尾的灾难。c++类不能被迁移,你必须复制自己,但你应该需要改变类名(我们从一个项目,我们想重命名自动生成字符控制器类)迁移的蓝图是永久瘫痪un-changeable原始类的引用。文件夹之间移动内容(in-editor)也是一个严重的疼痛点——虚幻的显式地留下的文件副本或空的子文件夹和各种各样的引用会破裂(一些un-fixable)。我们得到了这么多的最后一个问题,我们只是尽量不要移动内容——极其小心,我们项目从一开始的地方。平心而论,unity的关键资源数据库可能会损坏它,你在loooong一段重新输入所有的资源。但unity一切是自动检测自己的腐败和修复本身),而任何检测的问题或固定在虚幻的手动完成。

至于资源存储与不真实的市场而言,这仅仅是一种成熟。unity几年建立大型的和繁荣的商店充满自由/便宜和昂贵的资源(不同的质量)。作为一个作者的几个unity存储资源,我满意的内容创建和销售过程(最重要的是支付)。查找和导入新内容在unity中相当无痛。不真实的市场肯定是规模较小的小得多。甚至微小。和内容的“平均”价格更高。毫无疑问的。我们没有经验与出售(甚至购买)资源商店,必要时使用资源或起动器创建内部内容。

程序操纵网

    unity提供的能力操纵网���据(从头创建或操作后)的盒子。顶点,顶点颜色,uv -这是所有访问和良好的文档记录。多年来,我用它无数的原因——地形变形、网破坏/压裂,ExtroForge,我们的体元建设引擎需要它。它工作得很好,它是快速和无处不在。

我很惊讶地得知,功能从虚幻的“正式”失踪当我开始使用它(4.7左右))。地形变形不支持(至少与内置的景观类),甚至有趣的地形高度数据只能通过编辑器在运行时要求跟踪/ raycast地形的高度如果你想知道一个点!一个的论坛帖子,绝顶聪明的人有创建和发布自己的代码库来做一些基本的程序网格建设/操纵,但远未完成。v4.8,虚幻的发布了一个“实验性”ProceduralMeshComponent封闭一点的差距。我们能够繁殖体元程序网格技术在虚幻的(虽然我读到一些别人有问题,移动程序网格组件可以留下它的物理对撞机!)。4.9。X添加了一些增强,看起来他们将继续改进它。仍有一些什么不真实的差距提供了unity(如操纵现有的网格模型)但至少他们正朝着正确的方向前进。

照明

    虚幻的添加了一个令人难以置信的数量的开放世界照明工具我们的阿森纳。是的,联合推出了通过启发引擎实时全局照明,为一个开放的世界,但它仍然是有限的结构被添加和删除。我们真正受益的是现场环境闭塞的距离,通过光传播卷和实时间接照明。看着远处,在unity倾向于看平。一个遥远的山应该在下面的山谷投下一个阴影,但是我们无法实现,如果没有一个unity疯狂的影子距离。

虚幻引擎有一个解决方案。距离字段阴影和环境闭塞是为了遮挡遥远的东西以一种近似的方式看起来完美的从很远的地方。我们真的能够郁郁葱葱的和明亮的/阴影的世界,我们想与虚幻引擎。

使用光传播量,我们可以创建项目与发射材料暴露到附近的几何学。结果看起来非常棒。再一次——这是列为“实验”(我们不得不在引擎设置属性文件来启用它),但到目前为止,太好了!

开放世界的工具

    在unity中,我们使用自己的自定义生成地形高度逻辑以及自定义添加纹理和树叶/功能。都是在运行时动态完成,效果相当不错。我们有点失望地发现,我们不能在运行时修改地形高度在虚幻的(只要我们使用内置的景观元素)。然而,有一些补偿。我们能够造就伟大的新的程序性开放世界工具的使用不真实。能够分配随机草和植物某些地形纹理真的有助于让世界看起来郁郁葱葱,充满活力。

填充时地形和树木,新的程序树叶放置工具使它容易生长整个生态系统基于规则与我们的动态unity基础上的系统。我们仍然有很多工作要做在能够产生这些地图/动态的世界完全不真实的,但我们期待的技术挑战。

各种各样的特性和功能

    v4.6之前,unity的UI系统有点混乱。低效的内置系统取代了少数优秀的(但相对昂贵)的第三方资源。unity的新UI系统(> 4.6)似乎起床速度好,提供几乎所有开发人员可能需要。虚幻的UMG系统感觉类似——提供相同的健壮的UI特性的优势,但能够通过蓝图线和代码。在我看来,蓝图的完美连接UI逻辑和流的机制。我们这个地区没有重大问题除了有点担心小部件组件(允许您将一个UI小部件附加到一个3 d资源)是专门标记为“实验”。交叉手指——因为它运作良好迄今为止!

虚幻的AI行为树和知觉的特性没有平行unity以外的第三方资源。我试过几个这些资源,通常最终滚自己的FSM或HTN / GOAP在c#中是必要的。我们在实验中几乎没有触及表面表面不真实,但它提供了一个非常快速的方法添加基本原型人大和生物人工智能游戏而不需要hand-create很多基础设施。

最后一件事···

我一直在unity几个关键错误的接收端,避免一些手机游戏启动/糊涂事。我们是真正的摆布他们发布/更新周期。你可以同样的争论不真实(他们肯定有他们的公平份额的bug !)除了经常被扔掉是虚幻引擎提供了源代码。如果有一个关键错误/问题,你可以跟踪它,自己修理它。如果你需要一个引擎不支持的特性,您可以添加它。对于大多数业余爱好者,这是一个白日梦。ExtroForge团队,然而,这是一个现实。我们已经分叉的引擎代码,并添加了逻辑,这样我们可以有多个集uv的程序创建的网格。这是一个关键的障碍在我们的体元逻辑,这样我们可以应用体元健康/伤害/权力通过材质(材料),而不浪费CPU周期。这是令人兴奋的能够调整引擎的方式(不到20行代码),这将是更令人兴奋的,看看我们可以提取和合并4.9.1释放到我们的引擎代码干净。

好吧,你拥有它。仍然有很多的爱用unity（虽然我还没有打开它在一个多月），我们仍然积极关注他们的进步，对多人网络的东西和其他关键引擎增加。

我们的团队每天需要探索和学习更多关于虚幻，在未来，我们将以其他元素，我们可以比较unity相关的随访（一旦我们有足够的时间）。