• FEATURED

View more

View more

View more

$10 ### Image of the Day Submit IOTD | Top Screenshots ### The latest, straight to your Inbox. Subscribe to GameDev.net Direct to receive the latest updates and exclusive content. Sign up now ## Unreal Engine vs Unity Engine 51 replies to this topic ### #41phantom Members Posted 20 March 2017 - 08:25 AM - Hard to follow control flow - How to debug, i never found a way except for stupidly printing out ???? I'm intrigued by what you mean by the first one of these? The second... well, if you are talking C# scripts, then you can debug stuff from Visual Studio (with the Unity Tools plugin) or one of the OSX Mono environments easy enough.. in fact, using the Unity Tools plugin I think you can debug C# code with VSCode..? ### #42deltaKshatriya Members Posted 20 March 2017 - 10:46 AM - Hard to follow control flow - How to debug, i never found a way except for stupidly printing out ???? I'm intrigued by what you mean by the first one of these? The second... well, if you are talking C# scripts, then you can debug stuff from Visual Studio (with the Unity Tools plugin) or one of the OSX Mono environments easy enough.. in fact, using the Unity Tools plugin I think you can debug C# code with VSCode..? Interestingly enough I've never found debugging to be much of an issue in Unity either. Like people have said, once you get used to Unity, it's not really that annoying after a point. @GianReto: Do you find that Unity is graphically inferior to Unreal? That seems to be a dominant theme of this discussion, that Unity is not as good as Unreal in terms of raw graphical power output. @ScoutingNinja: Hmm, yea most of Unity's docs are aimed at people who've got very little experience with dev/programming, etc. There definitely are in depth docs, just not usually very accessible/for everything out there. That may be mainly because Unity markets itself to the small dev getting started. I've always had that feel that Unity did market more towards indie/beginner devs in some ways (not that it's meant for the absolute beginner with no coding experience at all). I've heard that the Unity demos (Adam, Blacksmith) are usually made with some serious customization/custom solutions. I'd be curious if those could feasibly run as a game environment. Kryotech ### #43frob Moderators Posted 20 March 2017 - 01:51 PM All the amazing programs -- on either system -- rely on considerable work and custom behavior. Engines are a good starting point, engines provide the bulk of the functionality. Engines give you a bunch of building blocks, code that would take thousands of work years to build from scratch. Some of the building blocks are better suited to some problems, others are not. Neither engine will give you your perfect game right out of the box. (It is possible to buy someone else's game parts, but that's their game, not yours.) Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast. Also check out my personal website at bryanwagstaff.com, where I occasionally write about assorted stuff. ### #44stupid_programmer Members Posted 20 March 2017 - 07:14 PM - Hard to follow control flow - How to debug, i never found a way except for stupidly printing out ???? I'm intrigued by what you mean by the first one of these? The second... well, if you are talking C# scripts, then you can debug stuff from Visual Studio (with the Unity Tools plugin) or one of the OSX Mono environments easy enough.. in fact, using the Unity Tools plugin I think you can debug C# code with VSCode..? I can see how it could be hard to follow the control flow if your project wasn't setup well. Dozens (hundreds?) of random scripts on random objects in maybe several random scenes. A lot of times there is no real way to tell how one game object relates to another. As far as debugging, I still don't think it is clearly spelled out you can attach the Visual Studio debugger to Unity and be able to inspect everything at run time. Even then you have to leave Unity, attach the debugger, then go back to Unity and start the scene. While not a pain it does break your flow. We use Unity at work so I am fairly biased towards it. We do social and mobile games and Unity seems to support them much better then Unreal does. Our designers seem to be able to wrap their heads around the Unity workflow pretty easy so that is another reason we don't look to switch. Most of our tools are run inside of Unity so that designers tweak and go as they please. If we were a larger studio and could afford to just outright buy an Unreal license we might consider the switch (but there is still that mobile aspect and retraining designers). But as was pointed out earlier, Unity is cheaper in the long run and we aren't pushing any hardware limits. Edited by stupid_programmer, 20 March 2017 - 07:15 PM. ### #45Gian-Reto Members Posted 21 March 2017 - 04:21 AM - Hard to follow control flow - How to debug, i never found a way except for stupidly printing out ???? I'm intrigued by what you mean by the first one of these? The second... well, if you are talking C# scripts, then you can debug stuff from Visual Studio (with the Unity Tools plugin) or one of the OSX Mono environments easy enough.. in fact, using the Unity Tools plugin I think you can debug C# code with VSCode..? Interestingly enough I've never found debugging to be much of an issue in Unity either. Like people have said, once you get used to Unity, it's not really that annoying after a point. @GianReto: Do you find that Unity is graphically inferior to Unreal? That seems to be a dominant theme of this discussion, that Unity is not as good as Unreal in terms of raw graphical power output. @ScoutingNinja: Hmm, yea most of Unity's docs are aimed at people who've got very little experience with dev/programming, etc. There definitely are in depth docs, just not usually very accessible/for everything out there. That may be mainly because Unity markets itself to the small dev getting started. I've always had that feel that Unity did market more towards indie/beginner devs in some ways (not that it's meant for the absolute beginner with no coding experience at all). I've heard that the Unity demos (Adam, Blacksmith) are usually made with some serious customization/custom solutions. I'd be curious if those could feasibly run as a game environment. My take on the Unity vs. Unreal thing is this: Unreal stock components are good. Very good. You can easely see that Epic has some expierience in creating games, and the Unreal Engine was created for THEIR games (though I am not sure if Epic still produces any game since becoming an engine dev first and foremost). You can take the stock editor and really start producing AAA looking stuff (given you have good 3D assets) right off the bat. Unity's stock components are a mixed bag. Whatever Unity has updated in the last few months and years is good. Sometimes better than what you get in Unreal, especially in the usability departement. But there is always a ton of junk left in the engine that is sometimes 8 or more years old. See the terrain system. Unmodified, it looks severly dated. I don't think Unity has done much since I started in the Unity 3.5 days about 8 years ago on their terrain system (altough some things got better. Unitygrass might still look dated, but I is no longer buggy as hell... so someone MUST have touched it since I have started). On the other hand, there is a thriving scene of thirdparty assets that can REALLY transform Unity into an engine rivalling Unreal Engine 4 for visual quality. The problem is, you need to either spend money on these, or develop them yourself. With upgraded components, I think Unity can look just as good as Unreal Engine. The only thing I wouldn't be sure about would be the performance, becuase Unreal Engine 4 achieves that with tightly integrated stock components, while in Unity you need to work with tacked on systems... which, given some of the thirdparty assets devs are quite amazing and have been tuning their systems for over 5 years, isn't as bad on performance as some people might think. But still, pimped up Unity will most probably always at least loose some % of performance against UE4 just because not everything is as tightly integrated. In the end, the big difference really is behind the scenes, where the really loud badmouthers are not looking (because I guess many of those are not actual game devs but more gamers and cry engine fanboys)... Epic rebuilds their engines from scratch with every major release (at least they claim they do)... Unity tries to reuse as much as they can, only replacing whatever they want to replace with a major release. Thus UE4 is the more streamlined and most probably more efficient engine where every system is of similar quality... whereas Unity offers more choice and a better usability, as old stuff that was good does not get kicked out and has to be re-invented with every major release, and the UI has been perfected for years. The graphics quality difference really is mostly coming from people comparing stock engine to stock engine (in a world where no studio worth his multi million$ budget is using a stock engine and stock components), and "videophile" BS like "The lighting is better in CryEngine" (which could be correct, even though 90% of people looking at the same scene reproduced in multiple engines most probably see little difference once all engines have been tuned to produce the same result).

