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

Has anyone here abandoned Unity for another engine only to return?

If so why did you return to Unity? What engine did you try?

I guess I'm at a point now in my game (almost 3 years later) that I'm just fed up. So many corrupted projects, failed upgrades, failed downgrades, incompatible assets, and general feature bloat/confusion, that I don't feel like continuing. Of course, it's not as if I think other engines are without their own issues.

 

C# and almost decade of code base keeps me here.
Have you released anything made with unity ?

 

Not with Unity, but I'm nearing the finish line. My hope is it will be worth sticking around.. C# is also a major reason I've stuck around.

I know that C# is supported by GoDot, cryengine, but I have also been learning Unreal over the last few months. I would hate to waste a few months porting my game over to another engine only to find that it's just as bad or even worse.

 

We’re missing quite a few forum regulars lately, they haven’t returned.

We’re planning on leaving Unity after our current Unity projects end, which won’t happen for a while, but at least knowing there’s an end to this madness in the future helps me maintain my sanity.

 

Interesting, what exactly is 'the end' you foresee? Will there be a Unity 2?

 

I think he means that the incoming change of engine is keeping him sane.

 

Why does it have to be "abandoning"? Being familiar with and using a variety of tools is a good thing.

 

Not abandoned, but using mostly Unreal for game based stuff now, and then three.js, babylon.js and playcanvas for web based 3D.

DOTS is great but until that matures, not really that interested in unity for game development anymore.

Until the "good" new features mature enough and all these preview packages holding the best bits actually become verified its basically just a waiting game for me now. I can see many regulars including hippocoder have dropped off so I expect a lot of people are slowly coming to same place.

I dont think the IPO coming out at the time when there is so many issues with unity that the community have been highlighting for a while helped anything. It would have been nice for them to have "cleaned up shop" before the IPO, whereas now it tends to give a sense that the current state may not even get sorted out.

Thats what keeps me at bay right now, I keep thinking "well based on how unity have been, how do I even know they wont just drop DOTS in the end once they complete their IPO and have potentially shifted direction from that point on ward?"

So yeah for me its a cry wolf situation where all these amazing supported features that suddenley got dropped, makes it hard for me to buy into the really good ones they have been piping on about.

When things get a bit clearer and people are able to tell whether the talk about getting better was just talk or not, you will either see a ton of people return, or a final mass exodus of the regulars. Waiting to see which it is.

 

Just curious, what are y'all moving onto after Unity?

 

Unreal Engine. I remember @hippocoder and @zombiegorilla mentioning that they had largely switched to it in a discussion and the studio I'm currently contracted to wants to move to it with their next projects so I'll likely be joining them before too long. Unity is still the king for 2D but for everything else they're rapidly falling behind.

 

I started learning Unreal, but two things stopped me from continuing:

1. The C# thing. I'm proficient with C# and not familiar with C++. I know I could learn it, but with a full-time job, two kids, and working on games as a hobby, it's just so tough to find the time and justify it. I tried learning Blueprints, but visual scripting is even more foreign of an idea to me!
2. Unreal Editor had a bug in it that would crash the editor when anything tried opening a Windows explorer window to select a file. Every time. As buggy as Unity can be, I've never encountered something like that where my editor would crash consistently for such a basic and central task.

And then I got a job where I actually use Unity to make software, so... I guess I'm sticking around for a while!

 

I read a bit of his Twitter and saw that he had been frustrated with Unity. But I hope (genuinely, I have no loyalty to any of these products) that it isn't a case of "grass is greener" because he is far more familiar with Unity (and its frustrations) than he is with Unreal Engine. I've heard a lot of people have frustrations with Unity and decide to move to Unreal, I hope it really does solve their issues. For myself, I am just a hobbyist who works as a software engineer as my day job, so it isn't a big deal what I play around with. I suspect that no toolset is perfect and there will be issues regardless of where you go. But I do think that, as far as business model is concerned, I prefer Epic - a royalty only on successful games feels more like a "partner in success" than Unity, for which its users are more customer than partner.

 

There are a good number of cases where a feature you had to implement in Unity already exists as a tool for Unreal, and the tools are very rapidly brought from concept to stable and then battle tested with Fortnite.

