When planning out the Sandbox mode, I started thinking about all the things that we need to get right to get there. Player movement, inventory, health, dying, weapons etc. 

I try to break tasks like this up into logical chunks, so it makes sense to me to peel as much of that off as possible and try to make it without worrying about all the other sandbox stuff on top. To try to spot design problems in the engine and work through those things without fighting 10 other things at the same time.

We've been doing that, and it's lead to some of the stuff below.

Our intention is to let people create games with s&box and export them as standalone games, which can then be distributed on Steam etc.

For this to be possible we need Valve's permission - since it's built on their engine. This means they need to update the license agreement we have with them. They've done that, and are in the final stages of checking it over. I'm hopeful that we'll have it this month.

Once that's signed we'll need to work with our own lawyers to make our license. This should be simple, as it will be giving you permission to do whatever you want as long as you don't blame us for anything that goes wrong.

Over the last month we've made improvements to our standalone exporting in preparation for when the legal stuff is sorted.

We've added the ability for you to pick a custom icon and startup image (splash screen). We're being flexible on this and we're not forcing you to use our branding - you can pick whatever you want, though it'll use the s&box icon by default.

We've reduced the base size for an export by 4x (from 2GB to 500MB). This improvement comes from targeting specific files - we export the specific files your game needs, rather than taking a shotgun approach and copying loads of redundant stuff. We expect to make this smaller but there are obviously some practical limits here.

The export wizard has been streamlined for better usability - we've added presets, which is particularly useful if you've got multiple game branches (e.g. staging and stable branches). We've also redesigned both the overview and build stages to reduce clutter and make things more functional.

One of my big regrets with Garry's Mod is that we didn't let creators monetize. A lesson I learned from Valve is that we succeed most when our community succeeds. This is something we applied to the skins market in Rust.

We have been planning this stuff for a while, but have been waiting to see if Valve could help us deal with paying money out to creators. They can, but it would end up too restrictive. We're looking at other ways now, but don't see it being a big problem, and expect it to all be in place by the time we need to pay out.

Our first offering will be an automated algorithm-based system, where you receive money based on the amount of players playing your game. This will be funded from skins/game purchases, the games won't be pay-to-play.

I said this before, but I want to take this stuff slow and steady. If we can find a way to fund our development where everyone can win, that's what we should do. If this turns into a system where there's a UPGRADE TO VIP button right next to the OPEN MENU button in every game right, we fucked it up.

On the topic of paying out developers, we've been working on allowing developers to add their own clothing to the store alongside our items, similarly to how we do it in Rust.

You can publish clothing items to our backend and alongside it you'll publish your clothing to the steam workshop so we can pay you if your clothing is added to our store.

Here's a few items the community have already been working on!

We've been working on Documentation for Creating Clothing. Explaining the set-up and submission process. https://sbox.game/dev/doc/clothing/first-time-setup/

We explain and walkthrough certain requirements / our level of standard, what you'll need for your clothing to be accepted onto the store.

We've released pages running through our process of creating certain items, which goes into further detail on set-up and meeting our quality bar. More pages on different clothing groups will be released over time, so look out for that.

Following the set-up of publishing to Steam Workshop, we've created these documents for artists to have a better chance at their clothing being accepted and used on our store. Allowing another avenue for creators to make money on S&box. 

Dedicated Servers are now in a really good position. As we've been working on Deathmatch, we've been running it on a Dedicated Server to improve things there. We've made Dedicated Servers network their FPS and bandwidth stats to clients, so those clients can see the stats in their console. I've made connecting to servers more reliable in general and we've made it so you can change the map and have clients automatically reconnect to the server, and the server will update the game in this process as well.

We've added a user permissions system. Dedicated Server owners can modify permissions of individual Steam accounts in a file - and permissions of a user can be checked in code. We'll use this in future to limit certain actions such as kicking or banning to only users with those permissions.

I've moved all the networking code over to be multithreaded, improving general performance and preventing some issues with Steam networking performance and thread starvation.

I spent a lot of time debugging de-sync issues that some users were experiencing, and now a lot of lag / delay when processing packets has been solved. Users are no longer reporting these de-sync issues in their playtests and overall things appear to be a lot smoother and painless.

We added a new flag for Sync Vars that will interpolate the value of that var for remote clients over a few ticks. One way this could be used is for the view angles of a player, so if they're moving their view angles super fast locally, it won't appear to jitter and will appear smoothly for other clients too.

I added a way to test packet loss locally using a `net_fakepacketloss` command, and a way to change that in the editor alongside the Fake Lag setting. Using this has helped me resolve a bunch of rare problems, especially with Sync Vars that could happen if the user was experiencing unusual packet loss.