Funny enough I am no beginner at all, so I tend to ingore all the beginner level tuts, but still I like the Unity documentation a lot while not having digged the Unreal Engine 4 documentation a lot. Has to do with my hate for Blueprint. Still, having THE SAME quality of documentation, in fact THE EXACT SAME documentation for UnityScript and C# really is refreshing after having seen the non-existence that is the UE4 C++ documentation.

So if "almost no documentation" is what people call "non-beginner documentation" nowadays, then they are right that the UE4 C++ documentation is aiming at true pros ;)

As to the custom systems built for the Unity techdemos... the good thing is, you can download them and integrate them into your own games.

Some of them work amazingly well, even if a little bit rough around the edges. I was using UnityGrass in one of my scenes as it is the only grass system that worked well for me. And as that component was created many years ago, and was never really designed to be usable outside of the terrain system, I had troubles getting a nice look for my mixed terrain / mesh setup (using terrain for most of the ground to make changes to it easier... using meshes for rock and overhangs). So I downloaded the paintjob tool from the Blacksmith demo, and tried using that to paint grass on the meshes.

Results were mixed. It worked suprisingly well, did get the grass to show up on my meshes... the tool just is a typical quick hackjob that is good enough for a techdemo. Lots of things that could do with improving for a real engine tool, like having to setup your grass twice, as you create a new "pseudo-terrain" for the grass that gets placed on meshes.

