We're going to be making a bunch of small scoped, polished, fun games. The first of many is Mini Motors - we've worked on this as a small team of a few people over the last 2 weeks, start to finish.

Mini Motors is a top down arcade racer which includes a bunch of maps, cars, pickups, achievements and leaderboards, where you can compete for the fastest lap times. You can also play against bots!

The objective here is to provide nice polished experiences for players but also to provide a learning resource in many ways to developers: the code is open-source to use as an example, and we've created tutorials based on the game on how to use the stats system, build ghost recordings and replay support.

In previous versions we supplied a code archive with the games. This was kind of like a zip file of the source code for that game. We thought nothing of it, because if you were using Lua in Garry's Mod the code would be right there, and dlls are trivial enough to decompile.

But you guys didn't like that logic, you didn't like that anyone could see your code. So last week we shipped it so we compile your code on our backend and ship a compiled, trusted dll with your games instead. This had the benefit that clients don't need to compile code, so games start faster etc.

This week we removed the code archive completely, so it's never downloaded and never shown to clients. So raw source code should be completely secret now. Unless you choose to open source.

We've got a mounts system in s&box that lets you play with content from your installed Steam games. This has been accessible in Sandbox mode for some time, but this week we've integrated it into the platform and stuck it right on the main menu.

You'll now see a Mounted Games list on the main menu and pause screen, where you can enable and disable game mounts. You need to own the game on Steam and have it installed on disk to mount it.

This replaces the old automatic behaviour in Sandbox, so you're in control of what's loaded, as we add support for more and more games.

With this new integration, and as mounts can now provide scenes, we've extended the map picker to include mount maps right alongside workshop maps — meaning you can now play on maps from other games, where the mount provides them.

It should work with any games that support workshop maps, and it works in multiplayer too, though other players will also need to own the game and have it installed to join.

This is still early days, and is fairly limited for now, but there's some really cool potential here, and just exploring levels from your favourite games with your mates - exciting stuff.

Our mounts editor side panel needed a bit of love, there's now a search bar and shows which mounts are installed or not and takes you to the steam page to install or buy games for supported mounts.

You can now inset faces in the mapping tools.

This feature was already in the scene editor but I've ported it to work with the mapping tools now.

Tidied up the unboxing scene so cards now show item rarities, particles display to hint at the rarity of the items inside, and the scene itself got a bit of a makeover. There's also a custom transition between the scenes!

Movie Maker's track list now features a sub-track search box, and various track creation bugs have been fixed.

To help everyone play by the rules, there is now a new page in the Publish Wizard which informs you of the Cloud Assets you are using and whether or not they:

a) Are elligible for the Play Fund
b) Require attribution
c) Have no set license  and should be used with caution
d) Are CC0 and can be used freely

We've got a few engine components that we ship as built-in projects, stuff like our UI components, and most of our editor tools. Until now, we'd recompile each of these from scratch every time you opened the editor, even though most people would never change anything here.

Now though, we build once when we need to, and the results are cached and re-used. If you do edit one for whatever reason, we'll recompile that one.

This should speed up editor launch times quite a bit. On my pretty decent machine, this cuts startup times by more than 10 seconds every editor launch.

A feature requested by a user to have a function that computes the penetration normal and distance required for 2 overlapped colliders to resolve penetration.

When working on mounts I would run into texture loading bugs, to debug this it would have been useful to inspect each mip level of a texture, so I added it, along with showing a checkerboard background to see the alpha channel more clearly and a way to see each color channel.

Like particles and world panels, the 3d text renderer now also has an option to face the camera.

I'm slowly going through our existing shader documentation and expanding all pages where it's possible. This will not be a fast process, but the goal is to keep all articles up to date, and provide information that has not been included there previously, which should make learning shaders a bit easier.

So far, I was able to do the following:

There will be more in the future, and eventually I will write a number of beginner-friendly tutorials on s&box shaders, which will be on the Learn page.

Our GTAO pass was taking up more time than we wanted so we improved it. After opening it up in a frame profiler I spotted a couple of things we could do better.

The first thing that jumped out was the three denoising pass right after the main AO pass.

Those big blue bumps are L2 cache throughput, and we were completely maxing it out by the sheer number of texture fetches those passes did. Every pixel was re-reading depth and normals straight from textures, over and over, including the exact values its neighbours had just read.

By doing some shader magic and a memory optimization called Local Data Share, we were able to reduce those texture fetches and improve memory throughput for those passes. Now each group of pixels loads its little patch into shared memory once, up front, and does all its blurring from there. This Halved the time spent on average on each denoise pass. From 0.12ms -> 0.05ms on average.

We also did various improvements to relieve memory pressure

We know our player experience isn't what it should be. It isn't meeting expectations. Our developer experience is shining star in s&box - but that's not what 99% of people see, they don't get that far.

So our plans are to keep improving the player experience, then do a sale and promotion. We have a few different goals to improve the player experience.

First of all, we need to do Game Jams again. They need to include the player community more. The jams should be aimed at getting players in game to play and vote just as much as they're aimed at developers. We 100% need to avoid the situation we've seen in previous jams where people reveal their game an hour before the Jam ends.

Secondly, we need to improve the Sandbox game. While we've resisted "subscribing" to addons in favour of cloud based runtime spawnable entities, I think we're coming around to the idea of the two systems co-existing. I need to personally spend more time developing and fleshing out the Sandbox Game.

Then we can do a sale and some promotion. We're going to do that once we're happy with the condition of everything. There's no point doing a Rust crossover and getting a bunch of new players that are going to play it once and be immediately turned off. 

We think that aiming to do this around Christmas time will give us plenty of time to tweak and polish everything that needs to be done.