6 ms·

I've heard horror stories of trying to develop a game and also maintain an up-to-date Unity install. AFAIK it's best to just live with whatever Unity version yo

I've heard horror stories of trying to develop a game and also maintain an up-to-date Unity install. AFAIK it's best to just live with whatever Unity version you've started your game in and be careful of upgrading point releases and avoid upgrading to any major release. Also, I think it's worth mentioning that if you care about the longevity of your game (like 10+ years into the future), depending on the Unity runtime being compatible with future OS versions is also a risk. Then again, the alternative requires some pretty hefty engineering chops and prior knowledge of a whole host of lower level concepts and APIs. EDIT: Also Heaps is the choice of Dead Cells dev and he's written about it some here: https://deepnight.net/tutorial/using-my-gamebase-to-create-a-heaps-game/ https://deepnight.net/tutorial/using-my-gamebase-to-create-a...

BoorishBears 6y ago
How is that any different than the average game engine? It's not that they make it impossible upgrade to a new major version, but yes it's not prudent to switch between major revisions of a game engine deep into development, that's not unique to Unity. Game engines don't have the JavaScript style churn where your library is dead if it doesn't do something major every month Unreal Engine 3 => 4 was 8 years? Unreal Engine 5 is going to launch next year, almost 7 years later Unity 4 => 5 was 5 years, and then Unity switched LTS releases which are getting updates for 3 or 4 years? - The improvements that come with major versions just don't make sense to try and pull in on a game deep in development either I mean look at this year's releases, a big focus has been the new render pipelines, but are you going to rip out your game's entire graphics stack mid development and redo every single shader and material? Unless you really have a good reason, probably not...
- vvanders 6y ago
  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...
- ratww 6y ago
  The problem is that Unity always has 2 or 3 ways of doing things for each feature, and the "proper" way that's actively maintained (and recommended by the community) is always the one that's still in Beta and missing features, so you're kinda cornered into updating. Of course you can not update, but then you might be relying on half-finished/half-broken features that could be fixed just by upgrading. Also, the whole upgrade process itself could be improved if they put time on it. There's nothing inherent to game engines that forces Unity to have so many breaking changes all the time.
  - BoorishBears 6y ago
    > The problem is that Unity always has 2 or 3 ways of doing things for each feature, and the "proper" way that's actively maintained (and recommended by the community) is always the one that's still in Beta and missing features, so you're kinda cornered into updating. First part of this sure, Unity likes to have different ways to do stuff and I do wish they'd focus more. The roadmap approach they're taking shows that they are committed to working on it, and I'd say they've done well tackling that. But the second part? About getting cornered into updating by new features, not buying that for a second. If the feature is done enough to use it in a game with a large scope trying to follow a real development schedule, it's not disappearing. If it's not, don't use it. LTS releases are getting 3+ years of updates, before that we were going 5+ years with the same unity version, so when you say "actively maintained" when you mean is they're not getting changed anymore. Which is a good thing. Unity 5, from 5 years ago, is still getting security updates. Where you get cornered is trying to pull in beta features into a game that has a hard schedule then getting screwed when the beta feature takes advantage of has breaking changes during a major release... which is kind of the point of a beta. Unity has a huge community with a wide range of expertise and scope in their projects, if you're just blindly following what people in the forum are talking about, you'll follow some people working on small projects with small lifecycles. Unity has never been for rug pulling, if something works well enough for your game today, it's going to work well enough tomorrow, they're not going to yank it just because it's not the new hotness. Even Unityscript ended up getting a smooth path into the sunset with a converter tool despite being used heavily in under 4% of projects (and being used exclusively by <1% at the time) - > Also, the whole upgrade process itself could be improved if they put time on it. There's nothing inherent to game engines that forces Unity to have so many breaking changes all the time. Again, where are these breaking features "all the time"? Unity 4 => 5 was half a decade? Now they have their date-based versioning, but LTS releases still get at least 3 years of support, and the next LTS is the next year, not the old 5+ year cadence, so you get an incremental upgrade path with 3 whole years of smoothing. Outside of major releases I've only ever seen a tiny handful of breaking changes per release, the majority of which where back when we were going 5 years between major revisions so they'd hold everyone's hand with a detailed guide and "pay once, cry once": https://docs.unity3d.com/Manual/UpgradeGuides.html https://docs.unity3d.com/Manual/UpgradeGuides.html Note how now only LTS versions need these... I mean, someone brought up Monogame here, apparently not aware that XDA 4 which it targets was a major breaking event from XDA 3. Game engines have breaking changes on major revisions. Software, often has breaking changes on major revisions. Don't build your software, on other software, hoping to blindly chase every major release painlessly, it's just not going to happen once you get to a certain level of complexity. These companies are not abandoning previous releases instantly, they still get maintained I could Ctrl+R Unity for Unreal in this comment and nothing would change, it just comes with being a swiss army knife of this sort
