Unreal Engine 5 = Game Changer

Even if you and 95% of users would even look at source code - which would be a pretty... inefficient for a programmer...
Your automated test won't tell you how to write a code to utilize the engine better. Won't tell you what happens inside Instanced Static Mesh Component when you're thinking on the most optimized route in code. And this alone perhaps gives UE4 programmer more than C++ itself, if we're talking about optimizing systems/game.

If Unity would release source code publically... this would immediately eliminate the possibility to do many tiers of engine features for users. They could keep paid support, but that would be far less useful/needed. After a few months of this huge community digging in sources, most of the questions could be answered on the Discord channel.

Opening source code forces a company to change its business model. No tricks, no dark theme in the paid subscription. Engine API must be clean and commented clearly. I mostly don't care about engine documentation while having source code. It would be only nice to have good extensive docs for new people (new to C++, but also programming in general) and explaining concepts behind every system. That's it

 

Indeed. Why "salvage" a project when you can revert it to a working state in a few clicks?

 

I have over 100GB of backup folders and the game in several milestone stages. I have crap bandwidth living at the edge of a huge natural forest with tourist eating the local bandwidth with NetFlix...and I went thru another WTF when I tried to upload the project the day before to collab when the first crashes started. I linked to a created Project ID and started up its submit routine..good 45 minutes preparing that. Then I am making more changes and prefabbing the heck out of everything and saving states to get around the15-20 minutes fiddling to get textfields and stuff in place. Everytime I hit save I would have to wait while it checked my entire asset folder for changes. I shut it off. Do you want more detail on data conservation prophylaxis and Unity frustration because I can offer myriad more scenarios an details from my other project 'Cyclotronica' which has way more moving parts than this motorcycle sim. I could weave dastardly tales of triumph and woe at every stage of the Collab process and constant crashing to the desktop..repeatable on other machines.

 

Have you tried other VC tools? Both git and SVN are industry standard tools and allow you to do things entirely locally, so they're probably a better fit to low-bandwidth situations.

 

You can't put out the fire after the house has been turned to ashes

 

No, but you can learn from it and make sure it doesn't happen again.

This stuff is industry standard for a reason, including free options. I'm sympathetic when people lose their work the first time. If they don't learn from it then that's nobody else's fault.

And it's entirely engine and toolset agnostic.

 

With what? Not sure what this is referring to.

 

megascan mesh assets
They already have a hold on texture generation and object placement, they are getting scaringly close to sound like music, and text is somewhat in a place where we try to parametrize the output toward something sensible.

If we found a universal descriptor of games we can parametrize, the make my game button will be a reality.

 

The button might be there, but what would be the point of pushing it?

Even from a purely selfish perspective, it's not in your interests to have that button because the value of such games would be wiped out overnight. There is no such thing as absolute value in the economics of customer choices, especially in something like entertainment.

 

Speaking of which have you seen the article where an AI recreated a game using video footage?

https://blogs.nvidia.com/blog/2020/05/22/gamegan-research-pacman-anniversary/

 

Checked it briefly.

I suppose in this scenario neural network acts like an FPGA.

 

It's not exactly entirely new, it's progress from game NN where the io flow is reversed and they started generated plausible (blurry) hallucination of the game (even 3d one), it was obvious ...

I didn't knew about the pacman though.

But I guess in game we have fully got out the denial phase, we are still early in NN exploration and we don't seem to have reach a plateau yet, ie hard block, either practical or theoretical.

Actual "explicit" reasoning is in infancy, though "simple pattern matching" seems to get a healthy 50% of the way, given current nlg quality about "implicit" symbol manipulation. Most of the problem right now is about managing the data, decoding what the ai does and architectures.

I was half joking though lol

 

If you for reasons unknown need to work locally only you should still use git, it's distributed and that means you never need to push to remote. You will still benefit from versioning, branching etc. A million times better than manually marshaling backups on a disk.

You should backup the git repo regularly though if you do it this way.

 

i am very sorry this is happening to u sir, i pray things work out for u and family.

 

Another issue with Unity are the multiple render pipelines. Not just from the developer perspective but also for Asset Store devs. Some even need to sell it as separate asset to cover cost. A fragmented Asset Store is certainly not healthy for the Unity ecosystem.

 

