4 ms·

One of my on-boarding tasks at my first tech job was to evaluate the merits of upgrading to a newer version of unity. I installed the new version, imported our

One of my on-boarding tasks at my first tech job was to evaluate the merits of upgrading to a newer version of unity. I installed the new version, imported our code base, fixed a few bugs, and everything worked. We gained a few niceties, we could remove some of the hacks we had to program in to bypass unity weirdness, and we could start keeping our product up to date. I gave a presentation, we went over the pro/con list, and decided to move forward. It was awful. Every other programmers' attempts to upgrade failed, and each in a unique way. We had to pause releases to untangle everything. I felt terrible for derailing production my first week on the job, but after a dozen or so people took me aside to tell me some variation of "it's not you, its Unity" I learned a valuable lesson. You said it perfectly: the instability is not temporary.

haydenlee 6y ago
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.
- ReticentVole 6y ago
  Just get to the LTS release and stay there.
  - dahfizz 6y ago
    The LTS is only supported for two years. That doesn't really solve this problem.
    - santoshalper 6y ago
      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?
      - pjmlp 6y ago
        Most software products LTS are between 2 to 3 years actually, even stuff like Java.
        yCombLinks 6y ago
        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 6y ago
        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.
        kbenson 6y ago
        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? 1: https://en.wikipedia.org/wiki/Java_version_history https://en.wikipedia.org/wiki/Java_version_history 2: https://www.oracle.com/java/technologies/java-se-support-roadmap.html https://www.oracle.com/java/technologies/java-se-support-roa...
        pjmlp 6y ago
        Yes, free support is only three years. 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.
  - deleted 6y ago
    [deleted]
- vvanders 6y ago
  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 6y ago
    Well, things haven't really changed...
- pjmlp 6y ago
  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.
- cecilpl2 6y ago
  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 6y ago
    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 6y ago
      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.

haydenlee 6y ago

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.

ReticentVole 6y ago
Just get to the LTS release and stay there.
- dahfizz 6y ago
  The LTS is only supported for two years. That doesn't really solve this problem.
  - santoshalper 6y ago
    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?
    - pjmlp 6y ago
      Most software products LTS are between 2 to 3 years actually, even stuff like Java.
      - yCombLinks 6y ago
        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 6y ago
        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.
        kbenson 6y ago
        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? 1: https://en.wikipedia.org/wiki/Java_version_history https://en.wikipedia.org/wiki/Java_version_history 2: https://www.oracle.com/java/technologies/java-se-support-roadmap.html https://www.oracle.com/java/technologies/java-se-support-roa...
        pjmlp 6y ago
        Yes, free support is only three years. 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.
- deleted 6y ago
  [deleted]
vvanders 6y ago
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 6y ago
  Well, things haven't really changed...
pjmlp 6y ago
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.
cecilpl2 6y ago
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 6y ago
  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 6y ago
    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.