Anybody else have aversion towards Unreal, Unity and other ready-made engines?

For whatever personal reasons, for me it's inevitable. I don't like it personally, I like it professionally, but again, it's inevitable.

In my opinion, The future is already predicted since the old Flash days because of its ease of use, and game engines like Unity + mobile devices are the ones that finally let them mesh into mainstream, as Flash couldn't. From what I know, Unity's big venture was its web player, so the Unity's transition mainly comes from web game developers, which at that time was mostly Flash before HTML5 existed. This “Flash developers" won, so the engines are here to stay for the same reason this group of developers exists (and now lead to the next generation).

I'm not saying this from imagination, but based on how game developers in my generation and region were mostly started from Flash until they get to Unity when mobile devices are here, and then followed with Steam indie phenomenon.

I got to pre-face this by saying, I personally hate Unity, for a variety of reasons (the workflows are pretty bad, and you have too little control over the foundation of the engine to optimize them). That being said, I do not belive that the engine actually limits the gameplay in any meaningful way.

For my own free-time project, a 2d action-rpg with ~30h playtime (as of now, which is~50% done), I use my own engine, that I've been developing for the last 12 years. The workflows are much better, so I can create content faster. But I do have to spend weeks, if not months at a time, sometimes, just for improving the engine. So the overall time would be faster with Unity, even though I'm very sensitive to suboptimal workflows, so I'd rather spend +50% time on developing an engine and then using the best possible workflow, then use a premade engine and have to spend extra time on the content creation.

Still though - I could absolutely do the same game in Unity, no question. I could do a 1:1 port of the gameplay, so no, I don't belive premade engines restrict you in that matter. Even at work, where we use eigther Unity or Unreal, our concepts are rarely limited by engines, but more the time we have due to budget. So having to spend extra time on developing the engine would rather limit us, that way.

So yeah, that's my takeaway. Custom engines can offer better workflows, but they are not really worth investing the time for most use-cases. My own engines main highlights are things like deterministic, lightweight replays (that I can use to both auto-test the whole game, as well as record user sessions to reproduce bugs), and a blueprint-inspired scripting language with heavy focus on coroutine-style programming (but with close to native performance and more programmer-focused) that makes creating both gameplay-systems and cutscenes very easy and fun. But if I had the discipline to just use a worse workflow, I could have probably finished the game already if using Unity/Unreal (with the same gameplay, 1:1), because I spent multiple 10s of thousands of hours on the engine already, and I'm primarily focused on 2d… I will continue doing my engine, because it gives me a lot of joy; even when starting to do 3d projects… but for the general case, one of the U-engines will be the way better choice.

ScienceDiscoverer said:
I strongly dislike the vector that game development acquired some years ago, and according to which it continues to move steadily at present. The overuse of mainstream, generic game engines. Yes.

But this trend isn't restricted to just engines. It also affects anything else - gameplay, setting, story, characters.
With that impression in mind, choice of engine seems to have the least impact on the often disappointing outcome.

ScienceDiscoverer said:
I think that the “core” or “soul” of the game is its Engine.

That's only true if your game requires certain technology which generic game engines can not do.
But if your generic game can be implemented without issues on any generic game engine, nothing wrong with using a generic engine.

Ofc. some innovative game with new mechanics, or another game not doing anything revolutionary but being just good, can also mostly be implemented using generic game engines without restrictions. In this case - again nothing wrong about using them.

ScienceDiscoverer said:
Another issue lies in the fact that game designers in many cases need to adjust their design to fit concrete engine.

Do they? I would guess engine limitations are rarely an issue. I mean, they try to make a game which is similar to their last game usually, just bigger. And for being bigger the limit is usually content creation, so budgets, not so much engine limitations. But idk.

ScienceDiscoverer said:
I wish gamedev industry would ditch this engines one day, and begin to foster original ideas on all the level of development.