About the C++ Resharper, y try it yerterday and what a difference... now the intelisense works near same speed of C#, and the autocompletation show all functions with all params and many (really to much for me, what a popups..) information about every override and parameters.
The consumption is big yes, but appear inially, load the project make VS 2019 go from 1,2Gb to 2,6Gb using 40% CPU, and then after 1 minute drops to 1,6Gb and no CPU usage, if you edit some class i see no issues again.

 

Absolutely bonkers. I barely talk on these forums, maybe once every few years. Every so often you get these threads that you just have to inject yourself into.

What the hell happened @hippocoder - I could never have imagined you'd talk like that in this thread. Something really must have happened over time in the background for you to become this jaded.

Guys, we asked for this. Many years ago, when UE was releasing incremental versions, we begged them to open up their development flow with all their preview features. When they finally did, everyone was super excited..and now, a few years later, you realize just how many features get thrown away because they weren't good enough. That's how development works. We asked for this.

Remember UGUI? Before that, they had this super-secret new gui planned. We were all still using NGUI, how many of you were begging constantly for them to release even an alpha of their new UI? If you had gotten it, you would have been happy, and then unhappy when they threw it away because it wasn't good enough. And then happy again when you realize the next iteration was that much better and forgotten about your woes. Because you aren't trying to ship, you're just chasing the next best whatever. Develop in the NOW.


I'm gonna say it now, just what we did all that time ago. Thankyou Unity for bringing us into the development process and being much more open. But you definitely have some internal issues. It feels like good people are going to waste, and toxic people are allowed to flourish.


And for everyone else, this doesn't mean S*** to me. I haven't seen it in the editor yet. And even if I did, and it was amazing, with all these graphic improvements, have you looked at Quixel? it really doesn't have many assets as you think, definitely not enough to build a full-fledged game with. You're going to still need to build custom stuff, so good luck making custom stuff that matches the quality of Quixel.

Now..the workflow improvements. I can believe it scales, I just don't believe it scales as well as they claim. And if it doesn't, can it be tweaked for higher performance on lower-end devices without sacrificing too much? Who knows. That's why I'm not even looking at UE right now.

Most of us aren't targeting PS5. So what does this do for PC? Damn guys, we just recently got RTX and now you're all talking about free GI.

Even though we asked for all this, I did not ask for Unity to break every release, with newest package versions not working because some other package it relies on hasn't updated yet, etc etc. Demos don't work years later. Demos are released with price tags of $250. Documentation is atrocious. Bugs exist years later, or get fixed and don't get fixed in previous versions for people who work on stable versions. You have a massive employee count, what the hell are they doing? are you hiring two people for the same job? More doesn't mean better. Epic have HALF the employees.

I'm only onboard right now because of DOTS. If DOTS doesn't improve, I'm out.

 

My nieces ask for ice-cream all the time, but it's my fault if I buy them a ton of ice-cream and then they have a tummy ache or something.

Also, the problem is not that they started releasing more preview features. It's that somewhere along the way, they also lost the ability to finish features. Seriously, I'm reading release notes for features in the 2019.x cycle, and 80% seems to be about features that are in preview and even those that are "finished" are still very buggy to use.

Transparency isn't the problem. The problem is that Unity is going through a transitional period starting from Unity 5.x and many years later, we are still in an even bigger transitional period, and people are frustrated.

The current super frustrating situation is that if I want to do X, I can either use "Deprecated feature A" or "In Preview feature B". And I don't like either of those and no one asked for this.

And about UGUI, I'm not sure why you're presenting it as a success story. Because without any transparency, we got a "meh" UI solution, that then proceeded to not get any improvements for years. I don't see how development being more or less transparent would have changed something here.

 

If you wanted to do X, you could have done "Deprecated Feature A" and never had known it was deprecated until much later. This is my point. They experiment with new features and ideas, and are letting us in on the process.

Unfortunately, I guess, none of us expected it to be this bad. They still haven't really finished things that are in preview. And what isn't in preview isn't getting much love. They're abusing this a bit too much, but it was something we wanted, badly. I imagine it was a pretty big shift from what they used to do, with incremental upgrades to push us into buying the next version of Unity.

Just imagine how bad their in preview version would have been, is what I mean. On a side note, I'm really looking forward to UI Elements! I hope it doesn't disappoint. I've been wanting something like this for a _very_ long time for mod support.

 

