A VR social sandbox

Friday News 3

Slow week : June

Another week and another post. Unfortunately this week was one of the weeks I was dreading to post about. All work was focused on my end on a single part of networking which I’ll get to in a second. Everyone else was busy with their personal work, with nothing they wanted to talk about. We were expecting this to happen eventually, where either not much work gets done during the whole week, or everyone gets lots done, but nothing to post yet. Blog posts encourage people to save up all that work up for a longer post when finished, as a nice and neat story. In the future when this happens I’m thinking about just skipping the weekly post if It’s too small, or filling it with a mod showcase. Would love to hear what is acceptable with you.

Discord Announcements, Nightly branch

We’ve now got an announcements channel within our server, if you would like to follow it for news feed within your own discord servers. So far the plan is to only use it for blog posts, major game version releases (beta, main). We also went and removed the password from the nightly branch (it was pinned in our server). Please keep in mind that branch is the absolutely most up to date version of the game, and will likely be broken and buggy.

Network Controllers

To recap our networking layering, We have a low level driver sending data through steam or directly through ip (udp). Next to that layer isolated, we have an instance management system hosting multiple servers which in turn each have an actual 3d world each. The next layer routes data from the low level drivers, into the instances they belong with. Last week, these layers were mechanically complete, just with new packet types needing to be added as we go. 

This week has been focused on the very next part of the layer, inside the world dealing with the new data that’s now flowing. We wanted to simplify the back and forth on startup between a client and the server, body id, client id, desired controller. In the future this will allow us to provide an exact network API so custom clients can be created if desired. 

After cleaning up the back and forth I went and jumped onto the player controllers so we can get our old player systems running again. A few weeks ago we decided to shift our controllers to be more fully simulated on all clients. This means that we can pick up on various events that were not transmitted before, like a user opening a UI could actually display a fake version of the same UI locally. It's absolutely required for shifting between on foot, cars, planes and zero g. Or allow for local ik selectively per player if desired.

But this change brought up new problems where the controller prefabs generate different data on a local client vrs a remote client. A local player might have a camera, then generate a movement entity, plus a local input entity to drive said movement. On the other clients you would not want to have the camera or the input entity. If you left these, pressing move would move the other player as well which would cause desync. This variance of course is handled by the controller spawning system, selecting local, remote / server. But we didn’t have a mechanism for taking a templated controller with select synced network parts of it and making sure those all got the same network identity on all clients. Now that we have this system, we have ‘mostly’ the same controller data on all clients and the variants are accounted for. We are also able to repurpose this system for lua entities, spawned props, cars, etc.

With that now out of the way the controllers are looking much simpler. Which is the main goal for this rework. The same controllers on each client allow for interaction, movement, seats, cars to be very simple. I’m now working on switching between controllers, On Foot and Seated controllers currently for vr/desktop. I’m trying to avoid mutation, so one controller only solves one kind of state a player is in, but this requires very seamless controller switching. One change we had to make with this new setup, involved making the players body part of the controllers. This allows the controllers to drive them, like keeping your hips stuck within a car, on desktop making your character hold onto and turn the wheel with ik.

Sorry about the shorter overall post and wordy networking section this week. 

If there’s anything you would like to hear from us, get in touch through discord or steam community.

- Lavender Team

Friday News 2 - Solar Systems, Network History

Some helpful notes

ECS: Entity Component System. In the context of Lavender, this is unity's new ECS system based on fixed memory data first design. It’s closer to how old MMOs were made rather than modern object oriented games.

Instance: A single world that you the player run around in, which is different from the server as a whole. Think MMO again, shards, instances. The gameplay part where the physical players and props live in.

Version numbers: I’ve always disliked fake version numbers products use like, 0.4, 1.3.22. Early on we switched from this over to just displaying the raw revision of the project’s master branch. Unfortunately we’ve shifted the project from one repository to another and the numbers reset, which is pretty confusing. The project started on revision r875, had thousands of versions up to r4565, then we ported to a new repo starting over at r1. We are currently at r428 as of writing. 

Eventually we want to change our version numbering, We’re just not sure what yet.

Abstract : June

Network is one of my favorite topics when it comes to game design. It’s both high level and low level. Hand crafting packets and bit compressing where needed. While also having to manage the complexity and abstracting this away enough to actually get the magic synced up between two game worlds.

In this space, there isn't really one single right way to do networking either. Pretty much everything is a trade off when it comes to networking. Mesh vs Hub spoke, hybrid mesh, host transitions on disconnect, lobbys, it goes on and on. Cheating is a major concern, which has become very apparent these last few years. There's just so much room for experimentation and learning when it comes to it.

I wanted to give an overview of the networking within lavender, how much it’s changed over the years, due to the game changing.

May 2018 - Lavender prototype is added to our SVN Repo, cloud projects added to TFS

