Unreal Engine 5 = Game Changer

Unity's speciality is not having a speciality. They aim to support every platform, every industry, and every developer (from a solo beginner to large studios)

But it does seem to be increasingly holding them back, the product now seems to be unmanageably complex, with it taking a long time for bugfixes to make it into releases, and with vast areas of the engine essentailly 'legacy' - deprecated or expected to be deprecated in the near future (from 'legacy animation' to the standard render pipelines, even UGUI and the humble GameObject/Monobehaviour itself may be on the way out). But with so many people actively using these systems, and the replacements not yet production-ready (or the replacements appearing less flexible, or harder to use), they can't strip any of it out.

I'm starting to wonder whether Unity should have created 'New Unity' (DOTS/ECS, SRPs, Shader Graph, VFX Graph, new input system, and more) as a separate product, initially focused like UE on higher-end platforms (and higher-skilled developers), giving them the ability to almost start over, or at least strip out massive amounts of legacy stuff from the start. Then 'Unity Classic' could have become been more focused on mobile/indie and rapid development/ease of use, with 'New Unity' eventually adding more support for mobile/lower-end?

It's difficult though. People want to make higher-end games then port to Switch/mobile later. Whereas others are very much mobile-first but may want to put their game on higher-end platforms later. You want an engine to support everything, but there's always going to be compromises.

 

Man, I feel like I agree with literally every one of your posts lol.

 

I agree, and I think it is admirable to a degree just how much Unity has worked with older pipelines to keep them at least usable in future builds. But there is a greater cost. There is "burnout". You can hire people, you can force them to work on all this tedious parity across so many devices and legacy pipelines. Now the spirit of your company isn't innovation or perfection, it's a mundane, never ending cycle of fixing things. Kind of a waste of talent that could be working on making the rock solid, expandable functionality that should have existed all along.

Gamedev is messy. Things break, nightmares set you back and you sometimes have to redo things. That's just how it goes. They need to pull off the band aide and stop using excuses. Make high end tools that compete.

Anyway, it's easy to be a critic, what they've built is impressive, but sustaining it seems to be coming at an unsustainable cost with their competition making such large strides.

 

So really the only takeaway from this for Unity is that they need to copy this polygon streaming tech, it's not like it'll be a secret for long, allocate more resources into making a kickass Realtime GI system they've been planning, put everything in preview for 2 years and we're good to go.

 

Then leave it in preview for another 4 years.

Unity's got bags of good tech, it just doesn't finish anything. We've had a whole bunch of good things that are left to die on github.

Unity's got a heck of a long way to go and I doubt strongly they can ever catch Epic on the high end any more. This constant AEC focus is pointless, AEC will pick whatever is less work to work with. If that means throwing billion dollar meshes at a game engine with infinitely good lighting, they will, and they will prefer to do that.

I think Unity did lose it's direction in recent times and that's just something they'll have to work with internally.

 

I don't know if that's a great idea. I'm bias, but i'd like to see them fix everything they've left in a half-ass state first; core services, core engine.

They are tackling AAA quality but leaving us with a dollar-store AAA battery because they are splitting ends and seem to have a team that is beyond unorganized in priorities.

If they are going to tackle meeting 1:1 to spar against UE, they need a completely new team, because the current is not cutting in on all fronts. Worst, by far is QA -> Dev -> "It's in the works" (for years without any improvements/resolutions), and introducing even more complicated features? Goooooood luck.

 

its nice to hear they invest in Audio too, its important. We are currently moving our game to Microsoft Project Acoustics, and it makes alot of difference

edit: Unity is basically useless vanilla in this regard.

 

Why are people S***ting on unity so much in this thread?
Unity's future looks way more bright, and having tested out all the new system, I don't for a second doubt that unity will dominate the next generation.
Unity is better in every aspect for the sole exception of unreal being able to reach greater heights when it comes to trying to achieve photorealism, if that's what you're going for

 

We're rightly criticizing Unity for constantly abandoning features or letting them languish in preview for much too long while having a historical focus on acquiring new technologies that either do not meet the needs of its users, end up in preview forever, or end up getting abandoned before proper implementation.

 