Every time some studio proudly announces to ditch their custom engine in favor of Unreal it's sad news, and it feels like a slow death of game development in favor of just content creation.

ScienceDiscoverer said:
This is hard and expensive, I get it.

I don't. I expect paying 10 programmers is nothing compared to paying 300 artists.
Idk what's the problem. Maybe it's Epic and NVidia sucking up all talented people, and studios having a hard time to find experienced expertise replacing their seniors.

ScienceDiscoverer said:
I tried it myself, you know. Some years ago I tried to implement some primitive 2D engine, but it turned out to be TOO primitive. This year I tried to challenge myself to create DX12 engine from complete scratch. The ultimate goal was an FPS game.

You could be already done with that game if you had decided to use Unreal, and it might look better and run faster.

Eventually. But maybe i'm wrong. Yep - i'm pretty sure i'm wrong. Otherwise i would not try to do the same thing myself. ; )

ScienceDiscoverer said:
but I got cut down by the super complex math of collision detection system

Personally i do a compromise. I use libraries, e.g. a physics engine.
I worked on physics sim decades ago. I could get it to work, somehow.
But likely i could not reach the robustness and performance of the open source physics engine.
So i better spend my time elsewhere. It's finite, and i can't do everything on my own.

I'm definitely not a fan of Unity at least, which is the main engine that I use at work. It's excruciating to use on larger projects and very slow overall. Just editing 1 line of script code takes 30+ seconds for unity to even become responsive again since it has to completely recompile the project every time. Heck, even launching unity hub (much less opening a project) takes 30 seconds. I'd never choose to use Unity for anything non-trivial. I spend way too much time waiting for Unity to “Hold On….”

For my personal game project there are technical reasons why Unity/Unreal could never work. I'm creating a realistic-scale space/planet simulator, and those engines are not setup at all to handle those sorts of scales. I had to integrate a multiple coordinate system architecture deeply into all engine systems (graphics, physics, etc.), so that massive scale works in single precision without any glitches or faking it. This simply wouldn't be possible in Unity, and would take ages to rewrite Unreal. Particularly physics is a problem - the physics engine needs to handle collisions between objects that are in different (neighboring) coordinate systems. An off-the-shelf solution would be impossible for what I'm doing. However, the pain is that everything must be built from scratch which takes a long time.

For the commercial world, time is money.

Unreal has about a 30 years of work and around 150B in direct technology investment, billions more through mergers and acquisitions over the decades. Unity is a decade younger and around 40B across the decades.

Sure it is still possible to build from scratch, or more typically, from libraries and SDKs that include parts of the functionality you need. But by doing so, you are also leaving behind a multi-billion-dollar technology suite that many players expect to see in games.

Doing it yourself can mean many years, and many hundred thousand dollars or more, developing the tools you get included in the major engines.

JoeJ said:
But likely i could not reach the robustness and performance of the open source physics engine.
So i better spend my time elsewhere. It's finite, and i can't do everything on my own.

Yea, this is actually the saddest part of this this reality for me. If only we could have infinite time… Then, even if it would take 100 years, we still could create the game of our dreams alone and with minimal budget!

ScienceDiscoverer said:
I think that the “core” or “soul” of the game is its Engine.

If the soul of your game is the engine, and not the story, or characters, or gameplay, your game is doomed. A truly great game idea should transcend the limits of the engine/platform it's built on. A better engine might make the game look or sound nicer, but the choice shouldn't make or break the game idea.

Game engines like Unreal, Unity, Godot, etc. serve a specific purpose. They provide baseline functionality and tools required for individuals and small teams to jump right into to making their game, without having to make all their tools first. Imagine if you were tasked with building your own tiny home: if you were provided a with finished lumber, power tools, and plans, you could probably get it done. Consider this statement in Juliean's post above:

Juliean said:
I use my own engine, that I've been developing for the last 12 years

