• Updated the project to unreal 5.1
• Moved from steamvr to OpenXR so most / all vr headsets should work.

Reverted the main branch temporarily to the last unity build which was more feature complete than the current unreal branch of the game. This is just a temp fix for right now.

Catching the main branch of the game up with nightly. Finally got unreal engine automated builds going. Sorry about the massive downtime! life really caught up to the team and me, so we couldn't get anything done on lavender for a long while. I'm finally freed up again to work on lavender, so fingers crossed the updates start flowing again :)

Added full Vive face tracking, check the SDK out for the new companion component called FaceTracking, placed next to your avatar component. Eye tracking is next on the list, stay tuned. Several bug fixes to prop spawning, scripting, networking interpolation.

No patch notes this time, but larger finished patch will contain them. They require some editing to be clean of internal implementation details. This update contains all the WIP UI, on the main menu and on a server. Only accessed though desktop mode at the moment. Please provide constructive feedback in the lavender official discord server. If you need any support or help, mods or us developers can be contacted there to help you. You will need to register an account on the website and link your steam account. This will be done in game, from the login prompt, as soon as the new galaxy client code is brought into the public client.

Hows things going, whats coming? Updates are on the way for several features everyone has been asking for. The current task as of writing is a full UI overhaul, replacing the UI for VR and desktop. Both are being totally redone to be much more user friendly with high Accessibility. You can view them on the nightly branch of the game, with updates coming nearly every day, Monday-Friday. The curse of Sandbox games When I refer to a sandbox game, Im talking about the kind of game that is solely about user created content, with no core game content outside content packs in service to the content creation. Im not talking about an open world game with sandbox elements, as those are full games, just with sandbox elements added on. A third type would be any game with mod tools, as those are usually much, much more limited in scope. The final type which could be argued to be a pure sandbox game, with modding added, would be procedural games, such as Minecraft and No man's sky. Both examples have a core gameplay and content though, which is a component to success. Some of the first kinds of sandbox games were level editors for games, where mod tools were basically the entire engine tools that were used to build the game. This type of control would and did allow for completely making a new game though the engine tools. Over time, these types of tools were either dialed back as to what you can do with them, or they ended all together. The most popular pure sandbox game of all time, Garrys Mod, started out as one of these. Garrys mod started out as a modded level for hl2, a single player game with sandbox elements. The enduring popularity of this type of game has generated countless other pure sandbox games, very few successful. Games that are great for development, have a fixed amount of content. You always have a rough idea on the amount of content needed to finish the next level or scene. After weighing your resources (People, time, money, skill) you can boil down to a small manageable set of content. This ability is a massive boon to development time, you always know if you're moving towards your targeted release. When you start out working on this kind of game, you usually have a good vision of what the gameplay is going to be. As you progress you can measure your gameplay funness, knowing if you're moving in the right direction towards that vision. If we convert that into a quick list, it might look like this: Fixed content, per Scene/Level/Map Fixed content allows for game centric performance optimizations, which might be a deal breaker on complex games. No one likes to play at 10-30fps. Scope of game can be adjusted to resources on hand, mainly People and time. Always have a rough estimate on progression though projects life towards finishing. Single type of gameplay, which is the same vision as the entire game Can adjust gameplay as development progresses, to refine and adjust towards the vision You might already begin to see why sandbox games are very difficult to finish. I personally think that each one of those bullet points are a must for finishing a game at any kind of reasonable timeline, to an acceptable quality of game. Lets walk through each of those points. Sandbox games are inherently about the content the users build and provide for the game. The users create the levels and scenes. You dont get the ability to control the quality of the entire game, you are giving up that control completely. Now you cant easily divide out what exactly is the core content of the game, limiting your ability to delegate out what exactly the artists and level designers should be working on. This causes friction for your artists, who then struggle, struggling members of the team drag everyone down with them. Having fixed levels, with either a linear path, or a boxed in, open world, allows you to control where the players go and see. This provides good reduction in workload for artists, allowing them to produce lower quality distant assets, or reuse general assets over larger areas. Both are great for workload reduction and improving morale. Sandbox game levels and scenes are not created by the development team, so they are fully out of our control. This means the performance is mostly up to the creators of the content. Optimization and performance tradeoffs are a difficult thing even for seasoned developers. For a casual user just wanting to make something fun this is a massive mental burden on them. Games are all about serving the users, giving them a great experience, learning about draw calls, mesh culling, fragment shader performance, etc are not fun. No team has unlimited resources, so depending on the scope of the game, you might be making a single player game with 6 unique levels, lasting a total of 6 hours of gameplay. Or you might be making the next open world game, with 50sq km of terrain, thousands of npcs and dialog. A sandbox game has no core content like this, but it hopes to support both kinds of game content created by users. This is a pretty tall order, because part of making either of those games perform well enough to be playable, is to create the game in the first place. Very much a catch-22. You cant know what types of things the terrain system might need, without creating art with it, up to its limits before raising them. You cant know how performant your physics engine will be, until you scale it up with real world content. In sandbox games, the players will smack all of your limits, the very first day you provide a build of the game. Its just the nature of players to learn the limits of the sandbox. Some of these players will blame the developers, for not accounting for their creations limitations without any thought as to why the developers didnt prioritise their use case. Since sandboxes then are trying to cater for all types of content creation within their tools limits, they then must support as many general gameplay types to match the content. If your tools let you build water, users will want to swim in it, see props float in it and create water vehicles / boats. You might have a first person player running around, though standard state machine driven movement. But maybe its desired to also run a third person GTA style animation driven movement, where the player slowly turns and steps around realistically. Now you have to cater to two different kinds of gameplay, along with all the supporting systems and content added. All unknown on how it fits into the original gameplay vision for the game, since there usually isnt a strong one. Ive always said, sandbox games kill studios. They have unending scope, where even after finishing them, users will want updates to expand the tools. If you want the sandbox to keep succeeding into the future you work on it. This keeps the studio shackled down to it, never able to fully shift to another project 100%. Unlimited creation means unlimited development time. How does this affect lavender? Throughout the entire development of this game, since before we even started, Weve had this on our minds. This isnt the first type of game we wanted to publish, but it is the first one I've personally had the absolute drive to create. I can still see the vision now to this day. Ive been struggling deciding how to provide as few limits as I can on users, I want to enable users to create anything they want. But this is one of the core problems with Sandbox games. Ive been struggling with this back and forth for years at this point. Weve seen other sandbox games come and go struggling with these exact points, maybe even without knowing why. We still dont know the right way to finish this kind of game, as developing a fully open ended sandbox is the same as building a game engine, a gameplay framework, and then a bunch of frameworks for users to create in. Its very much not traditional game creation. This struggle has brought some really low lows for me personally, drifting away from friends and family. Ive spent so much time telling people I just have to finish, then I can finally be free, even though you can never be free of sandbox games. These last few months have been brutal on my mental health along with being chronically sick during the last half year. Ive done my best to just keep working in spite of it all, but this depressed state of mind leads me to make rash decisions, along with doubling down on bad decisions after the fact. I can say that Im now doing much better, finally feeling healthy again, laughing and having good times with friends. Ill keep doing my best, and bringing this game closer to 1.0. See you at the next meetup. -June

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 Ill 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 Im thinking about just skipping the weekly post if Its too small, or filling it with a mod showcase. Would love to hear what is acceptable with you. Discord Announcements, Nightly branch Weve 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 thats 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 didnt 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. Im now working on switching between controllers, On Foot and Seated controllers currently for vr/desktop. Im 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 theres 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. Its 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: Ive 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 projects master branch. Unfortunately weve 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, Were just not sure what yet. Abstract : June Network is one of my favorite topics when it comes to game design. Its 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 its 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 garrys 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 (dont 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 theyve 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, Ive 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, heres 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 in 2018. 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 wasnt 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 hadnt 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 Im 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

Build r3415 finished up now with several safety settings now build into the games settings. due to time constraints they don't have ingame UI yet, but will soon. the settings can be accessed from your settings ini as usual. The new values are: [Safety-Player] MaxTransforms=300 MaxParticles=1000 MaxMaterials=20 MaxLights=1 RenderThreshold=2 NoParticles=true NoTrailRenderers=true NoAudioSources=true No2DAudio=true MaxParticlesPerSecond=1000 MaxTrailRendererLifetime=30 RenderQueueThreshold=6000 [Safety-Props] MaxTransforms=300 MaxParticles=1000 MaxMaterials=20 MaxLights=1 NoParticles=false NoTrailRenderers=false NoAudioSources=false No2DAudio=true MaxParticlesPerSecond=1000 MaxTrailRendererLifetime=30 RenderQueueThreshold=6000 These should cut down some a few types of crashers. More updates to this system to follow, along with settings for friends, and toggling ingame. This runs for both props and avatars. Fixes: * full world loading, scene loading overhaul. please report any bugs with world loading as its all new systems entirely * world loading is now faster, much more stable and should cause less issues . * home worlds now load though a elevator always * fallback world thats just a empty cube floor, if you see this it means the world failed. future update will display this info in the world. you can now choose to stay in the doomed world or open the tablet and disconnect. Or maybe the server can change maps if you are lucky. * fix for no home world set, connecting to server you disconnected from causing elevator + main menu to be loaded. * when banned the UI will display this under the login field * ingame registering and linking to steam

More updates to the audio, voice, networking systems to iron out bugs. This update includes some functionality changes to server world changes while things are being worked on. When you localhost, by clicking a world from the main menu, only you can now change maps. On a dedicated server, or connected to someone's local host, the world change request will now be ignored until we add in the world change voting system. the wiki has been modified to be a github pages, which can now be forked and edited. Wiki * internal change to severs, to help with the voice bugs and network poses * Old session files will now get deleted when starting the game (Blackscreen not loading bug) * uicache folder now checks if its readonly and will fix its self to be read/write

* fixed bug with keyboard scaling * keyboard now spawns facing the player * upper limit on fov changed to 120 (can still be set higher in settings.ini manually) * default volume level set to 80% and world default set to 50% avatar/player left at 100% * moved spawn point up on main menu * adjusted default voice system settings, should use much less cpu with lots of players * switched audio backend back to what we were using, should fix audio directionality. * users voice volume on servers now uses "Avatar Volume" instead of being lumped in with world volume

Build r3339 Live on all branches with several bug fixes.

• audio sliders fixed for overall game volume, world volume.
• audio sliders fixed for mic input volume and mute toggle.
• Voice activation / PTT toggle now works again, the visual toggle button might not display when you open the settings for the first time.
• MaxDownloadsAtOnce setting is reenabled, This allows for multiple downloads (like world + 3 people on the server all downloading at the same time
• "No Name Set" bug fixed
• Asset loading bug fixed that caused several maps to fail to load. This also caused the world stacking bug.
• Nameplates resized to half size
• Tablet scales with player size (0.1 to 10x size)
• VR keyboard only shows in vr
• VR UI cursor only show in vr

Lavender is now available on Steam Early Access! Thank you to all of our Patrons who made this happen, we could not have done it without your help and support. You can find Lavender here https://store.steampowered.com/app/886710/Lavender/ You can also find us on Discord and Twitter

Thanks for helping out testing everyone! Check the discord for more info on future tests