VRChat: My first day in scripting

I had some wrong preconceived ideas about creation in VRChat, because instead of verifying people’s and my own misconceptions I took them as an excuse not to have a look (I’m not a big fan of VRChat‘s ‘chaotic’ experience).

‘It’s restricted to like four shaders on standalone (Meta Quest)’

It’s not! That limitation only concerns the avatars – and kind of makes sense.
I can’t take that as an excuse anymore to avoid world-building.

‘You have to use a Graph Editor’

Thank god, you can script in C Sharp and it then will interpret to its own magic called ‘UdonSharp‘. The visual scripting is still welcomed of course and will be useful for less experienced users (and noodle-scripting fans), but that UScript thing is awesome.

‘Let’s just wait for VRChat to switch to Universal Render Pipeline’

I’ve always been waiting for a transition from the built-in render pipeline to URP.
After some search, it looks like they are simply going to stick to built-in as long as they can (and pray for the best). So I could wait another few years or just deal with it.

So, with that sorted out, I thought I could take advantage of my Unity experience to try to build something quick. I have this habit of sometimes trying to code a little old-school ‘shmup’ when I study a new language. But after that first look, I wasn’t very confident in what I could achieve, and still not getting much of the tool’s limitations.

User controls

I started by looking at a way to use the controllers to pilot my spaceship.
I found out the proper way to do that in the documentation but wasn’t sure how to implement it, so I went the lazy way by referencing exposed inputs instead.

Code Logic and portability

It seems like objects are bound to the world in VRChat, unlike in Altspace, I haven’t seen a kit system that allows you to use a kit independently of the space you are in.
So using new layers for the code logic doesn’t sounds like a great idea, so I went for the component check instead (ie. inside a TriggerCollision method), for the sake of compatibility and portability to other ‘worlds’.

Finding A way to lock the player properly

That was quite funny to try to test my code in-game. At that point, I was able to control my spaceship, move it, and fire within the limits of the game’s frame, but with the extra difficulty of my avatar moving at the same time! I was worried that I wouldn’t be able to freeze the user to the seat while playing. Thankfully again, Udon gives you the possibility to work around that, so I don’t have to throw away the whole project.

So from what I discovered on that first day, what seems possible to do with Udon? Quite a lot actually, and my idea of recreating a little but complete retro arcade game seemed feasible after the first few hours!

I’m gonna list the limitations that I reached instead:

• no coroutines
• no lists (but I simply used arrays instead)
• no access to send/broadcast messages (but there is apparently a custom messaging system)
• No third-party tweening system for my Shmup, or any other fancy asset
• Impossible to reach an Animation component (it’s deprecated anyway, and reaching Animator instead works perfectly)

The thing is, except for these problems, for which I have most often found a workaround, I’m quite stunned to be able to develop the equivalent of another Unity project, almost flawlessly 🙂