12 years. That is the stone axe route, my friend. It can be a rewarding path, but it is definitely not for everyone, and certainly not for someone who wants to make a game for profit rather than their own hobby project. Creating a whole engine and development environment can consume you to the point where you never get to actually making the games. It's all too easy to become like the woodworker who is only ever crafting their own next workbench.

ScienceDiscoverer said:
I was wondering if I'm the only one having this feelings, or is there any other people like me out there?

I wouldn't call my dislike of Unity and UE an aversion, but rather questionable decisions and shady business practices that are my main concern around those.

Generic engines give out a basic toolset you can use to make a game - it is going to be useful for some projects, but useless for others. Before adding any tool into given project, you have to consider its pros and cons … and here comes one problem with the 2 above mentioned.

Epic is well known for questionable business practices (Fradulent purchases without consent in their products, etc.), buying out companies that developed middleware or assets and pushing those “for free” into UE - which means all the bought companies must operate at loss (which may or may not be a problem). Their introduction of many things into engine just to drop them a version after is another thing.

Unity questionable decisions and bad practices are well known - introducing massive changes like ECS/DOTS, UIElements, etc. - having them for years in beta changing interface (rendering those useless). Not to mention their weird business model (we all knew they operate at massive loss, but their decisions were just bad and weird damage control doesn't help it).

Not to mention their weird introduction of “Industry” and other licenses, which increase cost for industrial customers at literally no advantage. Giving you option - either drop your product or start paying N-times more.

These are reasons why NOT to use them - as you can see, most of those are legal/business ones. There are also technical ones (UE control latency feeling off, performance of both, etc.) - but these are project-specific, rather than generic.

Note: There are other engine development companies that offer to an extent comparable generic engines, and each come with their own ups and downs. I do mention above 2 because I do have experience with both. This doesn't mean I won't consider using them for some project, it's just my 50c on what to always consider with these 2 companies. The benefits may outweigh these risks!

ScienceDiscoverer said:
I think that the “core” or “soul” of the game is its Engine. And by reusing the same generic engines in all the games, this essentially creates unoriginal clones “at the core”. Another issue lies in the fact that game designers in many cases need to adjust their design to fit concrete engine. And when you have only 1 or 2 engines, this forces same designs to manifest over and over again.

This is incorrect, engine isn't anything more than a bunch of underlying functions and libraries allowing you to develop products (games) on top of it. Yes, these generic ones have editors (as well as the one we built & use in-house and for commercial products) - but they're not what makes the game.

If designer needs to adjust their design to fit given engine - then the whole studio does it wrong.

Going for your own tech comes at few downsides - it costs resources to develop it, those can be significant (it depends on what kind of tech you need). Our own tech has been developed for 10+ years so far and I doubt you'd call it solo-project. It is also commercially used.

If I were to make a game without that tech available - I'd choose one of ready-made engines (assuming those would be suitable for given game), instead of developing my own from scratch.

ScienceDiscoverer said:
I wish gamedev industry would ditch this engines one day, and begin to foster original ideas on all the level of development.

This is hard and expensive, I get it. But I think it would be better to have less games, less often, but more unique and optimised ones.

Why? They are tools. Much like WinAPI, Direct3D 12, Blender, Photoshop, Krita, etc. What you do with the tools is entirely up to you.

There is no shortage of generic engines, and there is no shortage of games using their own engine.

UE/Unity/… bring in some specifics to the asset pipeline, which might be considered a good thing in some projects (especially with larger art teams where rotation of artists happens often). Visual-wise there isn't that big difference between what you can achieve with either of those generic engines - all can be used for high-fidelity games, all can be used for stylized games, etc. If it's done good, users won't know.

If the decision is solely based on “UE just looks better than Unity” then whoever called that decision and the management are just full of complete idiots (and yes, I know some teams that did this).

Overall - use the tools you consider the best for given kind of job. If Unity can significantly accelerate development of your game and risks aren't that big - go for it. Same foes for UE. Or for Godot. etc. If they won't provide any major benefit (or no benefit at all) for given project - don't use them.

frob said:
Unreal has about a 30 years of work and around 150B in direct technology investment, billions more through mergers and acquisitions over the decades. Unity is a decade younger and around 40B across the decades.

Kind of. Most games nowadays aren't even pumping out the most realistic rendering. You only need about a years worth of work if you are talented, not 30 years x 1,000 developers for a mass majority of games out there to build an infrastructure.

I've found that at every job whether in-house or Unreal, I program about 1000x slower than if I boot up my codebase and want to implement some random feature. Working at EA with Frostbite being the absolute worst. There is a misconception that shared engines (Frostbite) across teams increases value because of some $100B you think. I can't even explain how painful and timewasting my go on EA Frostbite was just getting builds to work or track down someone for knowledge. Paying someone 150k/yr but only able to be effective 75k/worth (honestly more like 30k worth). That was an entire team. Losing 30Million/year and a much worse developer velocity. Nobody on Madden @ EA knows anything about anything going on with that game since they ported to Frostbite.

Engine does matter though. Unreal was pretty nice to work with. Respawn being under EA has said hell no to it and is more productive in Unreal Engine. You have people learning it a bit in college as well, so it has a wider talent pool.

The biggest issue I have with Unreal is their selling of shares to Tencent.

ScienceDiscoverer said:
I think that the “core” or “soul” of the game is its Engine

Most zoomers will not spend 5 minutes to learn how to write a few for cycles to render the models and the geometry of them, when they can use this 5 minutes to watch tiktok videos.

Some type of existing engines are very useful (such as an RTS maker to make an rts, lets call these genre-specific makers). But these unity-unreal-cry type of engines, which have one sole purpose, to make up a cover for the fullblown incompetence and lack of real passion of the so called “developers”.

And ironically the end result usually takes far more time to create, than what would it took if they would have spent a few weeks to learn the basics… because for example instead of understanding what a 2d array is and making their game map level overnight, they start singing and lament around some camp fire for 10 years, crying how a “proper level design system” and the people to operate them will require another 100 person. Digging a much deeper hole than what they would be otherwise in, vomiting and grunting in front a mirror for years, conviencing themself about how impossible is to write a game engine (aka for cycles with gldrawarrays and fread) and then they vomiting their sorrow on others, infecting them with their zombie bite.

To also reflect on your personal problem.

ScienceDiscoverer said:
I tried it myself, you know. Some years ago I tried to implement some primitive 2D engine, but it turned out to be TOO primitive. This year I tried to challenge myself to create DX12 engine from complete scratch. The ultimate goal was an FPS game. I managed to setup the pipeline, write some simple shaders, generate some primitives and even add some controls but I got cut down by the super complex math of collision detection system, and because of this had to freeze the project for the indeterminate time…

Stop overcomplicating the problem you are facing. You could have used opengl instead of directshit12 and would have achieved your goal 99% faster.

Techbro-ism (austistic fixation of cutting edge technology) is just as bad as the incompetence of the unity boys, its just the opposite extremism.

You should learn how to choose the efficient solutions to your problems, what should be in front of your eyes is how to solve that problem in an efficient, reliable, compatible way as fast as possible, and this is not just true for game engines, its true overall to the entire it. Like for example your office coworkers will not like you, if you built the network from centralized servers and switch devices in total of 40 k usd - when you could have just used old 6 tplink routers bought for 5 dollars each.

When i did my first renderers, i also fell into this trap, listening to techbros who randomly selected a new feature which they read on some gamer bloodstephen site about “how it will be the new future” and trying to implement some of them… Dont do that.

Geri said:
incompetence and lack of real passion of the so called “developers”.

Just call them ‘content creators’ like i do. Avoids the insult. \:D/

Geri said:
Stop overcomplicating the problem you are facing. You could have used opengl instead of directshit12 and would have achieved your goal 99% faster.

Yes, i can second this. I mean, i really heave to use Vulkan, because it runs my compute stuff twice as fast.
But the day i switched from GL to VK so far was the last day i did some actual gfx on GPU.
Drawing a single triangle with VK is more code than a whole software rasterizer, so i really postpone the tedious gfx work as far as i can. I don't want to check 10 tutorials and specs that read like patents, just to draw some stuff.

GL was so much easier to use. And i miss it as much as i hate it.
However - sadly there is no raytracing for GL or DX11. Maybe you don't need that anyway, but this also means the industry has decided that the old and easy high level APIs are dead.
Intel already only emulates those old APIs.
As devs, we can contribute to a sane and efficient industry by not using deprecated APIs anymore, so GPU vendors can focus on making drivers for fewer APIs, but those well. That's faster and cheaper GPUs for us.

Thus, you should not attempt to stop low level people, i think.
Low level is the future. It's harder, but if you do anything interesting on GPU, it's totally worth it.

Geri said:
Techbro-ism (austistic fixation of cutting edge technology) is just as bad as the incompetence of the unity boys, its just the opposite extremism.

Yes. Those guys have images of Jensen under their bed instead a Playboy magazine. And they already prepare to put their 4090 on ebay to get a 5090 on day one. And they believe that restir is an ‘optimization’. Haha, how foolish. /:D

But that's not why people use low level APIs. It's just about getting better performance for more work. That's all. And it's a good thing, not a bad one. ; )

