First Networking Test

I just completed the first networking test for Orbus. I took a quick video of it for posterity:

Hopefully some day I'll look back on this day and remember it fondly :-)

What you're seeing here is a simple test where as I move my controllers and headset, those movements are sent to the server, and then relayed back to me (which is why the dummy in front of me moves just a split second behind what I'm doing). However, there's a lot more going on here than just a simple Unity Networking test.

Warning: technical content ahead, feel free to skip the rest of the post if you don't care about the inner workings of networking architectures.

First off, Orbus uses a server-client model, and the server is written in NodeJS. So just to get this off the ground, I had to get Unity and Node talking to each other. I'm using Node (as opposed to just running a Unity headless server) for the simple reason that it would be impossible to support an MMO-sized community on a server that's just running Unity in headless mode. NodeJS gives me an incredible amount of control over exactly how much processing to do for each "frame", allows me to quickly spin up or spin down additional servers as needed, network them together into a mesh, etc. I could probably achieve all of those things in a Unity headless server too, but a) I've no experience doing it, whereas I have lots of experience running Node servers at-scale, and b) it's a much more opaque process. Just running a Unity headless server with nothing else happening but loading the default scene, for example, constantly runs at 10%+ of the server's CPU. What's it doing? Who knows.

For the Node server itself, we're actually running a full physics simulator on the server as well, which allows us to do things like server-side checks for collisions. So when you swing your axes like a wild Barbarian, the server will be handling deciding if you hit that golem or not, as opposed to the client (which is necessary to make sure that bots and cheating aren't a rampant problem). So that was another whole challenge to overcome, involving writing code in Node that could read Unity's scene files and prefab files, so that I can read them in directly and re-create the same geometry and colliders on the server that are present on the client.

I've also created a custom binary protocol that can rapidly send all the necessary position information for the two controllers + head of the other players in the game (in addition to other entities like enemies) to everyone so that you can see your fellow adventurers moving around. The goal is to require less than 200 KB/sec of download bandwidth to run the game, and right now it looks like we can achieve that as long as there are less than 10 players and 30 other entities (like monsters) within your sight radius, which seems pretty reasonable.

Finally, there is an entire entity-component mirroring system built on the server as well. So for example, when you teleport in the game, your PlayerCharacter component in Unity fires off a command to the PlayerCharacter component (in Javascript) on the server to say "I would like to teleport, please!" Then the server can do a quick verification to make sure you're not going to go someplace incorrect, and relay a command to all the other clients that says "this person just went here!"

So, all of that, for a 10 second video showing me jumping up in the air in victory, and having all of that information sent at the speed of light between my house, our server, and back again, all in around 80ms. Feels good.

Riley Dutton

Read more posts by this author.

Subscribe to OrbusVR Development

Get the latest information on OrbusVR delivered right to your inbox.