Problem is in this business you don't just lose focus in recent times. The stuff that brings Unity down today was planned already several years ago. A technology like nanite or lumen takes a decade to implement, it's just strategically good planning from Epic and poor decisions from Unity we see nowadays. Something like the deprecation of enlighten without a proper substitute on the horizon made a lot of us already question the future of Unity.

 

Talking about that, Have they even announced a replacement for realtime GI now that they have deprecated enlighten?
I dream about realtime GI fast enough for VR

 

doesn't look like they're even thinking about abandoning dots/project tiny or ui elements or srp

unity literally had that since 2018, when they showed it off in the megacity demo

dsp graph is very epic

 

They demoed a Audio solution in that? Wasnt that a demo to showcase ECS?

 

The graphical pipeline control is implicit in Unreal. You have full access. More so than in Unity, regardless of pipeline.

You'll be productive far quicker than you think. I made the same transition, and finding your way around the API was easier than I thought since every system is integrated. This resulted, at least for me, in a speedup rather than a slowdown.

I also had written a lot of frameworks, but I found that all except one of them no longer were necessary. (The exception had to do with anisotropic pathfinding of roads on complex terrain – but porting the C# libraries to C++ was fairly straightforward.)

So am I. But it was offset by the exhilaration of finally working with a mature game engine, which actually allows you to be lazier. Unity forces you to work hard for your results as soon as the task is non-trivial. And large projects are extremely difficult to author, as the Unity editor doesn't scale.

 

Below is Mikes from GamesFromScratch opinion which i totally agree with, especially with the "Performance" part...

That's what would stop me from using Unity engine at first place, because the editor becomes less and less performant. Then graphics quality, HDRP is not even close to current UE4 in both performance and quality - i got higher FPS in a test with UE4 with shadows and post-processing enabled then in Unity with HDRP and everything disabled !

Just watch for 5 mins if you want.

 

It was a demo to showcase ECS, that only works with 2019.1.0b7...

 

I'm fighting for better (editor) performance for several years and it finally seems there is hope now.

 

You just made mo download latest alpha

 

Well, is obvius, U5 will be very superior to Unity 2020, not only in dev tools and quality, in license mode too.

 

they're pretty close man. but unreal holds more up to scrutiny in different lighting conditions at different times
but honestly, you wouldn't at all be limited by the graphical capacity of unity. HDRP is demanding though.

 

I don't know if I agree that 3D is to blame specifically, but there's no doubt that Unity was built on the idea that a game engine should be first and foremost about ease of use. In their words 'democratising game development'. I've complained about the technical aspect of what Unity is capable of in the past, but I always praised it for being wonderfully flexible and easy to use. The editor customization is still its best feature and an incredible benefit. And of course the cross platform support which is far and away better than the competition.

If they added these two features that Epic are bringing in, it would fit in precisely with their strengths and apparent core aim. Target the biggest pain points for game devs in general. Even if the results were not spectacular, the workflow would more than make up for it - as has been the case in the past.

But instead there seems to be a whole host of features that do not particularly aid general game development (in fact complicate it) in favor of performant machine-learning driven simulations or something like that. Which is a weird direction for a game engine to go that has been about making game development accessible. At this point I'm more certain that Epic are focused on aiding indie game development than Unity are.

Unity needs to get back to its roots and focus on making easy to use tools for game devs. I'm working with Mecanim right now and frankly to see such a fundamental feature as the animation system neglected for so long in favor of some new programming paradigm or esoteric machine learning tools is disappointing. If their focus lies elsewhere then my place probably will too.

 

The lack of any meaningful abstraction means that pipeline changes are far more difficult to implement.

I have evaluated the engine. Multiple times.

Cool, good for you. As I stated, I've evaluated the engine multiple times and know what my needs are. My case is not unique either.

 

I'd agree, except they keep showing off photoreal demos like Heretic. I'd like to see Unity rise to the challenges... I've only been using Unity for 3 years, it is a really great platform. I'm just now moving into HDRP, which is a new learning curve but adds a lot of great features. The problem though is that when Unity does it's tech previews, it's all technology they don't make it easy to use/learn. Trying to work with Shader Graph is like a profession in itself, want to do something like Megacity, you have to change the way you foundationally think about programming (they tell you that in the Unity video on ECS/DOTS).

I think one of the best insights I heard about why this is (I don't remember who said it) is that Unity doesn't make games so they don't know what game developers experience, only what game developers tell them they experience. The tech previews that Unity develops are done with teams of 5-10 people for a year (Like Adam) and because it's never a "game" or built like a game, it never helps any of us game developers. It's just a bunch of videos showing us what it's sort of possible if you stretch the engine to places most of us can't or have a hard time going to.

I am a Unity fan, but they really make it harder on themselves than they need to I think.

 

That Chinese money buys a lot of pretty toys.

 

Mecanim is fantastic, it has some quirks (I remember spending weeks trying to figure out why my animations were all breaking and that additive layer animations need to be in a T pose on frame 1 and this was detailed NOWHERE). It suffers from a lack of documentation and core tutorials covering just how cool it is, and relatively easy to pick up and mess around with. I know there are events you could tie to animations and I would certainly have used that in my project if I knew how but many of these cool aspects of the engine are just not documented anywhere.

Mecanim is a perfect example of something I would say Unity did a GREAT job with, and there is no excuse why there are no tutorials explaining how to call events on sword swings that trigger collision checks and a bit of code that modifies playback speeds that tie into upgrade systems, how to set up seperate layers for running and attacks.

They create amazing functionality, then do nothing to relay that information to their users.

For every key system: particles, mecanim, etc. There should be a sample code doc that simply has sample functions doing things you will very likely want to do, like say Enabling or disabling all particle emissions in a parent particle emitter for the duration of a buff, or playing a particle in forward speed, to an apex, and then reversing it back into nothing. This wouldn't even have to be upkept by unity themselves, such code examples could be built by the community somewhere. But it doesn't exist.

Both Unity and Unreal could do a lot more to help facilitate better tutorials for their ever evolving platforms. It's kinda crazy just how much power and functionality can lie just outside of reach because you're not privy to some small amount of code, or didn't figure out the T-Pose thing I listed above. Tiny sample projects that demonstrate general code manipulation of specific systems would go a long way.

 

i don't think many people realise that base unity has been almost completely abandoned since 2017. and thus they are frustrated with the complete lack of new features

dot's is not just about muh performance. procedural animation, spatial audio, editor subscene workflow, netcode, multi threading, ecs, havoc physics, new way of making builds, are dots only features

all the graphical changes are being made in srp and all the ui changes in ui elements

base rendering, base editor workflow, base UI, base animation, base audio, base netcode, base physics, base project build system, base particle system, haven't changed at all

 

If unity was a country and we were the citizens, and then one day a different country would have a revolution, bringing their citizens great freedoms and no taxes until a person is rich. A citizen of the first country would look into it's government, and start thinking and asking questions, what is being done with all the resources from his tax money. Of course, while the government lets you do your thing, everything is fine for you. Until one day, you notice you can't go play with your friends as the roads have been removed, and there's just a notice, that the roads will be put back in place in 3 years and until then you can use a third party solution, such as hire a helicopter. Alright.
But then the government at the same time decided to completely reorder everything in the country and most of the country is under construction. It is indeed going to be a beautiful country one day. But the borders are open...

 

In depth tech analysis

 

What a ridiculous comparison.

 

So far I've found that you cannot change the speed of specific animations in code, even though you can easily change it in the Animator window. Nor can you extract the name of the current state from the animator despite the fact that a) you can check if the current state name is or isn't a specified string and b) the first argument to the function you call to programmatically add a state to a state machine is its name. And people have been complaining about this for literally a decade.

I'm not saying Mecanim is completely useless or unhelpful, it's that fixing issues with something so fundamental to game development should take priority over introducing complex changes to the engine that are targeted toward relatively small parts of the user base.

 

Thing is, the core concepts of both ShaderGraph and DOTS have been around for ages. Back when I started learning graphics and writing small OpenGL demos, the way you designed a basic engine for raw performance was to take object data (positions, velocities, colors), lay it out in a SoA (struct of arrays) fashion, then have separated functions that took that data and transformed it in some way, akin to ECS systems. This made sense from a performance standpoint because data was tightly packed in memory, cache misses were minimized, and you could also benefit from SIMD if you knew how to use intrinsics, for a x4 boost in performance (which is kinda what Burst does).

When I started using Unity I was pleasantly surprised by the conceptual simplicity of their component-based approach. I though "this thing can't also be fast, can it?" Sure enough, the GameObject/Component combo performance was (and still is) abysmal when you compare it to what can be done in a simple C++ home-made engine.

The tradeoff was worthwhile for me because Unity was meant to be easy to use, not extremely performant. Their promise -a solid, easy to use foundation to write games and deploy them to many different platforms- was fulfilled.

We users asked for more performance, better graphics quality, visual shader writing.... and they delivered, on all technical aspects (some other aspects not so much). Turns out, with great power comes great responsibility. Even then, they managed to make everything quite easy to use imho.

 

So take the UI for example. We have had UGUI, then Text Mesh Pro, and now something else altogether? This isn't the way to make life easier.

I don't believe that 'abandoning' the current state of your engine for four years is a good move either, especially two years after introducing massive changes (in 2015). Unity is in a dangerous limbo and has been for some time now, and I'm not even sure if the departments are pulling in the same direction.

Unity need to aim at a clear goal and hit it hard and fast, otherwise they will lose the advantages they have gathered so far.

 

Unity's future is bright for sure! And it will stay that way

 

UI elements replaces UGUI, IMGUI and Text Mesh Pro, its not a fourth addition onto them

 

Did I go overboard with the metaphor? Sorry about that.
There are things that are ridiculous indeed, most of them have been mentioned.
My point. While in real life changing your country is not easy, in software, if you don't find that it doesn't work for you you are free to use alternatives. Obviously we can't change the way the company executes it's policies as we have no right...

 

You can tie the speed of animations in Mecanim to float parameters, which isn't too bad. I do wish that you could just define a hard-coded "blackboard" ScriptableObject for Mecanim though, as opposed to relying on string variables.

 

The fact you're unaware how to tune animation speed per animation illustrates this lack of communication perfectly.

If you look at the attached image you can see that you can tie a float parameter to modify the animation speed, and simply adjust that through the animator with a simple line of code:
animator.SetFloat(name, value);
I use a singular float for all attacks that i use to modify attack speed bonus "AttackSpeeds", but you could create unique floats per attack if you want to adjust attack speeds on a per attack basis.

 

That's clunky and makes a mess in the Animator. The real issue is that the concept of a Motion or a Blend Tree does not exist outside of editor API.

EDIT: specifically talking about inside blend trees.

 

Not inside a blend tree.

 

all the < add feature x > and < why doesn't unity have y but unreal does > is because it has been done but not inside the base unity systems

 

But who actually wants it? XML, USS, uQuery... It sounds like a big step in the wrong direction. I'll admit that I've not actually *used* it yet, but browsing the forum was enough to put me right off.

A game UI isn't a web page. It needs rich VFX and animation. Forget menus, think of HUD elements - bars, gauges, minimaps, and so on. And the sort of in-world UI found in VR games

UGUI has performance problems. But now that we have nested prefabs, UGUI seemed pretty good to me. It could be improved without scrapping it and starting from scratch (while also scrapping+replacing almost every system in the engine at the same time!) - especially if the end result risks involving a workflow that many don't want and a reduction in flexibility (as the UI is no longer a hierarchy of GameObjects with regular components, at least AFAIK from reading about it)?

Yes, a better UI system *for the editor* is a good thing. But editor tools have very different requirements to game UI.

It's worth considering much knowledge/experience is thrown away with every system that gets completely replaced rather than iterated upon. People are going from being Unity experts to almost Unity newbies again, as the entire engine is changing into something else. And while 'New Unity' may be much faster, for now very few people know how to get results from it that are comparable to what they could achieve with the old stuff. It's tricky enough to keep track of which bits may or may not be complete and stable enough to use in a live project...

 

But you can adjust the play speed of the blend tree itself at the top level, meaning you could code a solution that lerps between whatever play speeds you want using whatever criteria you're using to blend, which is generally movement speed. So long as all your animations are normalized i'm not sure why you would need per animation tweeking for their play speed.

This functionality would be nice but it's hardly necessary or limiting.

 

You can do all of these things in UIElements. UIElements is specifically for layouts, which these systems are a massive boon for, especially when it comes for things like UI scaling nested elements across aspect ratios and resolutions, something UGUI makes into a real nightmare. UGUI's major benefit was that it was better than IMGUI but not by much.

 

IMGUI had everything wrong with it that was wrong with OpenGL immediate mode. Just like OpenGL immediate mode rapidly broke down once you needed more than a spinning triangle, IMGUI rapidly broke down once you needed more than a quick and dirty debugging interface.

UGUI would have been a step in the right direction but it simply added more problems than it solved. One of the strengths of Unity is the multi-platform support, but UGUI takes the concept and tosses it out the window by making it a constant battle to achieve a consistent layout across all devices.

UGUI performance is simply awful and most people don't truly realize just how bad it is until they watch the following talk from Unity 2017. A not insignificant number of Unity's "bad practices" are being performed regularly under the hood by UGUI. Including variants of GameObject.Find.

UI Toolkit (formerly known as UI Elements) simply cannot arrive fast enough for me. An approach that is not too far away from HTML/CSS/JavaScript makes sense because it's an approach that has proven itself for many years. Since before Unity existed at that.

Spoiler: Unite 2017 - Squeezing Unity: Tips for Raising Performance

 

Except it has been rewritten to use the Playables API and is now programmable, you can add your own burst-optimised passes to it etc.

Several PhysX upgrades.

SBP.

Strange, there are new features in it on every release.

Like, there are plenty of things to rage at Unity about, there's no need to start making new ones up.

 

Dynamic adjustment of walk speed, without adjusting the speed of every animation in a blend tree?

You're trying to argue your way around a simple problem with a simple solution. And it's not even the point of my argument, just one example.

 

And neither is mine, far from it. Needs do vary. Let's just not promulgate the idea that Unreal somehow is extremely difficult or time-consuming to learn – or use – when coming from Unity. That's not the case. The integrated nature of the Unreal engine gives many developmental advantages which simply don't exist in Unity. Whether you need them is up to you and your game, but the learning curve is actually not as steep as some people would have you think.

 

Mecanim works on string hashes, not strings. You can check if the current state is a particular string, or pass strings into it, because the first thing it does is get the hash for your string. With that in mind, you can work with hashes everywhere in it and if you need to display a string anywhere for some reason, have a reverse look-up dictionary, it gives you the hash for the current state anyway.

 

UI elements was not just designed as a more performant alternative, that does't have a constant update loop and doesn't have gameobjects. One of the biggest selling point of ui elements is that instead of having to use prefabs and prefab variants to reproduce content, you use USS files and hierarchies. By default, none of your ui elements have position coordinates, offsets, size etc, it inherits from the uss file and from how the parent visual element sorts its content and how the parent's parent sorts its content. its now < container based > instead of < property based >

So everything is perfectly evenly aligned and symmetrical. instead of making sure all the ui stuff has the same properties and positions, all content by default fill its container. 5 ui buttons for example, will all evenly spread out through their visual element container from top to bottom. or from left to right if you set that in the parent or however you want it. in the old system, if you decide to change your mind as to how the ui should be arranged, you would have to manually resize the buttons and make sure each button offsets in perfect intervals




you can make animations or changes or anything that's required of a hud or anything you could do previously.

it's more performant, iteration time is way faster, its more feature rich. its better in every way, but there's more to learn and get used to

 

I didn't realize this was an argument, I was trying to help you solve a technical problem. Walk cycles specifically you need to set up so the animation lengths are normalized with the same animation beats of feet hitting the ground and lifting up, otherwise the characters feet will shuffle awkwardly as they transition between a run or walk animation. I can't think of any situation where you would want per animation speed adjustments for blend layers which are designed for blending walk and other movement animations almost exclusively. Unless i'm missing some common edge case, not having per animation adjustments would be a positive so you don't accidently offset this parity.

This is getting way off topic.