Unreal Engine 5 = Game Changer

I don't see how you could make ecs any more readable, you'd still be communicating the same underlining idea no matter what language you use. if you don't like ecs, you still won't like it if it were communicated to you in french

 

well, you would find that perfect cache hit rate can be achieved when all your data is stored together right next to each other, instead of in different places in memory. vectorisation is done by the compiler and not a feature of ecs

 

from a scale of 0 being not next to each other, to 1 being next to each other, ecs is a 1

 

From a scale of 0 to 1 ECS is a D, because an Entity Component System has nothing to do with optimizing memory layout.

 

This right here. Hardware will only continue to improve across all devices, we can bank on performance improving by default as always. Hyper focusing on performance and stalling all current development doesn't IMO make sense for the identity of Unity. Maybe it did 2 days ago.

This is a problem with modern tech companies. They are so enamored by monopolizing emerging markets, that they end up overcommitting. There is already more than enough power in dev tools and platforms for the vast majority of game types. Performance is in the death throws of being the bottleneck of "fun". Is fighting 5000 zombies THAT much more fun than fighting 200?

At some point we will need more performance, when we have zombies with emotions, and rational brains. But before we have zombies with rational brains we need ergonomic tools that will allow us to create more engaging content.

This is a common game programmer mindset: to hyper focus on optimizations, to assume 2x performance = 2x better game. "Fun" is much more throttled by tools, by the hiding away of best practices, from build times, from bugs, from lack of in engine features, from confusing API's, from poor repository solutions, from barriers between the developer and ergonomic mechanics. Burnout is the death of forward progress towards more fun. There is far more room to reduce burnout and improve pipelines, than there is to improve performance.

What if Unity focused more on usability improvements, involved the community in sorting out core features and abnormalities that could use improvements. The asset store could sell modular elements of games that were QUITE GOOD. Imagine being able to buy the framework of a diablo style inventory system with all the random modifiers and UI ready to be dragged and dropped into your project. Fully loaded character controllers could also be sold with unlockable double jumps and movement and attack unlocks.

Standardized frameworks would be a joy to work with out of the box with assets that compelled you to buy more, not just to improve your game, but to improve as a developer.

What if making an infinite runner with itemization was as simple as piecing these frameworks together. Imagine the Unity team knee deep in creating modular systems that are well commented. Now imagine each of these assets were accompanied by a 10 minute bracky's style video explaining the code methodologies behind their core features. Cultivate a community of developers that can create great games with a sane level of standardization. Group coding standards would rise across the board through osmosis. Set this standard, invite other creators to match it. Create a network of creators, some who provide tutorials for top selling assets, and provide bonuses to users who reach that top tier level of shine. Promote collaboration among the best of the best. Solicit specific assets that would pair well with the engine. Create something that grows and becomes better rather than the current system of perpetual refactoring.

Why is there so little talk of the cultivation of fun? Of expanding code and tools to make the construction of fun systems less of a headache. Fun could be commodified, fun could be a product. Instead we are rambling on about trillions of polygons. Trillions of polygons are not innately fun.

Imagine a world where Unity made games, actually had a stake in the game, a better perspective. Imagine they had dedicated teams working on titles not just to make a stand alone product, but to make the modular frameworks that can work together to make a variety of titles and sold these bits on their stores.

How many profitable games would benefit from the release of this Unreal tech? A small subset. Most games do not rely on hyper, top end graphics. The biggest hits, the most profitable games are not technical wonders, they are fun. We live in an era where it's a blue moon between compelling, FUN, innovative games. Maybe Unity missed their opportunity. They have not doubled down on making games, they have become distracted by technicalities. Unreal is flexing the GPU, Unity is flexing CPU.

Who's flexing the best tools and pipeline any more? Seems to be Unity less and less.

How many games have failed or been hamstrung because of the clunkiness of having to deal with quaternions? How many developers have devoted months to learning UI, mecanim, and other CORE systems because there isn't a simple 15 minute braky's style video teaching the basics of these systems.

Why aren't more tutorials about core systems like mecanim? Perhaps because no one, even Brakeys' team have access to material to fully understand these core systems. Even Unity's sponsored content is light fluff that doesn't address the core aspects of the engine because they don't want to tackle it. This is the heart of the problem that if Unity solved would put them back ahead of other engines in usability.

