轻量级，安装、调试和打包方便
配置VR项目十分简单
开发成本低
UI系统
在PS4上调试方便，有批处理文件可以一键运行
Asset Store
提供了一些VR下的Demo作为参考
Unity的劣势：
内建工具不够完善
渲染差，光照系统糟糕，阴影bake有bug，只能勉强达到2A游戏入门水平
对于控制器支持较差，一些如手柄震动、VR控制器空间定位的功能引擎未集成，需要第三方插件或额外代码 没有材质编辑器，需要第三方插件
Prefab不支持继承
没有内建的Level Stream支持
Unreal的优势：
画面效果完全达到3A游戏水准
光照和物理渲染即便在缩水的状况下也足以秒杀Unity
森林之神与仙女们蓝图系统，从此策划不用再写代码
强大的材质编辑器
各种官方插件齐全
fiypaper对于手柄、VR控制器支持良好
提供各种游戏模版，用来做原型配合Blueprint甚至比Unity更快
Unreal的劣势：
C++
如果要开发PS4游戏需要重新编译引擎，12核服务器，24线程编译大概需要20-30分钟 如果需要重新编译引擎，光拉代码就需要至少一个小时
创建新项目大概又要编译十多分钟
如果切换平台，要编译几千到上万个shader
PS4部署不方便，打包编译同样非常久
学习成本高，各子模块功能强大但操作复杂
部分功能没有任何文档，已有功能的文档同样不够完善，不如Unity
开发成本高，某国内3A团队做了个10分钟的VR Demo，据说已经烧了一千多万UI设计器非常之难用
VR下的一些best practice同样缺乏文档和例子，目前都在摸石头过河Buuuuuuuuuuuuuuuuuuuuug
我觉得写了这么多结论已经很明显了：
小团队没钱追求快速出效果，对画面要求不高的项目用Unity。
中大团队不差钱，买得起Unreal技术支持，分工明确有专人填坑，对画面要求高的项目用Unreal。
这里还有一篇老外写的关于Unity和Unreal的文章，建议阅读：
ExtroForge
科研能力评价The Switch from Unity 3D to Unreal Engine
A High Level Decision
Let me start off by saying that I (and other team members) are still HUGE fans of Unity. Several of us on the team have been using Unity since v3.X days (including Pro licenses) and CONTINUE to use it for various projects. If I was starting a mobile project today, I would still reach for Unity.
We made a LOT of progress on prototyping ExtroForge with the Unity engine. Huge swaths of game
play elements were engineered and integrated. We thrived with the rich variety of Asset Store packages available to us as well as the YEARS of online posts, blogs and tutorials. With at least two 15-year software engineering professionals on the team, we were efficient and proficient under Unity.
All that being said, we got to a point where a single aspect of the Unity Engine became a critical blocker – multiplayer networking. Several people on the team had experience with building multiplayer projects with Unity – one using the third party SmartfoxServer and the other with the built-in RakNet functionality. Extroforge, however, brought some specific needs to the table. – including Authoritative server logic, server-side physics and collision logic and high-performance (Extroforge is part FPS and part RTS in many ways). We prototyped multiplayer using the built-in networking and in the meantime, looked at some third party options. We were eagerly awaiting the Unity 5+ replacements for the networking – UNet.
image08
The first iteration was less than impressive. Extremely limited (missing?) documentation and oddball (buggy? flaky?) performance. Simple replication of an
animated model (location/rotation) was either non-functional or super-laggy. We experimented. We r
ead forum posts. We waited. There were no official Unity tutorials. Some of the people that WERE making tutorial videos that we followed actually gave up and decided to wait until future releases. Then the Unity roadmap was published. With the implementation of the standalone simulation server pushed out to March of 2016 (plus some other elements undefined), we decided to look at other options. What a pleasant shock it was to fire up Unreal for the first time with a starter project and see that little side menu next to the “Play” button that allowed you to auto-start not just a dedicated server, but also as many ‘additional’ player clients as you wanted to. It was multiplayer nirvana.
Note that this was not SOLELY a decision based on multiplayer functionality built into the engine. We have struggled for some time to get the
world/terrain/foliage/water to look the way we wanted. Our Team/Studio lead who was responsible for the look and feel decided to look at some other game engines to see how quickly he could achieve the desired results (our Unity results either looked too cartoonish or too “claylike”).
image09
CryEngine was so beautiful “right out of the box” that he almost cried. But convincing the team into such a low-documentation, small community, high learning curve environment was a non-starter. Wit
h Unreal, the desired look and feel was quickly created and we were all MUCH more comfortable with the user community, documentation level and toolsets (including Blueprints).
Once we were convinced (via a few sample projects and prototyping sessions) that we could get the look-n-feel that we wanted – and with the multiplayer stability and scalability that Epic brings to the table (after YEARS in the multiplayer FPS space), we made the official decision to jump. It was a HARD decision. We had a lot of code and content that was Unity specific (including our procedural mesh based voxel implementation). We were so familiar with the Unity way of doing things – including the C# language. Blueprints and C++ gave us more than a moment’s pause…but we had committed.
C# versus C++ versus Blueprints…oh my.
The ExtroForge team had some technical depth. Both senior engineers had worked in C and C++ years ago – although had moved on to managed languages since – heavy in Java and C#. The rest of the team had mixed experiences in different high level languages. We were well experienced in both OOP and Component based design. C# was an ‘easy’ language to work with in Unity and the additions that GameObject and its related brethren brought to the table had become second nature t
o us. I’ll admit that the Blueprints concept in Unreal frightened me a bit. Interestingly enough, none of us
had done any visual scripting before, so we had nothing to compare to. I had some bad experiences with wired prefabs in Unity – where we could easily lose a bunch of important settings. I got very used to establishing important values and settings in code. That fear, along with many many years of software development experience behind us, made me confident that we could/would blow the dust off our C++ skills and start that way. I was encouraged by the fact that most of the ‘starter’ sample projects that were available to download/install through the engine/editor had a Blueprint AND a C++ version. That encouragement was short lived, however. Not to sound demeaning – but because of the large number of ‘hobbyists’ that flocked to Unreal because of it’s price, there were a HUGE number of tutorials, forum posts, videos, etc related to accomplishing Unreal tasks in Blueprint land. There were SIGNIFICANTLY less in C++ land. At first I wasn’t too worried. Give me a good API doc (and the engine source) and I should be fine.
image00
Yeah – not so much.
It was hard enough to remember or research the ‘right’ way to do things in an unfamiliar language – learning the “Unreal” way to do those same things sometimes was too much for my tiny brain. Even when I had a modicum of success on the C++ side (some custom structure/classes to embody our voxel world), I was unable to get Unreal to allow the use of these custom structs/classes in certain areas (like RPC calls). image04Oh, I could get past compile errors by adding the appropriate macros or proper ‘naming’ of my structs/classes – but even after that, RPC calls that used one of these custom structs simply produced empty results on the other side (a problem I STILL haven’t figured out – so I pass things around in Unreal specific structures and convert/de-convert on the other side). That issue aside, we made progress living in
C++ land. I was able to dynamically reference mesh or materials (by name) at runtime so that I wouldn’t fall prey to any brittle wiring losses like that I experienced with Unity. Yay. Until we tried standalone non-editor builds. Then the dynamic techniques to grab those assets at runtime fell over with ugly errors. I’ve read all the articles and tried all the techniques – and still found myself unable (at runtime) to dynamically grab a material or mesh or blueprint by name at runtime in C++. So I started looking more closely at Blueprints to see how they could help.
image02One senior team member had already started wiring up some blueprint functionality – addin
g to the skeleton first person character BP that was tied to the
cttC++ classes I had been working on. Creating little boxes…dragging little wires….all the colors I was fascinated. Most of it was input/controls related as well as GUI/UI
stuff – elements I figured were probably the best use for Blueprints. I started my foray into blueprints myself was for Material logic. I was AMAZED at the stuff we could easily do in seconds in a material blueprint that would have taken….DAYS writing shader code in Unity. It was easy, it was fast, and it was (dare I say it) satisfyingly FUN. While my code remained firmly in C++ land, we slowly learned to expose variables from the C++ side so they could be accessed from these input/UI blueprints as needed (still haven’t determined if you can access a BP variable/function from C++ side – but it looks like it is painful). I learned that I could create my critical settings and initialize arrays of important game elements in C++ (where it was safe in a non-binary-corruptible file) and expose it in to be used as necessary in Blueprints.
Sort of.
So interestingly enough….enums are now the bane of my existence. I love enums. Been a huge fan since before the dawn of time and have used them in every high level language since I was a wee e
爪形手
ngineer.
Many of the low level elements of our game uses enums at the base to represent all sorts of things – Building types, Voxel types, Resource types, etc, etc, etc. And I spent a bit of time Unreal-ifying these enums so that they could be read properly and used properly image06in Blueprint land (Unreal made some changes to make it easier back in v4.7? you used to have to use some oddball techniques to deal with them). At the heart and soul of things, Blueprint-land doesn’t know about enums – but it knows about 8 bit bytes – and it treats them as such (but you can still reference them as the Enum type you carefully crafted in blueprints). All that aside, the issue we have been having (v4.9) is that SOMETIMES blueprints want us to cast the Enum type to a byte and sometimes NOT. Sometimes a section of blueprints that previously worked WITHOUT a cast to a byte – now errors out and requires it. AHHHGGGG. It’s not unusual to make a bunch of C++ code changes (UNRELATED TO EXISTING ENUMS) and have the Blueprint editor FREAK OUT after a compile and show a trillion errors (all related to Enum references). At first I spent HOURS recreating seemingly perfect nodes with the exact same inputs and outputs to clear the errors. Then I learned I can simply close the editor and re-open and all is well. WTF? That doesn’t make for a good workflow – but we are managing. It’s possible that this (or part of this) is fixed in 4.91 (several Enum/UEnum r
elated fixes in the release notes) so we will have to see. (UPDATE – nope – neither 4.9.1 or 4.9.2 seem to have fixed this…so we remain mindful).
We are drawing more and more of the C++ side and Blueprint side together – exposing C++ functions to blueprints and even creating custom blueprint nodes. I have learned that I really DO love blueprints – and their place in the development process. They represent a perfect mechanism for certain elements of game development and we appreciate them more and more every day. Most of what we are
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议