Moving From Electron to Unity

I have spent a lot of time trying to get Tone.js, Pixi.js, and Electron to behave like a real game engine in Javascript.

I went to some lengths in the above-linked article to describe my reasoning, there - I’m much more experienced as a Javascript developer than I am as a C# developer, I already know the ecosystem really well, and Electron has some real concrete advantages in the space of UI and network communication primitives.

I’ve been oscillating back and forth between Electron and Unity for a while. I’ll probably continue to, to be honest. They each have their own positives and negatives. I have beef after beef after beef with Unity.

But I will say that Tone.js and Pixi.js are a lot of effort (behold, a narrow wrapper around a sine wave and some pixel blits), and I am becoming increasingly convinced that trying to shoehorn React (and react-pixi) into the project at all was a mistake. ]\=

Faced with a significant rearchitecture, I thought it might be time to give Unity a chance to shine.

Now, instead of moving forward, I’m moving sideways! How unsatisfying!

So far, though, every Unity solution I’ve tried has been less effort and looked better than its Electron equivalent, though. I’ve had to flash a little bit of cash (it helped that I took this project on ‘round Christmas, during a bunch of sales), but the VHS Pro shader honestly gets you from zero to that retro TRS-80 computer feel with so little effort it almost feels criminal. I popped a text editing tab up and just enjoyed the experience of typing “poop poopity poopadoo” while watching the accurate waver and jitter and burn-in and effervescence of a really old CRT play out on the screen and it was immediately satisfying.

The Path of Least Resistance WRT UI Design

It is funny how the path of least resistance affects the overall design of the game, though - Electron leads itself really well to creating low-effort powerful, nested GUI interfaces, 98.css gives us tools that we can use to build pretty convincing windows-like components, and so the obvious retro-computing angle becomes something in the Windows spectrum. Which would be absolutely a fun direction to go with UI primitives and stuff. I could very easily build an in-game wiki using a mock Netscape Navigator or Encarta, the music interface could be a thinly disguised WinAmp knockoff - I could record myself performing a mock Weezer song, crush the file down to like 5 megabytes, and leave a file link somewhere in a media directory. I am already having fun thinking about building a fake Windows-like UI filled with 90’s era windows nostalgia.

(behold, a mock window)

That’s less practical in Unity, though. Still possible, but Unity’s UI primitives are still … primitive. The new kit, UIElements, is shaping up really nicely to be a powerful, general-purpose UI engine with a lot of inspiration from XAML/WPF - but my developer’s instincts suggest that it’s not going to be the stable choice for UI development in Unity until about mid-2022.

But just typing on a CRT screen is immediately, deeply gratifying - I mean, to me. It is possible that lots of people don’t get that electric thrill when they press down a mechanical key - with an audible clack and the spring of a buckle, a character springs to life on a simple text console in front of them. I would like to submit that these people are missing out.

So with Unity, it feels a lot more likely that we’ll end up designing interfaces intended to evoke a slightly earlier era of computing. There is an obvious pun to be made about a shell game. BBS jokes. The serious and ongoing question as to whether or not you can get ye flask.

I’m convinced I could write a text-only game using just this CRT shader and it would still feel good. I should probably do better/more than that, and not fall down the fun-times hole of NLP. I guess. I mean, I definitely, 100%, should not blow an entire human year building “very stupid Alexa”.

This may not be true for developers who have a strong vision and an indomitable will - they decide what they’re going to build, design what they’re going to build and then build what they’re going to build - but I am not one of those developers.

Updated Music Output

Here is a more recent run from the thinger.

Compare with a clip from last month:

The music generated by the two systems is produced by the same underlying algorithm - the only difference here is which instrument is playing it.

Unity Stuff

  1. Flurl is very good.

  2. Odin is very good.

  3. AudioHelm is extremely impressive, given its scope and that it is built and maintained by just one developer, but building what I want to build with it has involved more than a little bit of guesswork, and I’m not entirely convinced it’s performant enough to be used in a video game.

  4. .NET’s built-in websockets implementation is poorly documented and arcane.

  5. which is why the whole C# universe appears to use SignalR, which is, IMO, an interoperability nightmare

  6. So far, Unity seems to be more crash/freeze prone than Electron