Sandbox Logo
01 May 2022

April 2022

More bleedin' tools.
From day one we wanted a way to extend models with extra animations, you
can now do this by using a base model and adding new animation nodes.
The model will reference the base model and include the extra
animations without having a whole copy of the data for the base model saved into the asset.
You can now press F6 to start recording a video of the game, these get saved to the screenshot folder.

The engine came with code to record video but it was very slow. I made it stupidly fast by encoding the frame buffer on the GPU - this allows it to record video without affecting performance.
The little red border tells you that the game is being recorded, this doesn't get saved into the final video.
I have started to add support for group nodes. This is a pretty complex feature that they added in the dota tools. We don't want to go running to Valve every time we want their updated code (although it would save me a lot of time) so I spent the time to add the feature myself.
Groups on their own aren't too useful but they open the door to supporting subgraphs that are saved as an asset.
There is now a window that lists all the available animation clips in the preview model, they can be dragged into the graph and added as animation nodes.
This saves a fair bit of clicking around just to add an animation node.
VFX Shader syntax was expanded to support classes and interfaces.

It works as you expect with inheritance and paradigms of object-oriented programming, all child classes override their parents and the results are all inlined, there's no runtime branching so it's has zero cost in runtime.
You can inherit a base class, make an interface contract of which method calls will respect, inherit a shading model, expand it, and the compiler will know which code path to use.

This is essential for organizing big shader codebases, and makes the vision for a new base shader API possible.
When materials are compiled they can generate textures. This will happen if you choose a color instead of a texture, or modify the texture in some way (like limiting its size).

Previously this used to name the new texture like this:
Where the 8c hash is generated from the properties you chose. This has been changed now so it names them like this:
The benefit of this is that we can gitignore *.generated.vtex_c and never see or think about them. Our build process calls contentbuilder, which generates them anyway.

I'd like to have taken them out of the file system completely, but this'll do for now.
With a better understanding of what the backend site is going to be used for now that we have better tools it was time to clean things up. So I did. 

The backend site (which we're now calling s&works) is now coded in serverside Blazor, which has made it more responsive and has a few extra features, like you can see who played your game and for how long, and explore rankings.
This was really me setting up a foundation for us to build on top of, since we needed some admin tools and I didn't want to write them on the previous iteration, knowing that I'd have to re-write them on the next iteration.

The API changed to a new URL with friendlier URLs too. I still expect the API to change over time, so I wouldn't build anything substantial based on it right now, but it's there if you want to try to have a mess.
I implemented css keyframe animations in our UI system. It only took a couple of hours, I should have really done it months ago.

The only real difference between our implementation and the real browser version is that each element can only have one keyframe. Personally I don't think that's a huge disability, so deal with it.

There is now a models window that allows you to bonemerge models onto the preview model, this is helpful for when you want to see how clothes will look while animated.

Something that's always sucked has been making maps for custom games.
There was a lot of hassle that I've spent the month removing.

Now you can simply choose any game from s&works and use the entities straight away within your map.

Grabbing the entities directly from s&works opened up a lot of ways to improve the workflow in general too, you can now easily filter entities used in games as well as search for them.

I've also added a recent entities tab, in theory this should contain a lot of your most used entities making it quicker to work with.
An additional improvement is double clicking a solid entity will take you to the Block tool where you can drag out your mesh entity straight away.

If you're in love with class names you can still use them too.
I'll be making further improvements based on feedback as always.

And like most of our code this is all available to you in tools addons, so anyone can modify / extend on this functionality however they see fit.
I wanted to be able to edit our custom assets like editing objects in Unity. I made a push on that this month.
Here's the old insector on the left, and the new inspector on the right. Clicking an asset property opens up the selector, like you'd expect.. except we use our own asset browser.
This is going to allow us (and you) to improve the asset browsing experience over time, in c#.

The asset definitions that generate this UI haven't changed, it's still just the C# code with attributes.  We'll probably save a cleanup here for a pain day.
It's important to me that property editors can be made in tool addon code. From a workflow point of view it's nice to me to be able to edit the code and see the changes immediately, but beyond that it means that you can create custom editors for your types.

So on the simple scale of things,  you have attributes like this that define which type a control can edit.
But then you can make editor widgets more picky. For example, this float editor is prioritized if the property it's editing has a [MinMax] attribute.
And the attribute is passed during creation, so you can initialize the control.
We also support generics for certain types. Like this type below, which creates a Flag property from an enum which has been marked with [Flags] or [BitFlags]. The <T> value is the enum type.
Sometimes when you're prototyping you want a sound for something but you don't really want to get into it that much. Wouldn't it be cool if you could just shout the sound down your mic..

It should be a time saver, but it's also pretty fun to just play with.
The editor is really starting to fill out now, to become more like I'd imagined. There's still some rough edges, but the bones are there - we just need to add more meat to them.

There's a few places we're weak at the moment. Collision rules are confusing, that's a big one. Another big one is sound design. We don't have simple things like sound occlusion and we could probably tap into bigger things like the daunting steam audio stuff. This is how I'm going to spend my time next month.

Something I mentioned to the team last week, which is probably apparent in this update, is that every month we're spending more time experimenting with creating games than doing engine and tool work. That's a good sign 🤩!