When we first started the project our decisions were based around a totally different game. Based solely around VR social interactions, with complex interaction (cars, planes, guns, scripting), This version of the game had much different networking needs. Not to mention we were planning on a different monetization model at the time, subscription based for upgraded accounts (extra slots, data caps removed). Since the users just needed to get in and see each other quickly, we planned on using a cloud provider, like unity multiplayer (now dead and a new version replacing it) or photon - whatever it was at the time.

As you know from our current version, this didn't pan out and never even really made it into the game, only a few internal dev builds had access to spinning up cloud servers.

October 2018 - Cloud based simple servers killed (Photon, Unity Multiplayer)

With cloud based servers now dead and gone, we had to come up with a new game design and networking. Single server, multiple instances, basically reusing the concepts and tech we built for the cloud. But cleaning it up and handing it to users. This is when the concept of Galaxy, Solar System and worlds were created. Since we were shifting to a server that does more, why not shift the focus of the game a bit to reflect the change from the cloud. So we did, deciding to plan around a garry’s mod like sandbox experience, but retain all social features from before.

The solar system plan at this time was to create a process manager, with a web api for talking to our API and a local one, for direct communication with the game instances running on it. This process would have to both manage the users requests, which it would then forward to the cloud. Along with managing the CDN requests and keeping a central cache per solar system install (don’t want to download the same map for every single spawned instance).

November 2018 r1134 - ECS added to project

Around this time, unity releases an early teaser for a project they’ve been working on called ECS. During some time off I made a prototype on it, creating a Terraria clone. It was fantastic, and such a different way of thinking about game design solutions. I could already tell that if we ported our networking over to this, we could remove most of the crappy parts of networking while still being as easy to work with. There were other reasons for bringing ECS in, but this post is focused on networking.

December 2018 r1795 Ported and reworking core networking to ECS. 

Armed with this knowledge we discussed this with the community in the discord (which was much smaller). They all agreed I should do it, to take my time and do it right. This by far is one of the best decisions during the project, I’ve personally learned so much because of this.

Thank you.

The next year is spent struggling to learn, build and maintain this new system. It worked roughly like this. A single unity scene is loaded, the map you selected. And a single ECS world exists containing a bunch of entities with flat data. Stuff like, here’s a player made up of [PlayerID] [PlayerEntity] [SkeletonBuffer]. Players bodys were all processed in multi threaded jobs that uncompresses, unpacks and blends (interpolated) their poses. To perform any action or logic on the server, you would create an entity with data on it representing your request. Example: [SpawnProp] which has a position, playerid who requested it and a galaxy id to actually download the prop. The spawning prop system would then look at all requests and process them, checking if the user was at their prop limit, or disallowed from spawning props on this server. This inversion of logic all revolving around looking at the presence of entities is how it was all built.

ECS Networking finally working after the initial rewrite.

But things were still far from ideal, to local host a server (be both a client playing the game and hosting for you and other people) we had to come up with a way to isolate these two worlds. The simplest solution would have been to spawn two ECS worlds, which was barely doable at the time. The real problem came with unity scenes and global physics. There wasn’t a way to isolate either of these and a player would self collide with the server version of himself, or a prop might fly around doing the same. There ended up being lots of complexity from the server and client being the same world, same scene. 

Modern times

We were still not even remotely close to having the complex physics and scripting interaction we decided on ages ago. Fast forward to a month ago, Unity based split worlds became possible. 

I'm not doing well at this time and ask for advice. Can I take the time to rip it all up again? I hadn’t made as much progress at the game for months at this point, I had spent all this time reducing and increasing the networking complexity of the single world system, waiting on solar systems, to provide motivation and direction for what the game needed.

We decided since this would both simplify the entire networking stack, along with allow us to finally kill the solar system bogeyman, I should go for it. Entire stack was upended, there are now multiple worlds per server, each being a unity Scene and a ECS world pair.

Networking stack is split into 2 layers and a global manager, 

* Network Drivers, manage connections, raw data flow in and hand it off to the next layer

* Solar Server|Client The high level logic that manages the drivers even flow converting their data into entities and placing within the right instance.

* SolarSystem Creates either a Server or Client and tells the server if running to create world instances if asked.

And as of this most recent build, this is done, with support for Steam friends, direct IP and local hosting all going though the solar system and solar clients. This is a big deal internally, as it means we can shift our focus from networking, to interaction and gameplay scripting. 

Two very happy cube players joining through direct IP, and the other through steam relay servers.

The solar systems are now working in their most basic version but still have a few more things they will need before the next release. Solar Systems need to register their presence to a galaxy api somewhere to display and find users easier, users need to be able to see all servers running out there to find friends to play with. They also need the old web api from years ago to be brought back, so you can create worlds from a web api for power users.

