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.
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:
Unified our colour palette, sizing variables, rounding, etc.
Switched to a nicer font
Updated widgets, controls, docks to match each other for consistency
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.
Solution
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.
June Update
0.3.0
1 June 2025
126 changes in this update
add
Added
38 changes
::before and ::after to UI
New Prefab Instance System
Screen Space Reflections component
Dresser component - makes dressing avatars easier
Scene.FindInPhysics( Frustum )
Scene.Get<T>()
SequenceAccessor.Blending
ITagSet.GetDefaults
ParticleEffect.RealTime
Panel.SetRect
Plane.ReflectPoint
Plane.ReflectDirection
CameraComponent.BBoxToScreenPixels
Bitmap.Size
DebugOverlaySystem.Texture (draw texture on the screen)
Transform.Mirror
Application.OnWidgetClicked
Graphics.CameraTransform
Graphics.CameraRotation
Graphics.FieldOfView
Renderer CommandList wrappers
Renderer.ExecuteBefore (command list, executes before rendering object)
Renderer.ExecuteAfter (command list, executes after rendering object)
CommandList.DrawReflection
CommandList.DrawRefraction
CommandList.DrawRenderer
CommandList.DrawView
CommandList.Attributes.Set( bool )
CommandList.Attributes.SetCombo( bool )
CommandList.GlobalAttributes
Texture.Clear( Color )
TextureBuilder.WithInitialColor( Color )
Vector3.Dot( a, b )
[FilePath] attribute for string properties
accessors and constructor to Matrix class
Matrix.CreateObliqueProjection
Input.Suppressed
Gizmo.Draw.Sprite angle parameter added
north_east
Improved
42 changes
Editor theme improved - new font, color scheme and many tweaks
Shader memory layout changed to drastically reduce stuttering
Time classes internally use doubles for improved precision
Video Recording has been greatly improved for stability and speed
Human female🙍♀️ models look a lot more female
GPU -> CPU readbacks use cached memory improving speed
VR gets it's projection matrix from the headset directly
Updated Roslyn - your games will generate more optimized code now
GameObjectReference serialization for prefab properties
Create GameResource Save button when using a customer inspector
Improved aspect ratio in asset browser thumbnails
Select prefab/network root when selecting object in viewport
Blending mode on translucent objects, default alpha blending mode additive
Missing project settings button on asset projects
Input binds not saving
Dedicated server crashes when trying to use lobby methods
Error when in Eye Dropper tool of a list entry and the entry in the list is removed
Fixes a discrepancy between the hashed identity of TypeLibrary methods and MethodIdentity in WrappedMethod from CodeGen when the method is on a class contained within another class
BytePack struct serialization
TypeLibrary is disabled during cctors / package load
Context menu on normal files in the Asset Browser
Error when multi-selecting an asset and a normal file in the Asset Browser
Flickering when dragging material on to scene mesh
Tooltips linger when mousing out of a tooltipped pannel
Depth Linearization in Oblique Matrices
Crash in CSceneAnimatableObject::MergeFrom
[Button] not showing if not returning void
Fixed menu addon not loading in editor (due to whitelist)
ISceneStage spans the wraps the entire scene update, not just OnUpdate
Prevent EditorUtility.RenameDirectory making a directory a subdirectory of itself
remove
Removed
6 changes
Legacy particle system - legacy particles will no longer render
Prefab variables
Deleted many unused DLLs reducing the game size
Removed unstable GPU shadow culling
NativeRenderingWidget now doesn't render without a scene
Interesting idea about having prefabs work like interfaces. It sounds a lot like how HTML allows you to add new elements, you can define them but then hide everything so you just get a clean HTML tag with attributes, which hides the shadow DOM stuff.
With my Unity prefabs I tend to give them a dedicated script on the root object that controls any configurable properties for that prefab.
So maybe a good compromise solution here would be to add a prefab setting that locks all configuration for any prefab setting except the root object and its scripts and their properties. So you can still move it around or scale or rotate it or configure any properties on any script on the root.
This would be more of a developer control to indicate intent. Like controlling code styling. A dev could still go into the prefab itself and turn it off.
I've been wanting normal prefabs for a long time, and now there's the announcement of Sandbox Game (I remember Garry saying that s&box would be released after Sandbox Game). Thank you very much, good job.
Once I'm done with work, I'll go back to making games in s&box. All that's left is standalone export in Steam and private server code, and this summer is sure to be wonderful 💪
The honesty of Facepunch is peak. "We did something new... but it sucked, so we removed it and did what everyone wanted." is way better than "We made the great decision to reimagine our PreFab System(TM) to give developers the best experience possible."
Hey, I really liked working with S&box a few months ago, but now that I'm on Linux it's nigh impossible for me to use the editor. Are there any plans to make a Linux build, even if it's not entirely supported? I know C# is portable, so I'd assume it wouldn't be too difficult to build for Linux. It would be fine if Proton was able to handle the editor. There's massive flickering on the viewport, and a large black square covers it when playing the scene.
With my Unity prefabs I tend to give them a dedicated script on the root object that controls any configurable properties for that prefab.
So maybe a good compromise solution here would be to add a prefab setting that locks all configuration for any prefab setting except the root object and its scripts and their properties. So you can still move it around or scale or rotate it or configure any properties on any script on the root.
This would be more of a developer control to indicate intent. Like controlling code styling. A dev could still go into the prefab itself and turn it off.
Once I'm done with work, I'll go back to making games in s&box. All that's left is standalone export in Steam and private server code, and this summer is sure to be wonderful 💪