There is a free middle ground solution available. I understand wanting to stick with C# though. It's a fantastic language.

https://www.unrealengine.com/marketplace/en-US/product/skookumscri

 

Yes I often work in Unreal for awhile, and then come back to Unity because I find it be much more flexible and forgiving. Unreal engine kind of locks you into a path and it's hard to "undo" that path once you are on it (in terms of architecture). Unity is so flexible in so many areas -- and I'm so much more familiar with the systems at the moment.

However, to be honest, I'm really sad at how little progress Unity has made in the last few years in terms of what it chooses to focus on, and what tools it develops. They all seem like side projects. For the last 5 years I've been hoping for a good terrain and tree/grass system, that can allow developers to create really great outdoor scenes with ease. It's 2020 and I still have to use 3rd party trees, grass, and terrain shaders....... I'm very disappointed.

Plus I am not a developer that likes mobile, 2D, VR/AR, or making short cinematics. Which seems to be what Unity is starting to cater to for some reason. HDRP was the only "plus" for me in the last 2 years.

Unity's next "big feature" for 2021 is going to be visual scripting.......are you kidding me? LOL. I already dislike the focus Unreal Engine puts on visual scripting, as I find it very unnecessary. Why not focus on making the engine make great games instead of visual scripting.

Anyways, ranting over. All that being said, Unity is still my best option, but it never meets my expectations (as of 2020).

 

Frankly, for us, maybe not. It's still somewhat far into the future, so there are too many moving parts for me to predict anything now, but ideally, assuming we have the financials at the time and can find a couple of good extra coders, I'd be interested in making our own "engine".

Frankly with the effort we went through over the years to try and work around Unity features that get in our way, I think it wouldn't be too much more effort to write a very game specific, very limited scope, "engine" that does 10 things we actually need and does them well, and if we had done that we would be in a much better position now. But a few years ago I was still hoping Unity might improve.

But yeah, if that doesn't happen, Unreal.

 

We are also thinking of moving to unreal for next game but it sucks it does not have support for. Net. If you use a proper CLR like core 3.1 or net 5 its even faster than cpp in some cases thanks to hardware specific JIT optimizations.

 

The grass is greener concern is what really keeps me sticking with Unity. I'm also comfortable with the engine and C#, but at the same time I don't think I want to support a game written in Unity considering all the problems I'm having.

I'm at my wits end with Unity. My project is grinding to a halt at startup. I get endless "Busy messages". I don't like waiting 2 mins just to test a small code change. Two years ago I could upgrade all the time and rarely have issues, but now that is not the case. In fact, at this point I'm now working with alpha version just to keep developing.

The Unity demos look great every year and they are on par with Unreal, but the truth is those features are underdeveloped and there are very few assets that support them. Take HDRP for example, I converted my project to HDRP and it looked great. Only problem is it broke over 50% of the assets I had purchased, and in some cases there are no assets I can purchase to replace them.

I've been learning blueprints and I find that they are very easy for a programmer to use. In fact, I think I could convert most of my game using only blueprints without an issue. I just find it a lot more tedious than writing code. Of course, the real learning curve is understanding the engine and what functions to use while blueprinting.

So for me it's either Unreal or Cryengine.

 

If unreal 5 includes c# it will seal the deal.

 

Here is the latest attempt to bring .NET to Unreal, and it's based around .NET Core.

https://github.com/nxrighthere/UnrealCLR

 

Cool, have you tried it? Does ut work well?

 

I only found it shortly before I posted.

 

I looked at this a few weeks ago and it turns out that there are still major components of the engine that have not been ported over yet. Such a thing really does need Epic to embrace and support.

 

Everything he's ever said about C# has left me with the impression he doesn't find it practical and/or doesn't like it.

https://www.reddit.com/r/unrealengi...5?utm_source=share&utm_medium=web2x&context=3

 

Most cpp programmers do not know how well JIT optimizes code. It's really sad becasue the. Net clr is awesome.

 

Considering Unity is spending a lot of effort to "fix C#", which in the end results in really un-C# like code, I'm not sure C# is really the boon you make it out to be.

 