JoeJ said:
Yes. Those guys have images of Jensen under their bed instead a Playboy magazine. And they already prepare to put their 4090 on ebay to get a 5090 on day one. And they believe that restir is an ‘optimization’. Haha, how foolish. /:D

I have seriously laughed for past 10 minutes.

The problem of techbro-ism is that they are overly fixated on some tech, while considering everything else vastly inferior. Honestly I'd love to see their explanation of it … as theory behind such things is non-trivial and contains many pitfalls and possible problems.

Last time I laughed this hard was a statement from game studio, which used Unity before, with note: We are switching to UE5 for our next game because it has superior graphics to Unity.

Vilem Otte said:
Last time I laughed this hard was a statement from game studio, which used Unity before, with note: We are switching to UE5 for our next game because it has superior graphics to Unity.

But why is this funny? UE has high detail geometry and dynamic GI. Unity has neither?

JoeJ said:
But why is this funny? UE has high detail geometry and dynamic GI. Unity has neither?

I will object that with simple:

• Unity does have GI solution (for years) that are built-in (Enlighten one since 2019 already), additionally there are additional user-made solutions with various methods like VXGI (and more). They were progressively updated the HDRP one - and it is competitive to Lumen.
• Geometry-wise - if you're talking about standard geometry, they are pretty much equivalent
• When you're talking about virtual geometry - Chinese version of Unity does have that (I'm not sure why Unity didn't implement that for non-Chinese version so far - maybe there were some licensing/patent problems outside of China?). Additionally user-made solutions are available for some time - but they do vary in quality