Over the past month and before the holidays, a considerable amount of other bugs have been resolved with networking and I'm continuously looking to improve the overal experience, as well as adding new and important features.

Over the coming months we will be looking at optimizing bandwidth usage.

Progress on the scene map editor will be ramping up. Making maps in hammer and loading them up with a map instance component is a awful process. The idea is to move geometry editing from hammer into scene so that scenes become the map instead of a separate thing.

If you're a mapper and you're concerned about this, remember that I'm not planning on doing anything majorly different than what's already in hammer. I'm just porting the mesh editing from hammer into scene.

Here's some more mesh operations I've added recently.

While making Deathmatch, we wanted to add an area in the menu where you can configure how the game is set up. We could've done this in a menu in the game, but we felt like it'd be much more useful as a general feature for everyone to enjoy.

Any ConVar that is marked with ConVarFlags.GameSetting will now be added as metadata to the game project upon publish - which lets us jump in and show settings in the s&box game list.

We had a problem with textures. If you wanted to select an image to use as a texture you'd have to convert the image to a vtex first. This was a pain in the ass, so I started to think about how we could fix it and ended up rewriting a bunch of code.

Now it's awesome. You can select images and it'll automatically make a transient texture that you don't even have to worry about. You can even modify the input image, like change its size, and flip it etc.

But there's more. I realised that since we were generating textures from on disk images, we could generate them from other stuff. Like colors, radial gradients, linear gradients, random noise, perlin noise, text, emojis and svgs.And there's even more. You can code your own texture generators, and it's really stupidly easy.

IES data contains photometric information detailing how a particular light source casts its beam through it's radius and axis, stuff like a spotlight having a cool circle and so on.

You know how there's audiophiles, there's the same for lights it seems.

I've implemented yet another decal renderer to the engine, but it'll obsolete all the other various ways to do decals from before (projected_decals, static_overlay, decal shaders).

Instead of rendering on top of the scene, these are rendered as part of the models themselves. Because of that they inherit and inject PBR surface materials making them perfect for graffiti, tattoos as well as all the traditional use cases such as blood, bullet holes, and more. They work on transparent surfaces now as well.

These are incredibly performant and you can have 1000s decorating your scene's geometry with no additional draw calls and no noticable performance drop.

These are not traditional materials but instead rely on textures, thankfully Garry just finished texture generators so you can select any png without creating a material or vtex. Or you could make use of the texture generators and use text or svgs or more.

I've written some documentation on how to get started here.

We refactored our shader system to reduce the number of permutations, lightmaps are using modern rendering now and the shader knows when to load its data rather than needing to duplicate the compiled shader for that. Makes it much easier to work with this too.

Your shaders are half the size and compile twice as fast now.

ShaderGraph got a well-needed overhaul this month, taking a lot from ActionGraph's recent developments.

Certain nodes now have custom visuals, such as Texture Samplers, Binary Operations, and more.
Default values are also displayed on an unconnected input (if there is a default value)

You can now change the Domain and Shading Model of your shader, allowing you to create both Unlit and Post-Process shaders. This makes ShaderGraph much more versatile and opens a lot of doors for artists.

Certain nodes are now color coded (green is a subgraph, blue is the result node) and you can also enable grid-aligned wires (which just look a lot nicer)

You can now create your own custom ShaderGraph nodes without the need for any C# or HLSL knowledge. The video below shows me adding a custom node I created, hooking it up, and then opening the containing graph to show how it works (and then opening a graph within that graph)

You can instantly create a Shader Function from your existing nodes with a simple right click action

Or create a new empty Shader Function through the New Asset prompt

Inputs are defined using Constant nodes (just like the ShaderGraphs themselves) and outputs are defined on the Result node via the Properties inspector.

The more tech-savvy can also create their own custom nodes with C# and HLSL now by using GraphCompiler.RegisterFunction (no need to edit the base addon anymore) 

We've expanded our hand tracking implementation with improved APIs and more detailed data access: you can now get precise joint positions for each finger with support for different motion ranges. We've also added detection for whether hand tracking is active, allowing you to adapt your game's behaviour accordingly.
For developers, we've added a VR toggle button directly to the editor.

Our latest synchronization code has significantly reduced stuttering and performance issues - VR should feel much smoother now, especially in complex environments where there are lots of draw calls.

VR now has a proper dedicated menu system based on the flatscreen one; we're still working on this, especially when it comes to adding the overlay system for things like the pause menu. Eventually we'll have a perfect native VR experience when navigating games and game options.