I don't even care that much about next generation graphics. UE4's workflows were miles ahead of Unity's back in 2015. It's 2020, and now essential features are being split up into separate packages, and most the promised features are lackluster and destructive (updating to the newest features is time consuming and frustrating).

It's not so much what Unity is doing, it's what UE4 is not doing. And that's having an officially supported robust text based scripting language that's easy to write code with, and it's core functionality is integrated seemlessly with all Blueprint graph scripting functionality (BlueprintScript?).

Once BPScript gets officially announced and I can play around with it, I'll probably leave Unity behind forever (until an awesome tutorial series gets released or awesome Unity assets make game development a lot easier).

 

Technically, we can either use "Feature A" or "In Preview Feature B". None of the existing 'main' features that are being redone using different approaches/technologies are officially deprecated as far as I'm aware (except for realtime GI which was outright removed, correct me if I'm wrong). It does make sense for many of them to be deprecated in the future, but the thing is we now have access to the engine's future before it becomes its present. I have to agree that we kinda asked for it.

I very much prefer the -here's tried and tested Feature X, ready for production. We've marked the feature it replaces as deprecated- approach though. There's nothing wrong with preview features themselves, but for many people "preview" means "let's put in in production and then complain that it's not ready yet, then complain that it will take a long time for it to be". Hell, I've even met people who use betas for production.

Nanite took 10 years of research and 3 full years of development, or something along these lines. Just imagine what would have happened if Unreal decided to ship a preview version of Nanite 2 years ago: everyone would've tried to jump onto it, used it, become disenchanted with it, then bashed Unreal for shipping a half-assed feature. Sounds familiar?

The way I see it, all engines/software products are in constant transition. Some hide it from the users, who see things in "stop-motion" instead of a continuous stream of ever-evolving stuff. Whether this is a good or a bad thing largely depends on what your expectations are, and what you use the product for.

 

Yeah, and we could have offered feedback, which is what we REALLY want to be able to do. We want these features to come out in preview so we can have them as something we can offer feedback on.

But what you're doing? You're trying to reframe whose fault this is. This isn't our fault at all, but the fault of a company who is not properly listening to the feedback of its users. So how about you quit trying to blame the users and think about who really holds the power in this situation.

Was it the users who took down Unity Feedback and hastily redirected it to the forums, not even properly archiving the site so people could see what used to be there? Sure wasn't! I imagine part of that was because they didn't want people to see things like how a new terrain system had been requested for a full decade with absolutely no response.

How about how they completely closed down any communication options on Github and instead turned it into nothing more than a code dump? Did the users do that? Because I'm pretty sure they didn't do that either.

Oh, how about the standard assets thread from 2018? See, they asked for feedback on that and then, three months later, completely stopped responding. That thread, asking for user feedback from two years ago was stickied until about three months ago. Was it the users who stopped responding in three months? Again, no. User posts continued in that thread, including posts about how to get the assets from two years ago to even work in modern versions of the engine.

Time and time again, Unity has either asked for feedback and done nothing with it, or they've outright closed the ability to communicate feedback to them in the first place. Hell, people have been begging for something to be done about the mess that is Unity Answers for years and the most we've gotten on that front is "we've heard your comments and are looking into it," but that's not much at all, is it? At this point Answers is such a mess and so poorly indexed that I purposefully make sure to exclude it from google searches when I'm trying to solve technical problems.

If you want to place the blame for things being in the state they're in, maybe focus on the people who are actually responsible.

Unity replaced their old GI solution (Beast), in 5.0 and it has been a disaster ever since.

 

Unity is great!! :3

 

Eh, I would have, because I would have submitted a bug report or made a feature request or something and would be met with a "by Design" or a "Won't Fix".

Not really though, because In Preview Feature will have issues, and when I ask about those issues I will be met with "Well, it's a preview, what did you expect" and if I use Feature A, and have issues, and ask about those issues I will be met with "Well, it's deprecated, use the new stuff".

There are many examples of this, Legacy Animation / Animator is a pet favorite of mine, where for a long time I went through cycles of "Legacy Animation is buggy! -> We don't fix bugs for Legacy Animation any more" and "Animator is too slow for my simple use case! -> Just use the Legacy Animation silly, that's what it's for!".

 

