So some more character work and some weapon stuff from me this week. Having blocked out some character forms I needed to wait for them to be rigged and skinned so that we could eyeball the defamation and general shapes. So I moved over to creating some of the new hair and beard styles as they aren’t effected by skinning. Trying to get a better spread of shape variety than the ones we currently have in game. The textures aren’t final as we are planning to bake a bunch of these down onto one texture atlas.
We plan to have modifiable weapons, with a variety of attachments. So to test this we will use a pretty stock standard MP5 and give it a couple of scopes, stocks, silencer, and clip sizes. If this all works they way we want it to, we will go about adding a bunch more, both stock weapons and ones with more of a Hurtworld feel 😉
I’m in modding-town this week. You may have seen a new item appear on the Workshop in the past few days. It’s my little test mod for the upcoming expansion of the SDK! The Shigi Statue. Not a high-quality mod by any means, as that model is some real programmer art, but it does look pretty neat in a base!
All the ground-work is laid, and architecture built as far as I can tell. Probably still some kinks to iron out, but at this point you can make a bunch of construction attachments in the SDK, export them out as a package, upload them to Steam, and then just by putting a line in your server’s autoexec, it’s in and working! You can only add items to the Construction Hammer at this point, although we’ll be able to do items soon when ItemV2 goes live.
So how will this all look to a mod maker who wants to create their own set of pieces? Well, I’ll be making some documentation to explain in detail how everything fits together. You won’t have to do any coding or anything like that, and for the most part I think you’ll be able to find an existing piece in the default set that is similar to what you’re making and just adjust the configuration slightly. You’ll be able to use your own models, textures, and materials all native to Unity, or use our existing assets (which will make your mod super duper small and quick to download!). A server can also choose to not load the default construction pack if they want! So you’ll be able to do mods that completely replace the default set!
And how will it look to players? Well, you’ll just join a server as usual, and it will download whatever mods it needs. And you should be good to go! Workshop handles all downloading and updating. Good on ya, Valve.
There’s currently a few limitations that I want to try and get rid of before we go live, like the ability to define your own construction attachment point types in a mod. But we’re most of the way there. As always – I can’t wait to see what the community does with these tools. And I can’t wait to extend them even further!
Some good progress on ItemV2 this week. I’ve been punching on with the Unity animator system to allow me to drive our equipment animations explicitly while still letting Unity’s Mechanim drive things like walking jumping etc.
There are some cool APIs called Playables that are almost usable, but do to the fact that additive blending (layering animations over eachother nicely) are missing we are restricted to a few nasty hacks. Specifically the hard part is doing smooth transitions between equipment animations while explicitly setting the position in an animation we are each frame. The reason we need to drive the animation position each frame is to give us the ability to do things like attach a magazine mod to a weapon that gives 20% faster reloading. Trying to propagate that the speed of the reload animation needs to be increased, and by how much to ensure it doesn’t get out of sync with our simulation state machine is very tricky. What we do instead, is tell the animator each frame:
Set animation player to “Assault Rifle Reload”
Set animation position to 30% of the animation
Set animation player to “Assault Rifle Reload”
Set animation position to 31% of the animation
This works like a dream, and allows the state machine to drive the animations without double handling and leaving places for the animations to get out of sync. The problem comes in when we try to cancel the reload. We want to smoothly interpolate back to the idle position or to another animation. There is a Crossfade method we can call, however as soon as we tell the animator next frame where we want it to be, it trashes the Crossfade snapping to the new animation which looks like balls.
To workaround this, we were forced to drive the speed of state on the Equip layer by a generated parameter, and only explicitly tell the Animator where to be when it isn’t where we want it. If everything is working correctly, we set the speed of an animation before playing it, and call Crossfade whenever we want a change and allow it to play out. If we detect it has drifted from our own State Machine simulation, we force it back into place and let it keep going solo.
This is working like a dream now. What this means for us, is that we no longer need to think about how equipment animates. We build our equip state machine that controls the logic and don’t need to double handle anything. We can also now modify on the fly, any duration or speed property of any state in our simulation by parameters like Attack Speed, Reload Speed, Fire Rate, Draw Speed, Bad Melee hit recovery etc without worrying that synchronizing our animator is going to be a nightmare. As these properties are liquid, we will be generating random bonus values when procedurally generating items, rarely will you see 2 items that are created equal!
Once again, all these systems are completely modifiable as Equip is mostly state machine configuration which writes out to JSON.
Here is a complete state machine for the melee weapons in action in all its client side predicted, perfectly deterministic, arbitrary configuration driven glory:
‘Keep your City Beautiful’ Is not my motto.
I’ve been throwing garbage all over the place, trashing the city. I made some sets of boards that litter the streets, these help break up the road texture. I’m using geometry currently, which may change to a decal system in future, where texture is applied to create a similar effect.
When building the city I use a system of making geometry then fitting the geo into a part of the texture sheet that looks good. This means we save on texture memory and load times. The only downside is that we don’t make as many unique textured objects. The upside is we don’t end up like GTA V and have a billion year load screen and better performance. This is important, because we have a lot of players running some lower end machines.
I have added some fenced off areas with sea containers to reflect perhaps a quarantine/walking dead/martial law type vibe. This will give players some cover when moving up or across streets and helps fill the streets and break up the playspace.
I’ve changed the bottom floors to a two storey internal lobby situation. The shopfronts have changed to reflect that also. I will probably make a couple more general shopfronts to mix this up a bit.
This week I’ve been diving deeper into our equipment system working on integrating baking into our code base. With Spencer’s help we’ve been working on a new skinned mesh data format that will give us both a nice format for sharing custom gear through asset bundles (that can then be shared through Steam workshop) as well as allowing us to spread out the baking process over several frames to eliminate any frame rate spikes.
The plan is to distribute our base character model with the SDK allowing anyone to create their own equipment and then skin it to our characters skeleton so it will deform properly under animation. Once this step is completed there will be an importing step as part of Shigi Tools that will convert the mesh into our new format as well as run all the preprocessing we can to speed up the bake.
Generally when meshes are created they only store references to the bones that deform them (i.e. a character’s shoes don’t need to know anything about the arm bones).
Whilst this is efficient memory wise it creates a problem when baking as the final mesh needs to know about the entire skeleton, which requires joining the bone lists together and then updating the bone weight references to ensure they still point to the correct bone in the new list.
Another potential problem is when 2 equipment pieces are created and share the same bone (ie. the hats and the masks share the head and neck bones) but don’t share the same space (i.e. The hat might have its origin at the neck and a mask might have its origin at the nose). When this occurs you get conflicting data about the bind-pose for the bone (and this is what was releasing the kraken last week). The bind-pose represents the position of the bone in the skeleton when the mesh was skinned to it (relative to the meshes local space) and is used to transform the mesh into the proper position under animation. In the shot below you can see that the head model and the hair model have a different origin and orientation, you can also see the bind-pose for the neck bone according to both meshes, because bones to bindposes have a 1:1 relation per mesh we need to make these the same values. To solve this we have to transform all the meshes into a shared space (the characters root usually makes the most sense).
Luckily all this processing doesn’t have to be done at real-time if we push it into an import step when creating the asset.
It’s still going to be a little while until this stuff shows up in game as it’s being integrated into the larger overhaul of the item system that Spencer has been working on.
We’ve still got testing and things to work out with the best way to handle customization and random variations but we are really excited to see what you guys will come up with.