Another thing that we definitely needed to get done before release was the ability to localize shit. I've done this a few times before so it was quite easy to get going at a basic level. So that's what I did.

It's the bare minimum right now, I've got some bigger ideas for it - but we don't need any of that yet.

My hack week project was "After Dark" - a fixed perspective horror game in the style of classic PS1 era horror games. Navigate a dark and rainy city, fight off zombies and escape with your friends! You can play with 4 friends and you'll receive a completion time at the end of the level. You can play it in-game now!

I made lighting have correct energy conservation and fixed fog on Construct. 

Mapping is something out of my turf, but it's a step forward towards the goal we want for our flagship map.

For Hack Week myself and Rohan worked on a PvP Tower Defence game mode. Loosely based around popular mods from the Warcraft 3 days we we're looking to re-imagine and remake something that fits the countless hours we poured into the custom games section.

Here are some of the towers that got modelled.

Rohan got the AI pathing, health pools and towers attacking implemented. Towers can be placed in game and creeps will avoid them. The gamemode will refuse to place towers in spots that would block creeps from reaching the castle.

We've been giving access to the game out via the preview torture service. It's basically a raffle that happens every now and then. You click Enter to enter the raffle, then at the end of the countdown it picks a bunch of people and gives them access.

It's a shit way to give out access, but it's the fairest way right now. We're also granting access to people that show us good stuff they have made in Garry's Mod/Source Engine via the forums (don't forget to include your steamid).

Botting has been a problem with the torture service.. but it's inevitable with something like this. It's quite satisfying to add a new check on the backend and have them complain that their enter button isn't working though.

We reworked our internal system for managing shadows to resize the shadow partitions within an atlas, you can have as many shadows as you want without blowing the VRAM budget of your GPU.

Shadows that were previously very low resolution have also been fixed, the atlas now gracefully handles upsampling and downsampling of partitions.

Mixed light shadows, which are stationary on the levels also now behave much better, you should see less pop in for these cheap variants of shadows.

We can now control morphs in game code. This has been a feature that has been wanted for a while and opens the door to supporting lip syncing.

Here's a video of a user using this feature to control morphs via webcam tracking.

The plan is to create our own tool, starting with lip syncing and build it up from there. The faceposer tool included with the engine is complex and would need a lot of fixing up, it would be better for us to start fresh.

I made a wiki bot a while back that updated the wiki with documentation about the latest Api. Then forgot about it and never updated it again. I decided that the wiki isn't the place for  Api Docs.  It's too fragile and it's hard to keep up to date. The wiki definitely has a part to play, and should be integrated to easily link and reference the api docs.. but it shouldn't be THE api docs.

So I made this awesome system. When we commit code, it already builds the game and uploads it to Steam. So I made it after each build also send the dlls to asset.party, which can then build the documentation by using reflection.

This means the new documentation is available instantly, as soon as the game hits Steam. Here's what it looks like right now..

From a backend design point of view I decided to do this at runtime rather than generate a bunch of pages on change. This has meant that we can iterate quite quickly to make the site do what we want it to do (Thanks to Rubat for doing a lot of the leg work on that stuff).

There is another nice aspect of this. Because we have the dlls of this build, and the dlls of the last build, and we can parse them into these descriptive classes.. it's quite easy to diff them. Which means we can make a live changelog for the API.

There's a few more things I want to try, but I am really happy with how this has turned out so far.

In a platform like s&box you should expect the developer to have control over their creations, technical limitations should not dictate limitations on game design, thus the engine should be able to render as many lights and reflection probes as you can without the artist needing to know much technicalities behind it.

One of the main bottlenecks of traditional Forward Rendering is that performance is lost very quickly as you add scene complexity with reflection probes and lights.

We fixed that with a rework of our renderer, now parts of the lighting calculation are decimated in a previous pass in the GPU, this is commonly known as Forward+ Rendering, in our case, using the Tiled approach for it.

We now have the scaling benefits of Deferred Rendering without penalizing memory bandwidth or pixel quality.

In maps like Office we're seeing more than double the performance in some areas ( 60fps to 140fps )

This still in experimental state, and can be toggle enabled on the console.

Some more Outfits this months. Plus a few different hairstyles.

We've added Game Settings to s&box and you can use them to link to ConVars defined in your games. You can access Game Settings via the Project Settings, and they'll show in game lobbies so that players can change them before the game starts.

Currently Game Settings can have a bunch of different types: multiple choice, toggle, integer, float, or text entry. They can be linked directly to any server-side or replicated ConVar.

Ryleigh and I have been working closely together on Chippy and other stuff for years, but this is our first game jam together. The basic idea was to re-implement one of Ryleigh's old 2D prototypes in S&box, add multiplayer, and see what new ideas would come to us while playing around with it.

The original prototype has the player navigate a randomly generated 2D maze, with the twist being they can vault over the walls once every few seconds. They need to collect a key that opens the exit hatch, while avoiding the other denizens of the labyrinth.

We got the main game loop working in S&box within the first two days, while having a great time programming and testing together with one of us hosting a listen server. From there we started building on the idea, trying out mechanisms until we found interactions that let players co-operate, incentivised risky plays, or were just plain fun. We also added a bunch of varied enemy types that players encounter as they progress deeper into the game, and a simple scoring system with leaderboards for replayability. We rounded off the hack week by throwing in some sound effects, and Louie helped us with the environment art to make it look like a real game.

While we had a fun little game after hackweek, we'd like to do some final tweaks like add a proper ending and some more enemy variants. Overall I'm super happy with how much S&box let us achieve in a week, and can't wait to make more soon!

You can play Mazing right now in-game, let us know what you think!

No more will you need to memorize the magic numbers to convert your scales if you accidentally exported your model at the wrong scale. Now you can convert the units to engine units with ease

Myself, Tony and Louie worked on VR Table Tennis over the week.

We got a fully playable game with clientside physics, networking and elo.

I was expecting to reveal a lot of problems with the API, which is why we make these first party games, to expose the weaknesses in the API and fix them.

Instead we got none - developing VR games in s&box is great, the API is simple to use and hotloading makes iterating incredibly quick.

Me and Tony did some pair programming where I'd leave my headset on and he'd code changes based on feedback that I could instantly see.

Check out the source code on GitHub or play now in s&box.

For Hack Week I decided to try making a S&box game, since I didn't know much at all about S&box, Source 2, or Hammer (I usually work on Rust).

I came up with a basic game idea that I called Last Outpost. There aren't any other games quite like it, at least not that I've played, but the idea was sort of like an RTS or a tower defence except that the only unit is you.

- Fight against endless hordes of robot enemies.
- Killing robots gives you metal.
- Spend metal on base buildings.
- All base buildings act as power-ups for YOU.
- Enemies attack whatever they see; your base buildings or you.
- Survive as long as you can.

In the end unfortunately I didn't have time to get the buildings part working, but I made a map where endless enemies with basic working AI come at you and throw grenades, and the player has a jetpack and energy weapon that they can take them out with, plus a HUD with some stats and a fancy crosshair.

To be complete, apart from getting its missing features like placing buildings, the game should really support co-op multiplayer as well, but would need a big cleanup first.

Anyway, it's live and playable under the name Last Outpost, but please don't expect anything finished or polished. It's a very basic prototype and there's not much going on.

Internally I was able to pass on a few minor bugs I found in S&box itself, and learnt a lot about S&box.

So a different kind of month this month, with my two week holiday and hack week. It was really good for us to hear the feedback from the Chippy and Rust guys and see that they could actually figure shit out. They're all Unity users so it was really good to be reminded of our advantages and disadvantages there.

For me it has been a month about sharpening our goals. What are we trying to do, what is the bare minimum we need for release, what should we remove to make things clearer. As much as I dread going on holiday, being forced to slow down and reflect every now and then is really good for this stuff.

There are only a few challenges that lie ahead for us in terms of unknowns. After that everything else is easy, just needs implementing.. so it's really just about getting the work done.

I am going to be a bit sad when we do release, I am really loving my work right now.. but at the same time I am looking forward to getting stuck in experimenting with some game ideas I have.. ??