3 ms·

It depend on if those features coming with major versions include one of the platforms you intend to ship on... You can pull new versions while under developme

It depend on if those features coming with major versions include one of the platforms you intend to ship on... You can pull new versions while under development. I've been on a team that did it and it was not fun. Usually involved some poor soul pulling the short straw, spending ~6 weeks 3-way merging followed by a large uplevel commit that breaks everything. This follows ~4 weeks of bugfixing at which point you start the process again since a new major version was just released.

BoorishBears 6y ago
I don't see how this is at odds with anything I said, you're pulling in an entire platform into a game mid development cycle? That's going to hurt. But can you imagine the nightmare if you weren't standing on the shoulders of Unity and trying to do it in your own custom engine? Especially on console? Unity is probably getting hardware before 99% of devs on some platforms, and they have resources that dwarf most dev teams when it comes to shaking out issues. It'd 10000x the nightmare to go it alone... Like I said, it's not just Unity, and it's not like the game engines are even doing anything particularly brutal, they just treat major version releases with the weight they really ought to carry. You can upgrade, you just better have a damn good reason, and if you don't have good testing procedure you're going to suffer twice as much. - And honestly some of the pain is just out of their hands I remember Wii U development was tied to a specific major release of Unity when N+1 came out due to their custom integrations. But Nintendo didn't track that update, and gave no time frame for doing so for a hot minute. Unity 5 just ended up shipping out of beta with no Wii U support I don't know what a game planning on requiring Unity N+1 to ship would have done there, but I'm sure similar dependencies exist internally on other platforms that Unity has to manage. They've essentially got multiple engines that all need to be landing changes together in sync, I don't know why people are surprised that such an insane technical challenge requires you to treat major versions with some real weight...
- vvanders 6y ago
  Honestly I've done both on multi-platform engines and the huge advantage of the in-house engine is you can line up the releases and breaking api changes in a way that works with the internal teams vs throwing it over the fence. Last in-house game I did we had to bring a while networking layer online for a platform that didn't previously have it and that part was a pretty painless process.
  - BoorishBears 6y ago
    That advantage doesn't magic away the fact someone is still has to add support for the platform... if it's not Unity, and it's not you personally, it doesn't mean some other team isn't doing it. I mean to put it very simply, do you think that adding support for a platform with hardware that was probably pretty new since Unity does tend to be ready near launch for major consoles... was more work or less work than your 10 weeks of merging stuff then bug fixing? You could spend 10 weeks on a new hardware platform just getting to a working engine just because of toolchain teething problems... and I bet someone at Unity definitely did to get you to the point where all your biggest worry was testing and merge conflicts Also this comment in your original post: > at which point you start the process again since a new major version was just released. Surely you're not trying to imply Unity... which went half a decade between releases for a while, then switched to LTS releases with 3 years of support minimum... is forcing you to upgrade every 10 weeks...
    - vvanders 6y ago
      You might be assuming too much, I never said Unity at any point. The larger point I was trying to make is that an internal team is aligned with your goals and can support you. And external engine is tied to their own goals that might not align with your schedule/platform/feature set/etc. No one wants to be going through a contract dispute in the middle of development as it's a sure fire way to sink your title. Anyway, it's just a long way to say that when you do your due diligence on an external engine, is to only look at what you see now and not what's on the roadmap.
      - BoorishBears 6y ago
        Yeah I guess I assumed the replies to my comment were on topic to a thread about Unity on a post about Unity... Due diligence on an external engine is planning ahead instead of acting like a deer in headlights when a new release comes breaking changes, because that's what you should expect. That's what my comments have said thus far, nothing more nothing less. People are acting like it's a problem specific to one engine that yes... an external engine is not marching to your personal timeline and will have breaking changes on major releases so you need to adjust your own schedule to theirs... If you did your due diligence the cost of having to conform to their schedule should lower than the value that they provide is. Otherwise you shouldn't have used the engine. Honestly it's surprising I've had to spend this many comments explaining that... that's kind if the basic math before you should even use a game engine

BoorishBears 6y ago

I don't see how this is at odds with anything I said, you're pulling in an entire platform into a game mid development cycle? That's going to hurt. But can you imagine the nightmare if you weren't standing on the shoulders of Unity and trying to do it in your own custom engine? Especially on console? Unity is probably getting hardware before 99% of devs on some platforms, and they have resources that dwarf most dev teams when it comes to shaking out issues. It'd 10000x the nightmare to go it alone... Like I said, it's not just Unity, and it's not like the game engines are even doing anything particularly brutal, they just treat major version releases with the weight they really ought to carry. You can upgrade, you just better have a damn good reason, and if you don't have good testing procedure you're going to suffer twice as much. - And honestly some of the pain is just out of their hands I remember Wii U development was tied to a specific major release of Unity when N+1 came out due to their custom integrations. But Nintendo didn't track that update, and gave no time frame for doing so for a hot minute. Unity 5 just ended up shipping out of beta with no Wii U support I don't know what a game planning on requiring Unity N+1 to ship would have done there, but I'm sure similar dependencies exist internally on other platforms that Unity has to manage. They've essentially got multiple engines that all need to be landing changes together in sync, I don't know why people are surprised that such an insane technical challenge requires you to treat major versions with some real weight...

vvanders 6y ago
Honestly I've done both on multi-platform engines and the huge advantage of the in-house engine is you can line up the releases and breaking api changes in a way that works with the internal teams vs throwing it over the fence. Last in-house game I did we had to bring a while networking layer online for a platform that didn't previously have it and that part was a pretty painless process.
- BoorishBears 6y ago
  That advantage doesn't magic away the fact someone is still has to add support for the platform... if it's not Unity, and it's not you personally, it doesn't mean some other team isn't doing it. I mean to put it very simply, do you think that adding support for a platform with hardware that was probably pretty new since Unity does tend to be ready near launch for major consoles... was more work or less work than your 10 weeks of merging stuff then bug fixing? You could spend 10 weeks on a new hardware platform just getting to a working engine just because of toolchain teething problems... and I bet someone at Unity definitely did to get you to the point where all your biggest worry was testing and merge conflicts Also this comment in your original post: > at which point you start the process again since a new major version was just released. Surely you're not trying to imply Unity... which went half a decade between releases for a while, then switched to LTS releases with 3 years of support minimum... is forcing you to upgrade every 10 weeks...
  - vvanders 6y ago
    You might be assuming too much, I never said Unity at any point. The larger point I was trying to make is that an internal team is aligned with your goals and can support you. And external engine is tied to their own goals that might not align with your schedule/platform/feature set/etc. No one wants to be going through a contract dispute in the middle of development as it's a sure fire way to sink your title. Anyway, it's just a long way to say that when you do your due diligence on an external engine, is to only look at what you see now and not what's on the roadmap.
    - BoorishBears 6y ago
      Yeah I guess I assumed the replies to my comment were on topic to a thread about Unity on a post about Unity... Due diligence on an external engine is planning ahead instead of acting like a deer in headlights when a new release comes breaking changes, because that's what you should expect. That's what my comments have said thus far, nothing more nothing less. People are acting like it's a problem specific to one engine that yes... an external engine is not marching to your personal timeline and will have breaking changes on major releases so you need to adjust your own schedule to theirs... If you did your due diligence the cost of having to conform to their schedule should lower than the value that they provide is. Otherwise you shouldn't have used the engine. Honestly it's surprising I've had to spend this many comments explaining that... that's kind if the basic math before you should even use a game engine