We are a tiny dev team using Unity on a non-gaming project and we basically have to dedicate 2-4 weeks of the year to updating Unity and all the mess that it entails. But if you don't update then you have to spend even more time the next year catching up. Then we end up being too scared to use their new features cause they aren't supported well or cause bugs. Its lose-lose.
I'm in game dev and have been responsible for doing Unreal Engine updates for medium-sized teams (50-150) on AAA games.
Our updates have taken one full-time engineer for 2 weeks plus an additional 2 weeks total of various people's time for each upgrade. It's worse if we skip a version.
We dedicate probably 3-4 person-months per year to staying updated, but it's well worth it. As an investment its ROI is easily 100x.
Do you make changes to Unreal's source? Or have middleware that makes changes (Havok and Fmod)?
Your effort estimates line up with mine, but I'm not sure about the ROI (but it's been a few years and I was pre-fortnite).
We made limited changes to Unreal source, but I think we made more changes than we had to. We had our middleware, we fixed bugs (none upstreamed via github due to company policy), but we also introduced new features varying from necessary for the project (instanced mesh rendering) to unnecessary (fancy logging). Every upgrade, I regretted most of the changes we made.
But also, it seems like every upgrade our data assets and blueprint script would get less stable and cause weird infrequent crashes in the blueprint/uscript interpreter.
Do you use bleeding edge features? I recall being wary of anything that hadn't been around for a few updates.
Yes, we make a significant number of changes to Unreal source, probably on the order of 1-3 per day across the team.
All changes to the engine are required to be wrapped with a special comment tag indicating the author and explanation of the change, so that it's evident in a 3-way merge window how to resolve if there's a conflict at engine-upgrade time.
At a previous company we used Enlighten and Simplygon both of which made changes to engine source, and those were a nightmare to deal with. We had several source branches set up specifically to deal with 3-way merging at all steps of the way.
We also implemented things like instanced skeletal meshes, an improved navigation system, and additional shader passes. Those were all very complex to upgrade especially when Epic had refactored the underlying systems.
We don't use features that are experimental in shipping code.
Last year's Unreal conference had a couple of talks related to engine migration and how teams managed to do them, which some mentioned they rather do it between projects than jeopardizing an ongoing game development cycle.
Middleware migration headaches are everywhere, regardless of the chosen stack.
Honestly I've never seen this problem solved well for any game engine short of in-house engines(which obviously wouldn't break titles they were supporting).
It's been a while since I've been in the industry so maybe things have changed but last time I was there unit tests weren't even a thing. Smoke tests where if a set of levels loaded and didn't crash was considered success from an automation validation standpoint.
I think it is telling that in Unity world, 2 years is "Long Term". I wonder what cutting edge is? Building your entire game on the unstable weekly branch and crossing your fingers?
Not just unity unfortunately. .net core LTS is 3 years, Firefox "extended support" is 12 months, some random library from cargo/npm/nuget probably not at all. "Long Term" is becoming a meaningless buzzword.
Companies cling to 40 year old COBOL because there's nothing stable enough to migrate to.
Java has been one of the few that are more stable but I get the impression that's coming to an end. The support lifetime for the current LTS will finish 4 years earlier than Java 8 (according to wikipedia: https://en.wikipedia.org/wiki/Java_version_history) so it's trending down fast (although still good). It also looks that 2030 is only for people paying oracle, which isn't necessarily bad but it's something to consider.
There's also a lot more to consider than just how long an LTS lasts, like the degree of backwards compatibility and the rest of the ecosystem. It was my understanding that project jigsaw broke a lot of that, but I'm outside the java world so i didn't really keep up. .net for instance was great until recently because they had decent support lifetimes and kept backwards compatibility, so updating to the latest was at least simple and painless. Even trying to do those upgrades was like pulling teeth inside corporate environments though.
There's a difference between end-user software and software that you're going to produce things in.
2 years is a reasonable time to expect that the user will move on to the next LTS browser version. 2 years is not a lot of time to release a game without having to upgrade the engine mid-project.
That is the old model, the new LTS model is three years.
Oracle just extended it due to Java 9 being our Python 3, which is kind of pointless because all the packages that matter have migrated already.
But enterprise being enterprise, there are plenty of projects only now migrating to 8, and then there is that little robot that isn't even fully compliant with 8.
Not that I really know much about Java stuff, but it looks like maybe Amazon/OpenJDK are providing longer support lifetimes? [1]
And here's an official Oracle doc regarding Java support where they show Java 11 (LTS) being supported until either late 2023 or late 2026 depending on your support level. I'm not sure they provide free support anymore, or maybe that's limited and what you're referring to?
Java has several commercial and free implementations, so every Java vendor is free to choose their own timelines, I was only talking about the free layer of OpenJDK/Oracle, as that is what many around here understand as Java.
I'd add this the lack of a solid 3rd party developer ecosystem on their Asset Store. The fact that they don't have a subscription model for assets or any support for managing per-seat licenses is ridiculous and is the direct cause of multiple popular assets ending support. It doesn't make sense economically to sell any kind of service on their store.
Yet the support for it still sucks. I spent a few hours trying to set it up the other day and still couldn't get it working. (Unity developer of 6 years here). Maybe I just had one setting wrong.. but this shouldn't be that hard to anybody, and as rightly Garry points out its not necessarily a lack of documentation but the fact that the documentation is so out of date OR correct but only with one unique combination of versions from 2 years ago.
I found the 2nd & 3rd books of The Three Body Problem series to be much, much better than the 1st. IMO the 1st is just a bit of pretext for the real story of the series.
This could very well be talking about internal prototypes and internal goals for those prototypes, rather than a timeframe related to consumerizing it.
