Our migration from Unity to Unreal - the Good the Bad and the Ugly

We still love Unity (and team members continue to use for other projects and gigs)....but ExtroForge recently made the leap from Unity to Unreal and we'd thought we'd share some notes about our journey.

Hope some of you find this useful!

http://www.extroforge.com/the-switch-from-unity-3d-to-unreal-engine/

 

Nice write up. It's always good to hear from people that have actually worked in both engines.

 

Not so interesting.. I can also write a blog why we switched from Unreal to Unity, with solid reasons. See.. works in both ways.

 

Have you made the switch? If you have, could you write a blog post about it?

Most proponents of either engine have only used one extensively. Or they are just parroting what they here on the internet.

The experience of those who have built in both engines is valuable.

 

I found it quite interesting, actually - given I'm also working with a voxel engine and was considering working on a game in Unreal. I won't actually switch, but rather create a separate project in each. I really just want to broaden my skills since it's mostly about learning for me at this point. (Need to get better at C++ for one).

One of the things scaring me away from trying Unreal was what I heard about procedural meshes - but your post helped clear some things up about that.

 

@casperjeff,
thanks for sharing.
How long did it take to convert your project & get acquainted well enough with Unreal ?

It seems there's an awful lot of annoying stuff on the way, so I'll keep to Unity for now, though...

 

Thanks for the write-up. Very detailed and it's always good to hear a fresh perspective between the two.

 

We started experimenting with Unreal the first of July....and by the middle of the month, we were in full swing.
While we have made great inroads in converting long-finished features in Unity to Unreal, we still consider our Unreal work semi-prototype. Our biggest concerns have been that while we can get certain features to 'work', we are not sure we are doing things the 'right' way (or that those ways are scalable, performant and maintainable). With Unity, there was SO MUCH knowledge built up and information about the WRONG way to do things. For all I know, my C++ implementation of certain key features is leaking precious memory.every millisecond.

That was one element I neglected to add to the writeup - memory and CPU/GPU usage. When I originally experimented with Unreal (long before july), I gave up quickly trying to run on my high-end macbook - it was sluggish and the fan sounded like it was going to spin right out of the machine!. I haven't gone back to check later versions of Unreal (I understand it has become much more mac friendly). Some of our team members are getting concerned most recently about in-editor memory use...spiking up to 12 (or more?) gigabytes of use - although it spikes...can be a low as 2....or anywhere from 5-7 regularly. We haven't quite pinned down what aspect of Unreal editor use causes this (blueprint editing? map editing?) - but we are keeping an eye on it. We have not done much analysis (yet) in standalone build memory consumption....but for the most part we follow the cardinal rule "Optimize Later".

 

It is interesting. Their reasons for switching will apply to some people, while your reasons for switching will probably apply to different people. The more information there is available, the easier it is for anyone to find out which engine suits their particular case. The answer will not be the same for everyone.

 

I really enjoyed the write up. Hope Unity staff reads it.

 

Pretty much confirms my experiences and fears with Unreal - lacking C++ documentation, sketchy asset behavior and lacking procedural mesh functionality for the moment. Other than that, seems like a great engine.

 

We pretty much found the same thing across the board, using C++ / BP cross is powerful and efficient. After many moons of use if I want to create a char controller with camera / collision system for e.g. it doesn't take me longer than 10 minutes including animation..

Although it was frustrating trying to figure out what it wanted you to do initially (in every aspect). Also the asset management thing is a pain, ref locators don't work very well although they were discussing removing that (even if you remove them, had some odd side effects). I also find Unity's .FBX import system much more accurate. But little things really..

You should really be running a 4790K / Hexacore system with SSD and 32GB of RAM for lightmass. The builds if done well can run on some pretty poor hardware, but the editor does eat away. So that's a pro for Unity, ALTHOUGH when I had a large scene in editor with Unity the editor would grind nearly to a halt (even in Unity 5) even with a powerful machine then play fine in a build / game mode. Something I never experienced with UE..