This was from early 2018, feels like forever ago.

In a future blog post I’m gonna go through the “hall of shame and it's always next week” and go though the UIs history leading up to the new UIs proper reveal. That post will have to wait until the main style is settled on and most of the UI being finished.

We would love to hear from you, consider joining our discord, or opening a new post on the steam community. If there are any suggestions for a future blog post topic we would love to hear it.

Thanks for your support

- Lavender Team

Friday Facts

We have decided on releasing blog posts every Friday. This way if you don't follow the dev channel or would like a more structured read of what we have been doing, you will be able to find that now every week. It will be posted in discord and on our website at LavenderVR

Steam news posts

One thing we aim to correct now, is the fact we've been keeping our news and changes only on Discord, in a single channel. This is something we are going to change, first by posting blog posts every week which are mirrored to Steam news. Then after we finish up some tooling, we will also display automatic change logs and version numbers as they go up. We haven't decided yet if we are going to include the nightly changes or not. As we currently ship several nightly builds a week, but have yet to push any to beta or main branch in a while.

June: UI, UI, UI

UI Framework Change, again.

One of the most painful parts we've all been putting off on the team is the UI. No one wanted to take full responsibility for it, or if they did, they then got swamped by other work and no progress was made. In the past we have tried many different frameworks, UnityUI, PowerUI, Ngui, Ongui, CEF, and none of them have been what we have wanted. But now we have found a system that works well enough, its expandable and will be easier to maintain. We are moving all of the UI to Unity's new UIElements. So far in our tests they have worked great, have been very stable, and very easy to develop with. We hope to hear your feedback on the new UI soon. Overall we think this is going to be the best change we can make, and a change that doesn't require any outside libraries any more. Which means build times and size should be reduced as a side bonus.

Style

The UI style is something we are still working on and would love to hear some suggestions of what you guys would want to see in the new UI, or anything you don't want to see. We are currently aiming for something, somewhat tron like, but still feeling out the space. I've made a few material dark theme UI's using UIElements now and they can look quite nice in vr/desktop.

UIElements uses a CSS like styling system, so we should be able to rapidly develop this with your feedback.

Porting

Porting UIElements over and finishing the library (its like 75% done) to fully work in worldspace/vr really changed my plans for this week. I've ended up spending most of the week on RnD for the UI framework and structure to be able to continue and rework later as needed. Currently most of the old OnGUI based placeholders (World selection, hosting, avatar selection) have been ported, but nothing final. This is done now to prove that both UIElements and our UI framework structure will work out in the long run.

Ram: UI Stand

While working on the new UI Framework, we decided on all UI within the main menu should be grounded built into models in world space. The first piece/model I've finished up is the UI Stand, which will be used for Teleport locations throughout the mainmenu and the inital VR Login menu / Prompt.

The stand itself has provisions for the UI render target to be placed within the actual models body. 

We've also included some space below the display to host a UI based vr keyboard below the UI prompt. This is if the display needs some text input or not. We did our best to make sure the model was both pleasing and ergonomic for an average sized human (Accessibility settings are on the way). There may or may not be a hidden skin for the UI somewhere...

NO2: Galaxy and Auth changes

The past few weeks I have been working on our server side auth re-write. This should remove most if not all of the headaches with the current system. I have been working on this for a while trying to make it so there are no more issues going forward and to expand it later if we need to. This has also involved me re-writing some of the galaxy to be compatible with the new system. As a result of this it has reduced the complexity of the API by quite a bit and should be generally more stable in the future. It also has allowed me to change the runtime to .net 5 which has been a fun change over. It comes with many runtime stability and speed improvements. 

Along with the web api and auth changes I have been doing a lot of administrative tasks that I have been putting off for a few weeks and a general clean up of our services and backend systems. I will try and post more about this as the changes start to go live, and hopefully this new format will be better since I have not been the most active in the dev channel since I enjoy long form posts vs short updates. 

Aside from that I have been working on some rough website mockups for a new version of the website. We are not sure what we want from them yet and this is not a high priority, we should be able to share at least something in the next few months.

I also wanted to mention June is currently doing most of the game development right now. I have not had much time outside of what I am currently working on and other obligations to work on the core game. Hopefully this will change in the next few weeks after things calm down.

We hope these blog posts are helpful, maybe even enjoyable to read.

Thanks for your support

- Lavender Team

Alright here we go, a proper blog to start dumping out progress into a easier to digest format.

We've been wanting to do something like this for quite awhile but just haven't had the personal bandwidth for yet another project. So instead we compromised and went with a prototype version to hold things down for now.

We haven't decided on a release cadence, like factorio's Friday Fun Facts (FFF). For now we're thinking about updating as we go, until we decide on a set date.

Let us know what you think in our public discord

Discord Invite

-June