September 2021

When you open the console in game now you'll see a list of entities that are in the current map.

If you click on an entity you'll be able to see a list of its properties, which you can edit. This needs some cleaning up, but you get the idea.

This inspector marked a change in how we access properties on objects. Previously I had a class called PropertyClass, with the intention of deriving everything we wanted to access from it. This came with a bunch of attributes to give properties nice names and descriptions.

I didn't like that. We were re-inventing the wheel. C# already have these properties so we should use those instead. Accessing shit like this means that we can view objects that aren't derived from PropertyClass, and it works just like WinForms PropertyGrid. Which is ideal.

The entity list makes quite heavy use of bindings and UI panels, so it naturally highlighted a bunch of performance issues within the UI layout system.

I spent a day optimizing a few benchmarks I threw together, with 10,000 panels, and managed to get it performing on average about 6x faster.

This isn't the end of this, I've just managed to make the performance less embarrassing.  I think we can make things a bit more threaded to improve things further - but don't want to do that until I have to.

You can now connect your game to Twitch. 

This doesn't start broadcasting video or anything, but what it does do is connect to your channel so games can read the chat and interact with your viewers.

We're just finalizing the API right now so there's nothing super interesting to show, but this will create opportunities for games where the streamer can play with their audience somehow. 

It's not twitch specific. It's coded in a way that we can connect other platforms and they should all use the same API. We're just using Twitch as a trail blazer because nothing else seems to have a coherent API.

Garry did an example game in a couple of hours, but his stream didn't record. All that remains of it is this clip.

It's fertile mostly unexplored ground so it's going to take some experimentation to find ways that it could work, but this is what we like to do.

Just like the entity inspector, you can inspect your UI now. You can hover and click on panels to see what's happening with them.

The property sheet on the right is pretty much useless right now, but I'm hoping to make it more useful over time.

This month I continued making various environment props for construct. I finished a selection of items for the car park, various ticket machines, barriers and bollards. I have also produced a selection of fences and barriers that should prove useful. Lastly I made some new easy to skin fast food packaging items, for Lewis to skin and bring some extra detail in to the game world.

All entities can now have tags set in Hammer:

Tags are just a FGD type so you can add custom tag properties in other entities, like triggers.

This allows level designers to more intuitively control which entities can interact with each other among other uses, all without any extra filter entities.

Adding custom tag properties to your entities is as simple as this:

The TagList class then allows you to do everything you'd expect.

I got sick of looking at cl_showfps so I made a system for widgets. These are little panels that you can move around. Their position and visibility are remembered between sessions.

We'll probably find other uses for these over time, but for now they're a cl_showfps replacement.

You can now create shaders using the same workflow that we use internally.

To make it available to the public I have greatly simplified the common API, removing a lot of the needed boilerplate, setting complex parameters to be optional and making it easier to be kickstarted, this benefits everyone to not deal with have to deal with verbosity forever.

This is just a start but this gives a good starting point for the community to start meddling with their own shaders.

I worked a little bit on VRAD3 quality of life improvements this month

I wanted a better way for artists to control how vibrant their scenes would be lit, previously the only way to tweak how much indirect light bleed you have would be to change the power of the indirect light, this causes a lot of problems since it is not energy conserving, so it can look "off" to the eyes easily.

I have thought of a way to improve that for indirect lighting while respecting energy conservation.

This is similar to some techniques used in the animation industry to make colors pop more.

You can also use our Light Cookie system in baked lights now, it is set up exactly as in a dynamic light and will irradiate indirect lighting too, just tick 𝘚𝘵𝘢𝘵𝘪𝘤 in its properties

It's recommended to turn off light indexing if your cookie is multicolored if you use this in your maps.

Prediction is automatically disabled on entities that are physics based now. This is because their movement can't be predicted, since the physics engine isn't deterministic. Plus even if it was you'd be colliding with server physics objects, so it'd quickly not be.

This isn't a big deal. We're not dealing with 200ms pings here. If you're making a game where your pawn is using physics for movement, you probably won't even notice the lack of prediction anyway.

Additional to this, you can manually turn prediction off now too, this is done by switching Entity.IsPredictable to false.

Components like Unity. They're fully networked to client and can add as many as you need.

This is part of making things simpler, like the Tag system last month. If you want to associate some data with an entity, you can add a component now. 

