i can’t state whether there’s a lack or not, since i don’t work at epic. but i came to the same feeling as you a few weeks ago.
i’m personally not a proponent of automated testing on games, but i do think they help in a framework/engine, specially the size of ue.
i do agree that in this case it’d seem that automated testing would really help.
but i don’t think that autotest by itself will fix the root issue. and i think it will hinder if used on new features. it will certainly require effort and will certainly slow down new features and innovation.
it confuses me though, since i know that, in the codebase, there is some auto-testing. but as usual, it does not cover everything.
i still think their qa process could/should be improved too.
i think that’s a different issue than LTS, a bit tangential. you could target a LTS without refactoring the engine. lts is mostly a change in process, not work itself.
but i do agree. specially when building the engine. UnrealEditor target is 4000+ actions on my pc. and takes very long. and i’m pretty sure a ton of that could be moved to plugins. making it much faster to work with, and safer to modify and test.
sorry, maybe i’ve explained myself wrong.
i didn’t meant that LTS would stall development, i meant that a stringent qa would stall it. with forced autotesting, regression testing, and full coverage.
i do think that an LTS is better option than a stringent qa imho, since by contrast, it would not stall new features.
this is tangential to what you just said, but i think you have a good idea. by modularizing the code more, you can skip LTS support for beta/experimental plugins. hence reducing the amount of work on epic side.
i think the requirement for an lts is the willingness to backport fixes, and keep working on a specific version (but only for bugfixes, security issues, and only on non-alpha/beta code).
(potentially) by a dedicated team.
I struggle to believe that epic does not have the resources to have a team to just keep fixing bugs on a specific version, and backport fixes from new versions. but it’s apparent that they don’t do it.
it became apparent to me that epic is more focused on new features than on stability or performance since 5.0.
i could understood that at the time, since lumen and nanite were big jumps in complexity; but i think a lot of time has passed and the stability is not there yet. it feels as if they have taken those qualities for granted and underestimate the importance for users.
though 5.6 has had a ton of work on the bug fixing realm (and also pso). so i’m certain they are aware and are interested.
i do feel something is pushing them to do things (new/shiny) that users are really not finding that valuable, at the expense of a stable/reliable/performant/documented tool. imho.
it gives me the feeling they are spread too thin, even though i find it hard to believe for such a big company.
still i think there’s an issue with their process.
they could put a ton of effort in fixing bugs for ue5.7, but if they don’t figure out another way of working, it’s going to happen again on 5.8. imnsho.
in my work, i’ve had cases where it’s simply a no-win situation.
(this is from memory, i don’t make an effort to remember these things, so i might be mistaken, so take as example not literally)
e.g. in 5.2 umg retainer did not work (at all). in 5.3 it did, but it broke vertex interpolator in some cases. in 5.4 it worked but then something else broke.
so as your project grows, your chances of having a deal breaker bug increases, and your chances of having at least one dealbreaker for several versions increases too. and you end up not being able to use the engine. at all. which is pretty silly. it makes the whole engine useless.
LTS makes sense as well since for a company moving engine versions is really costly, and more risky than people would love to think.
so rarely you’ll upgrade your engine more than once per year.
i’ve used ubuntu/debian for over two decades, so i’m quite comfortable with the LTS cycles.
i truly love it and i’ve even used that in my way of working.
and i think it’d be the best way to have stability/performance, while not blocking innovation/fast iterations/beta adoption.
i really would love if ue could have an lts that’s focused on
- stability
- performance
- security
- documentation
- release code (not beta/alpha)
- that releases no more often than once a year. maybe once every two years.
. Even FAB is experienced by many as a partial and bugged implementation of what it could have been. Browse to any page and look for errors on your browser console. Sloppy and