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

Yes, exactly. There have been a TON of "give us feedback" threads and surveys and bullshit, complete with "we've gotten your feedback and we're going to act on it" follow ups, and then... nothing.

In the meantime they've become increasingly more aggressive with their monetisation, iffy and sketchy practices everywhere, all the bad habits of a big corporation. Unity has become a black hole of talent, great people go and work there, and then they are unproductive for many many years. There is no saving Unity, it's done. I don't even know if DOTS and ECS is the way to go for them, but even if it is, they're not going to pull it off. They can't.

 

I hope everyone that left for unreal recently is not working on a long term mobile project. Apple is not messing around, they are going to remove epics ability to keep up with IOS changes one way or another. No temporary court order is going to be able to stop them if they want to sabotage Unreal. A full blown anittrust case will take a decade to resolve. Sweeney pissed them off bad with that video of Jobs as a rotten apple.

Additionally it seems apple has some AR hardware in the works based on job posting and executive comments. They will cut unreal out of that too.

 

As opposed to Unity where they just don’t want to keep up with iOS changes.

 

Mobile development has been largely a waste of time for a while now so if you're working on a long term project chances are it's one that achieved success before it became almost impossible to achieve success which means you're already on Unity. If it's a project that was started recently choosing Unreal is the least important nail in the coffin to worry about.

 

Working with UE4 for now. Waiting for UE5, but Unity is in my heart, so I'll never leave it

 

I kinda expected a different tone in this thread. In the past those threads existed too and they were much more cheerful in tone.

And now it feels like most people are moving on.

 

I mean it feels the same over in the Unreal forums. Unreal's community is pretty much dead.

Could be game dev is dying out in general given that only a few make any money.

 

So it's less about engine and more about market contraction and saturation?

 

I think it's both, but honestly I find these threads funny because the exact same thing happens over in unreal land. For every long term bitter unity user there is a long term bitter unreal user. For every dumb thing Unity does there is some close equivalent done by Epic.

 

That's an interesting thought. But then again, communities dying out would mean less competition. At least less competition from complete beginners.

It also could be an indication of change in nature of the internet. Forums seem to be less popular these days.

 

[mod edit, follow the rules]

Buf IF we do an another project, it will be on Unreal. We would change the engine, but PCS is now 6 months in development and learning Unreal first and getting realy used to it will take it's time. Therefore we will finish PCS and then go. I will delete the account and be very happy.

I've never been so frustrated in my life, making games is hard, Unity will kick your balls every day but reaching out to people and get the deserved attention is hell. No thanks, never again.

I wonder how many good games are being cancelled due to lack of interest or problems with Unity.

 

I wish more people had experience programming software rasterizers to appreciate how easy things have gotten since.

To put it bluntly, community is unpaid peole, and they are under no obligation to help. You also received plenty of attention in that spaceship thread of yours.
https://forum.unity.com/threads/how-should-a-space-ship-behaive.950458/#post-6239324

mod edit, cleaned out quote.

 

I won't call this attention, there were a few people, right. But not because of interest in the game itself.

But that reminds me to update it, since thy tried to help.

 

Because there isn't any interest in your game. You're new to gamedev, it is your own pet project, and everybody here has a pet project of their own. So, if you ask "how do I do X", you'll receive a reply, because people prefer to share knowledge they learned, and prefer to help others avoid their mistakes.

However, if you expect interest that's unlikely to happen, unless you're creating something truly spectacular, or unless you're making a spectacular gamedev tool. People who were creating Gaia or Bakery or ProBuilder and so on received plenty of interest. Same goes for anyone making notable stuff.

Basically, folks have no obligation to take interest in your work, or care about fate of your project. And that is normal, such is life. Things you do you do for yourself first.

And yes, Gamedev is hard. It used to be much harder, and has been greatly simplified by tools like unity which save you roughly seven years of learning (to program, model gamedesign, and so on). If you want to get anywhere, you're also supposed to be able to pull your own weight, instead of relying too much on community and expecting appreciation.

And if in the end you come back and call everybody who interacted with you ignorant, you simply won't be receiving any help in the future.

 