What really is almost a deal breaker for me though is that the wind system is not in sync between the real terrain and the pseudo-terrain. With no slider to somehow manually sync the wind by moving the sinus curve of the wind waves, this really looks offputting when the grass on the meshes waves in a different direction to the grass on the terrain. With that one thing fixed, the system would be perfectly feasible for use in a game with terrain and mesh mixed. Most probably with a small performance hit, and with many rough edges when it comes to usability in the editor, but perfectly usable.

I guess if you are not using terrains but create your level entirely from meshes, it IS perfectly usable right now. And I guess that is exactly what they did for the Blacksmith demo.

So these demo tools are purpose built tools for their demos that you can use to build games, if your game follows the same constraints the demo did. Or you could use as examples for how to build your own custom tools (or use as starting point for that)...

### #46phantom  Members

Posted 21 March 2017 - 05:00 AM

Epic rebuilds their engines from scratch with every major release (at least they claim they do)... Unity tries to reuse as much as they can, only replacing whatever they want to replace with a major release.
Thus UE4 is the more streamlined and most probably more efficient engine where every system is of similar quality... whereas Unity offers more choice and a better usability, as old stuff that was good does not get kicked out and has to be re-invented with every major release, and the UI has been perfected for years.

Ugh... I wish that lie would just die... Epic have done no such thing.

Segments of the code base have been updated, and continue to be updated as time goes on, but there is plenty of code which goes back to the start of the engine kicking about - certainly UE4 wasn't a "complete rewrite" as I see so often claimed.

Both engine developers work in roughly the same way; you take what you've got and you add to it. Sometimes a subsystem will get rewritten or ripped out and replace, but the majority of the time its just updates on top of updates.

Epic and Unity are no different in that regard.

(And getting permission from management to rip out and replace a system isn't easy; a place I worked previously allowed us to gut our renderer and start again but only after weeks of convincing people that what we had wasn't going to work going forward.)

### #47Luckless  Members

Posted 21 March 2017 - 08:51 AM

Less a lie in my mind over a half truth - After all "Rebuilt from the ground up" in software is typically more like rebuilding a garden shed by unbolting everything, checking each piece one at a time, and fixing/replacing bits as needed.

Often this is limited to "Yep, that door still functions as a door..." and putting it back in place. Not nearly the same amount of work as going out into the forest to plant new trees, wait for them to grow, cut them, mill them, season the wood, then build a whole new door... But technically it is all 'built from the ground up' if you make a clean project in your IDE and start pulling code into it.

Just isn't nearly as impressive as some people make it out to be.

If your signature on a web forum takes up more space than your average post, then you are doing things wrong.

### #48deltaKshatriya  Members

Posted 21 March 2017 - 11:28 AM

@Gian-Reto, what components do you think need to be upgraded to reach the 'Unreal' standard? I know ScoutingNinja mentioned that Unreal just does a better job of pushing more polygons on screen at least.

I've heard a lot about the Unreal being rebuilt from scratch for each new release and I've always been skeptical over how likely that is. Even if it ends up being a 'rebuild', I can't imagine large segments of code being reused. It just doesn't seem like a feasible dev cycle otherwise. I admit I can be wrong of course. I'm not omniscient (yet  ).

Kryotech

### #49Scouting Ninja  Members

Posted 21 March 2017 - 03:56 PM

@GianReto: Do you find that Unity is graphically inferior to Unreal? That seems to be a dominant theme of this discussion, that Unity is not as good as Unreal in terms of raw graphical power output.

There would be some differences, however nothing as large as the current screenshots on the internet shows.

Obviously draw distance will be impacted, however if you scaled objects like grass on the last LOD to 1.2 it should fill the screen the same. Objects like buildings would need one or two more LODs to allow the same draw distance.

You will notice with Unity that if you plugged in a diffuse into the Albedo slot it would still render correctly even if it's a BPR shader, doing this in Unreal would produce very dark results. The side effect of Unity supporting old maps like this is that the color is dull and the details less sharp. However this can be fixed by tweaking the shader.

