As referenced in last week's analysis of the Steam Reviews, there are a lot of misunderstandings of what s&box is and what it isn't. We haven't done a good job of explaining ourselves on the game side. It feels like we have done a good job of explaining ourselves to developers, but have trood in a bunch of dog shit when explaining it to gamers.

This week I've added a welcome screen to the game to explain some of the unobvious. This screen will pop up on first run, explain a few things, and make a suggestion to play Sandbox Mode or Sausage Survivors 2. The hope being that people who are coming here for the first time will read it and their first experience will be a good one.

Obviously, no-one reads anything any more. No-one is even reading this. They're probably being told what it says in a youtube video, or a tiktok video with fart noises and someone playing tetris at the side to make sure they don't get bored. But you know, at least we can say we tried.

We now have a random drop system. There are certain criteria to meet to be eligible for a drop,  and once you reach that threshold you'll receive a random item. These items can be traded and sold, like any other item. You can get one of these drops every week.

We want to do more with this system in the future to encourage positive community interactions, rather than purely play time. For this reason we've made our own programmable backend for it, rather than using the existing Steamworks system.

Right now your chances of drops are based on factors like games played, new games played, time played, reviews and game ratings. We'll tweak this in the future so that people who are positive community members will be more eligible for rarer rewards. We'll be keeping an eye on it too, to make sure it's not being botted and gamed.

You can see which skins have been dropped at the bottom of the Skin Metrics page.

This site now has developer tutorials. This started as a way for us to write smaller tutorials without filling the documentation without too much noise, but it's obviously way more useful if the community can edit them too.

This is accessible at https://sbox.game/learn - and is something we'll be contributing to and will be improving over time. Let us know what you think!

Trade Protection is active for the Steam Inventory items in s&box. You can read more about it at that link.

Basically there's no reason not to have it, and it's better to have it enabled sooner rather than later, so if we do stuff in game with the items we can show that they're trade protected instead of doing it retroactively.

Everyone had to implement their own chat into their games, that was stupid. Now there's a default chat, this makes a consistent platform experience, players can turn chat off, mute other users and filter naughty words.

For new projects this is turned on by default, for older projects this is opt-in. It can be toggled on and off in the project settings.

You can use `Chat.AddText( ... )` to add system text for notifications, or whatever you'd like.

This has blocking behaviour built-in, and you can disable the chat in your settings menu. You can listen to chat messages using `IChatEvent.OnChatMessage`, so if you want to filter for stuff like team chat, add commands to your game, you can do that. We have potential plans for first-party commands / chat channels in the future.

To turn it off, visit your project settings.

We'll probably add a few more things like chat channels, emojis, and things. But customization won't be too crazy.

Check out more here.

We have a "Voice" volume slider in our settings, but we were relying on game developers to implement this functionality themselves. This was shit, and as a result it didn't work for most games...

Now all voice transmission MUST go through the Voice Mixer, or some Mixer that is a child of the Voice Mixer.
That way games can no longer circumvent the "Voice" volume slider, and both players and streamers alike can rejoice in the fact that they won't have to hear another soul once muted.

I added a grid on the brush that highlights the underlying terrain resolution. If you find that you need more granularity than the grid, you should consider increasing your terrain resolution.

Fixed-function MSAA resolve doesnt allow doing weighting by alpha, if you wanted to take a high resolution screenshot with a transparent background, but with still RGB color, the edges of the background would blend linearly with the thing, causing it to bleed on edges of geometry.

If you have a translucent background, whether on panels or screenshots, it'll use a weighted MSAA resolve that blends perfectly in all cases, and easy to maintain if we move away from MSAA.

We shouldn't consider special cases where this should or not be used, should just work.

With the new C# Shadows we ended up with a minor regression that shadows would not fade smoothly if your object is transparent by tint.

Furthermore opaque fade would not work if you have MSAA disabled on the editor.

Both cases are now solved.

I'm not a fan of this opaque fade stuff and how we deal with Alphatest for hairs, at some point I really want to do proper Order Independent Translucency so we dont have to depend on MSAA for things to look smooth, but iterating slowly.

Clutter tiles will now select the closest LOD for instanced models. This works on a world tile level to make LOD selection faster.

Before we optimize anything, we need to know which areas to focus on, which areas are holding players back. Is it the GPU? Is it the CPU? Is it physics, is it animation? The answer changes dramatically depending on the hardware people are running.

This update we started collecting GPU frametime in our performance analytics. Combined with our existing CPU profiling we can now classify every player session as either GPU-bound or CPU-bound, and iif CPU-bound pinpoint which stage (render, physics, animation, particles, etc.) is the culprit.

I've then added a new page to our metrics, performance bottlenecks - this groups players into hardware tiers and shows the dominant bottleneck for each CPU x GPU combination.

This gives us a clear picture that we are almost always CPU bound submitting rendering work to the GPU, the GPU never struggles to actually run this work.

You can also filter by game and map to see how specific content shifts this balance - a physics-heavy game might bottleneck the CPU, where as a very art heavy map might bottleneck on the GPU.

The sample sizes are low right now, as the update rolls out we should have a very clear picture going forward.

We broke a few things while moving to our UI batched renderer. One thing that was lost is the ability to use custom rendering on panels. This is useful for more advanced UIs like minimaps, custom geometry or shaders.

You can start recording your own render commands like so:

 public class GlowPanel : Panel, IPanelDraw
 {
     static Material GlowMat = Material.FromShader( "shaders/ui_glow.shader" );
 
     public void Draw( CommandList cl )
     {
         cl.Attributes.Set( "GlowColor", Color.Cyan );
         cl.DrawQuad( Box.Rect, GlowMat, Color.White );
     }
 }

A smaller update this week because of hackweek but we still got a lot of important stuff done in just a few days.

We've been tweaking discovery still on the backend, pushing the good stuff forward and dragging the slop to the bottom. The welcome screen should help new players get a more positive experience too.

Tutorials are a vital part of the ecosystem, we've already been seeing many new developers trying out s&box, learning the toolset and creating new experiences for everyone to play.

The performance data is leading the way with optimizations, now we know where the biggest bottlenecks are for all users across all hardware, we know where to focus our efforts.

We're getting what needs to be done, done. No slowing down - see you next week. 💪