3 ms·

There's not a lot of churn in Unity, but that's more because they mostly fail to ship anything of significance than due to excellence in backwards compatibility

There's not a lot of churn in Unity, but that's more because they mostly fail to ship anything of significance than due to excellence in backwards compatibility. I was in the audience when DOTS was announced, and a decade later Cities Skylines II showed how ill equipped for prime time it remains (not that the developers were blameless).

stingraycharles 6mo ago
Cities Skylines II is such an immense resource hog compared to what it actually does.
KronisLV 6mo ago
> There's not a lot of churn in Unity Deprecating entire languages (probably the right call long term, oddly enough Godot is keeping GDScript around). Render pipelines (URP and HDRP to be merged, built in likewise being deprecated). Most of the things around DOTS. Most of the things around networking. The whole package management system (I mean, it’s a nice idea, still counts as churn). Also multiple approaches to UI and input. I would say that a lot of the new stuff is built on good ideas but I sometimes wish they’d slow down a bit and ship actually thought out and finished features. And most of the above already had alternatives previously, this isn’t even getting into wholly new things like Sentis, if you are working on an old project thankfully it will mostly keep working, but if you need to keep up to date with the current mechanisms and practices, there’s a lot of churn. Maybe not as much as in Godot, but to be honest that other engine is going through a lot of evolution so instability and a feature explosion is to be expected (despite terrain still being a plugin, while Unity’s own terrain implementation is oddly dated and abandoned, while their water system felt like a tech demo and more often than not the asset store is expected to do the heavy lifting), while Unity tries to appeal to everyone and capture headlines it seems. Just look at the marketing around DOTS (and how long it took for it to be usable).
- ndepoel 6mo ago
  A lot of the things you mention there have been in development for the better part of 10 years already, and still haven't reach a stable, mature and production-ready state yet. Unity have also kept deprecated stuff around for much longer than they should have, which sounds great on paper for backward compatibility, but it just means they're lugging years of technical debt with them and it's slowed them down immensely. Looking at the past year of Unity updates, since 6.1 or so, it seems that most of the focus is now going to refactoring major parts of the engine to facilitate backporting HDRP's feature set to URP. It's all good work and high time they did some cleanup and committed to a single standardized render pipeline, but it's not exactly moving the needle forward very much yet.
- Macha 6mo ago
  > (probably the right call long term, oddly enough Godot is keeping GDScript around). Even in Unity 4, it was like "You can write scripts in C#, or you can also write them in Unityscript or Boo, I suppose..." In comparison for Godot, GDScript is very often the happy path. Things like web publishing work more seamlessly with GDScript than with C# (and miles more than GDNative/GDExtension). So I don't think it's nearly as likely to get deprecated as Unity's scripting languages.
- sph 6mo ago
  GDScript is great, what do you mean? And I am a language snob that would be quite happy writing games in Lisp rather than Python-likes.
  - deleted 6mo ago
    [deleted]
  - KronisLV 6mo ago
    > GDScript is great, what do you mean? They do have a pretty nice page talking a bit more about GDScript: https://docs.godotengine.org/en/stable/about/faq.html#what-is-gdscript-and-why-should-i-use-it https://docs.godotengine.org/en/stable/about/faq.html#what-i... The obvious additional good from this approach is that you no longer couple everything so tightly with just one scripting language, so in some ways it's a bit easier to introduce bindings for other languages. The downside, however, is that it leads to fragmentation in the community, duplication of effort (suddenly you need the double amount of docs), more difficulty and friction in development with new mechanisms demanding that you take the limitations of both languages in mind, oh and if you dare to write your own language then suddenly you have to support both it, as well as any dev tools for it. For what was and still is a communtiy project without strong financial backing (just look at how much money Unity burns on useless stuff, and how much more the people behind Godot could do with that money), that's quite the gamble. Maybe if they focused on the core engine more, then deltaV: Rings of Saturn wouldn't have odd performance issues for a 2D game and wouldn't get confused with multi-monitor setups. Maybe Road To Vostok wouldn't crash when loading into the Village map on an Intel Arc GPU, and also start on the wrong monitor same as deltaV. Maybe even demos like "Realistic Jungle Demo" on itch.io wouldn't have all white textures on said Intel Arc GPU. Maybe we'd be two or three whole releases of features ahead by now, if all of the hours spent on GDScript to date would have been spent elsewhere. On the other hand, there's no guarantee that any of those devs would fix the other issues if their efforts were to be redirected. Similarly, if they didn't try with GDScript, the community would be smaller, due to its ease of prototyping, and being simpler and more approachable for the folks who don't know C# yet, even if it's also unnecessary to the folks who like tools like Rider/Visual Studio or are coming from Unity or engines with scripting in C# or just C++. I'm pretty split on it overall.
