We're open now. Anyone can go to the give-me-that page and add s&box to their steam account.

I posted the link to the give-me-that page last week, just on discord. I didn't think anyone would take that much notice. I thought people would share it with their friends that wanted to join their development teams.

What happened is that gmod 2 is ready got posted everywhere, 50,000 people used the link, tried to play gmod 2 and got angry as fuck.

The game side of things was not ready for this kind of scrutiny. Our lobby system had a bug where a lobby could get in a toxic state, where the game wouldn't load, leading to a black screen. This happened when the lobby host got swapped to a joining client,  without any game info. Unfortunately I had written it so people auto joined the most populated lobby for a game - which ended up always being this toxic one with a bunch of people sitting at a black screen getting pissed off.

When people got in a game they realised that most of them were spewing errors. When they joined a map they had no toolgun, or spawn menu. 

Fair to say we didn't leave them with a good impression.

Finding and fixing these bugs had to happen eventually. And this enabled us to do that. It would have been great if we could have done it without leaving a sour taste in the mouths of so many people, but also without this amount of players this wouldn't have been possible.

And this wasn't the only bug. The burst of usage helped us fix a bunch of other bugs too. And the backend didn't get overwhelmed, everything scaled up really well.

And the thing that we've been working on, the thing that has been our priority - the engine - has been praised a lot for how easy and straight forward it is to use. 

The worst part of any criticism is when you know it's true. And while a lot of the criticism was true, there were a lot of misunderstandings there, that I hope I can clear up in this post.

For me, s&box is about minimizing regret. Unity has been good to us, but I regret that we didn't always have our own engine being developed in the background. I regret that the Garry's Mod community mostly have to leave Garry's Mod if they want to make money from the things they create in it.

So in my mind, s&box is broken into 3 sections.

The engine is the core of it. If nothing else works - we have the engine. I would like Facepunch to have an engine that we can use to create our own games. One that isn't Unity. One that we fully control. 

It would be great if our work goes into improving our engine. I don't want to pay Unity $500k every year so I can then pay my own staff to optimize and fix their engine. 

The long term goal is to be making all of our games on s&box, and to have expanded so the engine works on mobile/console/etc.

A Garry's Mod type platform, where there's a list of games and you can jump between them. But this time providing a way for the game developers to monetise.

Monetisation needs to be handled carefully. Everything you download on ios/android app store turns out to require a subscription. Every roblox game is pay to win. We need to do better than that. Let people make money, but don't let it get predatory.

For this to work we need games that get people sticking around. We're making games that will try to do that, and we'll be making an official sandbox mode too. We're also trying to encourage game creation by doing Game Jams.

In Garry's Mod, if you made a popular game, the next step was to abandon the community and make a new version in Unity or Unreal. That fucking sucks.

We want to let you use the s&box engine to create games, export them, give them away for free or put them on Steam. 

We don't want the burden of collecting royalties or license fees. The platform and our own games should make us money. That should be our incentive. We shouldn't be taxing your hard work, because having you use our engine is of benefit to us. I would also like to offer some assurance, legally, that we can't change the rules further down the line, when we get jealous about how much money everyone is making.

We obviously need officially Valve to say yes to this, but Valve are cool, they get it, I don't think they're gonna say no. They just need to know what they're saying yes to - so our aim is to put a demo together and see what we can do.

The main criticism with the last game jam was that it was closed access. That was a valid criticism, but it was also on purpose. We wanted to code and test the contest system in a controlled manner.

This time it's obviously open to everyone. The prize money pool is now £40,000 - which is double the previous jam.

I understand the concern that old games can be re-entered. Obviously the fact they've worked on a game for 6 months vs your 30 days is going to be in our minds when reviewing them.. so don't worry about that.

And ultimately - don't worry, this isn't the last game jam. Treat this as a warm up if you want to.

The dedicated server work has begun, you will find a sbox-server.exe in the game folder now. This is a work in progress, and isn't fully functional right now. I feel like there's a few reasons people want a dedicated server right now, and I want to talk about them.

They maybe think that the only way to monetise their game is via a VIP system on a dedicated server. That's fine, but I view this as an old fashioned notion. We will provide other, better ways to monetise in the future.

So maybe you're writing a gamemode and want to write into a database or something on your server, so the game is long lasting. You don't want people to get the database credentials. Yep. That's fine. I don't think we have a way for you to write serverside code right now though.

I suspect though, that if you're running code on your server, it doesn't need to be sandboxed and whitelisted anymore. I suspect that by doing that you can do whatever you want - like read a config file, or environment variables, or load other assemblies. So I don't see this being a big problem, it's just a goal we need to reach.

I worry about performance regressions a lot. We should always be getting more performant, not less.

So we made a benchmark system. It runs a bunch of tests on every version we build, and submits it to our backend. That way we can track the performance of each version, and see how it changed over time.

If performance has gotten worse, it's easy to go back and find the version that fucked it, and revert. 

If we're trying to make performance better, it's now provable whether that is working. You would be surprised how many optimization assumptions you make that change absolutely nothing.

We also get startup and shutdown times. Here you can see a simple cache in a low level system took startup time of our cubes scene from 9 seconds to 2 seconds.

We get a bunch of lower level information. The garbage collector in modern c# isn't a load of shit like whatever Unity uses, but this shows us how many heap allocations of each object type were made in each test, too.

You can run the benchmark by running benchmark.exe in your game folder. It's our intention that eventually all of your results will be listed on this site, which will let you track whether we've made things better or worse, or how different hardware configs change things.

We hear you loud and clear. You hate the citizen player model. You hate their sausage head. You hate their round eyes.  You hate their fat hands.

