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

That wouldn't look any better in code

 

Text is also a blob, imagine if someone hadnt taken the time to write a compare tool for it you would be looking at byte differences Though I do agree with you completly.

Someone should take upoin themselves to write a comparer for Unity scenes

 

To do this in code, you'd need to write it in old version of fortran.

Which requires a lot of dedication.

Spoiler

 

That is nuts. All of that could be converted directly into a huge spaghetti c# code so I don't see the point

The comparison should be between a competent c# coder and a competent blueprint coder.

Blueprints have functions, macros, event delegates, and even class inheritance. I can't fathom why this code in your example is so terrible. It's very easy to decouple blueprints from each other with event delegates.

As a coder, I'm using all he same rules I use when coding to design my blueprints. The end result when converting from unity to unreal is that I now have less code to manage

 

@Kev00 can you share your version control experience, between Unity and Unreal?

 

Blueprints are touted as a tool usable by everybody, so "competent blueprint coder" shouldn't be a thing you need in the first place, as in this case it is unclear what the benefit of switching to visual scripting is.

Blueprints are still code, though, one that is harder to read and that you can't git-bisect properly, due to it not being supported by git diff.

The code in example is excellent. However, it is written in language without scoping support, without named labels, without if/else block, where the only tool is goto/arithmetic if. As you can see in comments, the example is 54 years old.

My personal gripe when I worked with blueprints is that they require me to waste a LOT of time on cable management. Feels like too much effort for something that should be automated. Keyboard-only approach wasn't great either.

 

I wish visual graphs both Unity and Unreal took more Matlab simulink approach, when come to wiring. It would be much cleaner by magnitude.

 

Maybe Enterprise Architect can take a hint.

 

Sorry, but I must missed your point. How that fit to Unit and Unreal Visual scripting?

Because what I mean is more like
https://duckduckgo.com/?q=matlab+simulink&iax=images&ia=images





Wires are more visually appealing, than bendy lines.

 

Visual scripting has been such a.. "buzzword", for lack of a better term, lately, that at some point, you can break down visual scripting back down to its text equivalent. Basically, each visual scripting element is just a wrapper around the core feature of the implemented code block. My comment was a slight jab, that if you were truly able to see the contents of each visual node, it'd boil down to looking at a bunch of UML diagrams, or a variation of it. Enterprise Architect specifically allows you to build UML diagrams into compilable code.

Ultimately, all these visual scripting languages can help more visually-inclined authors to a certain point, but it eventually becomes a disservice and a lot of cruft that could otherwise be prevented if the author just learns how to read and write text-based code, and adopt long-standing design patterns. Text has been a universal standard for tons of programming languages for many decades. Visual scripting has a long way to becoming a standard by any means. And the closest visual scripting has gotten to a "standard" has been UML.

We can stop pretending that all the spaghetti lines in a blueprint actually serve a purpose if you habitually use the Ctrl+F, because that's exactly what you'd do in a text-based language.

 

Yep, that's classic circuit diagram. It is much easier to read than spline spaghetti.

Spoiler

Although things do get hairy with large number of wires:

Spoiler

And maybe that's why HDL is a thing.

All visual programming tools I ran into had following issues:

1. Lack of "Bus" connector. A "bus" is a large number of wires grouped into one thick cable, which "group" at start and ungroup at end.
2. Fascination with moving noodles around. It isn't supposed to be a cable management simulator, but a scripting language.
3. Poor support for keyboard work.
4. Poor support for existing versioning tools (like diff)

If those are solved, there would be a great tool.

 

Ah oki, I see your point now.

Yeah, without buses is a nightmare to work on such. This is where in my view Matlab Simulink shines.

I am happy with coding C# and DOTS by hand. But in deference of visual scripting, I see really good place for it.
I am terrible in regards of writing shaders by hand. Me working in Matlab Simulink, or Unity Shader Graph is fair. As long, as I can combine / inject own scripts as functions.

On side note:

Just out of curiosity, I looked into my recent changes in repo of shader from Unity shader graph.

Spoiler

Code (CSharp):

1.         {
2.             "typeInfo": {
3.                 "fullName": "UnityEditor.Graphing.Edge"
4.             },
5.             "JSONnodeData": "{\n    \"m_OutputSlot\": {\n        \"m_SlotId\": 4,\n        \"m_NodeGUIDSerialized\": \"cac01892-9765-4984-8e12-5381558f1df0\"\n    },\n    \"m_InputSlot\": {\n        \"m_SlotId\": 1,\n        \"m_NodeGUIDSerialized\": \"ce291bf0-b67b-4e89-ad13-7ba22852c752\"\n    }\n}"
6.         },
7.         {
8.             "typeInfo": {
9.                 "fullName": "UnityEditor.Graphing.Edge"
10. @ -3103,6 +3136,48 @@
11.                 "fullName": "UnityEditor.Graphing.Edge"
12.             },
13.             "JSONnodeData": "{\n    \"m_OutputSlot\": {\n        \"m_SlotId\": 0,\n        \"m_NodeGUIDSerialized\": \"897ddccd-337a-4633-a090-93287172e21e\"\n    },\n    \"m_InputSlot\": {\n        \"m_SlotId\": 1,\n        \"m_NodeGUIDSerialized\": \"bbe73e63-656d-4e49-905c-93988b5bd3d0\"\n    }\n}"
14.         },
15.         {
16.             "typeInfo": {
17.                 "fullName": "UnityEditor.Graphing.Edge"
18.             },
19.             "JSONnodeData": "{\n    \"m_OutputSlot\": {\n        \"m_SlotId\": 1,\n        \"m_NodeGUIDSerialized\": \"88e04df5-b57a-45f0-bf3f-9761396d2461\"\n    },\n    \"m_InputSlot\": {\n        \"m_SlotId\": 0,\n        \"m_NodeGUIDSerialized\": \"6e65de06-e0d3-4e22-872d-682ce30d887e\"\n    }\n}"
20.         },
21.         {
22.             "typeInfo": {
23.                 "fullName": "UnityEditor.Graphing.Edge"
24.             },
25.             "JSONnodeData": "{\n    \"m_OutputSlot\": {\n        \"m_SlotId\": 4,\n        \"m_NodeGUIDSerialized\": \"cac01892-9765-4984-8e12-5381558f1df0\"\n    },\n    \"m_InputSlot\": {\n        \"m_SlotId\": 0,\n        \"m_NodeGUIDSerialized\": \"f5d4f20d-a9cf-42d5-b9ef-a539bc37ac1b\"\n    }\n}"
26.         },

Sorry for missing colors and changes indications. But by looking into it, I am unable figure out, what was really changed. Also, there is more than one place modified in that given shader file.

In constrast, I compared generated codes, and took only some changes snippet

Spoiler

Code (CSharp):

1.  
2.                 float4 Color_E935DF40 = IsGammaSpace() ? float4(0.2400766, 0.4828764, 0.7830189, 1) : float4(SRGBToLinear(float3(0.2400766, 0.4828764, 0.7830189)), 1);
3.                 float4 _Multiply_4F4E2524_Out_2;
4.                 Unity_Multiply_float(IN.VertexColor, Color_E935DF40, _Multiply_4F4E2524_Out_2);
5.                 float4 _Multiply_8B4C2EDB_Out_2;
6.                 Unity_Multiply_float(_Multiply_4F4E2524_Out_2, float4(1, 1, 1, 1), _Multiply_8B4C2EDB_Out_2);
7.                 float _Split_E3818F2B_R_1 = _Multiply_8B4C2EDB_Out_2[0];
8.                 float _Split_E3818F2B_G_2 = _Multiply_8B4C2EDB_Out_2[1];
9.                 float _Split_E3818F2B_B_3 = _Multiply_8B4C2EDB_Out_2[2];
10.                 float _Split_E3818F2B_A_4 = _Multiply_8B4C2EDB_Out_2[3];
11.                 float _Comparison_F367F08_Out_2;
12.                 Unity_Comparison_Less_float(_Split_E3818F2B_R_1, _Split_E3818F2B_B_3, _Comparison_F367F08_Out_2);
13.                 float _Comparison_A8B6108A_Out_2;
14.                 Unity_Comparison_Less_float(_Split_E3818F2B_G_2, _Split_E3818F2B_B_3, _Comparison_A8B6108A_Out_2);