Its becasue unity are doing it wrong. They are using a broken ass mono version instead of using. Net core / net 5

 

AFAIK .NET 5 is not even officially out yet, so I don't think we can put this one on Unity.

 

If you read the link I provided you'll know that his complaints have nothing to do with how the JIT optimizes code.

 

He indicates cpp is a must because of performance



The multithread part feels a bit dated though any modern engine should support both multithreaded domain and rendering

 

MyObject?.

Well C# certainly isn't fully implemented correctly either. Apparently this is not a good idea in Unity.

MyObject?.SomeValue = 2;

 

I'm trying to figure out your point. AFAIK this is pretty standard C# nullable object operation. But it is only available from C# 6 on, I think.

Edit: corrected version from which on the operator is available.

 

I can't imagine why blueprints would be faster than C#. Fact is, many Unreal games are fully blueprinted and they run perfectly fine.

 

oh sorry, I forgot to mention that you should not do that with a MonoBehaviour object.

 

I think he tries to point out mono behaviour implementation details.

 

yeah, Unity's version of null is NOT System's version of null.

 

Its rather how null is treated when dealing with monobehaviour. I'm not sure I think it was a good idea overriding all the operators on monobehaviours.

 

yeah, it's a complex scenario. Needless to say, my game has many if statements checking for null that wouldn't otherwise be there.

That's ok though because I'm one of those programmers who has always considered Null to be a good friend. I shed a tear the day null became a keyword.

 

I can't blame anyone for avoiding the usage of Unity in their upcoming projects. It's fair to say all engines have their shortcomings and if someone weighs those shortcomings to find the engine that best suits their project then it's really their prerogative to choose what they want.

Objectively, Unity has made very risky pivots lately and will be a scary place for 2+ years which opposes its otherwise consistent past. Veteran users relying on that particular trait are going to leave. On the other hand, people who share an interest in razors edge tech, their design direction and risky experimentation are going to migrate to Unity.

So it's all a matter of perspective.

 

Sounds like you need to look over the state in your game. Excessive use of if null checks are a indactor refactor is in place

 

I'm probably on the other side of this debate as I think it's largely situational and consistency is more important. In this case though (for Unity), when you have assets that you didn't write integrated into your game it's not a good idea to throw caution to the wind. Of course, these checks are rarely inside the update loop so it's not a big concern.

 

I like the fact that Unity is taking a risk to implement HDRP. I was one of the people pushing for them to go into more high fidelity graphics and try to compete with AAA engines in terms of eye-candy. So the fact that they decoupled 2D and mobile from PC desktop is something I really like.

The challenge for myself is, this caused almost everything on the asset store to become obsolete for HDRP, or disappear. And asset developers are having to learn how to develop for it again.

Long story short, there's very little on the asset store right now for HDRP projects. But it is getting slightly better each month/year. It will still be a long time before HDRP becomes well supported on the asset store though.

 

I do not talk about performance, a null check is more or less negligible, I talk about domain quality.

Ask yourself why the state can be null often there are better ways to design so that is not the case.

 

This is not really the thread for this debate, but as I said there are many reasons why checking for null is a good thing. I often tell my team that Null is your friend and not to go down the quagmire of trying to remove null. It's largely a huge waste of time, especially when you can't control code written by other developers, third party APIs, and/or responses from databases.

I'm reminded of one guy we hired who tried to eliminate nulls (fresh out of university of course). He didn't listen though, his code ended up choking on every db null value in the database. Fact is reality isn't perfect and null perfectly solves that problem.

 

If you expect publishers of 3D content to adopt HDRP, you'll be disappointed. Until Unity makes a proper workflow for SRP then 3D content must be authored once for each SRP and since HDRP is not standard, accepted, stable or even really working properly at all, its a huge risk to build content for it.

It's very unlikely that any content will be rebuilt for SRP, but there may be some rare authors that focus solely on a specific SRP moving forward, like HDRP, and accept the risk and massive maintenance cost of doing that.

 

I don't agree and Microsoft does not agree either that's why they introduced nullable reference types in c# 8

 

