[haydenlee]

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.

[cecilpl2]

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.

[pydave]

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.

[cecilpl2]

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.

[pjmlp]

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.

[vvanders]

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.

[seba_dos1]

Well, things haven't really changed...

[ReticentVole]

Just get to the LTS release and stay there.

[dahfizz]

The LTS is only supported for two years. That doesn't really solve this problem.

[santoshalper]

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?

[flukus]

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.

[jaredklewis]

Java 8 EOL is 2030. There are plenty of stable options that are not COBOL.

[flukus]

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.

[pjmlp]

Most software products LTS are between 2 to 3 years actually, even stuff like Java.

[anamexis]

There's how often LTS releases are released, and how long they are supported.

Ubuntu cuts an LTS release every 2 years, but they support them for 5 years.

It appears Oracle supports Java LTS releases for 8 years.

[pjmlp]

Java LTS model has changed for 3 years for releases past Java 9. We are on 14 already.

[seba_dos1]

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.

[yCombLinks]

Java SE 8 (LTS) March 2014 December 2030 Java may have a new LTS every few years, but they support their LTS releases for much longer.

[pjmlp]

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.