We will be removing the citizen and replacing them with a generic humanoid character.

We've implemented the Reverse-Z Depth Buffer technique, which is now standard in every game engine. 


This brings a massive improvement to depth buffer precision, drastically reducing z-fighting and allowing depth-based screen-space effects like SSR (Screen Space Reflections), SSAO (Screen Space Ambient Occlusion) to be much more accurate.

This is essential as we push for the creation of larger open worlds in the engine.

We mentioned above our plans for s&box - including the ability to export your game as its own executable. 

We've been working hard on this. We have it at a point where you can export a game as its own executable, with its own steam app ID, with functional multiplayer, and without a s&box requirement on the user's end.

Standalone games support everything you'd expect, including VR, local storage, and can have their whitelists disabled.
The trade-off here is that standalone games have no access to the platform - which means you can't use our backend to load assets at runtime, or post scores to the backend leaderboard, etc.

This is a super basic feature set and we'll obviously expand on this as time goes on.

We've been progressing and iterating on Terrain, improving on the stability and user experience.. Our ultimate goal is to create something to allow large open worlds easily and procedurally.

We've recently added:

  • Box3D physics (faster, more stable)
  • Terrain Material physics (sand or grass would have different footsteps, bounciness, etc.)
  • Importing heightmaps and splatmaps
  • PBR materials with auto packing
  • Cloud Terrain Materials
  • Custom shader API and a material override
  • Documentation!

Height blending materials creates much more realistic blends between materials.

Holes for caves.

The most obvious thing that's missing right now is foliage, grass & trees. We're working on that now.

One of the most crucial aspects of creating an immersive scene is lighting, until now our Scene system had really flat lighting and some things would not show up as you were editing.

Lighting in the editor should now be much improved. Cubemaps and indirect lighting are generated in the Scene viewport as you work, so what you see is what you get.

You shouldn't have to compile your map to see good lighting; you should be able to drop into a scene and see something nice right away.

The goal should be to make the editing experience as seamless and interactive as possible, yet not heavy on your system's resources.

You can choose to have this calculated when the probe is dirty or even as a fully dynamic lighting solution, there's a test scene that showcases dynamic indirect lighting.

This whole indirect lighting stuff applies for Volumetric Fog as well:

This solution currently works fine but doesn't have the granularity for fine details that VRAD3 or a full global illumination solution would give, that'd be the next iteration.

A lot of people have concerns for performance or that quality would not be as good as a baked lighting solution, being interactive doesn't mean we can't choose to precompute lighting, just that it shouldn't be a blocking step, and that the artist has full control if they want it dynamic.

I'd avoid traditional UV lightmaps in favor of a solution that's unified between objects, geometry and volumetrics and doesn't need artist input. There's been some good research done on DDGI and sparse voxel textures that strike a fine balance between performance, memory usage, and fidelity, which I'm exploring next.

You can now remap all of the Shortcuts in the Editor through the Preferences menu.

You can also create shortcuts for your own editor tools/libraries. Below is an example of how that is done. Adding or removing a shortcut attribute will register/unregister it appropriately when hotloading.

Source 2 uses an internal physics engine called Rubikon. S&box now uses Box3D.

This is still pretty much Rubikon, made by the same people but a version that we can get constant updates to. This has already proved valuable for getting quick bug fixes.

Our VR system now uses OpenXR for its backend, rather than SteamVR.
The main benefits to this are that we get loads of control over everything, we can expand our feature set much further, and we're able to support a much wider range of devices.

There are no major changes to functionality on the user side right now - if VR worked for you before, it'll still work the same now.

Model animation parameters can be previewed directly in the asset inspector. This is useful for seeing how a model is animated when you download one from asset party.

I've been working with the community to improve our particle systems. A bunch of features have been added, like trail renderers, start delays, model renderer, light renderer, spin forces and pull forces.

We have been working on a 2D Sprite Library that allows you to create 2D Sprite Resources that hold individual animations each with their own Origin, Frame Rate, Broadcast Events, and Attachment Points.

I've also made a video that shows how to get started with these tools so you can make some 2D games of your own. Here's an example of a project using these tools:

Within the 2D Sprite Tools, I've been working on an editor that allows you to divide a sheet into a grid of tiles, and then quickly delete/move/resize them to fit your needs.

Once you have a 2D Tileset Resource you will then be able to select the Tileset Tool to create individual Layers (each with their own tileset if you wish) and Paint to them.

We developed a first-person shooter we initially developed in a week for a challenge. We have continued to develop and polish the game into a solid FPS framework.

A sub-goal was to push the human characters, which we'll be improving on in the months to come.

The source code is available on GitHub.

A brand new 1v1 turn-based strategy game where your goal is to destroy all enemy bugs by slowly revealing their positions on the board. The game is inspired by Battleship, but instead of attacking a specific cell by calling it out, players must launch physics based projectiles using different consumable attacks. 

A chaotic pixel painting game where everyone can place one pixel every few seconds on a massive shared canvas.

A top-down 2D roguelite inspired by Vampire Survivors. Originally made in the Entity system, the game has now been re-created using the 2D Sprite Tools.

A top-down bomb survival game where you must blow up your enemies and be the last man standing!

Lots of big, bold moves this month.  Lots of plates spinning. It feels like sink or swim time for the platform. We either have to make it work, or give up on it. We're going to give it our best shot, but at the end of the day, if it doesn't work, then it doesn't work.

I am expecting August to be a quieter month. We have a hackweek, then I'm on holiday for a week (so the team have a Holiday Challenge), then we have the gamejam ending.