If a Unity experienced team and a Unreal experienced team made the same game a screenshot should almost look identical; Unreal will just have a better draw distance. The most notable difference would only be noticed during game play, because Unreal's game would be full of animated objects providing a sense of a living world.

refreshing after having seen the non-existence that is the UE4 C++ documentation. So if "almost no documentation" is what people call "non-beginner documentation" nowadays, then they are right that the UE4 C++ documentation is aiming at true pros ;)

Finally someone touches on Unreal's greatest weakness, out of the box Unreal has only Blueprints for scripting. You need a separate C++ compiler if you want to program any thing into Unreal.

The reason I was waiting for this was because there is a very good point to it, first it prevents newcomers from doing any real damage. The visual scripting also helps in the learning.

The real amazing thing is what happens when it's used by a team, the same system that blocks amateurs also blocks the none programmers. When you have a large team miscommunication is a very significant factor, because your content artists don't keep up with changes in programming as they are busy it can lead to large bottle necks.

Now you can just prevent them from scripting by removing Visual studio from all of their PCs, they can still make the things they need with blueprints and if there is something special, they contact a programmer who has kept up to date with the changes in code.

This cuts debugging time by almost a third.

THEIR games (though I am not sure if Epic still produces any game since becoming an engine dev first and foremost).

They do just look at there releases, they have good games.

Ugh... I wish that lie would just die... Epic have done no such thing.

I think it started with Epic saying that the Unreal engine they used for one game was completely different  from one used in a other game; this was then assumed to mean they start from scratch each time.

Because a engine you use to build a FPS would be different from one used for an RPG. Epic probably keeps a base engine that is similar to the public one, that can be altered to match any game they are making.

The reason Unreal isn't as buggy as Unity(in relative scale) is because Epic hires independent studios to go over there engine code and optimize it. Hiring proofreaders and editors to optimize your code isn't something you would do, if you where just going to scrap it again.

@Gian-Reto, what components do you think need to be upgraded to reach the 'Unreal' standard? I know ScoutingNinja mentioned that Unreal just does a better job of pushing more polygons on screen at least.
Spoiler

Edited by Scouting Ninja, 21 March 2017 - 04:01 PM.

### #50mike44  Members

Posted 22 March 2017 - 04:24 AM

http://www.phoronix.com/scan.php?page=news_item&px=UE4-SteamVR-Vulkan-GNUX

What I like in Unreal is to combine blueprints with c++.

### #51Gian-Reto  Members

Posted 22 March 2017 - 07:38 AM

@Gian-Reto, what components do you think need to be upgraded to reach the 'Unreal' standard? I know ScoutingNinja mentioned that Unreal just does a better job of pushing more polygons on screen at least.

Terrain system is severly dated... no much has done since I started using Unity 8 years ago. Out of the box, no normal map support by the terrain shaders, god forbid height blending or parallax shading.

There are third party assets that pimp the Terrain System and bring it up to modern standards. RTP is a good example.... Parallax shaders, tesselation that gets rid of LOD popping, heightmap tessalation for the material layers, heightblending, up to 12 materials support... even features like procedural snow and wetness. In this case, you would have to spend A LOT of time in the UE4 material editor and do a TERRIFIC job with it to get anywhere near all of that in UE4.

Of course, on the flipside this is a 60-90\$ Thirdparty asset. And a tacked on, that while not really costing that much performance, would run faster if it was integrated into the engine instead of being bolted on top of a 8+ years old terrain system.

Postprocessing... Unity has made some strides now to provide better out-of-the-box postprocessing options, and even created a postprocessing stack. But the best examples are still the ones you have to get from the asset store, costing money, and most of the time giving you standalone postprocessing effects, which can be chained one after the other just fine (as Unity has implemented its postprocessing options since the beginning), but of course again costing performance over the fully integrated stack used by UE4.

You get WAY more options in Unity given you can spend something on the effects, and if you can, also better effects in some instances. But you loose out on the tight integrated stack, as Unity's own postprocessing effects traditionally have been no the best thus their own stack most probably will loose out against both thirdparty individual effects for Unity, and the UE4 stack (though to be honest haven't tried their stack yet, and their Temporal AA effect did a fine job compared to Epics Temporal AA, which didn't work well for me).