Don't know if these are representing same, but definately generated code is easier to read. But by shader default, that not what I see on repo. Unless I explicitly generate a code.

And yes ..
As much myself trying to get thing organised



Things get bumpy often. Which become a bit annoying to sorting out, instead focusing on deving the functionality.




Either way, I see both pros and cons of coding by hand and visual scripting.

 

I agree. I'm not completely against visual scripting. It has its place, as in the shader example you gave. Other examples, are like Behavior Trees and FSMs. I just hate the idea that some people think it's a replacement for text-based programming for anything other than trivial game designs. It should enhance it if anything else. And finding the right balance between both largely depends on who is using them.

 

That falls under signal processing (IMO), but yes, that's where it works. I wouldn't want to write a raycaster in shadergraph, though. That requires code.
I posted this shadertoy link before, I believe.

https://www.shadertoy.com/view/4dGBRy

Basically, the issue is that visual scripts work well when you're dealing with signals, generators, or when output flows from A to B.

The usual programming paradigm, however, is step by step execution of an algorithm, and the closest form to that is human language in text form. We aren't talking with diagrams, after all.

To be comletely honest, there is a form of programming that is compatible with visual scripting and that is functional programming. But it isn't exactly frequently used these days, especially in games.

Yes, they're serialized in a text form, but wouldn't be able to type this in by hand, and diffing this woudln't produce meaningful data.

I largely see a con when people get overly fascinated with it and try to do everything in it.
It has its uses, and can be a great training tool, but I wouldn't want to overinvest into it.

 

1. I may not be exactly sure what you mean buy a "bus connector", but you can do that in unreal. You can have execution lines merge into a single line and then have that line branch off into any number of exits. There are control nodes not available in c# like Gates and Multigates that can also help in this regard.

2. The fascination with moving noodles isn't really an issue. In some cases it's faster to connect nodes and in other cases it would be faster to write code. The practical truth is that programmers are not typists. They need time to think as they code or create blueprints. In the end, the time saved /wasted all averages out. With that said, I'm starting to think blueprints are saving me time since there is often a single node that saves me several lines of code.

3. I'm not sure what you mean by keyboard work. It really isn't an issue. Right clicking gives you the node selector and the keyboard works just fine.

4. As I understand it you can't do this with unity prefabs either. Blueprints are more akin to unity prefabs then they are to mono behaviors.

 

Bus connector means DATA lines. Have a dozen of data connectors collapse into a single "bus" and have them unpacked when needed. It would greatly reduce clutter generated by blueprints.

The practical truth is that some programmers are not typists.

If you can't type quickly, then do not assume that everybody is the same. If you can put your thoughts into code form in a blink of an eye, you'll LOATHE every moment where you are forced to use mouse due to poor design of the tools you're using.

It is an issue, as I do type at a decent speed (I think the highest I ever hit was around 500 cpm... which should be ... about 100 wpm?) and I'm not alone. Something that requires me to touch mouse is an unwelcome interruption. As I don't have three arms to keep two hands on keyboard and one more hand on the mouse.

There are basically two modes of operation - both hands on keyboard, where you're dealing with a lot of text, and one hand on keyboard, and another on mouse - when you're doing mouse-heavy work, and are not typing. Switching back and forth is an interruption.

Keyboard work in this regards means "create entire blueprint without touching mouse even once.".

If the tool is efficiently implemented you should be able to do that.