- cableshaft 6y ago
  Monogame isn't really an engine, more of a framework, but its API is so static that you can copy/paste 11-year-old code in XNA 4 Framework tutorials into your Monogame project and it will probably just work (shaders, storage, and a few other things are different). I did that just yesterday. (Monogame was initially created to match XNA 4 API). I didn't even try porting my 10 year old XNA game until a year and a half ago, and I was able to get it compiled and running with 90% functionality (again shaders and storage was broken) in just 24 hours. And they just had a major new release that, among other things, supports .Net Core, just two months ago, yet I'm still able to do this.
  - BoorishBears 6y ago
    Apples to oranges would be the understatement of the century here... Monogame is _literally_ an implementation of XNA 4: https://www.monogame.net/about/ https://www.monogame.net/about/ > MonoGame is an Open Source implementation of the Microsoft XNA 4 Framework. It's raison d'etre is to let you run stuff that ran on XNA 4 specifically, you could almost say it's psuedo-ABI is XNA 4. So while they've built on that... it shouldn't be surprising that yes, literally the one thing it was built to do, works. I mean it's to the point once upon a time XNA's API reference was MonoGame's documentation and to this day they match, even if it takes harming the soundness of the API: https://gamedev.stackexchange.com/questions/67040/where-is-monogames-api-reference https://gamedev.stackexchange.com/questions/67040/where-is-m... https://github.com/MonoGame/MonoGame/issues/5487 https://github.com/MonoGame/MonoGame/issues/5487 - Also you realize XNA broke stuff on it's major releases too right? It's actually kind of ironic and funny you'd bring up XNA 4, because it REALLY broke stuff: https://www.shawnhargreaves.com/blog/breaking-changes-in-xna-game-studio-4-0.html https://www.shawnhargreaves.com/blog/breaking-changes-in-xna... Literally the words of a Microsoft dev lead at the time: > I was relieved when the comments on my earlier post about backward compatibility agreed with the approach we chose for XNA Game Studio 4.0. Banjobeni summed up the general sentiment: > "If you break it, break it good." - But also, and I mean you allude to this right there in the first sentence, it doesn't have half the surface area Unity has, it'd be like pointing out SDL's API staying stable? Even if you look at something that isn't Monogame I'm sure you'll find some frameworks that have had static APIs for decades, after all, if your layer of abstraction is high enough while your scope is small enough, DrawPixel 0,0 is still probably going to end up drawing a pixel somewhere just like "forward 50" is going to "move the turtle forward 50"... But then to that point, the basic APIs like that in Unity haven't been completely ripped out or something, they're still there in the same way they were. I googled "how to jump unity" with older than 2007 and this code still works 7 years later: https://answers.unity.com/questions/30127/how-can-i-make-my-character-jump.html https://answers.unity.com/questions/30127/how-can-i-make-my-... Sure Unity added a new Input system, but they don't force it on you, it's not even enabled in new projects by default (probably so you can cut and paste 13 year old code and have it work) Even Unityscript, the most glaring removal since Unity 1, has an official conversion tool, and deprecation wasn't even started until heavy usage had dropped to under 4%. I actually find it a great example of how to deprecate software gracefully. They waited for usage to fall off, they had excellent reasons to drop it, and they bent over backwards to make it painless. If you're just doing basic stuff like moving CharacterControllers around and stuff decade old code still works in Unity. Most basic tutorials from back in the day still work. What broke was fancy shaders that were written back when graphics models we use today weren't even an academic concern... and like you pointed out, that's stuff that breaks as time moves on because it's just not high-level enough to be easy to have work in a backwards compatible manner