I can see a fair amount of WIP threads on the Unreal forum without any 'attention' just as with Unity. Same with reddit, twitter, youtube, etc. Switching to Unreal won't fix this problem.

To answer the OP though, I dabbled with pretty much everything but the one I felt closest to "leaving" for was Xenko/Stride. The idea of an all C# engine seemed amazing to me, and it was what I wanted. Something I could actually debug if I ran into issues, extend myself, etc.

Two things really brought me back:

1. I missed Mecanim and by association the built in retargeting, of all things. It gets some deserved hate, and I know UE is more robust, but I still actually like it. I can not explain why this dumb off center graph brings me happiness.

2. Owning Vegetation Studio Pro, implementing something similar to handle the indirect instancing is outside my current knowledge, and as such would be a massive time sink that I could better spend on the game itself.

 

Yeah, it won't fix the ignorance, but the strange random bugs and problems. I've encountered so many strange and impossible things, you wouldn't believe it. Only the hughe progress and C# are forcing me to stay at unity. The .NET features are useful, i use VS C# since 2010, i like it and i use them in my unity projects.

But the problems are not worth to stay. I've never used a such unreliable and random software like unity. Even a fresh installation on a fresh win10 installation is bugging and some times just going nuts.

 

You're in a forum for game (maybe some non-game) developers using Unity. That isn't players looking for games. You're not really going to get interest for the game itself, at best you get interest from a technical perspective of devs looking to do similar or just to learn.

 

That is correct. To get attention he would need to go to forum full of people who can't program. Preferably kids. Devs are interested in other things.

 

I took over from our CEO he got banned, there are alot of failed dev's here that spew hate towards dev's with actual competence, I got a list of some of those people and added them to the ignore list.

Pro tip

 

I've kept an eye on Xenko/Stride for some time, it seems one of the issues they have is a small team. I can't help but be excited about the engine, though.
As far as the unreal forum, yeah I agree, it's a weird community and in my mind it's always been a ghost town compared to Unity.
But the community was only one contributing factor, the main issues I have with Unity are the planning, communication, and overall how they do things and where they've taken the engine.

 

Unreal's community was never that impressive to begin with. I suspect most developers using it simply never bothered with the official forums. I know I can't find any of the people who have said they're now using UE on the actual UE forum.

There are effectively infinite combinations of hardware and software out there. I have had to work on computers where things have magically failed for seemingly no reason. I'll believe you're encountering the problems you say you are but I can't believe it's purely the fault of Unity.

Since @neginfinity touched on the idea that everyone has their own project and won't typically care about yours beyond wanting you to succeed I'm going to touch on the idea that it's "deserved attention". Because the catch with "deserved attention" is that there has to be a reason it's deserving of that attention.

I took a moment to skim through your post history and while I do see at least one attempt by you to assist others the majority of your posts are asking for assistance with your project. While there's nothing wrong with this it's important to understand that if you don't show any interest in the projects of others you can't expect them to show interest in yours.

You've been a member of this community for more than five years yet you haven't even broken a hundred posts. If you truly cared about getting attention for your game you should have at least started by having more of a presence. I remember the projects of people who do so. I don't remember the projects of people who show up every once in a while.

Finally this concept applies to more than just forums. If you want to be a successful indie developer you need to make regular posts on social media to drive attention for your game. If you only do it half-heartedly and post once every few weeks you've already failed.

If he told you that then he's being deceptive. We don't spew hate towards competent developers. If we spew hate at all it's towards people who are repetitively belligerent and trolling to the community. Being competent doesn't excuse a person's actions. I don't know the full details of his banning but based on his posts before that time I'm confident he earned it.

 

I have seen some of that too, though not so much since I have ignored the problem makers. So I have no reason not to believe him.

 

What happened to DOTS and Unity.Physics package? Its pulled from the package manager without any word from Unity. Stuff like that makes me want to move to Unreal. No clear goal from them.

 

https://docs.unity3d.com/Packages/com.unity.physics@0.4/manual/index.html
https://docs.unity3d.com/Packages/com.unity.entities@0.11/manual/index.html
?
Irrc in 2020.x they changed the preview toggle to be a project setting to make it less prevalant for people to use experimental/preview stuff for production, since it's .. preview stuff. Things change, there's bugs, and people start yelling that unity is buggy but they've opted into the buggy branch.

 