Also we're not talking AAA studio, but an indie one.

…

The main thing in terms of quality are assets, the difference lumen/nanite makes is really tiny difference as long as you have great design, nice assets and high resolution textures (plus the moment you precompute lighting - that surpasses any dynamic GI computation that currently exists in terms of quality, as long as you have high enough resolution).

For this I'd recommend looking at de_prime map in old CS:GO (I'll attach a video). The main point is, this one is still done on somewhat old Source engine, but due to heavily precomputed lighting, good assets and textures, etc. … it can still visually hold very decently in comparison to different engines.

Vilem Otte said:
and it is competitive to Lumen.

Can it do reflections as good as UEs SDF tracing? I have never seen such thing in a Unity game.
I guess Unity also lacks VSM and recent advantages on soft shadows, but idk.

Vilem Otte said:
When you're talking about virtual geometry - Chinese version of Unity does have that

Yeah, they work on it, but afaik that's a fork which has nothing to do with Unity. And i have not yet seen that either in shipped a game.

Vilem Otte said:
For this I'd recommend looking at de_prime map in old CS:GO (I'll attach a video). The main point is, this one is still done on somewhat old Source engine, but due to heavily precomputed lighting, good assets and textures, etc. … it can still visually hold very decently in comparison to different engines.

Nah. This is still dominated by SSAO, no complex materials just flat diffuse everywhere for most. Like a game from the 2000s but with hi res textures.
They fail to take profit from baked lighting. There would be better examples, but i can't come up with one quickly.