BoorishBears 6y ago

How is that any different than the average game engine? It's not that they make it impossible upgrade to a new major version, but yes it's not prudent to switch between major revisions of a game engine deep into development, that's not unique to Unity. Game engines don't have the JavaScript style churn where your library is dead if it doesn't do something major every month Unreal Engine 3 => 4 was 8 years? Unreal Engine 5 is going to launch next year, almost 7 years later Unity 4 => 5 was 5 years, and then Unity switched LTS releases which are getting updates for 3 or 4 years? - The improvements that come with major versions just don't make sense to try and pull in on a game deep in development either I mean look at this year's releases, a big focus has been the new render pipelines, but are you going to rip out your game's entire graphics stack mid development and redo every single shader and material? Unless you really have a good reason, probably not...

vvanders 6y ago
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...
ratww 6y ago
The problem is that Unity always has 2 or 3 ways of doing things for each feature, and the "proper" way that's actively maintained (and recommended by the community) is always the one that's still in Beta and missing features, so you're kinda cornered into updating. Of course you can not update, but then you might be relying on half-finished/half-broken features that could be fixed just by upgrading. Also, the whole upgrade process itself could be improved if they put time on it. There's nothing inherent to game engines that forces Unity to have so many breaking changes all the time.
- BoorishBears 6y ago
  > The problem is that Unity always has 2 or 3 ways of doing things for each feature, and the "proper" way that's actively maintained (and recommended by the community) is always the one that's still in Beta and missing features, so you're kinda cornered into updating. First part of this sure, Unity likes to have different ways to do stuff and I do wish they'd focus more. The roadmap approach they're taking shows that they are committed to working on it, and I'd say they've done well tackling that. But the second part? About getting cornered into updating by new features, not buying that for a second. If the feature is done enough to use it in a game with a large scope trying to follow a real development schedule, it's not disappearing. If it's not, don't use it. LTS releases are getting 3+ years of updates, before that we were going 5+ years with the same unity version, so when you say "actively maintained" when you mean is they're not getting changed anymore. Which is a good thing. Unity 5, from 5 years ago, is still getting security updates. Where you get cornered is trying to pull in beta features into a game that has a hard schedule then getting screwed when the beta feature takes advantage of has breaking changes during a major release... which is kind of the point of a beta. Unity has a huge community with a wide range of expertise and scope in their projects, if you're just blindly following what people in the forum are talking about, you'll follow some people working on small projects with small lifecycles. Unity has never been for rug pulling, if something works well enough for your game today, it's going to work well enough tomorrow, they're not going to yank it just because it's not the new hotness. Even Unityscript ended up getting a smooth path into the sunset with a converter tool despite being used heavily in under 4% of projects (and being used exclusively by <1% at the time) - > Also, the whole upgrade process itself could be improved if they put time on it. There's nothing inherent to game engines that forces Unity to have so many breaking changes all the time. Again, where are these breaking features "all the time"? Unity 4 => 5 was half a decade? Now they have their date-based versioning, but LTS releases still get at least 3 years of support, and the next LTS is the next year, not the old 5+ year cadence, so you get an incremental upgrade path with 3 whole years of smoothing. Outside of major releases I've only ever seen a tiny handful of breaking changes per release, the majority of which where back when we were going 5 years between major revisions so they'd hold everyone's hand with a detailed guide and "pay once, cry once": https://docs.unity3d.com/Manual/UpgradeGuides.html https://docs.unity3d.com/Manual/UpgradeGuides.html Note how now only LTS versions need these... I mean, someone brought up Monogame here, apparently not aware that XDA 4 which it targets was a major breaking event from XDA 3. Game engines have breaking changes on major revisions. Software, often has breaking changes on major revisions. Don't build your software, on other software, hoping to blindly chase every major release painlessly, it's just not going to happen once you get to a certain level of complexity. These companies are not abandoning previous releases instantly, they still get maintained I could Ctrl+R Unity for Unreal in this comment and nothing would change, it just comes with being a swiss army knife of this sort