I've always been a hobbyist and dabbler, so this comes with a grain of salt. And it's a bit of a rant.
Some years ago my brother and I switched to unreal, to see what it had to offer.
He loved the material editor, the terrain and vegetation system, and how they all worked together.
I liked how epic has a roadmap, and they are continually moving forward with features. They developers and teams themselves promote their product and produce learning videos.

I liked how Unreal includes many tools built in, which I had to pay for with Unity. I'd prefer not to tally up how much money I've spent on assets that are no longer supported. Heck, their free stuff (quixel) is pretty awesome.

I hated not having C#. I find C++ to be cumbersome and clunky to work with. If Unreal were to support C#, I think Unity would just about melt.
I liked blueprints. I feel they are more advanced than alternatives for Unity. I looked at Bolt, and honestly there are some issues with it. I still don't see breakpoint support, but heck maybe I'm just missing it. But given their recent announcement about bolt, and their tendency to very poor planning and decision making, I'm not optimistic there.

I miss the Unity community, I feel like they have/had so many talented and helpful people.

Mostly, I felt like the engine and company were focused, strong and moving the engine forward with mostly solid changes.
Recently, I decided to take a peek and see how Unity's doing. I'm so disappointed I don't see much point in investing time in it.

I remember a few years ago? There was a big stink, and people demanded to know what Unity was going to do to improve systems and communication. I remember "communication" threads popping up, asking people for their input, like for the terrain system. People put all kinds of ideas out there, to improve it.

I found it! hahah 2014.

https://forum.unity.com/threads/official-new-terrain-system.255232/

Sadly, it seems to be have been short lived. The communication was apparently just a way to pacify folks and give them hope. Every now and then people get really frustrated, and some bobble head pops out and says "can you please tell us exactly bothers you about X", which makes me wonder if anyone at Unity actually uses Unity, or wants to. I really can't have a whole lot of respect Unity as a company, or its culture.

The terrain system is as S***ty as ever.
The state a multiplayer? Ridiculous. Incompetence galore.
The UI for the shader graph? What the hell, the UI looks like someone designed it with an etch-a-sketch. And I'm not going to bother to look, somebody floor me and tell me that the shader graph supports the terrain, and more than 4 layers. I wish they had bought out amplify shader editor...now wait, probably best for everyone if they DON'T.
Sorry, it's a negative rant, but as much as I'd like to give unity another shot...I just don't see it happening without a huge change in leadership, talent and culture.

 

It's because visual scripting helps to make great games. Art and traditional programming don't cover everything you need for many "great games". Not everybody is capable of handling even just scripting language and not everyone needs it, i.e. level/narrative/quest/UI designers, writers and many other types of designers, also artists.

Visual scripting can be a blueprint. Also editing materials, fx (Niagara or VFX graph), scripting UI widgets, controlling animation (animation graph/blueprints, procedural animations), sound...
An extremely important part of visual scripting is the ability to easily mix code and data, but in a healthy way. Like not referencing to assets by string or other annoying methods. It's straightforward in blueprints. This makes it super fast to do any sort of "small scripting" (scripting specific actors and moment in a game), rapid prototyping and quickly learning tools.

Another example.I'm finishing the open-source version of "event scripting" (for things like quest and dialogue systems which are much, much simpler than regular scripting) which can boost productivity for small teams working on story-telling. It basically lets me work on scripting game flow like I used to with The Witcher quest system (instead of messy level blueprints which usually ends up as abomination).
It's a simple editor built using quite intuitive UEdGraph API and... free access to the engine source code.

I do hope Unity actually has a nice API underneath their new and upcoming visual scripting tools, so it would be easy for them and community to build a lot of great tools with it.
PlayMaker sucks, I hated to expose things from C# to it.
Bolt is very rudimentary too, couldn't even find any debugging options there (but maybe I missed something during my short inspection...)

 

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. We need more than just improved graphics to attract developers. We need the full suite of tools.

 

I found that HDRP content is not really an issue for models In my case, I was really looking forward to using HDRP since all my assets were painted using 3d coat. The latest version of 3d coat exports to Unity HDRP textures perfectly.

It'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.

 

the "big feature" is really just smoke and mirrors for the next big event.