Anyone here abandon Unity for another engine only to return later?

I still would like to have C++ bindings for unity, though...

 

All fair points but you missed a crucial thought! What does it help you to have all those if the editor is constantly locking you out of the workflow and shows you its hold on window for hours? I really tried to work around it by writing some code during that time but it constantly steals focus and makes this absolutely unbearable.

If you think i am exaggerating even a bit i am not alone in this boat (was), have look here -
https://forum.unity.com/threads/lots-of-busy-hold-on-etc.833644/

This problem persists for years which kinda makes Unity look either incompetent since they have no idea how to fix it or they don't give a damn (don't know which one i would prefer).

As for C# - it's good and no questions here but i'd rather code in Brainfuck if it means i can get actually work done. That's the most important point at the end of the day and in i don't usually care what engine a game uses, it's either fun and polished or it's not. I am not tied to any language thanks god since in couple weeks it feels second nature to me.

Sometimes it's important to leave the comfort zone and explore new territories and that precisely in what direction i took now. Just make sure you don't get burned as others did.

 

I'm all for greener pastures myself but, just to make sure, did you try disabling collab?

I had similar problems that I narrowed down to collab as the culprit.

(I don't mean to derail this into troubleshooting, just offering suggestion in case you want to try again some time)

 

Thanks for your suggestion! I tried a lot of things and missed every deadline and thus failed the project - this is sad really - an engine should take most of the work from you not work against you. I moved on now to a different engine.

 

Unity is fine to me, the problem HERE its me and i cant change my own brain to a better brain to code

But, we learn.

 

First thing to do:

Disable domain reloading.
https://docs.unity3d.com/Manual/DomainReloading.html
This will speed things up.

Additionally one of the staff members (I think) suggested to break code into separate libraries using asmdefs.
https://docs.unity3d.com/Manual/ScriptCompilationAssemblyDefinitionFiles.html
I'm not using this right now, but people reported a good speed up using those.

You don't really want to code in brainfuck copared to C#, by the way. Too many missing features.

 

I wonder how many of these stalling issues come from importing a bunch of bloated 3rd party Asset Store packages and then simply not knowing where to even start sorting things out. Perhaps the issue is not entirely with Unity?

 

My guess is almost none.

Bloated 1st party packages from the package manager on the other hand for sure had a big effect.

 

In that case, it should be a pretty straightforward fix in a couple clicks. I now remove most of them upon starting a new project.

 

You don't say. It would be still more productive then starring at hold on for most of the day. Weird huh?

 

Yes, as I’ve been saying Unity becomes better the less of its features one uses.

I wonder if we extrapolate a bit if there’s an interesting conclusion that can be made.

 

I've been using Unity for 12 years now across 5-6 different PCs and never had that issue.

 

There is a first time for everything.

 

The vast majority of users don't experience this issue. Otherwise, that thread would be way bigger than it is.

 

That would be accurate if you were actually "The vast majority" to speak for all - there is also a majority that just doesn't give a damn and there is one that just googles this problem, sees it's being worked on (whatever that is) and doesn't waste time posting (or just rolls back to prev version).

 

That's what i tried with great effect. Did extrapolate straight to zero and now have absolutely zero problems with Unity. - xlerp(Unity, AnotherEngine, 1);

 

I suspect there'd be no thread, as everyone would just leave. So the problem clearly can't be the norm.

What "shocks" me is that someone would let a project fail as a result rather than investigating and dealing with the issue. Computers are complicated, and effectively random stuff like that occasionally happens regardless of the tools you're using. Solving issues comes with the territory.

 

Just a reminder, this thread is about people who left and then returned! So all you people who simply left are off-topic.

 

This is why I'm saying, Unity was successful in the democratization of game development. Professionalism isn't expected anymore. Writing on a forum that "something is wrong" is exponentially easier than actually find out what's wrong and communicate the issue on a basic level.

The basic premise of this thread is wrong. No one should "abandon" Unity and then "return". Everyone should learn as many engines/techniques as possible and choose their right tool for their right job. I have 4-5 engines (I always delete and then reinstall Godot because I hate it) installed and work in 2 for longer time.

 

Some years ago i was a liitle bit sick of unity (i think it was 2017) in my mind i had this awesome commercial game's idea (very noob on those days jajaja) and i think unity was free but very limited and i was very frustrated, so i tried unreal, the first day was O.O wow this looks pretty out of the box, i made some objects and weapons for my game and ooooH looks preeetty XD, at the end of the first week i was: huh, so, unreal does not have that tool and a tool for doing this thing or that thing.
At the end of the second week i was: "huh, so, everything in unreal is almost 3rd party tools, i mean, is not bad ok but not that great.
At the end of the 4 week (i believe) i was like: this S*** runs like a potato i'm sick of this, yeah looks pretty but is not exactly well performance and some thing are annoying to configurate. Some times i liked the engime but most of the time it was not good for me. I spend 2 months with unreal (i think it was 4.3) and my project was everytime slower and slower.
I came back to the forums to see "made with unity" things and there were so many beautiful projects here and i said: "f*** Unreal, i'm going back home, i will make a simple game to learn stuffs and make some money to pay the pro".
Additional note:
Look i know Unreal is pretty and all stuffs, i recently tried the 5 and i'm in love right now with lumen is waaay superior to whatever unity have for lighting, but, i also know that most of the problems people say are their mistakes, like: " why i have to change my version everytime? why there are so many bugs? Why an URP version?
I'm not talking s**t, watch this:

You need better information to work with whatever software you want. Unity is not "prettier" or "AAA" than unreal, not even close, but it works pretty well if you know what are you doing. There are so many devs that can tell you the same. Do not blame unity for your mistakes.

 

Don't quite get your point here - if your new to gamedev then this is one workflow - there are publishers that set deadlines or you have a contract for a certain amount of time, if they aren't met they might close the project. Since you probably didn't read my prev posts - tried everything possible until there was no time left. So no idea what your really talking about - if you expect me not to have tried anything to my best than that's your thought process (and probably how you work) but that doesn't reflect me in the slightest.

But you miss the point here completely (like some here for some unknown reasons) - i'll try to chew it through for the last time since it's getting repetitive:
That this problem even exists for years for "some" people and might appear at the most inappropriate time for "anyone" is pretty reassuring isn't it? Don't get why it's so hard to comprehend.

theory

 

You mean to say that this nonsense in this video for example is not a Unity mistake but mine? (wow )

Did you bother reading this thread i was referring to?
https://forum.unity.com/threads/lots-of-busy-hold-on-etc.833644/

I work with Unity from version 5. My mistakes are my mistakes and i know that. But clearly you are defending the wrong side here. Again a progressbar that tells you it does something should NOT be intrusive or break your workflow.

That this hold on thing even exists, pops up multiple times in the center your screen, steals focus and you can't set it to run in the background - that is some absurd design. If you are defending that then i am wasting my time.

Here is a good design i.e. - the editor starts up, if it can't show a progress bar "inside" the editor for some reasons then ok - show the hold on window but make it possible to click it away and not make it popup afterwards a gazillion times. Or make a checkbox inside hold on that says "don't show again" or something like that. Pretty difficult engineering that isn't it?

 

No, it wouldn't be..Brainfuck is a pure turing tape. Even if unity froze for half a year, you'd still be more productive with it than with a pure turing tape.

I gave basic steps to reduce amount of loading. Did you try those? Because in absence of information the assumption would be that you did not.

That's GAIA. A 3rd party addon. Default assumption would be that the problem lies with GAIA. You should contact GAIA support with your issue.

The engine would behave this way if something continuously generates files in project's asset directory.

 

I never left, sorry for being off topic

 

I really appreciate your suggestions but i switched engines already (and yes, tried everything from the mentioned thread). Just wanted to "hold on" to this thread to make a sense of how the community ticks. Your advice might help others though!

The point i am trying to bring across the whole time is that the design is absolutely flawed with this hold on thing. I worked on huge projects before and with a lot assets in your project you can clearly see that a hold on touching all of them is a design fail. More so if Unity crashes and you delete the Library folder then the hold on repeats. Basically for years nothing improved in this area and this is sad. Unity 5 did hold ons (same focus stealing, same popup in the center) Unity 2022 does the same. Nice!

I don't see how this nonsense design should be anyone's mistake but Unity's. Picking Unity for the next project now that would be 100% my mistake.

 

The amount of ways in which you can use any engine is immense. Sometimes all your use cases are well supported, and it works like a charm. Sometimes some of your use cases aren't supported, and you're better off switching to another engine that does support that use case. In turn it may not support another one (that you don't care about at that time).
Sometimes it's just that the grass seems greener on the other side, but the cellar in that house is underwater. But if you never enter the cellar that's okay. You may never realize or care.
Sometimes you think an API matches your use case, but it's only on the surface and underneath it's accidentally quadratic and blows up.
Sometimes it's not you doing the problem, but some third party between you and the engine that ends up having a stinky closet when you look too closely at it. But again - for many users that may be fine, if they just care about the living room.
You can also end up only using the living room, and end up proclaiming the entire house is brilliant because the living room is brilliant. You've just never explored the rest, as you didn't need to.

This thread seems to be pointed at the case where yes the grass is greener on the other side, you moved to that house, but then you find out you did need that cellar and that now it's a flooded one, so you moved back. So the grass is a bit yellow now, but at least the cellar is useful again.

 

My point is that in many cases people claim to have had money and reputation on the line and still let stuff like this stop them. I was a rookie once, too, and I was also running paid projects at that point, and we ran into snags along the way. One approach that did very well for us was to treat everything as if it were our fault, and learn our way around it. Why? Usually it turned out that it was our fault, because we were green. Accepting that helped us get moving again more quickly and lead us to learn more, even if that meant a workaround rather than a perfect underlying fix. But mostly because blaming your tools makes you look bad even if you're right.

There's this old proverb that "a bad tradesperson blames their tools". The point is that even when something does go wrong, which happens from time to time, a good tradesperson isn't stopped by it. They have invested in good tools, have the experience to work through issues, and know to plan in contingencies in case they need to do that. So if they get to where they're excusing their performance by blaming their tools then the tools usually aren't the only thing to blame.

S o even if you're right, playing the blame game makes you look less reliable.

Note that criticism isn't the same as blame. Criticising tools is good where it's relevant as that's how teams internally gather data to make better decisions, and it's how tool makers get feedback to make their stuff better.

 

Just to dogpile onto what @angrypenguin is saying here, I too faced the "hold on" bug and as a completely non-technical noob, just through process of "turn one thing off at a time" I was able to find a way around it.

Now, I am not excusing Unity or suggesting to hammer through the pain and stick with unity because you like self-abuse - I left for Unreal and am developing from on top of a rainbow now - but if the hold on bug was only thing stymieing your development in unity, that would definitely be a bad reason to leave if everything else was going fine.

Bugs like this, even if a moron noob can get around, nonetheless cost time and energy and just because a problem can be solved doesn't mean that the existence of the problem doesn't have some effect. At the end of the day, the only problem we all really face is how to manage our time. So that is the big thing to consider when assessing the tool. Does it save me time, or cost me time?

But first thing I noticed when I saw the video was that the project looks like mine. Realistic graphics, open worlds, lots of foliage. And the same problems I faced. Whereas people who have been using unity since the dawn of time with no problems are making what I would consider to be "unity type of games", i.e. mobile, non-realistic graphics. Which just goes to illustrate, they are using the tool for what it is best suited for, hence not running into problems.

 

I might start quoting other posts so you guys take this seriously. I doubt anyone actually read the thread with hold on problems. Let me quote this for instance:

"Imagine being in my shoes, having pushed hard to switch to Unity for a new project at the company I work for, only to see our productivity tank completely compared to previous projects thanks to a completely busted up editor. Not only these constant issues make my work unbelievably frustrating and cause me and my colleagues to miss deadlines, I was made to look like a complete and utter buffoon to my bosses and colleagues because it was my call to switch to Unity. Saying I'm at my wits end is the understatement of the month."

From what your saying him and colleagues included kinda blame the tools and are bad at what they do. And note that apparently that happened on multiple PCs so this thing is pretty repro as it seems. Now, the question is why should someone waste that much time figuring this stuff out? Why should i constantly find workaround instead of working? Why don't the devs step in and resolve this for good? As far as i can tell there should be alot of bug reports already.

I am no rookie and worked with multiple engines. Heck, i even had to modify UE4 sources to get the desired behavior we needed (path finding problems) - so it's is normal to sort problems out if you encounter them. The point is that it becomes FUBAR if this battling/working ratio hits a certain threshold and makes you outright unproductive. You can't expect anyone to continue sorting things out indefinitely. And even if you manage this and solve the issue there is this feeling and high probability that you will encounter your next workaround soon enough so you kinda think "should i really go on with this?".

Nope, that had actually the reverse effect. I just showed them this pretty Unity hold on window and pointed to some forum threads (needless to say they were kinda shocked). The decision was made to pick a different engine but of course i had to figure out which one would be more suitable and do some tests first - so we agreed on that.

Isn't that what i described recently criticism? and constructive criticism at that? We might have different ops about criticism.

"The point i am trying to bring across the whole time is that the design is absolutely flawed with this hold on thing. I worked on huge projects before and with a lot assets in your project you can clearly see that a hold on touching all of them is a design fail. More so if Unity crashes and you delete the Library folder then the hold on repeats. Basically for years nothing improved in this area and this is sad. Unity 5 did hold ons (same focus stealing, same popup in the center) Unity 2022 does the same."

 

Unity has/had tons of problems. I remember working around point sprites because Unity didn't call glEnable() somewhere in there code and those point sprites had no textures on them (just a colored square) - workaround was to triple the vertex count and split them inside the vertex shader (memory wasted real hard). We did write about this but who cared? (not working - but working around again)

Next up from the top of my head was that you could not reduce the vertex/index draw count on the fly. Every graphics API has a draw call command with a range (ie. glDrawRangeElements) where you can pass that range. Pretty great thing if you want to reduce particle count the farther the distance. Had some major troubles with that to since that wasn't supported at all. Was a some years ago and might be well supported these days with the custom render pipe. (not working - but working around again)

Why i am telling this? I came to the conclusion that working with closed source engines isn't really a thing for me apparently since i am constantly depending on the devs. Had Unity been open source those things i described would be done in a day. So i left and for a good reason - too many workarounds anf engine battles instead of smooth workflow. Was probably the last nail in the coffin for me. Agree with you on most points though!

 

Did you read actually the title of the thread? Because this rally turns into blaming tool and excuses, based on own choices. Otherwise this is really off topic.

 

BS.
https://docs.unity3d.com/Manual/WhatsNew2020LTS.html

And again, the problem isn't the pop-up, the problem is when whoever experiences the popup doesn't find out what is the issue. Spoiler alert: it is not the popup.

But go on, don't let the facts creep in.

 

As for the title, I wouldn't say I ever abandoned Unity. I did try to learn other engines like RPG Maker and Unreal (technically UDK) but Unity is what I stuck with. It worked better for me than the others and felt way easier to understand workflow.

If I was to ever abandon Unity now, it would have to be over something drastic like a paid subscription to use even basic features. I only really use Unity in a hobby setting and wouldn't bother to buy a subscription to use it.

 

He could be meaning the checking for changes from Collaborate.

 

Just answering other posts - hope that's ok.

You mean this one?

If it looks like a hold on, sound like a hold on and behaves like a hold on i guess it must a hold on.

 

I still don't remember this window before 2020 at all. Certainly not Unity 5.

Also feel free to interpret my post in its entirety.

 

The thread was about people who returned to unity, though.....

There was a popup progress bar upon import.
Lengthy operations occasionally had a progress bar in bottom right corner, although this probably mostly applied to lightmapper.

Instead of hold up the editor could just freeze.

 

I know. That's what I'm talking about.

 

Honestly? Yeah. Changing core tools is always a risky process. Risk can be managed, and either that didn't happen or the steps put in place weren't effective. Everyone starts somewhere, so I'm not going to think less of someone for not getting it right the first time. But the tool blaming attitude means you're more likely to repeat the mistake, because you're treating it as if it's someone else's responsibility rather than actively figuring out how you can deal with "unknown unknowns" in the future.

As I said, I ran projects back when I was a rookie, too, and we ran into issues. Everyone runs into issues. You've got two choices:
1. Get hung up on them, miss deadlines, "look like a complete and utter buffoon to [your] bosses and colleagues" and clients, or...
2. Accept that stuff going wrong is normal and dealing with it is a part of the job, account for it in your planning, and build a reputation for reliably getting the job done.

 

no no no hahaha not you (maybe) i know every software in the world has bugs and issues, do not take what i said personally if is not your case, there are people that blame unity for their mistakes (sometimes even i do that), now, why are you taking it personally?

 

Also... you do realise that it can be disabled, right..?

 

Maybe, try to create a new thread (because is obvious that there are various reasons for that and maybe is not unity's fault) and lets keep this post on the original subject

 

They used to just have a spinning circle in the bottom right, but then some random staff member at Unity decided to add a progress bar to the middle of the screen...

Nobody asked for it. It's just that even back then people were complaining about the editor being unresponsive, and they didn't notice the spinning circle. Unity's excuse for keeping the progress bar is that the editor will not be interactable, even if they removed them, so they might aswell keep it.

I say they should just go back to how it was before...

 

Eh, if I have to wait regardless then I don't think the presentation really matters. I'd much rather be told I'm waiting than think the editor is actually frozen.

 

I think multiple Unity devs have written on the forums that the pop-up was to make it plainly clear why Unity is locked up, rather than a spinning circle which nobody would notice and subsequently complain about. Ergo, it's the result of feedback from users.

2021 and beyond also gives much more detailed information about what Unity is doing under the hood.

And you can even turn it off, or change the period before it pops up. But seems like folks are going to complain regardless.

 

It's created more complaints, and do users care that SceneView.OnGUI.Repaint/etc is happening? You could get that by clicking on the circle.

I'm more interested in why it hangs for a second when trying to open a component for the first time. Or why it doesn't load a project properly until you focus the window.

 

I tried Unreal for just such a project, and yes, if your goal is to make a realistic world with a first/third person controller Unreal is so much easier in many ways. Many of my projects are not that, they require a unique solution and I like that Unity doesn't push me into a FPS game all the time. I can meet with folks, design and plan for what needs to be made and easily make it with all the support, documentation and tools in Unity. If what needs to be made is a realistic FPS, I would probably switch to something that's designed exactly for that.

 

This matches my experience. Unreal feels extremely inflexible in comparison to unity.

 

We programmers often laugh at it but visual scripting is a major feature of most AAA game engines because it allows the people creating and placing content to add functionality without having to pull the programmers away from their far more important tasks. t's all the assets with custom shaders that are a problem. Things like water, fog, weather, terrains, special fx, etc. Sadly, after contacting many of the content creators I purchased assets from, most of them informed me that they would not be supporting HDRP. Which is not good since some of them are very popular assets that I just could not do with out.

 

We kinda had this discussion before.

The conclusion I arrived at, is that the engine should allow me to utilize my strengths fully. My strongest skill at the moment is programming. Despite liking C++ more than C#, in Unity I can work comfortably, while Unreal gets in my way with its fascination with visual scripting.

For visual scripting right now unity has shadergraph and I think there was something for game logic as well. The shadergraph suffers from the same problem, though, in that that working through code in it is very inefficient.
( https://forum.unity.com/threads/improve-custom-function-workflow.1229547/ )

Regarding your comment about VFX assets, those basically come with expiration date because technologies keep changing, and while buying a VFX asset, you're not really buying something you'd be able to use from now on and till the end of time, but are paying for saved development time you'd have to spend to roll out your own solution. So it would be a good idea not to buy many things in advance. Visual scripting would not change this sitation much, because if the underlying tech changes sufficiently, it might become impossible to support older scripts any longer.