Stock classes like character controllers and such... I wasn't too happy with what UE4 gave me in stock classes to speed up development of common code (mostly because it was tightly integrated into the whole Blueprint Fubar, with little documentation on how to use it with clean C++), but Unity's own also do not really make me too happy. This stuff is most of the time ages old, and severly limited in usability. Just recently started working on my navigation and looked into Unity's navmesh components. Well, after a short while I gave up because while the system might be relatively easy to set up, is also extremly limited. How hard can it be to make a hook-in point where I could query if the mouse is currently in the navmesh to implement a better UI that shows you if your characters can actually move where your mouse is currently pointing at?

Now, there IS something in the roadmap about a revamp of the whole navmesh component. Still, I would bet you could work better with Unreals stock classes as they had to be updated ANYWAY for UE4 as Blueprint is a rather new thing and tightly integrated to all of them.

Visual Scripting is not really my friend... in fact I hated Blueprint enough to make it one of the main reasons (besides the crappy temporal AA never really working for me, and no other options for AA being available) for me leaving Unreal again for Unity.

But still, Unreal has a built in visual scripting tool. Unity has a ton of good thirdparty ones, but again only if you can pay something for them.

Light baking is currently partially broken in Unity. Yes, it KINDA works for scenes without terrains or other large meshes (its just unreasonably slow)... as soon as you have a large mesh or terrain in your scene, the whole things crashes and burns as it cannot bake to multiple textures for a large mesh, and the max texture size is 2048x2048... good luck trying to get a good, smooth lightmap for a 1x1km terrain out of that!

And that is only if the process ever finishes... the current lightmapper has a tendency to be glacially slow, and it will trip over and hang for any reason.

The really sad thing is Light baking was working fine in Unity 4! The Beast light mapper was a joy to use and not too slow. Not the multithreaded and networked monster that is UE4's light mapper, but working completly fine for all projects. Shit did hit the fan when Unity believed geomerics that their enlighten tool could do more than just GI... I can already hear the management BS talk, and Unity engineers moan as they had to take out Beast and replace it with something that was never meant to be a light mapper!

Speedtree support is also only partially there. Yes, you can import speed trees. Yes, you can place them individually and they work. Yes, I THINK you can use them as trees in the very dated terrain system.

But the speed tree shaders are CRAP!... clearly made as an afterthought. There are community built PBR Speedtree shaders, but they also only work partially. I had to go into the shaders and hack them to get Specular and Smoothness support. To be fair, there are many reasons why the full set of shader goodies only could work in Forward, and not in deferred, and I think this has nothing to do with Unity, more with how deferred works. That might be ONE reason why nobody spent more than an hour at Unity to get speedtree shaders to work.

More worringly, until Unity 5.4 there has been NO instancing support, meaning your speed trees would severly eat into your performance budget whereas AFAIK Speedtrees are instanced in Unreal Engine. Now, you get basic instancing support in Unity... if you can change the shaders yourself to support instancing because AFAIK to this date Unity hasn't updated the speedtree shaders (which are still not even supporting PBR!)

And if you do that, you break many of the speedtree goodies like LOD Fading, as instancing in Unity currently does not support that.

So yes, you can get speedtrees to work in Unity. Sort of. If you work around the rough edges yourself by having less trees in the scene to not need instancing, or hide the LOD popping because fading does no longer work.

The really sad thing as to why nobody at Unity invests more into Speedtree support is this: A rework to their dated terrain system has been on the roadmap for years (see point one)... as part of it, Unity's own dated tree generator should be reworked. I guess Unity said to themselves "why invest ANYTHING into speedtree now when we can better them with our own tree generator and system when we get around to rework it"... of course the truth is at the current velocity the terrain system will most probably not be reworked until 2020... while speedtrees are still the unwanted step children inside Unity

Terrain Streaming AFAIK is handled out of the box by the UE4 Terrain system... in Unity there are thirdparty assets that can do that. Again, if you can pay the price.

Edited by Gian-Reto, 22 March 2017 - 08:39 AM.

### #52frob  Moderators

Posted 22 March 2017 - 12:03 PM

Unity's 'developer preview' started six months ago back in September. You can get the beta version and set the graphics API to "Vulkan (Experimental)".

Unity's roadmap has full Vulkan support as 'on target' in 5.6, to be released later this month.

So I'm going with a big YES to your question.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I occasionally write about assorted stuff.