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:
Security: We used to allow developers to upload DLLs and verify them on the client side, this eventually became untenable from malicious IL modifications (ILVerify is very unreliable).
Compatibility: Changing or upgrading API methods is a lot more lenient from code archives, games were much less likely to break between major engine changes.
This worked great but there's a couple of downsides:
Load Times: Compiling code was pretty intensive, each game would typically take anywhere from 5 seconds to 60 seconds to compile the game, every time you started it.
Exposed Code: Your game's source code was available in full with comments and all. Some bad actors had started to abuse this. Obviously decompilation still exists, but it's at least a bit more difficult.
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 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.
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.
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.
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.
26.06.10
26.06.10
10 June 2026
41 changes in this update
add
Added
12 changes
Mounts can mount scenes (which would be maps)
Rewards progression system
Twitch API for reading channel and stream data from your game
More human heads to the model library
Tracy profiler integration for engine performance captures (developer builds)
Basic screen-coordinate 2D view for drawing in screen space
Light contribution settings and rendering options for diffuse, specular, and transmissive lighting
`[Uniform]` attribute so vector property controls can toggle uniform editing
Sampler support on terrain materials, and exposed terrain rendering attributes
`FormatOverride` on `TextureGenerator` (alongside a texture color-space fix)
Toolbar shortcut hints
Icon color parameter on the `AssetType` attribute. Thanks @rzkid!
north_east
Improved
12 changes
Precompiled DLLs are now loaded from the manifest instead of CLLs
Improved buoyancy behaviour
Reworked and improved the Terrain sampling API
Improved escape logic for reverb and occlusion traces
Terrain displacement can now move both up and down instead of only up
DSP Volumes now use the `TargetMixer` instead of being hardcoded to the Game mixer
`OnRenderBefore`/`OnRenderAfter` callbacks now fire once per object instead of once per primitive
`SamplerState` now displays correctly as a property
Binary files are tracked as compile references so `_d` files rebuild when changed
Addons can no longer increment Game Stats
Mounted file systems now resolve paths case-insensitively, with Zio updated to 0.23.0. Thanks @joshuascript
Prop gibs now inherit velocity in most cases, using pre-velocity only for impact kills. Thanks @Xenthio!
check
Fixed
16 changes
Fixed vertex paint and the fast texture tool having no lighting, causing black squares.
Fixed Sprite Editor "Import Image".
Fixed PNG mipmap generation.
Fixed Movie Maker keyframe widget selection quirks.
`Game.IsPlaying` is now correctly set on game load and on init in published games.
Fixed Indirect Light Volumes / Envmap bake warnings and a light-volume blotch artifact.
Fixed `CitizenAnimationHelper` NRE issues.
Terrain collision now also updates on terrain edit undo.
Fixed a `QScrollBar` NRE in `BaseScrollWidget.ScrollingFrame`.
Use `g_sBilinearClamp` instead of `g_sBilinearBorder` in Terrain shader.
Always create a default draw call so the first submesh reuses it.
Various mount fixes.
Fixed Shorts clothing LOD.
Restored original icon colors for `PrefabFile`, `SceneFile`, `Clothing`, and `Surface`. Thanks @rzkid!
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.
People will definitely try to create bunch of AFK farm games with names like: AFK Skin farm 30 minutes (1) AFK Skin farm 30 minutes (2) ..... AFK Skin farm 30 minutes (127)
And with achievements that will pop after each 5 minutes of playtime
I understand the motivation behind it, but its really easy to abuse and might replace AI slop games with AFK Farm games.
4 Games per week could be a big motivator for that i would decreased it to 1.
People will definitely try to create bunch of AFK farm games with names like:
AFK Skin farm 30 minutes (1)
AFK Skin farm 30 minutes (2)
.....
AFK Skin farm 30 minutes (127)
And with achievements that will pop after each 5 minutes of playtime
I understand the motivation behind it, but its really easy to abuse and might replace AI slop games with AFK Farm games.
4 Games per week could be a big motivator for that i would decreased it to 1.