I'm at the point now where I find it much quicker / simpler and efficient to use. Even though the initial learning curve was much steeper.. With all the tools available, most likely the right move for your project.

P.S CryEngine does look sooo gorgeous, such a shame ain't it?

 

The part on UNet really hits home, so much waiting for a below average solution, at least so far. I'm not sure why the timelines are so long for it but definitely a contributing factor to many looking at UE.

 

This is a very well written piece on a subject that is often colored by engine bias. The one thing I really like about it is that it's the same project in both engines, which helps to figure out exactly which parts are suited and not suited for that kind of game.

On my own project, my team and I have constantly thrown the idea around of switching over. In concept it seems great, you look at that engine and expect everything to just work the same way. Unfortunately it turns out that there are a huge host of issues waiting for you that you don't expect. The grass only looks greener from this side.

One of my main fears was the Blueprints vs C#(C++) issue, and your segment on that directly matched my original thoughts on the subject. I'm very thankful you were able to investigate this, as the question has always been in the back of my mind.

Great work!

 

I found at least on mac that the editor was just too slow to be useful, you would need a monster machine to run it

 

I found the writeup interesting too. Coincidentally I'm working on something with open world-ish features right now. I was pretty jealous of Unreal's World Composition, but it looks like Unity 5.3 will give us multi-scene editing before I actually need those features. So that made me happy. Unity's terrain is also something that is severely lacking. Your article definitely made me want to consider switching for this project. But then I remembered what a complete pain Unreal's FBX import is to my workflow. I assemble all of my models in Blender, so everything is parented the way I want it. Unity happily plops the imported file in exactly as I assemble in Blender. Unreal unceremoniously dumps all of the meshes into their own objects and expects me to reassemble it. Unity also does a much better job of generating lightmap UVs. Unreal wasn't happy with a lot of the models I tried unless I did that myself. For me at least, the extra shiny isn't worth the massive headache that causes.

 

A reasonably priced gaming PC can easily handle it, but unfortunately an equivalent Mac is a couple thousand.

 

It performs a lot better with my new Mac with a dedicated GPU. It performed at a level that I could work with when I had only an integrated GPU, but it got the fans going a bit.

 

It sure can, unfortunately I'm impatient .. If you have the power it definitely can use it. Most important part is probably the RAM for lightmass..

@HemiMG

Import all meshes as separate objects, select them all then drag n' drop.. It'll place everything where it should be.

Hell every time I update most of a city I ain't placing by hand again jeez!. It's all these little nuggets that get ya.

 

You have no idea how sad it was to put a windows box together to do development over the last few months. My mabook and thunderbolt display sit nearly idle. (REALLY sucks that there is no way to hook that thunderbolt display to my PC)

 

Mac's still come in very handy, we use them for sound design and post process duties. You can't beat an Apogee / Pro tools config for a low cost professional setup. We use MOTU 1428 racks due to the amount of IN's / Out's which works with Windows but still Pro Tools runs like a dream on MAC..

For raw grunt on a price / power ratio then yeah PC for main development, I still use a Mac Mini for testing purposes as well.

 

Good read thanks for taking the time to post that.

Unreal networking works well for what it does, and it lines up well with the type of game Unreal is most used for. Server authoritative is the intended design, it's single threaded which is just fine for running lots of instances where you have say up to 64 players or so. C++ single threaded server means you can easily embed other languages if you don't want to be writing game logic in C++.

But it comes with a huge downside when it's not a fit, which is that it's incredibly difficult to integrate with any other networking solution. It's networking functionality is tightly integrated in a bunch of places spanning UI to various other systems. I started integrating Unreal with my Game Machine project and stopped. They simply had no abstraction layers I could even work with really, regardless of the approach I took. I would have been touching all sorts of internal api's to make it work because of their lack of good abstractions around stuff.

Unity on the other hand has an implementation that is just largely not ready for prime time, but they chose the right level of abstraction for how networking integrates with the rest of the engine. The Unity approach makes it easy to integrate almost any networking solution. And this kind of just fits the overall Unity model of relying on the asset store and community to round out the product.

 