Actually no.

In Unity, Prefabs are strictly data, so it is fine for them to be an undiffable blob, as you don't diff jpeg on textures, for example.
Blueprints, however, mix data and code and are heavily leaning towards being CODE rather than data, and they resemble monobehaviors the most. Because they store game logic, they have to be diffable.

The way I see it, in 21st century, any language worth using should have diff support.

 

Oh, that is sad. We are too far along with our game to switch so still hoping Unity will become more stable. I notice a lot of people gone...miss them. I have fond memories of this place.

 

I guess you haven't seen my code.

Visual Scripting could be the future of programming. Just as we moved from text only machines to GUI interfaces -- VS could in theory do everything regular traditional text based programming could do. Just it is a new frontier that hasn't been explored at that scope yet.

 

I believe, it couldn't, outside from specialized problems. During last 5 thousand years we haven't managed to get rid of text. We did the opposite and moved from visual representation to text form. And programming languages do not really rely on gui that much and heavily focus on text.

This may be related to the way people talk and think. As in we don't really talk in graphs. If we did talk in graphs, then Visual Scripting would've been the future.

 

Your analogy that "we haven't gotten away from text" to communicate is very different from representing complex ideas. Having diagrams and charts to explain things can often do much better than simple words. I mean, there's even a saying for it: a picture is worth a thousand words.

People do think in graphs. Pictures are more innate than text. Look at how people can communicate huge amounts of text in a few emoji.

 

I believe it will go much further than that, with AI and ML being the next abstraction layer.

There is no fundamental reason why we have to type characters into sequences or drag nodes around to achieve a particular goal. Just like AI is designing new airplane chassis and circuit boards and music, code (text or nodes) is next on the chopping block. We are going to be relegated to managers or directors of sorts, overseeing whatever project we tasked the machines on.

 

People think but do not talk in them. We speak in statements and do not transmit entire concept at once. And programming is telling computer what to do. Pictures are also incredibly hard to interpret unambigiously unlike written text.

In a future, a different programming paradigm might emerge for which visual scripting would be the most suitable.

However, as of now, I'm unaware of such paradigm, and visual scripting is only useful in edge cases. Which are signal processing and visualization of state machines.

Personally I see modern visual programming tools as a sort of evolutionary dead end which will be replaced by something else in the future.

 

Not all "communication" is the same, though. Emoji work because we've evolved parts of our brain specifically to understand facial expressions and body language, and turning them into pictograms takes advantage of this. It's a specific tool for a specific type of communication.

You're right that "diagrams and charts... can often do much better than simple words", but "often" is not "always", and it's worth considering when that is and isn't the case. Imagery is really good at communicating some things well, and it's pretty poor at communicating others. It's very much a "right tool for the job" kind of situation.

Communicating about something beautiful you saw today is often best done with a picture of the beautiful thing. In that case, yes, a picture can literally be worth a thousand words if you consider how much you would need to write or talk in order to describe it in detail. With modern tools such as cameras and the internet it's also incredibly easy to create and share those images.

As a counterpoint, though, here's a thought experiment: how would you go about creating a set of instructions which multiple people could use to bake recognisable versions of this specific Chocolate Coconut Cake with pictures alone? The whole recipe is less than 250 words, so it should be quick and easy... right? Personally, the first sentence in the Method section presents a challenge immediately:

How do I pictorially represent that people need to do something differently based on what kind of oven they have? It's possible, for sure, but it's going to take a great deal more effort than the 7 words you see above, for both the sender and the receiver.

 

Only time a visual lanuage is useful is state machine transitions. And only transitions. The actual functionality in the nodes is written in code.

 

Except... every alphabet is an advanced form of pictograms and it takes years to learn it properly.
C++ or C#... both represents abstraction layers for people who wouldn't be able (because of mental or time constraints) to type direct instructions to the binary machine.

C++ is closer to visual scripting than machine code. And programming in C++ in VS without a supercharger like Visual Assist is much more painful and slower than blueprints. It's more a matter of tools suitable for a given form than form itself.