The core functionality, the core usability, the core tools that we as developers would like to use to make our games better, to make us ALL successful do not appear to be taken seriously by Unity. They are either viewed as legacy, or in-progress and nothing reaches the level of polish or accessibility that is needed for excellence, or is stable enough for long lasting tutorials.

The frustrating thing is, much of this is low hanging fruit. A few fixes to nagging issues, a bit of listening to the community and providing resources to help them learn new key features and we would all be talking about how "Yeah Unreal is powerful but Unity is approachable".

Unity gets 90% of the way there, and just stops. They almost reach a level of perfection and they stop, distracted by the next shiny object or simply burned out by overwork maintaining a pipeline that is too large.

We all know the feeling, we know what it's like to push and push and be totally burned out and wanting to think we're done. But you can't stop at the end. You have to go the distance and make it perfect when the iron is hot or you end up where Unity is now, surrounded by features that were almost good enough.

Great tools are not born from a great idea, they are born from months of smashing your head against the wall in the pursuit of perfection. Finishing, getting feedback, and starting back up again. The ideal pipeline involves multiple individuals in the know who can share the burden of a common goal of perfection. It is my opinion that Unity needs to learn to be open and transparent with their code to foster this global standard of excellence, that they can sell back to their users.

They need to internally say "Ok we're almost there, lets fix up these last core issues and add this last bit of functionality so this really sings."

The new prefab system for example is awesome, but has a bigger footprint than is necessary, it's clunky. When we dreamt of nested prefabs and prefab variants we imagined shoving a prefab inside another one and calling it a day. It needs to be scaled down and made more elegant. A few more visual ques that bridge the confusion of when things are unique to scene assets or if they have parity with parent prefabs.

There is a clunkiness of not being able to move things in the hierarchy within scene prefabs and the user should be able to toggle if they want parity with the project level prefabs on scene objects so don't have have to worry if adjustments propagated or not. Make renaming them sane and more likely to rename the project parent. Do a better job of remembering the last asset you were looking at when exiting out of a prefab instance.

Prefabs are an amazing tool that is 90% of the way there, but not quite. A great # of people miss the old system. Every time you use the prefab system a little voice nags at you, "this tool isn't done yet."

The ONE thing Unity has always excelled at:
Out of the box usability and prototyping potential with the simple ability to drag and drop assets and C# scripts to make things come alive. If Unreal ever figures this out, Unity is done. Unreal is likely much closer to solving this singular advantage than Unity is of extending their lead in usability.

The list of assets that are good but just need documentation and maybe a bit of polish:
Mecanim
particles
shaders

Things that need a good bit of work:
Prefabs
In engine sound tweaks
Asset store and plugin integration
General implementation of core systems into the Engine so they feel at home there. That Unity is a cohesive game engine that puts its key features in prominent areas and they don't look like tacked on features.

Things that are a tad embarrassing, both in how broken they are, and how long they have been broken:
Lighting
Terrain

I don't think many are asking Unity to be as good as, or even compete with Unreal in AAA visual pipeline at this point. But what's the game plan? How will we continue to make more innovative games in Unity? How do we ensure current and new developers who join Unity won't be left in the dust by superior platforms with better run internals?

Rhetorical question as much has changed as of late. We'll have to wait and see. Here's hoping long standing plans are in action that will improve the painful environment of current gameplay implementation that haunts the entirety of gamedev.

 

I think C++ does not exactly need ecs and custom compilers though.

Few years ago it was possible to run sweep and prune collision detection in C++ program at way over 60 fps with something like 20k objects... on a single core. That's without doing much to optimize it. Games that deal with huge number of entities aren't exactly common either.

You are trying to sell us DOTS. Not sure why. It is currently having opposite effect as you're providing reasons to never use it, more and more as the time goes.

And the main issue is that you believe in it, as faith is not a logical thing. It is common for a programmer to fall in love in technology and go about "spreading the word" about their newfound belief. My practical experience indicates that in time such beliefs often ends up shattered and fail to withstand test of time. "The next big thing" turns out to be anything but, and the more people say that "it is the way of the future", the more likely it is to fail. We had Rust craziness not so long ago. And waves of Godot prophets. Nothing changed.