Nice write up. Sounds like the low level C++ stuff is a headache but the engine offers a lot of practical features.

They're both still growing into their shoes, i suppose.

 

One thing I really like about the idea of unreal is that you access to the source code. I was doing something with navigation agents, and they kept bumping into each other (and I didnt want player 1 and player2 units to be bumping into each other -- but theres no way to fix it).

 

Check carefully the license terms for UE, with respect to embedding other languages. Last time I checked, UE severely restricted (legally) use of GPL-like licenses. YMMV, and IANAL, but the licensing terms were one of the factors that caused me to choose Unity instead of Unreal for my project.

 

Both Unity and unreal forbid combining engine with anything that may result in engine turning into opensource project. That means GPL license.

Unreal has restriction for embedding langauge, which states that if you ever create and decide to destribute binding for another language, you must destribute that binding free of charge with source code included AND allow further redistribution of bindings/their source code.

 

You're correct; my choice of GPL as a "typical" license here was unfortunate, as I had forgotten that Unity also forbids that one. What I meant was simply that Unreal's terms seemed more restrictive to me as to what open source code was allowed and what was not.

 

Interesting article by the OP, and a very worthwhile and balanced read. When I looked at the two engines (and several others) last year, my conclusion was that both Unreal and Unity are excellent engines, but Unity was better suited for my specific needs. So I chose Unity but still hold Unreal in very high regard.

 

I don't know, I don't see significant opensource restrictions in UE4 eula. It does specifically spell out which licenses are forbidden as example, but it seems to be the same.

Unreal:

The important point about LGPL is "unless you're merely dynamically linking".

Unity:

Interesting thing is that unity forbids gambling, while unreal forbids gambling, air traffic control, military use with connection of live combat, and operation of nuclear facilities. (Makes me wonder if there were some precedents in case of Unreal engine).

Regarding opensource code, seems to be the same thing in both engines.

 

The nuclear facilities line may be an out to allow export to various countries that are under export restrictions for nuclear technology. No idea if it works.

But seriously, you would have to be insane to put lives in the hands of a game engine. That push should come from the industries themselves, not the engine developers. I would be laughed out of my day job if I suggested running the plant from Unity. Its just far too unstable (in the chemical industry that means it will crash more then once every ten years).

We do occasionally toy with putting training systems into Unity. And I have seen similar 3D software used for job planning (can we lift this massive tank out of the plant without hitting any structural beams?). And for incident visualization.

 

That's actually a misunderstanding of how licensing works. Combining GPL code with a commercial piece of software has no chances of making that commercial software fall under the GPL UNLESS you have the right to distribute the commercial software and do in fact distribute it with GPL code. Since I have no rights to redistribute UE4 as an end user, any redistribution I do that has GPL code is illegal to start with, and Unreal has no liability, my act doesn't make UE4 fall under the GPL.

 

Well I admittedly didn't think when I wrote this that it's fairly worthless to embed GPL if UE4 doesn't let you distribute it. Too much coffee...

 

Hear, hear! I formerly worked in the industrial controls area, in a discrete (pieces rather than continuous flows) manufacturing company. Had Unity or UE4 existed when I worked there, we might have used them for training simulators, but never for control of live equipment. In fact, some of the safety-critical systems I designed had physical relay cutoffs for certain safety features as a backup to anything software might do. We never trusted software to protect human life and limb without an electromechanical failsafe in place.

 

Thanks to @neginfinity and @snacktime for the further commentary on licensing. Unity and UE4 are closer together than I had remembered them being, so I stand corrected.

 

Also for some DoD contractors, only certain programming languages are allowed to be used: C and Ada.
The use of any computer programming languages used in deliverable SW or HW in C# or Java or Javascript is prohibited.

 

Nice write-up, out of interest did you ever evaluate uLink for multiplayer?
It has all those features you mentioned.

 