- raincole 6mo ago
  > oddly enough Godot is keeping GDScript around Godot community is practically all GDScript. If they removed GDScript it'd be more akin to Unity removing C# while keeping Boo.

stingraycharles 6mo ago

Cities Skylines II is such an immense resource hog compared to what it actually does.

KronisLV 6mo ago

> There's not a lot of churn in Unity Deprecating entire languages (probably the right call long term, oddly enough Godot is keeping GDScript around). Render pipelines (URP and HDRP to be merged, built in likewise being deprecated). Most of the things around DOTS. Most of the things around networking. The whole package management system (I mean, it’s a nice idea, still counts as churn). Also multiple approaches to UI and input. I would say that a lot of the new stuff is built on good ideas but I sometimes wish they’d slow down a bit and ship actually thought out and finished features. And most of the above already had alternatives previously, this isn’t even getting into wholly new things like Sentis, if you are working on an old project thankfully it will mostly keep working, but if you need to keep up to date with the current mechanisms and practices, there’s a lot of churn. Maybe not as much as in Godot, but to be honest that other engine is going through a lot of evolution so instability and a feature explosion is to be expected (despite terrain still being a plugin, while Unity’s own terrain implementation is oddly dated and abandoned, while their water system felt like a tech demo and more often than not the asset store is expected to do the heavy lifting), while Unity tries to appeal to everyone and capture headlines it seems. Just look at the marketing around DOTS (and how long it took for it to be usable).

ndepoel 6mo ago
A lot of the things you mention there have been in development for the better part of 10 years already, and still haven't reach a stable, mature and production-ready state yet. Unity have also kept deprecated stuff around for much longer than they should have, which sounds great on paper for backward compatibility, but it just means they're lugging years of technical debt with them and it's slowed them down immensely. Looking at the past year of Unity updates, since 6.1 or so, it seems that most of the focus is now going to refactoring major parts of the engine to facilitate backporting HDRP's feature set to URP. It's all good work and high time they did some cleanup and committed to a single standardized render pipeline, but it's not exactly moving the needle forward very much yet.
Macha 6mo ago
> (probably the right call long term, oddly enough Godot is keeping GDScript around). Even in Unity 4, it was like "You can write scripts in C#, or you can also write them in Unityscript or Boo, I suppose..." In comparison for Godot, GDScript is very often the happy path. Things like web publishing work more seamlessly with GDScript than with C# (and miles more than GDNative/GDExtension). So I don't think it's nearly as likely to get deprecated as Unity's scripting languages.
sph 6mo ago
GDScript is great, what do you mean? And I am a language snob that would be quite happy writing games in Lisp rather than Python-likes.
- deleted 6mo ago
  [deleted]
- KronisLV 6mo ago
  > GDScript is great, what do you mean? They do have a pretty nice page talking a bit more about GDScript: https://docs.godotengine.org/en/stable/about/faq.html#what-is-gdscript-and-why-should-i-use-it https://docs.godotengine.org/en/stable/about/faq.html#what-i... The obvious additional good from this approach is that you no longer couple everything so tightly with just one scripting language, so in some ways it's a bit easier to introduce bindings for other languages. The downside, however, is that it leads to fragmentation in the community, duplication of effort (suddenly you need the double amount of docs), more difficulty and friction in development with new mechanisms demanding that you take the limitations of both languages in mind, oh and if you dare to write your own language then suddenly you have to support both it, as well as any dev tools for it. For what was and still is a communtiy project without strong financial backing (just look at how much money Unity burns on useless stuff, and how much more the people behind Godot could do with that money), that's quite the gamble. Maybe if they focused on the core engine more, then deltaV: Rings of Saturn wouldn't have odd performance issues for a 2D game and wouldn't get confused with multi-monitor setups. Maybe Road To Vostok wouldn't crash when loading into the Village map on an Intel Arc GPU, and also start on the wrong monitor same as deltaV. Maybe even demos like "Realistic Jungle Demo" on itch.io wouldn't have all white textures on said Intel Arc GPU. Maybe we'd be two or three whole releases of features ahead by now, if all of the hours spent on GDScript to date would have been spent elsewhere. On the other hand, there's no guarantee that any of those devs would fix the other issues if their efforts were to be redirected. Similarly, if they didn't try with GDScript, the community would be smaller, due to its ease of prototyping, and being simpler and more approachable for the folks who don't know C# yet, even if it's also unnecessary to the folks who like tools like Rider/Visual Studio or are coming from Unity or engines with scripting in C# or just C++. I'm pretty split on it overall.
raincole 6mo ago
> oddly enough Godot is keeping GDScript around Godot community is practically all GDScript. If they removed GDScript it'd be more akin to Unity removing C# while keeping Boo.