That is a good thing IMHO. It allows quick checks for gameObjects, components and transforms etc. with simple conditionals and not doing somersaults with system Object nulls which will throw errors or leave you scratching your head due to the underlying engine setup which is built for the peculiarities needed for games and a component based frame dependent architecture as opposed to WPF schtick. The idea is to get on with creating and not get stuck in MS minutiae. Unity is NOT a dedicated to Windows only engine.

 

Define "excessive use".

 

Competence doesn't need to constantly brag and belittle. It is self evident.

 

I’ve been developing my latest project in record time and ease all by myself. Unity is great for me currently.

I wouldn’t use anything else for mobile.

i do plan on making a pc game in the near future, for that I’ll have to re-evaluate as it’ll require net code and terrain potentially...

Horses for courses.

 

I'd feel like moving on too, but I don't know where to.

Many many years ago I wanted to start on Unreal Engine 4, but for various reasons I decided it's not the right engine for me and went with Unity. I haven't actively done gamedev in years, but I've shared the frustration with Unity's development from the sidelines. But honestly, I don't know what other engine would be an alternative for me. They all seem to have more downsides to me personally than Unity, in part because of my lack of experience I have with them. For me it's rather a question of "Is there anything in the new versions of Unity that could convince me to move past the 5.6.x era?" for my next project.

 

Yes this is actually one of the biggest features I think Unity actually has a "leg-up" on Unreal Engine at the moment. Mecanim retargeting is a great feature in Unity and really easy to use. I know Unreal Engine can re-target as well, but it's not as easy, and somewhat "clunky" to do.

I often complain about Unity (because I always have high expectations for it), but I have to give Unity due credit for that.

 

Something like

Code (csharp):

1.  
2. a?.b?.c?.d?.e?.func(g);
3.  

would be ... not a very good thing, as it iis basically a huge if else tree that is executed every time

Code (csharp):

1.  
2. if (a != null){
3.     if (a.b != null){
4.         if (a.b.c != null){
5.             if (a.b.c.d != null){
6.                 if (a.b.c.d.e != null){
7.                     a.b.c.d.e.func(g);
8.                }
9.             }
10.         }
11.     }
12. }
13.  

Well, it is not the EXACT same tree, but funcitonally equivalent.

Basically, something like use of null conditional operator indicates that your code has a possible fault point, where a certain field/member/property can return null, and as a result everything in the code will have to try to accomodate for that happening, and should any part of the library forget about that, you'd get a bug. Additionally, it is a runtime problem and not a compile time one.

Ideally you'd want to exterminate all the null conditionals and ensure that "this field cannot ever return null" one way or another. That would simplify the logic in the rest of the library, and remove a possible flaw point.

Actually would be nice if there was a keyword in C# which would indicate "this variable is not allowed to ever be null".

unfortunately, it looks like they're moving in exact opposite direction:
https://docs.microsoft.com/en-us/do...erence/builtin-types/nullable-reference-types

 

There is an attribute.

https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.codeanalysis.disallownullattribute

 

That's not the same thing. Because the article says "Compiler warns", so it is similar to python type hints.

Such restriction should be strict, should always throw an error, and should be comparable to C++ const. Then it would be useful.

 

The new nullable reference types in c# 8 does not alllow null they throw compiler errors

https://docs.microsoft.com/en-us/do...erence/builtin-types/nullable-reference-types

 

Like I said ealier, many null checks are code smell. In a proper designed domain null cant happen because you have well defined boundries

 

The lack of experience part is fixable though.

It heavily depends on what your next project is and how you can comfortably execute the required workflows to make it in your engine of choice. If Unity 5.x fits the bill, that's great.

We found workflows we liked in Unity 4.x. Ever since then Unity keeps making our workflows more complicated, more awkward, slower, and producing works results. We keep trying to adapt, which is fine, but doing it so that we can more or less maintain our game's status quo, instead of actual improvements, feels really disheartening.

And also, I was mocked in another thread for saying this, but for me it's really important that I enjoy using a piece of software that I use daily, not only for my general well being but I also think it would more easily allow me to make better games.