This is a nice blog beacuse it shows some areas where Unity should improve.
Switching from one engine to another is always a matter of project needs.

 

Care to do it then?

 

They would have a reason to switch if they needed mecanim retargeting, had 2d project, or if they wanted to use some code asset from unity asset store. For example, ProBuilder or Morph3D. Neither is currently available on UE4, although ProBuilder is supposedly being ported.

 

Anyone who knows anything about development in UE / Unity would know this. You're supposed to do proper evaluations (prototype) games in each game engine before starting major development to assess flaws / ease of use etc.

 

That reminds me of old story I read somewhere.

There was an old computer/mainframe sitting in the corner and operating for years without a flaw. However, one day machine suddenly crashed. Upon crash it displayed a message "On the XX/YY/ZZZZ John Doe, my supervisor, said that this will never happen" (forgot the actual name/date).

Yes, everybody should know. However, it is still possible to run into situation you didn't predict despite the evaluation.

 

Of course there is, that's why I spend a lot of time poking support functions etc. to see what sort of response I'll get ..

 

please write it I would love to read it.

 

Keep i mind anyone can write anything true or not. And even if true for them (as in whoever is writing the article not literally these folks) at the time of writing doesn't really mean anything more than the writer's own personal preferences and their resulting experience.

Like I could see myself at some point writing an article Why I Stopped Wasting Time With Unity And Monkey X And Switched To C64 Assembly Game Development. I'd probably be able to list many pros for making the switch but that doesn't mean anyone else would have the same experience if they switched.

 

Or Pico-8. It'd be right up your alley.

 

Yeah I do want to try that out sometime! Working within such constraints would be a lot of fun.

Right now I am on a quest to find the best 3D game dev environment for me. I really didn't want to drop all the way down to OpenGL and do everything from scratch but after checking out numerous options it is where I ended up. It is amazing how so many different people can do it wrong. LOL That is a joke! Just that so many folks are stuck on these huge integrated scene editors and I don't like it. A basic scene graph of course but not this massive visual IDE stuff.

On the bright side I just found out yesterday that someone has created a slim version of a 3D framework in OpenGL for Monkey X. So now I am going to check that out before deciding to focus on writing it all in OpenGL. Exciting times!

 

Have you seen Irrlicht's scene editor?

http://www.ambiera.com/irredit/

 

Yeah I am pretty sure I came across it and probably another reason I skipped it. I thought Irrlicht never had one years ago but I guess even they felt the need to bloat it up. As soon as I see a screenshot of that kind of thing in my research I can quickly eliminate it and get on to the next one.

Of course, ultimately I will end up making some scene editors / 3D Map Editors and other visual tools too. But they will be dedicated to the task at hand and because of that very easy to get into and use. That is my goal anyway.

I guess I should have clarified that long ago. My main dislike is these massive all-in-one visual editors. All I want is streamlined dedicated dev tools. If that means having a dozen different utilities to work in then so be it. Actually Unity is an example of one of the better all-in-one editors based on my recent research.

EDIT: Oh no @Ryiah I am on laptop now and checked it out. Nope. I hadn't seen that one. That actually might be good. I am thinking there are likely many little open source tools out there I can pull in for a jump-start. Thanks for pointing this one out.

 

When Carmack trashed DirectX, I was already on board with OpenGL. But over the course of the following years, Microsoft improved DirectX so much, its capabilities and ease-of-use were on par with OpenGL, and eventually surpassed it. I admit having been a slight fanboy of OpenGL at the time. Now that Vulkan is out, another war is waged.

 

It saves lot of times for lonewolf devs or small indie teams. If i had to make all UE4 tools it would take years, from terrain tools, matinee, shader forge or all editor features. Lot of people need a ready to go package to directly create their game
with ready to go tools. If the game is planned around one or two years, they don't have time to make tools, they need the tools and high end features out of the box. This is UE4 strenght.

You should try CryEngine ( or Lumberyard ) geometry editor, it has some more features than Probuilder and it is included in the editor out of the box. This could become a strong point if Amazon will advertise it.