When we made the prefab system we wanted to try something different. We wanted to think of prefabs more like interfaces, where you'd expose only certain properties and objects to be accessed and edited externally.

Turns out that was all a load of shit. So we overhauled it to work like everyone would expect. Now when you drop a prefab into a scene you'll see all the GameObjects like you would expect. You'll be able to modify that instance of it, and apply changes back to the prefab, or revert those changes back to the prefab values.

You don't have to do anything to migrate to the new system, existing prefabs, prefab variables and prefab instances will automatically convert to the new system. Once you save a prefab or scene, contained prefab instances will be written to the disk in the new format.

In addition you can now also specify the transform of prefab roots.

We were really happy with last month's holiday challenge that we decided to continue work on this project - and we've been busy. We've added rollercoasters, staff that perform tasks in the park, as well as revamped the whole UI system. 

Theme Park is playable right now, check it out!

We've made some initial iterative changes to the editor UI - the first of many steps towards a more cohesive editor experience. We've mainly focused on the basics, trying to build a design language as foundations for more changes to come.

So far we've:

As an example - here's what the cloud browser looks like now:

We added a Bitmap class a while back. It's a really cool class. It lets you create a bitmap, load a jpg/png, clear it, draw on it, rotate it, save it as a png/jpg. It's a useful little class.

Now you can render a scene onto it. Just call CameraComponent.RenderToBitmap to draw straight to it.

This is particularly useful if you want to create thumbnails or something. It works both in editor and in game.

I did a sprint on the avatar system this month. My end goal is to make it so we can start adding community-created cosmetics in the same way we do in Rust. This was a stepping stone towards being able to view and rate them in the Avatar Editing scene.

The end result of this work is that we have a much cleaner, straightforward experience when customising your avatar. Citizen skin color and age are sliders. Changing the tint of things is much easier. Clothing is organised into groups and categories.

We've made adjustments to the female heads and body, making them look a lot more natural. Originally we were focused on making hair and beards work across male to female; which meant morphing the jaw and cranium, which resulted in the female faces looking uncanny. The picture below is a before and after of the changes made.

We've decided to rework the female heads, creating results that we are a lot happier with.

Alongside this, we've been working on how we tackle hair for the female human. A lot of our hairs were made with the intention of being androgynous, to work across the male and female head types. We're moving away from that and making sure all hair has female alternatives that compliment the female faces more appropriately.

Here you can see a new hairstyle we are working on that sets the bar of quality we are looking to make when created our adjusted female versions of existing hairs. 

We had a big problem with stuttering like many modern games, different combinations of shaders getting compiled at draw time causing hitches of anywhere from 100ms to 3000ms.

Most games usually solve this by prewarming every single combination possible at the loading screen, which is the long "compiling shaders" loading screen when you first play these games. It's difficult for us to figure out all the combinations that can be used on a UGC platform and honestly this wait kind of sucks.

Source 2 has a better solution with VK_EXT_graphics_pipeline_library, instead of recompiling the entire shader every time, the shader gets split into stages (input, vertex, fragment, output) that can be linked together very quickly at draw time.

This makes the number of shader compilations additive instead of multiplicative, this drastically reduces work required.

We weren't able to take advantage of this before because shaders had to be setup in a very static way, not befitting of a UGC platform or easy to use engine.

We talked to Valve on how to best support this dynamically, and within a few days they had made a solution in Source 2 🎉 We backported this to our engine and the results have been fantastic.

Broken Shaders

Games with outdated shaders will be hidden until you've recompiled and republished your game.
If your game is affected you will have received a notification.
This is unfortunate but it's a fundamental change and we've added a new system to avoid this in the future.

I've tweaked the website again. I'd taken it into sidebar hell, so I wanted to escape that. I wanted to make the site friendlier to new people, to explain a bit more and to be less overwhelming.

This new change has enabled me to divide the site into separate sections, each with its own custom header. I feel like that has made the site feel less cluttered and more digestible.

We improved the built-in screen recorder (F6) optimized performance and fixed various crashes.
Video quality can now be adjusted using the video_bitrate cvar.

Additionally we enhanced stability and performance across all our multimedia components (VideoWriter, MusicPlayer, VideoPlayer).

Our UI's stylesheet system now supports ::before and ::after.

I've wanted to implement this for about a year, and I finally got around to it. It works the same as on the web, it feels great to have this functionality in our UI system.. it's so helpful to have.

Previously, when razor panels updated and deleted their children, they didn't call the :outro. This was on purpose, because I assumed that it'd break everything and be unreliable/unworkable.

Turns out that assumption was wrong. It is sometimes unreliable and sometimes unworkable, but the rest of the time it works fine. So now you can take that chance.

The renderer component now has two new functions that allow you to set a CommandList to execute immediately before and after rendering.

Why would you want to do this? Maybe you want to render something to a render texture and pass that to the renderer, but only when the object is rendered. Maybe you want to draw something immediately before, or immediately after?

Our previous SSR system came from early development when we did not have the scene system or much control of the rendering pipeline, using a raster pipeline to mask objects and you needed a special combo to have it work on your shader. While it was nice it was completely unmanageable.

It's been reworked into a component all using compute shaders, with the same G-Buffer prepass system we have we can infer all material information to trace on screen.

Sharing the same thought how we handle ambient occlusion; as post for indirect diffuse, we treat SSR as post for indirect specular, so it just works on any objects where it's applied in the scene, the API is much cleaner so it can be expanded to expose any kind of reflection method you want to composite to an object.

The Play Fund pool increased in April. The top earning user got a payment of just over $5,000.

I get that it's not mega money,  not compared to Roblox and Fortnite. We're still in developer preview and still developing the Play Fund - so the pool is relatively low right now.

The good news is that in May we increased the pool too. And will again in June.

Particle effects now have the option to use game time or real time, for the situations when you want particles to play normally when paused or in slow motion.

A few months back we removed the source engine vpcf particle editor. These particles still worked, but you couldn't create or edit them. This update removes the legacy particles completely. If a game is still using them they'll just show up as invisible.

There are undoubtedly things that you could do in the old particle system that you can't do in the component based system. The good thing is that the new particle system is moddable, so if you can't do something you can write a component that will do it. And because it's a component that means it's way easier to make it configurable so you can re-use it in a bunch of different situations.

I never want us to end up with an engine where we have multiple systems running in parallel, with different levels of support. In general it's better to improve a system incrementally instead of completely replacing it. In this case we replaced it because we knew it'd be impossible to iterate on.

The engine now includes a component to easily dress your characters. This lets you either choose specific clothes to give them or use a player's configured clothing.  It also allows you to use the height, age and skin tint to customise your characters. This has been something that required some manual coding to achieve before, so hopefully this makes it a lot easier.

You can also select community clothing that has been uploaded from the workshop.

Things are shaping up. Everything feels brand new again. Our whole thing now is to look at what we have and find ways to make it better. Every day. The community is a big help there - thanks to everyone who is using the engine and giving feedback, it's a massive help.

I'm going to bite the bullet and start making the Sandbox Mode in June. I expect that this will start off being very familiar, and then get experimental for a bit, and then collapse back into a nice place. There are a couple of tent poles with sandbox mode that I want to erect, like making addons work again.