I know that when making something yourself, it is a good idea to design your product as if the company that wrote your framework will die tomorrrow. You have features available now, and anything promised might not ever come true.

That will ensure least amount of hassle, and also will ensure that completeness of your own product does not rely on promises of a third party which is not under any contractual obligation to fullfil said promises.

If you "believe" in it, cool, but you have to provide good arguments, and not "those who do not use dots are retards", as this is irrational. Otherwise you'll be written off as another programmer in a honeymoon phase. Or a beginner programmer in a honeymoon phase even.

 

under the hood that's literally what's happening, there is no greater level of abstraction.

 

it literally does though, thats absolutely the whole point. all components are right next to each other. there is no greater level of abstraction. if you were to look at the memory, that's what you'd see, a bunch of components right next to each other, grouped by component type. then systems act on those components. GetComponetnDataFromEntity literally is an array, its an array of all the components of a certain type stored right next to each other. ecs is not something invented to make it more readable for humans, its a literal representation of how it is stored in memory

 

Well, I guess everyone lost interest in UE5 already.

 

No. You are conflating ECS with data oriented design and while they are often used together, they are not the same thing.

Who cares about UE5 when we have semantics to clear up?

 

I propose to continue drooling on global illumination video.

I do wonder to which degree the Nanite system is entangled into GI, as like I said earlier - if they're using the tech from the earlier pdf, the one that spltis high poly models into texturized patches, that might not play well with low polygonal models. I suppose as long as they don't calcualte bounce using texturized patches directly.

 

I can tell you every direction Unity is taking is a bad one. ESC, DOTS , all the fragmented and confusing Unity versions ect. ect. There is no chance in hell Unity will be able to do 16 Billion Polygons with RealTime GI!! For another 10years if ever. HDRP can't even do grass!!! That is laughable..

 

it can't be made more readable, you can't iany system on top of that

what do you mean no? it literally is, thats absolutely the entire point of ecs. if dots is not mentally pleasing to you, then tough. that's how it is, its not unity's fault that you can't come to terms with how the data is laid out in memory and that its not conceptually pleasing, and that perfect cache hit efficiency is reached with the dots way of having all components stored together

 

Yeah, on the one hand using the texturized models for GI seems like a huge win, on the other hand, as I said a few pages ago, I then wonder if the system is usable for like stark minimal sci-fi graphics (that would typically have sparse clean geometry).

 

I absolutely couldn't at the slightest bit care less what anyone else uses. i am happy with the easy multicore scaling, i find the memory layout of my components conceptually pleasing, i love the api.

 

I mean the avatar was a hint, but you’re trolling, right? Goodbye.

 

there's no point to arguing with you because you have absolutely no idea what you're talking about and you've likely never even written a line of dots code and you're just completely going off the vague idea you have in your head based on what you've heard

 

That's "source polygons" in the entire scene, which actually makes it a pretty useless number. Especially if a lot of those were coming from off-screen copies of the same ridiculously high resolution mesh.

Didn't they say 20 million for a rendered image?

It's really cool stuff, but lets not forget that it's a marketing video. It's designed to sound and look as impressive as possible. That number is amped up, but if we understand how efficient algorithms work then we also know that you can boost the right numbers to be very high with very little impact on what work is going on.

The implication is that we can get film models and just throw them in our games. They may well have removed the performance barrier around doing so, but that's not the only barrier. How much memory is all that stuff chewing up - largely for detail that's just getting culled out? How much does all that stuff cost to store?

Even if we bring the numbers down to more reasonable levels, though, the thing I like about it is the simplification of workflows. If we can just work on the high LOD versions of stuff and let the computer handle the rest then that's awesome.

 

Now people are trashing DOTS and pipelines, but it was Unity's response to some of the biggest problems Unity had (games were heavily CPU bound and pretty much ALL midrange games ran like S***), and the other one was that the renderer was ancient, the batching was laughable, enlighten was clunky.
Unity is really trying to deprecate the whole engine, while trying to not leave users behind.
I do agree that having 2 pipelines instead of one that can downscale is just asking for trouble.
They went pretty much to the other side of the spectrum, now using DOTS and a totally new rendering engine.

