4 ms·

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 wa

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
    - vvanders 6y ago
      I feel like we're talking past each other a bit and maybe our experiences with external engines haven't matched up. I've seen whole platforms which were on the milestones in the contract delivered in an incomplete and unusable state. I've seen engine developers prioritize high profile internal titles over licensees including explicitly telling developers that their features will be de-prioritized until they ship. I've had to implement non-insignificant features(ex: LoD geometry streaming) because it wasn't a 'priority' to support open-ish world games. While internal engines shared across studios may not have the same level of polish they can align with what the teams need and roll out large breaking changes in an organized manner. Once you have 2-3 studios using an internal engine there's a critical mass that builds around it(assuming game types overlap to a degree). Like everything there's pros and cons, however if I were evaluating a external engine in 2020 anything beyond what's present today would be a nice bonus and not something I would plan around.

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
  - vvanders 6y ago
    I feel like we're talking past each other a bit and maybe our experiences with external engines haven't matched up. I've seen whole platforms which were on the milestones in the contract delivered in an incomplete and unusable state. I've seen engine developers prioritize high profile internal titles over licensees including explicitly telling developers that their features will be de-prioritized until they ship. I've had to implement non-insignificant features(ex: LoD geometry streaming) because it wasn't a 'priority' to support open-ish world games. While internal engines shared across studios may not have the same level of polish they can align with what the teams need and roll out large breaking changes in an organized manner. Once you have 2-3 studios using an internal engine there's a critical mass that builds around it(assuming game types overlap to a degree). Like everything there's pros and cons, however if I were evaluating a external engine in 2020 anything beyond what's present today would be a nice bonus and not something I would plan around.