VRChat Now So Popular With Devs, Thousands Are Using a Compiler That Converts C# to the World's Internal Scripting Language

As another sign of the VRChat community's growing strength as a creator ecosystem, here's another fairly mind-boggling factoid:

• Like many virtual worlds, VRChat has an internal scripting language. (Called Udon, in this case.)
• However, many developers (especially those who work on a professional level), prefer to code in C#, which already runs natively in Unity (the game engine underneath VRChat).
• So much so, a VRChat community member named Merlin has created UdonSharp, a C# to Udon compiler, which he built and open sourced on a voluntary basis to serve other VRChat creators, and has a Patreon in hopes that he can keep doing that full time.
• Based on the latest GitHub stats, the UdonSharp Unity package from GitHub has been downloaded around 20,000-25,000 times.
• Which suggests, based on recent stats, as much as 10% of VRChat's total monthly active user base have tried using UdonSharp at least once.

Varneon, creator of this impressive VRChat driving sim, estimates that the vast majority of VRChat worlds using Udon were actually scripted originally in UdonSharp:

VRChat scripting tutorial by Varneon

"I would probably say that anywhere between 90-95% of the VRChat worlds that are created with VRCSDK3 (Udon worlds) are created using UdonSharp instead of VRChat's own Udon node graphs," as he puts it. "Many of the creators in VRChat have some kind of experience with programming and prefer to write code instead of placing nodes on the graph, so UdonSharp is the perfect option as it allows you to write C# code that then just gets compiled into Udon assembly... for anyone who understands code, it is much faster to write something as text versus searching for each node, placing them and connecting them."

Varneon says it compiles pretty cleanly: "The workflow using UdonSharp is really straightforward and apart from the limitations that VRChat has put in place, using U# for world development doesn't differ too much from standalone Unity game development using C#."

Considering its popularity, should VRChat the company buy UdonSharp or just hire Merlin?

"I personally can't give a straight answer to that question, but having projects open source like UdonSharp is, allows their original creators to have full control over the project and have their own income streams (Patreon etc.) under their own name which some people prefer. Open source also benefits the community and is not subject to same kind of legal requirements as VRChat's own SDK is."

Which is another sign of VRChat's rising strength as an ecosystem, but maybe one the actual company might not prefer: The developer ecosystem has become so self-perpetuating, it and not the company is already starting to define the terms of the platform's evolution.

Comments

[Adeon Writer]

VRChat enabled this! They could have required you use their programing system - but they gave the option to also allow you to just submit your own compiled assembly, so you can use any programing interface as long as it can compile to an udonbehavior. Conscious choice here! And that’s where UdonSharp stepped up. And it’s great by the way.

[seph]

Babbage Linden for years (2006-2010 ish?) communicated the process of getting Second Life's scripting powered by Mono. He talked often in user groups and other places about a clear path towards supporting not just C# but other .NET languages like F#, IronRuby, IronPython, etc.

I'm not sure what happened other than Babbage leaving but obviously we never got C#. It seems now with that past work already done and Mono's licensing not being as problematic as it once was now that its owned by Microsoft (problematic LGPL then, MIT now), and there even being another option/successor like .NET Core, Linden Lab should invest in updating its own scripting again with the inclusion of C# and more .NET features.

[Adeon Writer]

The only thing Linden needs to do is let us submit our compiled Momo assembly. Users can take care of the rest in building a compiler into the viewer.