The biggest part of the problem is that the execution is just not there.
There have been many examples of very small teams (or even single people) outperforming unity's execution, which is really concerning.

 

In all fairness, on that specific point I thought (s)he was on the right track? I thought that the selling point of ECS is that it increases performance by improving cache cohesion. It might not be the part of the system that literally lays out the memory, but it's all closely related.

 

If they're using the tech from that pdf, I'm not seeing the benefit for GI from using texturized elements without some additional data. It is convenient to have a "positional grid", but it can't act like, for example, as a collision optimization structure, unless I'm missing something obvious.

 

i'd much rather have dots rather than rocks that look nice close up
multi core scaling, vectorisation, self contained scripts with no dependencies. what more could you ask.

 

Over long period of time, an optimization such as DOTS will be on performance is of course good. But in the meantime, there are many many issues to deal with other that some optimization, that 90% of your customers DON'T NEED. Period.

 

I guess the DOTS is for unity a way to fix everything that's currently not working

 

Except that's exactly what's I'm doing for my custom simplified GI approximation:
https://forum.unity.com/threads/exp...-es-2-0-and-weak-machine.752600/#post-5148662

What you really need is to start a ray and find the end point, texture or mesh don't matter that much. And since it's a global illumination, collision is "free" with all the ray computation as they start and stop at surfaces, getting one is getting the other, as soon as you have real time ambient occlusion at small scale for "contact" shadowing.

 

It is my impression that there is nothing in ECS that requires you to have cache cohesion. You can have an ECS system that doesn’t produce cache cohesion and it would be a valid ECS pattern. It lends itself to being able to do data oriented programming, but it’s not a requirement. At least that’s how I understand it.

And I could be wrong, or I might be splitting hairs, but I don’t regret putting him/her on ignore, at least for a few days.

 

i was just busy backing my scene in unity

 

Like having hired too many devs. Show them DOTS api and they run away, no severance pay

 

This seems to have become another Unity vs Unreal thread. Have used both. I’m not advocating for either engine in the general case as each one has its strenghts and weaknesses.

Imho, the main difference between both engines is the development curve they offer: Unreal allows you to get pretty results faster, but once you need to do some real development (generally early in development), it gets very demanding: C++ is harder to write, it’s much easier to break the entire game, compile times are over the roof, architecture is quite rigid... It assumes you know the engine innards and that you know what you’re doing at all times. Not a bad thing per se, but it expects a lot from the developer.

Unity on the other hand, is much easier to use, you can get further faster, but getting good performance and pretty visuals takes time and experience. So the difficulties come later in the dev cycle. Haphazardly throwing asset store packages at your project is often counterproductive and makes it difficult to walk the last few meters to the finish line.

So at the end of the day, both engines require a great deal of experience to make something worthwhile in. I think its a matter of personal preference and project scope.

 

Actually the DOTS API is a work of art to me. Never would i ever thought of seeing something so simple do so much complex stuff for you under the hood, all while handholding you to avoid you shooting yourself in the foot.

 

No, but there can be multiple user-facing APIs on the one animation system. The new animation system in Unity is playables. Mecanim, legacy Animation, Kinematica and DOTS animation are all implemented on that.

Well, yes, there can be, even in DOTS. In fact they have abstracted the data structures away from the implementations so that you can run Havok or UnityPhysics or your own on them.

 

Wow and they said , there is like 300 statues in the demo if i remember well
Maybe they gonna find ways to improve it later

 

Agreed, while DOTS has its place for performance critical cases, it really isn't a replacement for monobehaviours. DOTS is less approachable compared to the component based system and I'm sure it will push developers away if enforced.

 

I agree.
This shouldn't be a battle of unity vs. unreal. But the reason this thread is so prolific, is because a lot of people are questioning unity and bringing up issues they have with it. Partially, because unity's advancements in graphics are pretty much wiped (in high quality visuals, SRP is a good idea), so they will be looked at as the inferior again. Partially, because the business model has been shown as inferior. Partially, because unity is upgrading itself and you are forced to use an old version and means all the marketing talk of new features means nothing, yet.

I will give unity a few years time to fix itself Workflow in unity was always good, just now, using the newly advertised features is not really working for me personally. Hope it will change and we have viable 2 options for the future to choose from. We still have, but only the stuff up to 2 years ago.

 

