4 ms·

As a .NET programmer who is new to the gaming space, I find the promises of Unity’s new Data Oriented Tech Stack and the future of .NET (5.0) perhaps too compel

As a .NET programmer who is new to the gaming space, I find the promises of Unity’s new Data Oriented Tech Stack and the future of .NET (5.0) perhaps too compelling to consider anything that isn’t officially supported. That future just sounds too good to me as a back end .NET dev getting into gaming. I think, too, as a beginner the dead simplicity of Unity’s old game object system is very compelling for getting started if you’re brand new to development. I haven’t spent any time with UE4 though so I can’t compare.

wokwokwok 6y ago
> I find the promises of Unity’s new Data Oriented Tech Stack ... unfortunately, DOTS is a) a dumpster fire and b) not going to hit 1.0 in 2020, or I guess, 2021 at this point. The totally broken and unstable API and utter inability of the team to use their own package manager has left me with zero confidence in their ability to deliver a meaningful product with DOTS. ...but hey, .Net 5 will be great (of course, don't hold your breath for that either, "It is very unlikely that any .NET Core or .NET 5 support will land in 2020 LTS." https://forum.unity.com/threads/net-5-support.839890/ https://forum.unity.com/threads/net-5-support.839890/), but I agree it'll be great when it does!
- jayd16 6y ago
  The good news is they don't seem to be forcing everyone into a buggy paradigm. You can still use C# 7 and the monobehavior stack at least. ECS is overrated anyway. Just skip the hype, let it bake and ship games.
istorical 6y ago
the real danger of Unity currently is that they seem to start a lot of things but not finish them. don't necessarily hitch your wagon to the idea that any particular thing they do will ever completely manifest itself or be feature complete.
cpeterso 6y ago
I haven't used Unity, but from what I've read, Unity has a reputation for promising shiny new APIs and then neglecting/deprecating the old API before the new one is production-ready. This blog post describes some examples: URP or HDRP Render Pipeline, current UI system vs new UIElements, current UNet multiplayer support vs new system that will require integration with DOTS, ... https://garry.tv/unity-2020 https://garry.tv/unity-2020
- chrisdirkis 6y ago
  I don't disagree with everything in the linked post, but some of the commentary is just "make it better", which really feels like it needs more nuance. Render pipelines: URP and HDRP are the two Unity-supplied render pipelines, but they're part of a broader Scriptable Render Pipeline project, which allows Unity or other devs to write render pipelines that interface with the engine in ways that non-core code couldn't previously. The "Standard"/old render pipeline is the default now because most assets are built on it, but iirc either soon or now you'll get the option to select the render pipeline when making a project. "Just make swapping free/nondestructive" isn't really a solution for swapping between arbitrary render pipelines, and not even necessarily a solution for swapping between the two Unity supplied ones. UI: Mostly agree. The layout systems should be better, the masking should be better, the fonts should have been improved in the background as well as buying TMP. Hopefully UIElements is a good solution. Tried to write a React style renderer for UIElements once, but was stymied by the lack of duck typing in C# (without dynamic, anyway). Multiplayer: Totally a mess. Demos: Agree that there's often too much reliance on beta features or engine customisations. The SRP approach mentioned above alleviates some of that. Disagree with "don't make rendered videos out of Unity", I work in ArchViz and it's definitely a direction we're pursuing, due to cost and ease of iteration. There's a very cool DOTS/networking example that Unity has been using internally in Unite talks, and I'm waiting for that to come to stable, because it has a really cool editor interaction story for DOTS, networking, remote devices, etc. DOTS: Lots of the iteration appears to be addressing the author's last point, making the fast solution the simple solution. Transitioning to DOTS with a cleaner API should also help future backwards compatibility, which is a pain point the author identified earlier. Unity's current C# APIs are limited from changing in many ways due to an attempt at backwards compatibility, but a clean break allows you to have better architecture from the start. I guess the TLDR is that I actually do agree with the author in many ways, though I think they're also being unnecessarily harsh and acerbic in places. Lots of things are in a transitionary state, and have been for the past two years, and that's frustrating as a professional working in Unity. That said, if you're building a game using the capabilities and systems in place now, those won't fall out from under you unless you choose to try follow an upgrade path.
stevens32 6y ago
Net 5 looks great, but it's unlikely to land in Unity any time soon. Unity runs on its own fork of mono, and if you're trying to build for mobile you'll need to use the il2cpp backend. Official support is for some versions of C#, not all of dotnet (eg, F# and VB are not supported). I haven't played with it yet, but I think Stride3d is an open source engine that's actually built on dotnet - I'd expect newer versions would land earlier and wider language support.
- ntSean 6y ago
  The IL2CPP backend removes the need for the mono fork and is available in all modern compile targets. The Rosyln compiler also ensures unity's c# is quite modern and features such as C# 8 are on their way! Tangentially, you can use C# 8 now, or even F# or VB in Unity if you choose to first compile them as a DLLs.
  - stevens32 6y ago
    I do use F# as compiled dlls, but like I said it is not supported. Only C# compiled IL is officially supported with il2cpp, and issues related to other languages are liable to be closed as won't fix. There also is no good NuGet story for Unity, which may catch a dotnet dev off guard. On one hand, a lot of things work surprisingly well. On the other, if you're going into it thinking you're going to get the same dotnet development experience in Unity - that's not the experience I've had.
moron4hire 6y ago
As a long-time .NET developer (since it was invented), getting into Unity (have been doing it professionally, full-time for the last 4 years) was a huge exercise in pain and suffering. They have their own ideas on how projects and their dependencies should be organized that don't align with the rest of the .NET ecosystem and, quite frankly, it's maddening. It took me probably two solid years before I was making things in Unity that were any "good" (not dropping frames because of stupid stuff that Unity does like decoding textures on the render thread, not taking forever to load on startup, being able to cross-compile to different VR and AR systems without making massive changes to the application, etc.). After the third year, I had written workarounds for so many of Unity's built in stuff that I wish I had just started with my own game framework and skipped Unity completely. Well, I guess that's not entirely true. I wouldn't have gotten my first well-paying, fulltime job VR without Unity. But from just a technology standpoint, it's been a major impediment.

wokwokwok 6y ago

> I find the promises of Unity’s new Data Oriented Tech Stack ... unfortunately, DOTS is a) a dumpster fire and b) not going to hit 1.0 in 2020, or I guess, 2021 at this point. The totally broken and unstable API and utter inability of the team to use their own package manager has left me with zero confidence in their ability to deliver a meaningful product with DOTS. ...but hey, .Net 5 will be great (of course, don't hold your breath for that either, "It is very unlikely that any .NET Core or .NET 5 support will land in 2020 LTS." https://forum.unity.com/threads/net-5-support.839890/ https://forum.unity.com/threads/net-5-support.839890/), but I agree it'll be great when it does!

jayd16 6y ago
The good news is they don't seem to be forcing everyone into a buggy paradigm. You can still use C# 7 and the monobehavior stack at least. ECS is overrated anyway. Just skip the hype, let it bake and ship games.

istorical 6y ago

the real danger of Unity currently is that they seem to start a lot of things but not finish them. don't necessarily hitch your wagon to the idea that any particular thing they do will ever completely manifest itself or be feature complete.

cpeterso 6y ago

I haven't used Unity, but from what I've read, Unity has a reputation for promising shiny new APIs and then neglecting/deprecating the old API before the new one is production-ready. This blog post describes some examples: URP or HDRP Render Pipeline, current UI system vs new UIElements, current UNet multiplayer support vs new system that will require integration with DOTS, ... https://garry.tv/unity-2020 https://garry.tv/unity-2020

chrisdirkis 6y ago
I don't disagree with everything in the linked post, but some of the commentary is just "make it better", which really feels like it needs more nuance. Render pipelines: URP and HDRP are the two Unity-supplied render pipelines, but they're part of a broader Scriptable Render Pipeline project, which allows Unity or other devs to write render pipelines that interface with the engine in ways that non-core code couldn't previously. The "Standard"/old render pipeline is the default now because most assets are built on it, but iirc either soon or now you'll get the option to select the render pipeline when making a project. "Just make swapping free/nondestructive" isn't really a solution for swapping between arbitrary render pipelines, and not even necessarily a solution for swapping between the two Unity supplied ones. UI: Mostly agree. The layout systems should be better, the masking should be better, the fonts should have been improved in the background as well as buying TMP. Hopefully UIElements is a good solution. Tried to write a React style renderer for UIElements once, but was stymied by the lack of duck typing in C# (without dynamic, anyway). Multiplayer: Totally a mess. Demos: Agree that there's often too much reliance on beta features or engine customisations. The SRP approach mentioned above alleviates some of that. Disagree with "don't make rendered videos out of Unity", I work in ArchViz and it's definitely a direction we're pursuing, due to cost and ease of iteration. There's a very cool DOTS/networking example that Unity has been using internally in Unite talks, and I'm waiting for that to come to stable, because it has a really cool editor interaction story for DOTS, networking, remote devices, etc. DOTS: Lots of the iteration appears to be addressing the author's last point, making the fast solution the simple solution. Transitioning to DOTS with a cleaner API should also help future backwards compatibility, which is a pain point the author identified earlier. Unity's current C# APIs are limited from changing in many ways due to an attempt at backwards compatibility, but a clean break allows you to have better architecture from the start. I guess the TLDR is that I actually do agree with the author in many ways, though I think they're also being unnecessarily harsh and acerbic in places. Lots of things are in a transitionary state, and have been for the past two years, and that's frustrating as a professional working in Unity. That said, if you're building a game using the capabilities and systems in place now, those won't fall out from under you unless you choose to try follow an upgrade path.

stevens32 6y ago

Net 5 looks great, but it's unlikely to land in Unity any time soon. Unity runs on its own fork of mono, and if you're trying to build for mobile you'll need to use the il2cpp backend. Official support is for some versions of C#, not all of dotnet (eg, F# and VB are not supported). I haven't played with it yet, but I think Stride3d is an open source engine that's actually built on dotnet - I'd expect newer versions would land earlier and wider language support.

ntSean 6y ago
The IL2CPP backend removes the need for the mono fork and is available in all modern compile targets. The Rosyln compiler also ensures unity's c# is quite modern and features such as C# 8 are on their way! Tangentially, you can use C# 8 now, or even F# or VB in Unity if you choose to first compile them as a DLLs.
- stevens32 6y ago
  I do use F# as compiled dlls, but like I said it is not supported. Only C# compiled IL is officially supported with il2cpp, and issues related to other languages are liable to be closed as won't fix. There also is no good NuGet story for Unity, which may catch a dotnet dev off guard. On one hand, a lot of things work surprisingly well. On the other, if you're going into it thinking you're going to get the same dotnet development experience in Unity - that's not the experience I've had.

moron4hire 6y ago

As a long-time .NET developer (since it was invented), getting into Unity (have been doing it professionally, full-time for the last 4 years) was a huge exercise in pain and suffering. They have their own ideas on how projects and their dependencies should be organized that don't align with the rest of the .NET ecosystem and, quite frankly, it's maddening. It took me probably two solid years before I was making things in Unity that were any "good" (not dropping frames because of stupid stuff that Unity does like decoding textures on the render thread, not taking forever to load on startup, being able to cross-compile to different VR and AR systems without making massive changes to the application, etc.). After the third year, I had written workarounds for so many of Unity's built in stuff that I wish I had just started with my own game framework and skipped Unity completely. Well, I guess that's not entirely true. I wouldn't have gotten my first well-paying, fulltime job VR without Unity. But from just a technology standpoint, it's been a major impediment.