The random drop reward system was pretty opaque. You didn't know why you didn't get your drop, you didn't know how close you were, you didn't know what you needed to do. So I've added a progress thing to the menu to make that more clear.

That should make things a lot clearer. Once you open your reward you'll be presented with three skins and be able to choose one of them to keep, for free.

Right now you need to play for 30 minutes on 7 days (they don't have to be consecutive), play 4 games you haven't played before (for at least 2 minutes) and unlock 6 achievements. These seem like obtainable goals and all stuff that should happen naturally through regular play.

Once you are eligible for a Reward, you get a nice little box containing 3 options for you to choose from 🥳🎉

Whichever reward you decide to claim is yours to keep, forever (or trade/sell/ect)

We've added rarity to some of the items. This rarity is only added to items that are only obtainable by drops and act as an indicator of the probability of them dropping.

Our human heads were from Rust - they weren't very attractive and they looked stoned all the time. I've reshaped a lot of the heads now to look more friendly, our intention is to retire the old heads completely.

Each time you joined a game you would download the code and compile it on your machine, we did this for:

This worked great but there's a couple of downsides:

Now when you upload your game it's automatically compiled on our backend and served to everyone. This drastically reduces loading times of games by anywhere from 5 to 60 seconds and by compiling on our backend we can ensure the security of the DLL before it's distributed to users. After this update is out we'll start removing cll files from public manifests.

There was a lot of infrastructure that surrounds this sort of change, and it's reusable - in the future we might recompile resources and shaders on the fly so we can continue improving the API without breaking anything.

Adding your Game or Map to the Play Fund now requires minimum quality levels to be met. We saw too much low quality, low effort shit being ploughed into the Play Fund.. seemingly in the hope that creating 50 low quality games would make as much as creating one medium quality game.

I have restored and improved the Twitch/Streamer api, so it's fully possible to make games that interact with Twitch again.

This API allows games to access viewer names and events like chat messages. The idea is that if someone is streaming s&box on twitch, they'll be able to play games that allow the people in chat to interact directly with the game.

This seems like a pretty fertile game to explore a whole bunch of game ideas that haven't really been possible before because the barrier to implement these things was too large, so I'm excited to see what new things will be created. 

If you're interested in making a Twitch game, I made a tutorial on how to use the new Streamer Api here.

If you're a streamer and want to try a game, you just need to start streaming on Twitch in your normal way, start s&box then find the game "Twitch Poop". If a game can interact with Twitch it'll have this purple button:

Click that and it'll pop up a box that will allow you link your account to Twitch. Once linked, you'll be able to enable the Twitch interaction by clicking the Start Stream button.

My example game is obviously pretty stupid, but like I say, this is a rich seam and I hope that game developers will spot some kind of possibility in this API and make some new, fun and inventive stuff.

I've added a new section to this website for Benchmarks.

In the game folder we have benchmark.exe which will go through a bunch of benchmarks when you run it. When you go to the benchmarks page you'll see a list of your results. You'll then be able to share them with your friends and compare your results.

One of the primary reasons we have added this is so if someone says the game runs like shit for them, they can share their results with us. That way we can see their hardware and their timings in all the categories we test for, and be able to diagnose exactly why it runs badly and optimize specifically for that.

Here's an example result from my home pc.

Added a new 2D View that's built specifically for making 2D games. In this view, +X is Right, and +Y is Down, matching the same coordinate space as other screen elements (like UI)

When building a game in this view, it means Vector2.Up/Down/Left/Right will ALWAYS correspond to the correct direction whether it's a UI panel, a GameObject, ect.

Some of our artists wanted a way to control specific contributions for each light, so you could have lights affect diffuse lighting but no specular, etc.

Engine already supported the but was never exposed, now it is.

Indirect Light Volumes needed some love for a while, seems they've been suffering regressions over updates, you'd end up with shit blotches all around specially as you increased density.

I've had previously tried to to tighten visibility checks for each probe so that light leaks on thin walls could be minimized but that ended up being a terrible choice and caused a lot of aliasing.

Now it should be all nice and smooth, with the caveats that we recommend thicker walls if using it.

With this we can compress per-probe visibility checks without a guilt with BC6H too, making them 8x smaller.

I still want to iterate on Sparse Volumes & use Spherical Harmonics, that seems to be ultimate way to support higher detail, lower memory usage, no light leaks & cover large worlds, we have a prototype ready but should try to do it more incrementally so we dont use many months for it.

Our previous terrain displacement would move the vertices up, which worked great, but created weird transitions between different materials.

The vertices now also move down to keep the elevation between different materials consistent.

Terrain can now specify which texture sampler is used for rendering. This is useful for different art style where a more pixelated look might be needed.

You can change this setting in the advanced settings on the terrain component.

Our initial water buoyancy wasn't very good, things would keep bobbing up and down and never settle. Our improved buoyancy feels much better and we now have a component in engine for it.

We added a widget to the toolbar to show shortcuts that aren't clearly displayed anywhere.

Layers that handled Command Lists used to run on the main thread, now fired for in threads for different groups.

SSAO/SSR adopts own Descriptor Sets so their index is all handled in GPU to better work with multithread usage, instead of being passed by sequential Attributes.

This is an incredibly small change, but I made it so sampler states are now properly displayed as a component property in the editor, and can be actually edited from there.

By default, the only visible setting from there will be the filter mode, but you can always click on the right button to see the rest of sampler options. Might be useful if you want to configure whole sampler state for any reason. 

I added Tracy support throughout the engine, Tracy is another profiler but specifically designed for games with realtime nanosecond resolution that reveals performance blockers that just aren't visible with ETW based profilers.

This is internal right now, but if we can figure out a way to distribute it to developers without additional overhead on clients, we'd love to.