As you can see above, there's everything you'd really expect here. There's more work to do but I think this is a good start.

Previously bots and bot commands were done natively. We decided it would be a good idea to move these to C# so you can create your own bot types. We kept in the bot_add command, which by default adds a Mimic Bot like it did before.

When writing your own bot class, you can override a method that lets you modify its input or copy its input from another player if you want to. There's also a tick method you can override for any custom behaviour.

The avatar editor is kind of functional now, you can change your appearance and it'll save and restore between sessions.

Games have the choice to use the user's clothing selection. This is obviously not going to suit a bunch of games - but it works great for a bunch of others.

It's up to the game to decide what they want to do with the clothes. They might want to override the clothes with some game specific clothes and use the skin and hair selections. That's their choice man.

I also bound Source 2's Curve editor data to C# so you can easily read the data and use it in custom entities and asset types. This is already used by ent_door for the open/close animation customization.

The editor is a bit awkward to use right now being so tiny, so in the future we should probably add a pop out editor as well.

I rewrote the way network variables are written to be more agile. Entities can have classes that have lists of classes that have classes that have lists of classes now. It can recurse pretty much forever.

This was a big flaw in the previous implementation, where you could have a network class but its children all had to be simple data types, and you also couldn't have lists of those classes.

This system should support more raw data too. This is something Layla ran into when making the voxel gamemode, that we had no decent way to network all the blocks. That should be a little bit more possible now.

It should be faster too. I was previously using a Vector of bytes to store the data. Which in engine meant that each byte was serialized individually - something that became apparent when you had 32kb of data on it. I found that the Source2 networking system can send straight up data via CUtlBinaryBlock - which has made things a lot simpler and faster.

I ended up rewriting this code about 5 times over as many days. I would lie in bed thinking about how the code I spent all day writing was a pile of dog shit, and then completely rewrite it the next day until it started to make sense to me.

Valve updated the Steam SDK with the ability to detect whether it's being played on the Deck, so I added that to the API.

The biggest problem I found trying on the Deck was that the screen was too small, so now we can zoom in a bit. The second biggest problem was that we can't navigate our UI system with the dpad. That was something I was hoping to get solved this month but never did.

We had problems with our font rendering. It always looked a lot thicker when it was a light colour on a dark colour. We'd played around changing the gamma of the alpha, but fixing it for light on dark always broke dark on light.

So I did some reading and it's a thing. Light on dark is more visible than dark on light, so the alpha has to be adjusted.

I didn't do enough reading to find out how to do that properly though, so what I did was make a html page and screenshotted it in the browser, then made the same page in game, then fudged around in the shader until it was kind of the same.

I wanted to expose the post processing attributes to coders. The things like saturation, brightness, gamma, white point, contrast, tint. It turns out that it's pretty much impossible to do it using the built in stuff because the tools generate a look up texture for the colour correction, so it's not just a case of changing a few variables.

So I figured we probably need a way to create our own post process steps. We can already create our own simple shaders, so only really needed a way to draw a screen quad at the right point in the frame render.

So that was easy enough. I'm not a shader guy but I managed to get DOF and saturation DOF working without much trouble, so pretty I'm pretty interested to see what people come up with here.

This month I've been working on branding for any models that need a true to life aesthetic. Trying to create logos that look and feel like something you'd see in your local shop.

We decided that it'd be better if a graphic designer created these elements rather than a 3D artist, since it's really what a graphic designer does.

I created a small library of stickers that we can use as decoration on models. These make things feel more grounded and lived in. You might recognise a couple of them from our other games.

Same as the stickers above, the posters are decoration to be used on models and in maps.

I created the branding and texture for Tom's awesome Burger Box model. The burger, fries and drink carton will all share the "Fast F∞d" branding from above so keeping a consistent aesthetic.

I've also created the texture for a paper bag that'll contain those delicious burgers. But you'll have to wait until next month to see the final model.

Hey another month where I spent most of my time playing with UI stuff instead of game stuff. I've really got to try to restrain myself with this shit.

Right now the game discovery, starting a game depresses me. If you want to play pool you really need to have someone online who wants to play too, and they need to know that you're sitting in the game waiting for someone to join.. and that's very unlikely. I want to have a go at making this whole situation less shit. People shouldn't be waiting in a game, games shouldn't have to code "waiting for players" sections, we should take care of that.

So that's what I'm planning for the coming month. Making that all less shit.