Update 26.09.01

Putting games front and center only works if we show you games you actually want to play, so the discovery algorithm has been rebuilt too.

The old discovery page showed the same 31 games to everyone, picked using a few global metrics. That only covers 1.2% of the games on the platform. If your game wasn't in that set, there was no realistic way for anyone to find it.

The new algorithm gets that coverage to around 70%, so most games now have a real chance of reaching at least a few players.

You might wonder about the remaining 30%. Those are games missing the basics: no thumbnail, no genre, no tags, no screenshots... If you fill those in and get a friend or two to play, your game will almost certainly start showing up for other people too.

Games now appear in a mix of shelves:

Overall we hope this gives every game a fair chance of being found, and makes it easier for players to find something they'll actually enjoy.

I am aware that us re-doing the menu is a meme at this point, but the main menu has once again been rebuilt.

The common complaint we get is that there are no good games. I think there are good games but we're not sufficiently putting them in front of people. Their instinct is the click on the server browser and find games there, which is the wrong way to do things in s&box, so we've removed the server browser.

This redesign puts games front and center. We're trying to show you more games that you might like and showing you exactly what they look like by playing videos.

There is also music. This music is temporary. It's there to encourage us to replace it. This does come with a new Game.Music API and a MusicComponent that will make it easier for everyone to add music to their games too.

There's now a new Game Mounts page. The aim is to put this feature front and center and explain what it is.

Lastly we also updated the settings menu to align with the style of the new menu.

The game now ships with a fully playable native Linux client on Steam. This uses the Steam Runtime to provide a common set of dependencies and work across any distro.

People have been reporting good performance increases over the Windows version running in Proton. As well as big performance gains and stability on Steam Deck.

I'm sure we'll get snarky comments about Gmod and Rust's Linux support - this is different, we have made very deliberate choices to get here, we're open-source and we have the full source code and ownership of our engine.

We also got the editor shipping on Linux, this wasn't planned to happen as soon as it did, but the port of the client went so easily that a lot of the editor toolkit simply worked as well.

The editor never really worked all that well under Proton. And whilst there's obviously a good chunk of bugs still, the overall experience is so much better.

The only cave-at is this doesn't come with Valve native tools like Hammer, ModelDoc or Animgraph.

We've put ourselves in a very good position by choosing the right technologies that are open source and multi-platform like .NET, SDL3, Vulkan and more. This makes the burden of supporting multiple platforms much much easier.

So next up we'll be shipping a macOS editor.

Screen panels are drawn after post processing by default. That's usually what you want. But maybe you don't. Maybe you want your UI to get bloomed with the game, maybe you want radiation overlays to apply to the UI.

Well the ScreenPanel now has an option to render before Post Processing, which allows you to do just that.

Additionally, the UI can now render HDR colors, so you can make things super bright. The color parser understands basic multiplication now, so you can make colors brighter really easily.

background-color: rgba( white * 4, 0.5 );
color: #3273EB * 8; 

Linear, radial and conic CSS gradients are now rendered by the UI shader instead of baking an image. This means they're both smoother and quicker to generate.

I've gone through and made sure they're as close to 1:1 with the web standard as possible.. including positioned and repeated backgrounds, circle and ellipse sizing, pixel-based stops, transparent interpolation and corner directions.

The background-clip property is now supported!

I've been very bored of seeing rectangular UI in games, and wanted a way to draw arbitrary polygons and other shapes, but was lost on how to do it. Until I discovered the experimental CSS property border-shape.

With this CSS property you can define what shape your panels should draw in CSS:

border-shape: polygon( 25% 5%, 75% 5%, 100% 50%, 75% 95%, 25% 95%, 0% 50% );
border-shape: circle( 42px at 60px 45px );

I've implemented this in our UI renderer as SDF shapes, this means they're all lovely and anti aliased. You can give them border colors, you can give them drop shadows, etc. and they'll bit hit tested properly when clicking.

I hope this enables more and more creative UI in games!

Boxes, borders, clips and shadows all had different ideas of how round a corner was. This code has all been unified now, so they're all on the same page. It's also been improved on so the border radius can have h/v definitions too.

UI rendering is now done in Gamma Mode, which means that alpha blending looks a LOT more like you'd expect, like exactly like the web. I don't think anyone cares about this but it bugged me for a long time.

Gamma ModeLinear Mode

Heavily profiling the menu shook out some nice performance wins from the UI system. 

