Having used Unity since its 3.5 days... usability wise, I loved it since day one. Hated the limited graphics abilities and performance issues of Unity 3, and hated the bumpy upgrade to Unity 5.0... other than that, was happy with Unity 4, and have been happy again since I came back to Unity 5.3...

There is still a ton of things that could be improved with Unity, but the pros outweight the cons for me considerably.

Unreal Engine is a fine engine. I really loved a lot of the stock components that need a thirparty asset in Unity to work anywhere close as well.

But I disliked the visual clutter in the editor, and most of all the intrusive "tutorial function" (happily flashing a blinking thing in my face all day long until I tell the tutorial system that I have seen the hint and it can stop highlighting whatever it deemed necessary to highlight).

Most of all, I hat Blueprint. With a passion. Not so much because blueprint is an inefficient mess for anyone that has some programming abilities (because that is only half true). More because again, epic shoves it in everyones face no matter if you want to use it, or rather would go the C++ way... which of course you can. But good look finding the documentation for it should you get lost. The Unreal documentation is documenting Blueprint, first and foremost. C++ is the unwanted step child of UE4.

In essence, what I hate about unreal is the "the Unreal way or the highway" centricity of the engine. Do it exactly the way epic deemed the right way, and you are golden. Deviate from it and you will fight an uphill struggle.

Unity gives you more options than you will ever need. Which is what I like about it.

- 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..?

- 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.

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.)

- 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.

- 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)...

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.)

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.

@[member='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 :cool: ).

@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]

Terrain tools, I saw this was divided into two one optimizing the mesh the other optimizing the terrain details.

Particle tools, or just away to optimize it, the overdraw is a killer.

You can use a free atlasing code or 3D software, because the free stuff is better than what Unity is using.

You need a custom importer to have proper smooth groups and to remove import errors, also adding collision importing.

Some tools to quick preview the imported assets and see if they are working, Unreal's content browser is very good.

A updated BPR shader won't hurt.

Some kind of BSP mesh or any level design tool should help.

Static mesh and Animated mesh exporter.

A target based animation retargeting tool, instead of the Tpose one.

Better animation optimizing and importing, Unity's animation player is very good, so it's frustrating when you can only have so few characters on screen.

A proper instancing pipeline, for both meshes and materials. If not this then some zone tools or mesh merging tools.

A visual scripter for both coding and shaders.

A blueprint system(Not code), that keeps full working sets stored and ready for use.

The sound tools are neglected, if you have some good sound software outside of Unity skip this one.

Unity's navmesh isn't as good as Unreal, however it's still good, so a optional upgrade.

Unity's reflections and shadows need a boost, to match Unreal, although baking could cover this, so only needed if you want day/ night cycles or weather effects.

A skin shader with subsurface. Also foliage shader, none of the ones it has is very good.

Better Lod crossfades, the ones Unity has are very bad, in both performance and looks.

Hair shader, it's a large part of characters, cloth shader also recommended.

Terrain shader, I know there is a free one, just can't find that one.

UI tools also need a upgrade, although it's working as is.

Unity also needs improved Sky box/ sphere tools.

Improved 2D editor, with basic morph and mesh options.

A decal option, that extra UV workaround is a bad idea for a batch engine; UV maps splits vertices.

These should improve the visual experience without killing your budget, as for the other large differences, programming skill can compensate for it.

If you want I can make a full list, with all tools Unity is missing and some that Unreal is missing; this list is just a quick list of things I found in the store or the internet to improve Unity's visuals.

[/spoiler]