Sandbox Logo
03 July 2021

June 2021

This month saw major level ups in UI, AI and player animations!
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!
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
Like every other month, the UI system got a ton of fixes and updates this month.

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.
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.
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.

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.
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. 💝