Dreaming of C#'s future in Unity
Could webassembly ever make it into Unity? October 8, 2020 Games Tools
Sorry for anyone that reads this thinking that I’m releasing anything here, but I just wanted to take down some notes publicly on some thoughts I’m having. I know it’s Very Cool to hate on Unity, and there are lots of things to really be frustrated with as a developer, but I think a lot of this comes from the fact that people do really like Unity’s core offering - a really robust game engine that allows you to code in C#. We love it!
One thing we don’t like though is that Unity seems to want to reinvent the wheel for themselves so you have to live in the Unity ecosystem. Two key examples of this are - why did they make their own package manager instead of just integrating with nuget? Building up one of the strongest C# projects meant for scripting C# in, and then effectively cutting out tons of C# libraries for consumption inside of that furthers the divide between “real” C# and “Unity C#”, a gulf that helps nobody.
In addition to this, and because Unity wants to live in Unity C# land, they’ve also developed their own new (for the 3rd, 4th time?) UI templating system, UIElements, meant to give a much needed reactive-UI framework as an option to Unity developers. This is really great… expect for the fact Microsoft is heavily investing in its own version of this for C#, Blazor.
Not only this, but it’s hard to have faith in Unity’s approach when, like Google, they’re starting to get a reputation for spinning up new products, promising a lot, then abandoning them later after a nominal release and no more press. I’m not extrapolating here either - in their 2021 roadmap blog posts Unity openly acknowledges they are doing too much and creating an inconsistent experience in the editor, with many features left in a variety of different states that make sense only to internal Unity teams.
So when UIElements inevitably gets trashed for some new UI framework, we’ll be in a position again of choosing to trust the new thing or keep our old code on life-support.
Or maybe not?
I’m really excited about Blazor. I’m really excited about it because I do genuinely love C#, and being able to skip writing Javascript to author web apps sounds like a dream. But also, still have access to JS if you need it.
Additionally, I’m really excited about WebAssembly (WASM). A universal application runtime that can (theoretically, eventually) run anywhere, at native platform speeds? Hell yeah!
So the fact that Blazor has a WASM version is extra exciting - the promise is that you’re authoring typesafe webapps from a single language, deploying to a single binary, that can then deploy to any platform. Yes!
And if WASM can go anywhere:
Can we put a WASM runtime in Unity?
For all the nastiness that comes from trying to marry nuget and Unity, you could just build our the applications as WASM modules, and then load them into Unity like DLLs, but without all the dependency nonsense of DLLs.
You could also, and this is the point of the post, maybe embed something like Blazor as a wasm module for build the UI for your game, and then use a standard webrenderer to render the code from Blazor? Or maybe instead you intercept the rendered Blazor code and transform it into Unity UI code?
I don’t know!
I think what I’m suggesting is messy. It probably won’t work - but trying to dream of a perfect world where we get the best of Unity with the best of C#. Maybe Unity should just become and SDK again?
Date
October 8, 2020subscribe to my newsletter to get posts delivered directly to your inbox