Our previous scene undo system was slow and partially broken. This has been fixed, the new system is faster, more reliable and should result in a smoother editor experience.

If you want to add custom undoable actions to your editor tools check out the documentation on the new undo system here.

We've been working on our spline toolset. Those tools include both a general purpose spline class but also an experimental Model deformer.

You can grab the current version of the tools from scene staging . Over the next months I'll migrate the spline features over to the core engine.

We moved a lot of our Navigation code from C++ over to C#. Functionality is still the same and surprisingly performance is too.

Having the navigation code in C# will make it a lot easier in the future to iterate on Navmesh features like Nav Links & Nav Areas.

We've improved the performance when cloning GameObjects.
Cloning GameObejcts is now up to 6 times and cloning Prefabs up to 3 times faster.

Line renderers now support lighting and fog, the same as sprites and particles.

We've been continuing to make improvements to the editor experience so things are generally nicer to use and faster to work with. There's been lots of little changes, but here's some of the highlights that make for pretty pictures:

The gradient editor has been revamped with UX changes and support for presets, as well as handy tools for reversing and distributing the gradient points.

There's now a proper audio widget built into the inspector to preview sounds, you can jump around freely and inspect the waveform too. This replaces the old asset browser behaviour where we'd play previews in the background, and you can now turn auto-play off. I listen to all my music this way now.

We've added support for custom asset pickers per-resource type, and soon we'll be adding specialised pickers for common types so you can find stuff faster. Stay tuned for that.

Modern engines for a while now have made the move to calculate skinning in a compute shader instead of vertex shader, this has a few benefits. 

GpuBuffer is a new C# class that lets you create, read and write arbitrary data on the GPU. It can be passed to any type of shader both compute and rendering.

These are various usage flags that can be used and combined together:

GpuBuffers also have a generic variant which automatically calculates the needed stride values.

// Allocate a GPU buffer that can store 2 elements of MyData
using (var buffer = new GpuBuffer<MyData>( 2 ))
{
	// Upload data to the GPU buffer
	var data = new MyData[] { new MyData { Value = 1.0f }, new MyData { Value = 2.0f } };
	buffer.SetData( data );

    // Pass the buffer to a compute shader
    ComputeShader.Attributes.Set( "myData", buffer );
    
    // Dispatch the shader
    ComputeShader.Dispatch();
}

Structured buffers support HLSL's IncrementCounter() API which can be accessed and manipulated in C# with the methods:

Because GpuBuffer can just be a vertex buffer or index buffer, we can just render these directly. This unlocks the ability to construct geometry and render it all on the GPU without ever doing anything on the CPU.

Here's an example of a waving plane calculated in compute shader and rendered with Graphics.Draw.

It can also unlock the ability to emit billboard quads in compute shader and rendered with any material. Currently, any time we want to render billboard sprites, it has to be done with a sprite shader that has just a texture. If we wanted to support sprites and particles with any material, this would now be the way it can be done.

Source 2 used OpenGL (std140/std430) layout for shader memory layout for compatability with its older renderers.

The main problem with this layout was the forced padding, everything would get padded to 16 bytes which would make it difficult to match the layout in C++/C# without adding padding, and would generally lead to memory inefficiencies where padding is unused.

We've switched to Vulkan's scalar block layout which lays the memory out in a C-like structure layout that's more memory efficient.

We've updated the minimum required Vulkan version to 1.2. This was technically already the case anyway because all the extensions we required were core to Vulkan 1.2, but this formalizes our supported feature set and makes minimum system requirements clearer.

The main features of Vulkan 1.2 that we're using are:

Device support should be the same, these are the absolute minimum devices that support Vulkan 1.2:

Light cookies didn't support animated texture sheets, now they do. If we allow the new texture generators to create animated sheet data, this could be used for some cool effects.

We're building a timeline tool for choreographing cutscenes and eventually exporting videos. You'll be able to describe how almost any property in the scene changes over time, and trigger bits of code to run on cue.

You'll be able to edit using keyframes, or a motion editor like in SFM. This lets you sculpt movement in a keyframeless way, with lots of control over how your changes blend with the existing choreography.

When the basic feature set is complete we'll move this into the engine. You can play around with what we have so far in our testbed project.

It feels like we're getting somewhere.  We have a lot of work to do still, but it feels like we're making awesome progress in a lot of different areas.

There are a lot of unknowns in our future still, but every month things get clearer as we continue to push things forward. It's still too early for me to fully think about release dates, but it's no longer unimaginable.