I used to enjoy using Unity. I don't any more. Ever since 4.x they have under performed, under delivered, made many dubious changes, moved towards goals I don't like, made the editor feels worse, all while more aggressively monetizing parts of Unity.

I've been excusing them saying that they're overhauling the engine and there are many moving parts and at some point things will fall into place and Unity will start making sense again, but it seems clear to me now after many of years of being patient, that they don't plan on doing that.

 

That is certainly a mess. I usually use one Unity null test per function if I use it at all

Code (CSharp):

1. void TestForGameObjectDeletion(GameObject go) {
2.     if ( !go ) {
3.         //do this
4.     } else {
5.         //do that
6.     }
7. }

 

I agree. It used to be straight forward. My opinion is they let a bunch of MS trained C#-ers in the door and now it is becoming a convoluted mess. I recently had to do an MS security app. I would nuke the MS docs site for it's actual usability and answers as to why I want to have all kinds of verbose crap in my app when i want to do one particular thing. I found after trolling through stackexchange, blogs and etc that i could basically distill it down to just the few lines I thought should suffice to get something done. I had to make use of a package for elliptical encryption that I literally commented out several thousand lines of code and trashed the config files and it worked just dandy. It would have worked just dandy for 99% of the people using the package IMHO. I give no bonus points for extra lines of code or convoluted methods. Seems MS devs love that crap.

 

Yeah, that's why I'd rather not switch engines for 3D games (2D is different because I don't know Unity's 2D tools at all yet). It would take me a long time to just be able to do what I can do in Unity now. UE doesn't have enough appeal to me to make me want to do that.

I can relate to that.

I'm sure they always planned it and still do, but my hope they'll ever get there is diminishing with every year, because their commitment to other things looks higher.

 

Trying to fathom what cases in Unity you would want something to never be null. Not saying yer wrong..Just trying to learn what I don't know. If general WPF or console C#..well.. I don't really care one way or another but it may be handy to just have that trivia available.

 

Yer boss had code smell. I watched him develop a gun and trigger pull system for nigh on a year I could have pulled off in a few days. His well defined boundaries should have included not being so bloody anal retentively complex for no good reason. I suspect he didn't understand the software and was jacked into his "I am a superior dev thingamajigee". Jargon epizeuxia does not make a good Unity dev.

 

Unity3d is a YAGNI type of software.
Developers decided that you are not going to need some functionality, even an obvious one, relatively easy to implement.

Just today I tried to get Unity.Collections.Allocator from already created NativeArray - YAGNI.
it is not the first time in this engine that I could not get something that was previously set.

Physx implements eACCELERATION flag (drive spring is for the acceleration at the joint (rather than the force) ) - YAGNI (It would by better if they made it with eACCELERATION by default instead of forces)

It's nice they added inheritance of prefabs and nested prefabs. Problem is that making some changes like moving GameObject up and down in hierarchy is impossible. You are making everything correct from the beginning or you are f****d.

etc.

 

I am also tired of unity, but my project has invested too much with unity so....
I have to continue with this fatigue.

 

In most cases when you have a subroutine taking a reference to some Component as a parameter. Meaning pretty much everywhere.

For example, you have MyRigidbodyDriver class, and have a function "doThingsToRigidbodyDriver(MyRigidBodyDriver argument)". It would be easier if within the function you could be 100% certain that MyRigidBodyDriver argument will never be null.

But it is nullable, so you can't be certain.

So, you do the usual thing.

Code (csharp):

1.  
2. void doThingsToRigidbodyDriver(MyRigidBodyDriver argument){
3.     if (argument == null){
4.          return;
5.     }
6. }
7.  

Now you have another thing to consider - whether having null as an argument is a routine thing, and the function should bail (as it already does), or if this situation is not a routine thing and the function should throw (throw new System.ArgumentNullException).

Over time those checks pile up in every function that deals with reference types, references to components and so on, and you're writing boilerplate code everywhere, as every single function does a little ceremony in the beginning with null checks.

Would be great if you didn't have to do any of that, don't you think?

By the way, the whole "reference type" thing makes me appreciate C++ appraoch more. C++ has no reference types, only value types, however, you can declare that you want a reference to a value, or a pointer. Now, a pointer to value is nullable and is pretty much equivalent to C# reference type (sans garbage collection unless we're talking about smart pointers). A reference to a value, however, cannot be null.