Now, i have played quite a few UE5 games already. And to me it's a noticeable generational leap visually. It's more than what we've got with the PS4 generation back then.
Though, i never noticed any dynamic GI in any game. Never i can open a door and see how the light floods the whole room. I know it works, but only from demos on YT, not games.
I guess the level designers just miss the opportunity so far, and have not yet learned to take advantage.
Or maybe they need to exclude doors from GI, similar as with characters and most dynamic objects.
That's something i really wonder about. But otherwise i'm impressed and also happy with perf. on my old HW.
(Sadly i'm not impressed from the games themselves til yet, but that's another rant.)

Personally i do not wonder if some devs switch from Unity to UE for better visuals.
I wonder much more why Unity buys a offline VFX company, but refuses to bring their gfx up to date. It took them a decade only to get their TAA right.
There are impressive Unity games too, e.g. this:

I'm impressed from all those simulations going on. But the lighting feels average and can't compete UE, imo.

JoeJ said:
Maybe you don't need that anyway, but this also means the industry has decided that the old and easy high level APIs are dead. Intel already only emulates those old APIs.

Yup, a natural fallout.

Players want photorealistic worlds with tremendous complexity. Major game engines provide all the heavy lifting without individual developers needing to implement it. Click a checkbox and you get realtime, photorealistic dynamic lighting, shadowing, and effectively limitless view-dependent on screen detail.

The systems aren't designed around “draw a triangle" or “draw a cube”, and haven't been for many years. Instead the systems have changed to “draw this complex scene document that's longer than a bestseller novel." The consequence is that you build a system capable of rendering the complex scene, but instead of throwing gigabytes of data at it, you give it the document with your single triangle.

JoeJ said:
Can it do reflections as good as UEs SDF tracing? I have never seen such thing in a Unity game. I guess Unity also lacks VSM and recent advantages on soft shadows, but idk.

Technically speaking Unity is quite modifiable as engine, with SRP and other additions over the past years (but not just those - it was quite “bendable” even before) - there are SDF generators + tracers well integrated and implemented by 3rd parties. Same goes for various shadows algorithms.

The question is - whether this counts (I mean from users-perspective it definitely does … but it isn't developed by Unity Technologies)? I don't have much experience with UE - so I can't speak about how modifiable it is.

On the other hand I do have quite a lot of experience in Unity (and we had to make it work with custom ray tracing, integrate with in-house engine, etc.). I can't share that work though due to legal reasons (unless I'd talk to my partners about sharing specific things out).

…

Additionally, Unity does also implement HW Ray tracing for quite some time in HDRP for example. Feature-wise they aren't really as behind as people tend to portray them.

JoeJ said:
Yeah, they work on it, but afaik that's a fork which has nothing to do with Unity. And i have not yet seen that either in shipped a game.

It is Unity official version for China - https://docs.unity.cn/cn/tuanjiemanual/Manual/VirtualGeometry.html​ - this is the official docs for it and they also have some more details in https://developer.unity.cn/projects/64883165edbc2a116e4f941e​

I still have no idea why they haven't considered adding that tech also outside of China and what's their reasoning behind that.