Soooo if it will look like, and work like it would be the same (except better)?

Note that DOTS is not editor-ready. There isn't much of the editor integration yet.
This 100% will change in the future.

Most of us will jump onto DOTS train once that happens. It is just a matter of time.
From my experience, it is much cleaner and simpler experience than MonoBehaviours, but MB just wins in the integration / user-friendliness part.

Edit:
I don't understand much hate towards DOTS. Its state-of-the-art dream that most of us mortal game dev coders begged for an eternity. It just not ready yet. In the end we'll probably just operate on entities like GameObjects right now. With minimum to no boilerplates involved.

Heck, you can start writing your own editor with the pure ECS + custom bootstrap already right now. Nobody's preventing that and the Editor is absurdly extendable.

I can understand why less tech savy people are upset, but these comparisons are just wrong.
In theory you'd want BOTH that magical art auto-workflow thingy, AND DOTS.

Imagine full simulation strategies with infinite zoom in (w/o any quality loss) with max possible FPS and full dynamic lights. Posibilities would be endless.

Like everything in this world, Unity is evolving.
MonoBehaviour is a past that sticks until future is here.

 

You know, our team has found that DOTS is such a smarter way of working, that it’s hard to think about going back.

Some folks have asked questions in here about how some game types would benefit (puzzle, visual novel, etc).

Since making the switch to DOTS, I’ve found it much easier to prototype things quickly, regardless of game type.

A smarter, more scalable foundation has given us a better place to start from for any project. If we were to start a puzzle game, we would know that it could scale in some cool way if we needed it to. And that it will be running as efficiently as we know how if we don’t.

 

Isn't it weird that some of our lives are depend on Unity's vision?
And Unreal shows that they can support their users in long run without question. They can give away lots of features and services basically free while I am expected to pay a subscription fee for features that evercoming? Oh, and when that promised features are arrived with "Production Ready" tag, you can't produce s*** with them because they are delivered just in favor to make subscriber hooked...

My suggestions:

• Merging URP and HDRP into Standard Render Pipeline & making them modular enough to scale up and down with additional packages. (You want HDRI Sky, install this. You want volumetrics, install this. You want single pass, remove this.)
• Make Game System tutorials for your modules, targeted more serious audience, if you're gonna ask money for them. (Current "come on kids let's make a game" attitude is funny as hell.)
• Overhaul Unity Hub accordingly. Currently it's performing as a list to see projects and installs which can be more.

 

and the visions of CPU & GPU makers. Yeah...it would be nice to have the time to be self reliant - design everything from scratch.

 

Sooo making them packages? They already are.

Thing is, what you're asking is pretty much impossible (merging everything together) and will result in a complete unusable mess. And also, that would require Unity to deprecate built-in and piss off magnitude of people.

URP / HDRP / built-in are all DIFFERENT pipelines.
They work differently, and their needs are different. Some cannot be simply ticked off.

Pick one, and stick with it. Personally, I've transfered my 3yrs old project from built-in to HDRP with no regrets whatsoever. I don't think its that hard to do on the lesser scale.

And it is better for me, and for the project.
Because HDRP is pretty much good enough already, and it is much better than built-in (in my case).

TL;DR: Just pick one that suits your project most. Know your target audience / devices.
Or even better. Create your own one, that uses only features you need with SRP.

 

Well, I think he’s saying that he doesn’t want to have to choose between the two renderers when starting a project. Sounds like he just wants a “Unity renderer”, with packages that can add additional content if needed, kind of like in the standard renderer days, but better.

 