cableshaft 6y ago
Monogame isn't really an engine, more of a framework, but its API is so static that you can copy/paste 11-year-old code in XNA 4 Framework tutorials into your Monogame project and it will probably just work (shaders, storage, and a few other things are different). I did that just yesterday. (Monogame was initially created to match XNA 4 API). I didn't even try porting my 10 year old XNA game until a year and a half ago, and I was able to get it compiled and running with 90% functionality (again shaders and storage was broken) in just 24 hours. And they just had a major new release that, among other things, supports .Net Core, just two months ago, yet I'm still able to do this.
- BoorishBears 6y ago
  Apples to oranges would be the understatement of the century here... Monogame is _literally_ an implementation of XNA 4: https://www.monogame.net/about/ https://www.monogame.net/about/ > MonoGame is an Open Source implementation of the Microsoft XNA 4 Framework. It's raison d'etre is to let you run stuff that ran on XNA 4 specifically, you could almost say it's psuedo-ABI is XNA 4. So while they've built on that... it shouldn't be surprising that yes, literally the one thing it was built to do, works. I mean it's to the point once upon a time XNA's API reference was MonoGame's documentation and to this day they match, even if it takes harming the soundness of the API: https://gamedev.stackexchange.com/questions/67040/where-is-monogames-api-reference https://gamedev.stackexchange.com/questions/67040/where-is-m... https://github.com/MonoGame/MonoGame/issues/5487 https://github.com/MonoGame/MonoGame/issues/5487 - Also you realize XNA broke stuff on it's major releases too right? It's actually kind of ironic and funny you'd bring up XNA 4, because it REALLY broke stuff: https://www.shawnhargreaves.com/blog/breaking-changes-in-xna-game-studio-4-0.html https://www.shawnhargreaves.com/blog/breaking-changes-in-xna... Literally the words of a Microsoft dev lead at the time: > I was relieved when the comments on my earlier post about backward compatibility agreed with the approach we chose for XNA Game Studio 4.0. Banjobeni summed up the general sentiment: > "If you break it, break it good." - But also, and I mean you allude to this right there in the first sentence, it doesn't have half the surface area Unity has, it'd be like pointing out SDL's API staying stable? Even if you look at something that isn't Monogame I'm sure you'll find some frameworks that have had static APIs for decades, after all, if your layer of abstraction is high enough while your scope is small enough, DrawPixel 0,0 is still probably going to end up drawing a pixel somewhere just like "forward 50" is going to "move the turtle forward 50"... But then to that point, the basic APIs like that in Unity haven't been completely ripped out or something, they're still there in the same way they were. I googled "how to jump unity" with older than 2007 and this code still works 7 years later: https://answers.unity.com/questions/30127/how-can-i-make-my-character-jump.html https://answers.unity.com/questions/30127/how-can-i-make-my-... Sure Unity added a new Input system, but they don't force it on you, it's not even enabled in new projects by default (probably so you can cut and paste 13 year old code and have it work) Even Unityscript, the most glaring removal since Unity 1, has an official conversion tool, and deprecation wasn't even started until heavy usage had dropped to under 4%. I actually find it a great example of how to deprecate software gracefully. They waited for usage to fall off, they had excellent reasons to drop it, and they bent over backwards to make it painless. If you're just doing basic stuff like moving CharacterControllers around and stuff decade old code still works in Unity. Most basic tutorials from back in the day still work. What broke was fancy shaders that were written back when graphics models we use today weren't even an academic concern... and like you pointed out, that's stuff that breaks as time moves on because it's just not high-level enough to be easy to have work in a backwards compatible manner