I never used collab, always did the versioning on GIT, but it seen collab is full of problems in this regards. If you ever create a topic or blog post with the experiences with this project and the collab backups let me know. I think it would be very informative. Again sorry for all your lost work.

 

I have a pretty large project entirely based on Legacy Animation, started it back in 5.3 and currently sitting in 2019.3. Haven't had any issues with it tbh, so I don't know how Unity would have responded if I had. LA does not appear as deprecated in the documentation (or I can't find a place where it says so explicitly), so if they refused to apply bug fixes to a non-deprecated feature that is still used in many ongoing projects, that's a genuine reason to be majorly pissed off.

 

Read right under what you quoted . I agree with all your points though.

 

This really doesn't address my primary complaint of not ever listening to feedback!

This development process thing? We haven't been brought in at all.

 

Previews is an example of listening to feedback.

Also, read where I talk about toxic people, too many staff, etc. I"m clearly blaming Unity. It's quite clear from looking at the unity blogs, and staff members on these forums, that there are some very passionate and intelligent people working at Unity, and then a completely different crowd. So why is there so many struggles? That's where I'll leave it .

Previews is this. You've been around a while, and I'm sure you remember the old days. I'm not saying that it's perfect. Far from it. But it has come..somewhere. But it's lackluster, not even going to deny that.

 

Though I agree with most of what you said, I think conflicting package versions and general broken/brittle behavior is inherent to preview features. Basically you're sailing on a ship as it's being built. Stable releases are stable, preview features are often broken.

But I could argue that the execution of the 'preview' concept has been far from perfect, yep.

Try luck with other engines, then. If you don't think docs can be worse, think twice . Imho, Unity's docs are quite good most of the time, and they cover a lot of ground. Of course there's room for improvement, but I would not say documentation is one of the engine's weak points.

Few things I've proposed / bugs I've reported, have been listened to / fixed. Maybe I'm a lucky one, but I don't see a general tendency towards ignoring feedback.

 

True. But it seems to me that the teams aren't all in sync. They don't make sure their old demos still work with newest versions, or upgrade them to the newest etc. This should be priority #1, if they're building new features, then how are they testing them? Typically a working demo would be a good starting point to keep up-to-date and showcase all the features for that package. As well as serve as a testing grounds to make sure you didn't break S***. I bring it back to the people in this case.

I've been playing with their preview packages in my free time which is where this came from. For the actual core features, it's been great. I should have stated the difference, since ofcourse preview packages are changing a lot, so its hard to keep their documentation or have time to document it all.

I've always been able to get around my major showstoppers, even if it's a little time intensive/ugly, it's fine with me, I don't expect it to be perfect.

 

100% agree. Preview features are poorly documented. I've been heavily using DOTS recently, and there's a lot of "bool Thingamabob(int): this method thingamabobs " stuff in there. I'd expect it to improve over time.

 

You'll find a lot of this when you look up a lot of graphics things that have been in the API reference for ages.

 

I know, it's mostly obscure/advanced stuff though. I remember being bitten a while ago by this:
https://docs.unity3d.com/ScriptReference/Camera-forceIntoRenderTexture.html

If I recall correctly, the second paragraph wasn't even there a couple years ago. It simply said "Should camera rendering be forced into a RenderTexture." What? why the hell would I care/need to do that? Turns out, it's quite important to ensure certain post-effects work correctly with HDR/multisample AA, as rendering to a render texture or the frame buffer is managed differently.

I raised a bug report because a post-effect I wrote was not behaving properly, and had a Unity staff member explain to me why it was not a bug and why forceIntoRenderTexture was required to get things working in my case. Well formulated, concise explanation that sadly never made its way into the docs .

So yeah, there's room to improve. But honestly, it's by far one of the best documented pieces of software I've come across.

 

Unity was working on some kinda upgrade to the Legacy Animator a long while ago. Never got integrated into the engine or into a package tho, kinda like the nav mesh component.

https://github.com/Unity-Technologies/SimpleAnimation

 

Honestly, I see people say this a lot, but I guess my big comparison to make is the one I think we're all familiar with and don't seem to give nearly enough credit:

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/

The Microsoft language reference is so incredibly comprehensive that I recommend it above any other resource when it comes to learning the ins and outs of C#. To say that it makes the Unity API reference look lacking is an understatement so dramatic as to be laughable. You point to a single sentence that was added to explain things, but take a look at what could otherwise be a very difficult concept to grasp for a new developer in C#: stackalloc

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/stackalloc

Up front, you're presented with what it does, including links to the relevant terminology, followed by an example in code, use cases, and an entire section for related content. In Unity, this same sort of content would be divided between the manual (Unity's manual is a whole other mess, if I'm being real), the scripting API, and very possibly the other manual that's popped up: the package content documentation.

To make matters worse, sometimes when you search for things in the manual with google, you're brought to entries in the manual/scripting reference/package manuals for earlier versions of the editor/package. In the case of packages, there's no clear way to actually get to the most recent package version; but in the case of the manual/scripting reference, if you click the "current version" link, you'll likely be brought to the front page of the manual or most recent scripting reference, not to the relevant page. To make matters worse, despite features existing in the latest version of Unity, there have been cases where I have had to use earlier versions of the manual because the things I was searching for were not in the most recent version of the manual.

Right now, the Unity documentation is incredibly labyrinthine, and the way it's getting divvied up doesn't help at all. There really needs to be a unified documentation system and I think it would do Unity a lot of good to bring on some technical writers and planners to lay out something much more akin to the documentation that Microsoft has had set up for some time now.

 

Not really though, since it actually really uses an Animator so it has all the overhead that the Animator has anyway. So for those of us that complained about the performance with the Animator, this wasn't really a replacement. And I guess it was abandoned because the guy that started it doesn't work there any more (I don't see any indication that he is a developer in the comments), but read his comment about SiimpleAnimation in the comment section bellow the blog post:

Legacy remains faster, they just refused to fix bugs with how it handled animated materials, because... just use mecanim! Then they forced everyone to migrate to mecanim since supposedly it would cover all use cases, (which I guess didn't pan out, maybe the team that wrote mecanim left or something) but then proceeded to tell us to use the Legacy for simple cases because it's faster. And even then, the manual is still talking about it being there only for compatibility reasons and it shouldn't be used otherwise.

 

I will tell you why. Because there was a distinct possibility of Unity doing this again from loads of past experience. I had bandwidth giving me 70FPS in a pretty dense scene. The previous fully saved versions opened at 20FPS and were unstable and crashed to the desktop silently as well with no bug report. Your advice is boilerplate worthless just like the three months of reinstall DX11 advice I got from the bugz QA guys. You can't frickin' reinstall DX11. It was a damned PhysX bug crashing Cyclotronica not a faulty DX11 driver. They fixed that bug and it no longer crashes and the game designer is completing the tweaks for release on Steam as I write this. Regardless, I soldier on and have exported all terrain as .objs as well as the one long single object road and setting up the terrains as platform agnostic, optimizing vertices counts on terrain not within 50 metres of the road and create a planting system of nulls in C4D so I can use pooled vegetation that unplants from behind and replants forward of the vehicle and camera rig. That way, Unreal or Unity I can easily set up the environment over and over instead of losing it. SVN/Git/collab doesn't matter to me at this point. I am goinna take lemons and make lemonade. Seems to me that I could have released a SVN archived version and then dealt with players having crashes because somewhere under the hood was an undefinable bug that could resurface at any point based on the users computer characteristics and graphics cards, driver version etc.. I get one chance to make a proper impression on rollout. i am taking full control over what is generated at this point and will probably get much higher FPS bandwidth with the procedural systems and optimized mesh and shaders I intend on completing by the end of today outside of any game engine. It will be importable and set up easily in Unity or Unreal.

In case you missed the real pain it was the fact I was at the end of fine tuning a motorcycle sim which had much remembering what each tweak of a setting did as i changed numbers, watched gear ratios, checked the rpm's on the UI tachometer and correlated it with the speedometer readouts, made sure banking looked properly correlated with physical velocity and turning radius snd studying the suspension characteristics to be able to properly set up the mesh parts so shocks would remain pointed at each other deep inside the motorcycles hierarchy with different parent objects as the wheelColliders reacted to the terrain and road rise ad falls. Ya see, that is not a simple task as you have many major groups of moving parts such as the front steering assembly, the rear fulcum/upper rear shocks and lower rear shock, front forks upper shock assembly to lower shock/wheel hub. This was complicated further by ensuring every part could be replaced with a customized chopper replacement such as body tubing configs, front body geometry, extended forks, front and rear fenders, splashguards, headlights, taillights, gastank, handlebars, seat, wheel rims, tires, brake discs. Keep the low level boilerplate coming pal and I will continue reminding you that you know little about the actual issues involved infuriating me.

 

Microsoft devops coupled with git LFS is all you need (granted I haven't tried out unity collab). You get a nice mature issue reporting and management system plus a mature build server suite. For free upto 5 dev's

 

He's talking about version control. Git, for example.

Let's say you're working on Unity version XX.YY.ZZ. You use version control.
Version XX.YY+1.ZZ arrives, the editor asks you to upgrade, you make a version control checkpoint, and upgrade.
Then you launch XX.YY+1.ZZ, which promptly crashes your computer and no longer works in any way.

In this case, you uninstall XX.YY+1.ZZ, download editor version XX.YY.ZZ, and restore code from version control checkpoint - to the EXACT condition it was before you upgraded, and continue working.

Version control is a must have thing during development. It is more reliable then sequential backup, and it allows you to prevent data loss by letting you roll back to the EXACT state code and resources were at some point. It also allows more fun things like finding exact spot where some bug is introduced.

In general, if some unity version works on your computer, it will continue working indefinitely. It can't ever break, and will always work the same way, because code does not rot. In order for your installation to break, you need to upgrade it to a different version number. If the new version doesn't work, you can download the old one from download archive, and then restore the code to the working state via version control.

That's the rough idea of it.

 

Any tutorial on using version control ?
My main project is +300 gb and having it in a free (open) github account doesn't seem to be a good idea.

 

Google "git tutorial" and "git lfs tutorial".

I don't believe you'll be able to upload 300gb anywhere for free though. But you would be able to have a local repo and a backup repo.

 

Yeah. I get it..but it was always unstable to some degree and I had upgraded and kept it in a version for a while that was stable and giving me 70FPS. Reverting to the backup of the previous day yielded 20FPS..unacceptable for a vehicle sim game. There is a side issue to this. I had Windows upgrades off as I finally had a stable set of driver/OS configs and one morning I awoke and Windows had backdoored my system and upgraded. I found yesterday it had turned back on the Defenders anti-virus. That shushed down the screen tearing issues alot when i disabled it. I now only have screen tearing in Unity and not in C4D which never in 18 years had an issue with that.The further issues is testing the local clone backups in various versions required tapping my foot whilst Unity re-imported 10+ gigs of assets. At some point due to financial constraints originally introduced by the 3 months of Unity QA ignoring my pointing directly at the cause of the Cyclotronica PhysX bug I had to move on and get sh*t done. This is not a theoretical situation as many pretend it to be. Add to that things like trying to use the Package Manager to simply update Azure Sky to get the sweet environment I had prior to rebuilding would be this...Open PM-> load My Assets-> Update not showing-> A few minutes later after several refreshes it would show up->should be on my computer as I have used it frequently-> I get Update only and not Import which is grayed out-> Import asset for 12 minutes-> Progress Bar hits 100%-> Import button greyed out and Update not available only original version-> repeat process->same thing->repeat process->same thing x 15 x 12 mins->run head into wall->brains hurts. Well, mr dev..why did you not get it from the previous clone..I did..and it had some crap introduced that turned the nice chrome into gunmetal when I hit play after the blow-up. Tweaking settings did nothing for the issue. I finally got a fresh install of that asset and had my nice chrome and reflection Probes working the way they had for the two months prior. Now, put your brain to that one and explain the user error. It eludes me as to how this is my responsibility.

 

Devops don't have a upper limit, but for large binary files you should use LFS

 

Unity just bought Bolt and Bolt 2 will be implemented as well as Unity Visual Scripting.

Democratizing game development right? i.e Typist gets to play and Visual Coders get to play. Lots of people shouting for Visual Coding thus in favor of this democratising game dev...they will be getting it. I dont understand why people (not unlike yourself although this is not aimed at you specifically) hates the fact that others are capable of making games in something like a visual language. Back in the day Macromedia Flash got the same treatment. "Oh it'snot a real coding language" and "oh its not coding when you use a timeline - so it's bad". Some amazing things were built with that tool,and all that would not have been done if it was not for a tool that catered to the right brain person.

It comes accross as elitist or maybe even a little insecure that some hardcore programmers are so vocal and passionate about dismissing the fact that others can make a game and not need to code by typing text into an editor. I guess it sometimes undermines years of learning and getting to grips with coding and learning little details of how to optimize code to let it run faster etc.
I think programmers are still safe that a visual language will not overtake it soon, but I agree with @Murigold that especially in the case of something like Blueprints - but also others like Bolt, Playmaker, Construct 3's , Clickteam Fusion etc. has enabled some really great games to be made that many enjoyed.
As an Indie or AAA developer that should be welcomed, nurtured and praised. Not tarred and feathered.

 

One thing to note is that you should actually rebenchmark any assumptions about speed of using that vs legacy. It could still be slower, or not. One of the reasons is that the entire animation system is now rewritten to use playables and the Simple Animation component uses Playables. Having an Animator on no longer means using Mecanim, unless there is a controller actually assigned for it, plus the Playables system is increasingly multithreaded.

That said, I'm fairly confident that for very simple clips (i.e. low single unit bindings) legacy will still have a smaller overhead, it's just that some systems that are seen as static in terms of development have actually had quite a lot of development so it's worth re-evaluating just in case.

 

So as far as I can tell, Bolt (and by extension Bolt 2) will remain paid assets ($70 last time I checked.) Unity, as far as I know, has given no indication that they are going to allow people to have Bolt for free. People who own Bolt will still receive Bolt 2 for free (as long as they own it before a certain date), but that's only because Unity is honoring Ludiq's initial offer. Same issue with their cool Artomatix acquisition. It's expensive enough that they're not even publicizing the price (just like source code access.) It's a different business model than Unreal Engine, but there is at least the perception of Unity nickle-and-diming while Epic is giving away tons of free stuff. Unfortunately, at the end of the day, Epic has turned their indie gamedevs into collaborators, while to Unity they're customers. Epic only gets paid (from an indie dev) when the dev is successful, whereas Unity gets paid regardless. So it makes sense that Unity would continue to focus on acquiring the newer markets (engineering/XR, cinema, AA game studios) and just let indies buy what they need from the asset store. Because at the end of the day, it doesn't matter if the indie devs make a game, as long as they're buying Bolt or PlayMaker or whatnot, and maybe kicking in a subscription if they want dark mode and a custom splash screen.

 

Are you directing that at me since you quoted me? I use node and flow canvas in a lot of my projects FYI. Not at all the point I was making. All unreal threads devolve into visual scripting wars here.

 

People that can program traditionally have better things to worry about than some insecurity. This sort of nonsense is something people are supposed to grow out of either at late teens or by the time they hit 25.

"Hardcore" programmers typically realize limitations of visual scripting tool and know where it is useful.

• However, when visual scripting tool is implemented, it is usually touted as "the way of the future", and in process people who need power tools and know how to use them get shafted. That's what happened to unreal, by the way. See documentation quality for C++ and for blueprints.
• People that promote visual scripting typically do not use them in the areas where those are efficient, but everywhere. When you're unwrapping a one-liner formula into a screenfull of nodes, that's not efficient. This creates a mess, which will need to be fixed by traditional programmers in the end.
• There are limitations to visual scripting, proponents are often unaware of those limitations.
• And when you dare to voice disagreement, what you hear "you're a bad person". Because "you must be feeling insecure and you must be trying to prevent other people from ever making a game?". Do you people even listen to yourself, when you write something like this?

When making anything I want to deal with a tool. Not with a cult. A lot of spirited arguments in favor of visual scripting sounds like they come from some some sort of cult. Which... isn't helping its popularity in the long term.

The reason while people criticize Visual Scripting is because they know that there is a better way, a more efficient way and it is not that hard to learn, plus you'll get long term benefit. When you tell that, however, you often get "you're a bad person" response.

 

We last tested this 4 months ago, the difference was tremendous. I doubt anything changed since then.

AFAIK the slow part of the Animator is not the state machine, the way it plays animations is just much slower for simple cases. Last time I checked this (although this one was years ago), I couldn't actually find a use case complex enough were Animator was faster.