We were doing some stuff that doesn't really matter on its own, but starts to add up when you're doing it to 2,000 panels every frame, like inverting a matrix.

The text rendering is now unpremultiplied, which means it can be batched with everything else, leading to less draw calls.

Scrolling has gone back to not invalidating the whole layout - which felt really horrible.

 

Select two neighbouring faces and press L to continue the loop across the mesh, making long strips of geometry much faster to work with. 

Select Similar finds matching meshes and models from the current selection, bringing a familiar Hammer workflow into the scene editor.

I have updated how transform gizmo behaves with scaling and rotation. Before this update, rotating and scaling objects would not differ regardless of current transform space. This wasn't very intuitive and convenient, so now I've made it so using global/local spaces would have a difference for these tools.

Now, when resizing a group of objects in global space, they will be treated as one, from the centre of selection, instead of scaling each object individually. Resizing objects in local space will resize objects from their origin, just like before.

Rotating objects in local space will now rotate each object individually around their origin. Global space rotation stays unchanged.

You can now specify how do you want to set up initial materials on the model when creating them from asset browser and context menu. Before this, your model would have been always created with a default material group with a global override.

Now you can opt out of it entirely, and if you enable this option, you can specify which material should be used as a global override.

Scene tabs can now be dragged into whatever order suits the way you are working.

Hovering or selecting a bone gizmo now displays the bone name directly in the scene view, making rigs easier to navigate.

Our long term goal is to remove usage of Qt entirely. We've been evaluating alternatives and have decided that our best move for the future is to use our own Panel system.. because whatever we end up using we'll be wrapping it and making our own UI system layer from it anyway. If we're using our own Panel system then anything we improve for the editor will also be usable in game. It just makes sense to us.

So, as a first step, we've converted the Launcher away from Qt, and now uses the panel system.

This launcher comes with a few user-requested features. One of the most asked for is the fact that when you launch the editor it will detect it, highlight it on the entry, and not launch it again.

The road to replacing Qt will be a long one. There are a bunch of things that we need to implement, fix and improve on the panel system. Some of them have already happened. But to help us so that we have another app, in the bin/managed/ folder called PanelGallery.exe. This is a way for us to show and test the UI system.

The forums are much more forum like now, they should feel more familiar and easier to use.

Our documentation, API reference, tutorials and release notes are now all available in markdown by either appending .md to the end of a URL or through Accept: text/markdown.

Pretty boring stuff for humans, but exciting for clankers 🤖

We weren't doing a good job conveying our goals and progress, so we've updated the roadmap page and items. We've made it easier for ourselves to keep this up to date, as well as made it more consumable for you guys, each roadmap item can be clicked into a modal that has further details, links to GitHub and more.

We've had a distracted few weeks, but we're back at it now. I wanted to go over our plans, because I think I've mentioned them in the discord but not actually wrote them anywhere, and with the player numbers being pretty flat I am sure people are worried.

This is our engine. It's the Facepunch engine. We're working on it because we're Facepunch and we think that at some point we'll want to make game using our own engine. I don't want us to rely completely on Unity. I don't want them to be able to change their mind one day and tell us we owe them 40% of revenue going forward. I don't want us to become Unity. I want us to make a free, open source, modern engine. So regardless of whether people are playing in the s&box platform or not, we're going to keep doing this, it's an investment in our idealised future.

That said, we obviously want the platform to be successful. We want people to play games on the platform and enjoy it. We want people to make money from the platform. We want it to pay for its own development. So we're going to keep trying to encourage that.

The next step is a Game Jam. This will happen this month (September) starting on Friday 4th. It'll have a total prize pool of £50,000. We're trying to engineer a system that is as fun for players as it is for developers. We want the players to vote for the winner. We'll likely do a free weekend or a sale at this point. There'll be more on this really soon.

Then after that will be a Christmas sale with cross promotion with Rust. The hope is that if we're selling to an audience of people that aren't die hard Garry's Mod enthusiasts, they'll be more likely to find something they like, instead of things they don't like.

Then next year we'll aim to do more Game Jams at regular intervals. We'll iterate and improve each time and try to get them to a place where they basically run themselves.

Then at some point we'll look at what we have and say to ourselves.. you know.. let's make a game with a whole new IP. Then we'll get a team internally making a standalone game on our engine and release it on Steam and whatever consoles are knocking around at that point.