That's the rough idea of it.

 

Yeah that on null do nothing approuch gets ugly fast in a large application since it silently fails and propagate the error it can be a bitch to debug. It's almost as bad as the old on error resume next in VB

 

What's wrong with just writing a log error at the entry point of the function? Even if you had an argument to a function that could not be null, at some point you'd have to check what you're sending to it.

Personally I have no problem with nulls, the main reason being that either at some point you have to check if stuff is null, or you have to create an 'empty' value from the very beginning while your real reference is getting ready or non-existent, which I consider to be worse code smell in every possible way.

The fundamental building block of OOP is an object, the most fundamental property of which is whether it exists or not.

I think issues with null references arise mainly from issues with hierarchy design. Functionality should be compartmented into substantial chunks, and the entry point into each chunk can check if an argument is null. Everything else inside does not need to check anything. A function shouldn't have to dig ten references deep into an object to do its job.

 

Nulls aside, if it fails silently that's not the tool's fault. That's the programmer choosing not to take appropriate action.

 

Back on topic. I'm still here with Unity because I'm not really interested in any of that SRP or DOTS stuff and so far, it hasn't got in my way. The biggest single advantage of Unity is editor customization, which makes it possible to build a factory of content for a game and improve the user experience. That's really the thread that holds me here, otherwise I am sure I would be much more inclined to try other things.

It was a long time ago so it might have changed, but I remember wanting to rename an Unreal project and finding out that I have to edit some config files or something. Whereas in Unity I just rename the folder. These little things add up and at least until recently, Unity have shown that they are more aware of the user experience.

Even in my short forays into Unreal, I would find something that went wrong inexplicably. Whereas until recently, I virtually never encountered a bug in Unity at all. That's all changed though. Now in Unity, the inspector pop-up windows for stuff like prefab selection disappear when you click something on them, and a few days ago Unity took full control of my desktop (The X button in the corner disappeared, and I couldn't exit or switch context to any other program, and had to restart). Maybe that was my computer somehow but it never happened before, and I only just started using Unity 2019 regularly several months ago. There have been little things here and there that just didn't reflect the usual Unity polish.

So basically, I am relying on what Unity was, and so far, still mostly is. A game engine build on top of a set of good user experience principles, giving you a lot of leeway into how you want to develop your projects. But the way new features are being taped on via the package manager I doubt I will be inclined to use them. I liked the idea of the package manager (and still do) but I think it has become an excuse to quarantine non-optimal development practices from the reputation of the engine as a whole.

So far Unity is still ahead for me. If I needed certain features, it definitely wouldn't be, but it hasn't changed so drastically from its former self (yet) that I feel inclined to go and learn something else. At least not for my first one or two games. Then I'll consider what I need to do to optimize things going forward.

 

I'm using SRP and honestly. it's super easy. Shader graph is really good too. I did start a new project using it though rather than convert an old one to it.

I feel like Unity 2019 is 90% through the transition form old prefabs to new prefabs, the new changes in 2020 look like they're fixing a lot of the usability pain. I haven't upgraded to 2020 yet though. I'm hoping to do that next week! I'm super looking forward to it!

 

I mean that if I was using graphics assets from the asset store, or writing my own shaders I would not be too keen on using SRP. Converting standard materials is straightforward, but a lot of other things seem to be easy to break. I don't have a lot of experience with it though, I'm mainly going by the experience of a few reputable people.

I heard they removed Shader Graph support from the render pipelines too, which isn't exactly a vote of confidence (although I'm not sure in which direction that is).

That's what I'm hoping for. Unity really is much more fun to develop in for me, and if they hadn't broken so many things and created a patchwork of new features, I wouldn't really be considering much else (although the graphical capabilities of Unreal are still significantly ahead).

My first game (the one I'm working on now) is the kind of thing where I will simply cut something out if it's too much trouble, because the main thing is to ship it. But going forward I don't want to have that mindset. There are a bunch of experienced devs whose patience with Unity seems to have reached breaking point, probably because they cannot make those kind of sacrifices.