I've added a set of morph targets to the Citizen model so they're now capable of facial expressions!

This is very much a first pass on something that will evolve over time as Max works on the animation. Shapes might get changed or added if we're finding certain expressions are difficult to achieve, and the flex rules themselves still need a bit of setting up. Having said that, the system is already very flexible (and hella fun to play around with!)

Max has already set up some simple expressions that fire off when you shoot and I'm excited to see what we can do with them going forward!

I've also added some improved skin variation materials, as well some shiny new eyes that use a proper eyeball shader.

The Citizen animgraph has 3 design goals:

• It should be easily understandable (and commented thoroughly)

• It should be flexible and easily "scalable", from simple basic behaviour to fancier flourishes.

• It should prioritize requiring the least amount of input to get the most amount of features going.

It might look scary... but it's not too hard to wrap your head around!

Right now, if you wanted to add a new "holdtype" (a way to hold something, like a weapon) for your gamemode, you only have to feed in two poses: one standing, one crouching.

That's as simple as it gets: existing attacks are additives (so they'll fit on top of almost everything), and existing reloads don't necessarily *have* to line up with your pose. They might end up looking a little janky, but the blending will help.

But you can also feed in additional poses (and, of course, animations) to let things be fancier. For example, you could also put in a "long idle" pose: using logic entirely driven by the animgraph, if you don't move or perform any actions (firing, reloading) for a certain amount of time (~10s), the holdtype branch switches to a different pose with different look chains.

Check out how much more "alive" these little fellas look now!

Everything is geared towards being pose-driven as much as possible. This means switching between different paths on-the-fly. For example:

• IK chains & look chains enable and disable themselves at specific times.

• Each weapon branch is responsible for its look chains, and can switch to different ones with different damping settings. This is how the weapon gets ahead of the upper body, adding a little bit of delay, inertia and follow-through that gets things feeling a bit more natural.

• Upper body compositing uses different weightlists when idle, moving, or performing gestures (like reloading), letting more or less of the underlying movement animations through.

Now, everything is not perfect yet; usually, most of the jank I have to deal with is caused by unintended reset signals, waning values that lock themselves when they shouldn't, or vice versa. This is the real tricky part of the graphs, and I'm striving to leave notes about these edge cases in comment nodes, or in notes inside the nodes themselves. (That's a feature from ModelDoc that we have specifically ported over to the Animgraph tool—thanks Layla!)

And there's a few features that aren't used yet. For instance, the aim stuff in the video above? It's entirely "procedural" look chains. Once pose matrixes get added into the mix, aiming around will look much more natural. (But it's a testament to the power of Animgraph that things already look quite good!)

There are more nice little flourishes being added every now and then (the latest of which has been an additive directional blend used when flying around when noclipping). I'm hoping to create something similar for jumping.

There are also exciting ideas potentially made possible by the Player Controller now providing two sets of values: "move" (movement as it actually happens) and "wish" (describing player input). One idea on my list: when trying to air-control your character, the legs could be dragging behind your movement, while your upper body would instead lean towards your input direction.

Now that we don't have to deal with working from existing content (that is to say, HL2DM player models and their animation sets), one huge burden I'm trying to not have to deal with again is the multiplication of "holdtypes".

In Gmod, we had a dozen of those, often with very little differences.

With s&box, my goal is to have fewer, but tweakable types.

The starting point for that: the first iteration of this new "holditem" type.

The idea is that you can make the Citizen hold anything by specifying:

• The general body pose: right now, a 2x2 combination of narrow/wide item, spreading the arms & light/heavy, dropping the pelvis)

• The handedness: right hand or left hand... or both!

• The "attack" type: here, a medium throw or a far throw.

• The hand pose: select from a library of 18 (so far) hand poses, or any point in-between neighboring poses.

If you wanted to show the Citizen carrying a crate, your code would ask the Animgraph for a handedness of 2H, you'd set the body pose to 4 and the hand pose to 0.02, then you'd parent a crate model to the attachment named "middle_of_both_hands", which is always positioned in the middle of an imaginary line traced between both hands of the character!

If you wanted to show a grenade weapon, you'd instead set the handness to RH, the body pose to 1, the hand pose to 0.11, and you could switch the "attack" type between 1 and 2 depending on whether or not you want a small throw and a large throw (kind of like in the Counter-Strike games!)

There are compromises to find in the implementation of these systems: for example, I was envisioning, at first, a system that would use a variety of floats (bend/curl/roll/spread) so that you could control the pose of each finger very precisely. But... for now, a bunch of pre-made poses is "good enough", and in the future, it might just make more sense to just let people who want to have such precise control to somehow do it via code!

As the systems get extended in such ways, I find shortcomings to solve... well, that's really just a nicer way to say "decisions I took earlier are now getting in my way." And it's a matter of continuing to iterate more and more on them! ??

These parameters will spread to other holdtype branches; next on my list is being able to switch between a 2-handed and 1-handed (RH) pistol!

I fixed VR rendering, since starting the project we had worked a lot on improving some rendering flexibilities for Source 2 and adapting it to work for what we want but never validated for VR until now.

Getting VR in a good state has always been a concern for us and I'm glad now that I've tackled the initial work to have it supported.

This was just the first step, not much is bound to the actual s&box code yet, so right now the only thing you can do is being a passive tourist in your creations, but this opens the door for us to experiment with it and build something that everyone could enjoy and build upon.

AI is something I didn't want to leave as an after-thought, so I'm keen to prove to ourselves that we can have legit decent, extendable AI in addon code without falling back on any of the built in AI in the engine.