There are of course other various implementations on Unity - at various stages of implementation and reaching various performance.

As for shipped games - one of the problems of Unity is that AAA studios just doesn't select it. Yes, we have Cities: Skylines for example (incl. the 2nd one - which has terrible performance) - and it is by all means a high fidelity game … still, most of the games in Unity are smaller.

For whatever reason decisions of Unity corp. doesn't seem to be in line with their target audience … which I consider much bigger problem than missing tech A or tech B (which is, in case of Unity, still supplied through 3rd party assets).

JoeJ said:
Nah. This is still dominated by SSAO, no complex materials just flat diffuse everywhere for most. Like a game from the 2000s but with hi res textures. They fail to take profit from baked lighting. There would be better examples, but i can't come up with one quickly.

I wanted to point that one out because it's kind of abusing an engine that's ages old, while still keeping the results somewhat good enough quality.

It will heavily differ on what kind of visualization/game you look at, and what you aim for. For this kind of games it's absolutely okay to have precomputed lighting, etc.

JoeJ said:
Now, i have played quite a few UE5 games already. And to me it's a noticeable generational leap visually. It's more than what we've got with the PS4 generation back then. Though, i never noticed any dynamic GI in any game. Never i can open a door and see how the light floods the whole room. I know it works, but only from demos on YT, not games. I guess the level designers just miss the opportunity so far, and have not yet learned to take advantage. Or maybe they need to exclude doors from GI, similar as with characters and most dynamic objects. That's something i really wonder about. But otherwise i'm impressed and also happy with perf. on my old HW. (Sadly i'm not impressed from the games themselves til yet, but that's another rant.)

So far I wasn't really that impressed with UE5 games, and that mainly counts for visual/performance rate (when you need to upscale the image - it is by far worse than PS4 era games).

As for the games - I have to second that I'm not impressed by the games itself. They can be visually beautiful - but that will only hold the game for so long. If they're boring, with shallow characters and bad story - the game is just bad (but yeah, this rant can be done elsewhere).

…

This being said - my most “regular” game these days is AoE2.

JoeJ said:
Personally i do not wonder if some devs switch from Unity to UE for better visuals. I wonder much more why Unity buys a offline VFX company, but refuses to bring their gfx up to date. It took them a decade only to get their TAA right.

The TAA bugged me for so long (among other things). They did (and still do) very … weird things as a company.

You have 3rd party unbiased renderers that integrate well with hw rt they provide. But they're unable to provide theirs? Even after buying whole company focused on such thing?

The worst thing on Unity (and again, I can't really compare to UE and comparing to in-house tech is unfair) is that their performance gets version-by-version more terrible. Every single change in C# code or assets ends up in progress bar where you wait for multiple seconds. That wasn't case 5 or 6 years back, now it is.

This one thing is objectively much worse than any of the visual things above - and it doesn't matter how much visual extensions they bring in - as long as they won't fix interactivity, it won't matter. Doing larger-scale projects in Unity is annoying and you're constantly fighting the performance of editor (I know that far too well). Sigh…

Vilem Otte said:
Every single change in C# code or assets ends up in progress bar where you wait for multiple seconds. That wasn't case 5 or 6 years back, now it is. This one thing is objectively much worse than any of the visual things above - and it doesn't matter how much visual extensions they bring in - as long as they won't fix interactivity, it won't matter. Doing larger-scale projects in Unity is annoying and you're constantly fighting the performance of editor (I know that far too well). Sigh…

This is my biggest problem with Unity and it happens even in small projects (<1 GB). It's a huge productivity killer. I sometimes wonder how much developer time (and money) is lost waiting for Unity to “Hold on…”. I think the editor is just very poorly designed and implemented. Even opening Unity Hub takes 30+ seconds, much less the time it takes to actually open a project. God forbid you need to re-import a large project. You might as well come back the next day (I literally once had a 18-hour first opening of a 35 GB project). Yuck.