And let's don't dive too much into our bubble. C#, Javascript, PHP, C++ or whatever languages... are also tools for "specialized problems"

PS Come on, that's weird statement that visual language is only good for state machine transitions. Maybe if someome's job already is full time programming and this person hates "clicking into nodes". Sure, whatever suits you. But that sounds like a personal opinion than meaningful analysis

Incorrect. We use text commonly for no more than 200 years. We invented print like 500 years ago, but it got very limitted use for few centuries. And before that, we have few scholars using alphabets... and pictograms.
Going forward we return to images, pictograms and plain audio-video communication because technology makes it easier

Anyway, visual scripting can't be "a future of programming". I love having blueprint in UE4, it's awesome to contribute for people who will never become full-time programmers = other forms of programming don't exist for them, are irrelevant.
Hovewer... there's an incredible amount of code/engineering required to make this happen. Visual scripting can't replace any of traditional programming, it's a supplement. Or a "middle man" between "text programming" and clicking buttons in your software or microwave. I guess, we just got more forms of giving orders to machines.

From this point of view talking about "visual scripting is future, or it's crap" make zero sense. It's like saying that "mobile is future of desktop PC". It's a different form designed to fulfill different needs. We need them all

 

(seems like it's not public yet)

 

Speaking of emoji, those are very ambiguous, to the point where different people assign different meaning to them.

It takes about two weeks at most to learn alphabet of up to 80 characters for an adult.

The exception is kanji and highly foreign systems like hangul, which require more effort for the information to stick. But for small alphabets it is definitely not years.

Natural languages, than to visual scripting. No noodles and no nodes.

It is called speaking from experience. In all problems that did not involve signal processing or state machines using visual scripting always royally sucked compared to text form. It was more verbose, less readable, and required more effort to maintain it. ALWAYS. I also saw multiple attempts to get it to work, they were all awful.

Hence my opinion.

Speaking of visual programming, a decent example I saw was the "language" used in autonauts.

Spoiler

This is actually very clever. Because those are obviously text statements, but at the same time they can be operated by drag, so a programmer sees at a glance what's going on, and non-programmer cannot mess up.

 

This looks awful and it is a wrong way to do it.

This is traditional screwup when somebody tries to badly shoehorn a problem into OOP.

A node should be fully represented by a single function. It should be small and compact. Its arguments should define its entry data types, and its return type should define its output.
Making it a class, and on top of it, one with 3 callable methods 2 idents deep is just plain bad design.
And it looks like it has to possess an unique name on top of that. The choice of C# is also very dubious. A language that does not require function to be written within a class would be a better choice for this kind of task.

I saw mix of code and nodes before, but if that's how they're planning to do it, it is not worth using.

 

I like it more than only programming or only visual scripting but the main downside is lack of ide power. It resolves issues with spaghetti math and bad loops performance in blueprints.

Not they, it's the same person that made mix of c++ and blueprints before. It's only a start and he's already trying to make what you described.

 

I don't know who "that person" is.

The idea is right, the solution is wrong.

The author should probably consider a different language. I've seen attempts to get rid of class bodies while scripting in C#, and results were not good, as it makes splitting things into multiple files impossible. They should consider using a different language.

If I were doing something like this, I'd check traditional lua, maybe python (ugh) or lisp dialect. C# seems like a wrong tool, due to its insistence of everything being an object. Lisp would be probably most suitable powerful language, plus it is stupidly easy to parse, but it is not exactly popular.

 

nah, c# is ok, classes for nodes could be encapsulated in modules to reduce unneeded bloat.
You can split into multiple files using "partial".

Lua is in rapid decline, python very different than c++ or UnrealScript and lets not even talk about lisp.

 

C# is not okay, because it has garbage collector and insufficient tools to control object lifetimes. Basically the way I see it, the worst part of unity right now is its insistence on using C#.

You can't encapsulate classes for the nodes in modules. The problem is existence of the class itself. It shouldn't be there.

Code (csharp):

1.  
2. class UselessWrapper{//This line shouldn't be needed
3.    public void actuallyUsefulStuff(){
4.    }
5. }//This line shouldn't be needed
6.  

The code of the node should look like this:

Code (csharp):

1.  
2. void nodeFunction(){
3. //blah.
4. }
5.  

That would be efficient.

Basically, trying to code in C# without wrapper classes was done in space engineers where user scripts were inserted into hidden class wrapper. It was awful, as it prevented users from splitting code across multiple files.

Basically, the way I see it, the language has to support standalone functions that are not part of some class. Then it would be suitable for "inline" coding within modules.

Stuffing Lua or Python into nodes is not too different from using C# as that's not main language of the engine. Both languages support standalone functions, though, which makes them preferable.

And we should talk about lisp, if the language woudl allow better workflow or efficiency.

 

For me c# is the best part of unity.
Yes it got it's cons, but the speed of development and debugging overweights it for me.
Also the worst part of unity are the numerous bugs and unfinished/broken features.

Since the code is in some kind of nodes you can processes it however you want I don't see a problem, it is creators of this system issue.
You say it is impossible to make it the way you want ?

It is disadvantageous to mix too much different languages in one project, this is why I would opt for having similar language in nodes as in main source.

 

Hear, hear!

 

The point of using any tool is to make your life easier.

If "code in the node" makes you lose IDE support, and you still have to write all the fluff code within so it registers, then you aren't gaining anything from using it - you're doing the same thing as before with more effort.

Mixing languages is fine, as long as they match their tasks and can talk to each other. It used to be much more common in the past IIRC. C-library being driven by higher-level language using some sort of CFFI interface. Still happens to this day with, for example with numpy or OpenCV which has python bindings. Thinking about it, PyQt applications aren't unheard of and unity itself is an example of language mixing.

At least that's how I see it.

 

This wants me do to opposite of the thread title. I still can't understand why Unity isn't doing the same.

 

Because Unity Technologies isn't a video game development company. And it shows.

 

Then buy a video game development company, give them Unity source to contribute and fix bugs when needed and make them use the newest TECH releases.

This was a funny news: "Fall Guys (Mediatonic) bought by Fortnite maker Epic Games". From job listings looks like Mediatonic is using Unity only. Weird, very weird as FG is only on Steam.

 

A bunch of stuff that's been built with source access license has made its way back to the engine, but it's a slow process even if everything is sent back. There are faster and more effective ways to solve the issues that plague Unity than buying a studio or making a game.

 

Is it to slowly turn into an ad company and chasing other industries while losing touch and respect for video game developers? Because that's what they've been doing.

 

If that's true then is sad.. Because I thought they were taking space into architecture, automotive engineering, geographic information systems, other engineerings..

also that other companies are being more opened and creating SDK, plugins for it to be compatible to Unity but also Unreal...

 

Them making a game or buying a studio will just make them a failed game developer on top of this, burning tens of millions of dollars in the process, and accelerating them further towards things like ad support and things outside of the games industry.

 

How are they losing "touch and respect" for video game developers? Many game developers fund their projects by doing work in aligned areas. Unity building capability, awareness and capability in those areas is a big win in my books. I'm not taking advantage of those things right now, but I have in the past and I may well do so again in the future.

I agree that things are less than perfect, but perfect isn't a reasonable expectation to have. I see that Unity are doing a lot of stuff for people who are different to me, but I don't feel that Unity have lost either touch or respect for me in the process. On the whole things are still getting better for me as time goes by with Unity. They're a big company, they can do good stuff for different groups of people simultaneously.

 

I don't disagree. My point is more that whatever it is they could do to make things better, easy or hard, costly or cheap, they simply won't do it and us here arguing about whether they should make a game or not to improve their game engine is kinda pointless, as evidenced by what they're currently doing.

I mean I guess I don't have to say this at this point but: I do.

This is not my experience.

And none of them well enough.

No one is expecting perfect.

 

Last time I've heard from someone they weren't allowed to share engine changes with Unity not to mention being stuck with old version to avoid bugs.

 

Fair enough, I was just curious as to how your experience differs from mine.

So much of the stuff I see others complain about is stuff I look forward to. And so many of the complaints I had in the early days of Unity are either resolved or on the way to being resolved, particularly in regard to supporting projects of large(r) scopes. But my background is not that of the average Unity user, hence my curiosity.

Edit: In case it comes across otherwise, I'm asking, not debating. I'm not trying to get you to agree with my perspective, I'm just interested in what other peoples' perspectives are.

 

in my oppinion I love Unity because it has many good asset and easy for beginner how ever for stable engine now a day unity is not stable anymore I face many error in myproject and I can not solve it just delete and star over again and again one day I might stop using unity engine

 

After multiple years of this stupid "hold-on" madness moved on cause it took literally around 6-8h for the engine to complete this hold on - crashed inbetween - had to be restarted - crashed again - etc. - delete you Library was never a good option for me because of the wait afterwards again for 6-8h (a whole freaking working day wasted). Basically my workflow was looking at this hold-on window and you can't even play a game or code something else cause it steals focus all the time (i mean who the hell designed this crap? who the hell tested it afterwards? makes me question everything about the Unity team and their priorities). Needless to say that i missed every deadline possible.

So in short - i don't trust this piece of junk engine anymore - i don't trust the Unity team for this let down and ignorance for many years again. All i hear from Unity are lies everywhere - like we are fixing it (3 years no fix) and "Performance by default"? lol dream on! - Cocos and Defold engines beat your engine no contest. All those pretty marketing words with nothing behind it.
If you want to know more about how people struggle with hold-ons then have a read here since it pretty much explains everything about Unity engine and the "remarkable dedication" the team brings to the table - https://forum.unity.com/threads/lots-of-busy-hold-on-etc.833644/

Moved on to Defold engine now. It uses LUA and i had to learn first but it's easy - though needs some getting used to (as every new language i guess).

After this atrocious attempt at an engine i really can't touch anything that's not open source these days. With open source at least i am able to fix things myself (done it) and improve my workflow if i really have to - not waiting for promises never delivered from Unity.

Hope it helps someone in making a sound decision next time they pick an engine. And trust me - never ever this Unity crap for me!

 

Only two things?

What about..

1.) A battle tested engine that has been proven for years over thousands of devices and hardware configurations?
2.) 3rd party SDK support such as backend services, ad network support, error logging SDKs, multiplayer SDKs etc etc?
3.) A community/knowledge base over 17 years old with most issues answered in some form or another?
4.) A large 3rd party marketplace of assets I can use to easily extend my game with?

I wouldn't dream of exchanging any of those 4 for an all C# engine or some QoL improvements that another engine may have over Unity.

 

I just had to do two intense weeks of coding in Unity for a client's project. Before then I was pretty salty about the state of the engine and was looking to explore alternatives since both Defold and Godot are getting better EsotericSoftware's Spine support.

But I had a surprisingly good experience in those two weeks. I stuck to the latest LTS, didn't use any new packages or recent acquisitions. URP is in a good enough state for the client's 2D project. Engine didn't crash once, didn't have any bugs that were not of my own making, didn't make me unnecessarily wait. I got a Windows blue screen of death when launching Unity once, but it might be my PC showing its age. Built this thing back in 2016, time for an upgrade. And if I had some questions, answers were a single google search away. Overall, it was a very pleasant two weeks of working with Unity.

The only real gripes I have with the engine for this project are a lack of native tweening system and the engine's primitive serialization options which force me to adapt 3rd party solutions like NewtonSoft JSON and Odin Serializer. But as long as I don't have to touch any of the new package manager stuff besides URP, I'm a pretty happy camper.