Unity is simple-ish (C# etc) and flexible.
You can rebuild the graphics pipeline, use all your own shaders etc if you want, so you could go for AAA if you wanted but I bet 90% of Unity users are targetting mobile or 2d or just not the land of endless art-time and optimisation of AAA graphics.

So if all you want is to be amazed by realistic graphics out of the box then try Unreal but otherwise stick around!

 

Modularity within a single render pipeline isn’t free. Supporting all possible feature combinations would force to have a monstruous base architecture.This is hard to write, maintain, customize, and pretty much impossible to make performant. Exactly the problems the built-in pipeline has, and exactly the ones solved by SRPs. Better to have specialized pipelines, that one huge pipeline that does everything, but succeeds at nothing.

 

I don't, wasn't in the moment i guess. Can you elaborate, and point out what caveats turned out to kill the hype? really interesting

 

If anyone is still wondering what ECS is about, this is a good intro:

There is no question that it is more busywork and less intuitive. ECS is an incredibly useful tool to have and opens up certain possibilities that weren't there before, but it's a very risky foundation to build everything on for an engine targeted at beginners and weekend warriors. And if visual scripting is supposed to put a welcoming face on everything, all I can say is good luck with that.

 

I don't dispute DOTS is technically a work of art. Like you said, MB wins in the integration / user-friendliness part, which is very important for keeping developers onboard. No matter how great it doesn't matter if devs don't like the boilerplate stuff.

 

For people bashing DOTS, remember that it’s the name given to multiple things working in unison (that can also be used independently, to great effect):

- NativeContainers allocating unmanaged memory and allowing efficient access to it.
- Job system, for safe and easy multithreading. (this alone is praiseworthy on its own)
- Burst compiler, to generate native auto-vectorized code from jobs. (another brilliant piece of engineering imho)
- ECS system, an high-level abstraction built on the previous 3.

Years ago, in the MMX / Voodoo cards era (man, I sound like my grandpa) this is how you wrote anything that needed to be performant. Specially common design for particle systems, btw. Except that it had you crying blood by the time you got it all working.

So on top of this absolute marvel, Unity gives you a way to work in editor with GameObjects/Components, then convert it all to entities. *mind blown*. I do not think most people realize just how awesome this is. Of couse Unity as a company and as a engine is far from perfect, I’m the first to criticize everything they do wrong (a lot). But this is not one of these things in my opinion, I think I can recognize great engineering when I see it.

 

Unity: Look at all this amazing stuff, thousands of intelligent virtual cameras, state of the art motion matching, thousands of renderers and HLOD, visual scripting, photorealistic graphics, super optimized animation pipeline.

Meanwhile in reality: Can't get out a third person controller that have been working on +2 years.

Like yeah, it's pretty cool all the demos, really amazing you could 4D a guy and have amazing artists working for you.

The 3D platformer was a nice point to actually have a 3d template to work from and improve on that, instead it'll be another project that will be forgotten, with other "templates" that have random scripts that will get abandoned, while their actual template is still being worked on. Did anyone actually start to dig in their FPS Sample ? Did anyone use that as their base for a multiplayer FPS ? At some some point they should prioritize actual usability instead of marketing.

There are improvements for sure, Timeline is in a usable state right now, Cinemachine is a beast, the VFX graph is in constant improvement (and the spaceship demo was one of the few unity demos that is actually educational).

I don't doubt that all their promises some day will become somewhat true, but they jumped the shark announcing them so early IMO.

 

As much as Unity's implementation of ECS interests me, this video illustrates my issue with the design system. Every video on it avoids doing anything meaningful and instead focuses on just putting a ton of objects moving on the screen. Where are the videos explaining how to implement actual gameplay systems in DOTS? FSMs, behavior trees? Where is the video that just shows throwing together a 2D platformer in ECS, animating properly? I've seen a lot of people creating impressive screen savers with DOTS, but I haven't seen anyone showing how to actually make a game with it that isn't just a simple "move dude and instantiate a million bullets at thousands of inanimate things translating towards him."

 

Well, I’m porting an entire physics engine to DOTS. Nearly done with it, btw. Cloth, softbodies, ropes, and fluid simulation, that I had written from scratch in C/C++ using a custom task scheduler and hand-optimized simd. Took 2 years to write the original. It took right under 6 months to port it all to dots. Most of the time was spent copying-pasting code and replacing math data types, it just worked.

You don’t have to take my word for it. Unity’s ecs physics package, you can check it out. If that isn’t more complex than a dude moving around a million bullets, I don’t know what it is.

 

I've only used DOTS for a very few things honestly. (Well Jobs and Burst), never have did much with ECS yet. But I tell you what, seeing a task go from (just an example) - 15MS down to 2MS, then down to 0.15MS with burst is quite a lovely thing to see lol.