Making the navigation mesh feasible from c# is going to be a big part of that, so I started worked on that earlier this month in an addon called ai-lab.

This game functions more like an app where I can try a bunch of different experimental things. Above you can see it building the optimized paths for these npcs using the navmesh from the map.

We can see the NPCs successfully navigate around the map. It's not always perfect, especially when there's other NPCs around, but it's good enough to say that it works.

This is something I like to play around with, and I'm sure there's going to be people in the community that make better AI with it than I ever could. The functionality is there.

Like every other month, the UI system got a ton of fixes and updates this month.

Support for variables

Support for @import

New property: pixel-snap

New PanelEvent system

text-transform support

font-style support

letter-spacing support

text-decoration support

:nth-child support

Added UseTemplate attribute

Stylesheets adhere to css specificity rules

:not support

:empty support

:first-child support

:last-child support

:only-child support

Special pointer-events properties

backdrop-filter support

Improved text shadow

Improved text rendering

Improved image rendering

It's nice to make our UI system better and stronger every month like this. It feels great to be able to fly through all the old code and clean it up by switching to the new stuff.

Navigating a bunch of menus in game has a lot of pain points. So I tried to figure out why that is. We navigate webpages just fine every day - why is that different?

So I figured out that we need forward and back. It needs to work like a website. If you click on the wrong thing, you just press back, rather than clicking home and going through a list of things to get back to where you were.  The previous page should return instantly, it shouldn't load anything, it should just appear.

This encourages a ton more exploratory clicking because you have the comforting knowledge that you can just tap the side mouse button to go back to where you were.

I also wanted to make adding pages as easy as in a web framework. None of the pages should be aware of each other, they should open addresses and the navigator should be able to build that. So I made a system around attributes.

So navigating to this URL in the navigator will create this panel and make it the current page. Subsequent navigations to this url will re-open this panel. It won't be deleted and recreated.

As you can see here, this supports variables too. So you can navigate to "/game/facepunch.sandbox" and this panel will be created, it'll get a "game_ident" property and be able to look up the game information. Again, it won't recreate this every time, it'll create one instance of these for each unique game ident, so more caching.

This has proven a much nicer system than what I had before and makes the menu system a pleasure to extend, rather than a house of cards.

This whole system, the attributes, the lookup and the creation is written in addon code, so it should serve as a nice example on how to make similar systems in your games and addons.

Sometimes it's useful to know client-side when a network variable has changed. You can use this to update your UI or do something else so that you don't have to poll for changes frequently.

The home screen got a Citizen on the left. The plan is you'll be able to customize your citizen with new clothes, skin colour etc. Obviously whether the gamemode uses those customizations is up to them, but I expect where it makes sense they'll allow it, and where it doesn't they might at a minimum adopt the skin colour and re-dress the model. But obviously some gamemodes won't even use the citizen player models, so they'll do whatever they want.

The quick play buttons create the exact same game you last played in that gamemode. This is really great when you're developing because you can jump right back to where you were.

Overall this screen will be developed into a more hubby tile screen without all the empty space but right now it's showing what needs to be shown.

Writing FGD's by hand sucks. So lets decorate our entity classes and generate the FGD automatically.

This is a much nicer way to work. We're spending more time analyzing the way we work in Hammer and bringing it up to date. 

Something that came up was how we have two types of entities for a bunch of things. Like we have solid (brush based) entities, and model entities. That's not needed in Source 2, they're all just models.. so we can unify those into one entity.

I've said this before but I really feel that one of strengths with s&box right now is that we can throw shit away. Valve can't/won't do that, they have to remodel around all of the the old stuff that they want to support. We can bring in the dynamite and clear way for the future

I implemented the party system this month. The party system works like you'd expect, you join a party, the party owner joins a game - the entire party joins with them. 

I've worked to make this whole thing as frictionless as possible..

The number of people in your party is currently limited to 16. This isn't really a hard technical limit, it's just because I'd need to make special UI to support this amount of people.

If you're the party owner you'll get a yellow circle and be able to manage the members. You won't be able to kick or ban members though, because for some reason Steamworks doesn't have that feature. Apparently the workaround is to recreate the lobby and invite everyone but that person - which is both hilarious and dumb.

When the owner creates or joins a game, the party will follow. When they leave the game, the party will follow.

There's a few more things to decide here. There's voice and text chat, we need to decide how the best way for that all to work, but the fundamentals and the unknowns were done this month.

How about you start a game and instead of joining a dedicated server, or another player's game, it talks to a web based API. 

That API tells you where there are other players, where entities are, what the world looks like. Your client spawns those entities and keeps them in sync by constantly talking to the API.

This stuff is interesting to me. It's relatively unexplored territory, it has potential for games with tens of thousands of players on the same server. I think if we pick at it enough we can make something cool - or at least trigger the community to make something cool.

This month Rohan explored this by adding a websocket class to s&box. Then he made Towns as a proof of concept. In this game you connect to a remote websocket server, which then streams in the terrain and entities. 

You can't do much more than fly around right now, but it proves the concept and has highlighted a few areas we can make things smoother to support this better.

Another fun month for me. Got some overall progress, fixed a load of bugs, filled a load of requests, did some fun stuff. I'm still bursting with stuff I want to do, so it's exciting to be pushing things forward like this.

The rest of the team is smashing it. Self motivated, self managing, all pulling in the same direction. The community is making helpful requests and bug reports, they're fun to chat to, nice to be a member of.

I'm getting married in July and we're taking the kids on holiday for a week so I don't know how much I'm going to get done. I'm writing the month off from a work point of view, so anything I get done is going to be a bonus. ??