It’s strange when the words and phrases used on the radios and TVs of your own fictional outbreak start to be heard on real-life broadcasts. So before we get going this week (much as it’s not exactly the role of a faceless weekly development blog to say so – sorry!) we hope that you and yours are doing okay – and will continue to do okay in this period of uncertainty.
So anyway, the next patch for the IWBUMS beta will be 41.32 and it’s pretty much content-locked with some further polish/fixes to be applied before a release early next week. Content includes:
Okay this one’s going to get a bit technical I’m afraid, as we’re heading over to Zac who is deep in MP work – and while he’s in the guts of it then there’ll be a lot that many of us (including the blog writer) don’t quite understand.
With this in mind then, let’s head over to Zac and nod solemnly at everything he says.
“Right now I am taking apart the current implementation of a character’s networking packet format (known as ‘IsoZombie’) and rebuilding it to support the demands of Build 41’s new anim state system.”
“The overall objective is to transmit and receive the Zed’s AnimState, Orientation, Velocity, and relevant Anim Variables. The IsoGameCharacter, IsoZed’s ancestor class, features a pretty spiffy and complex anim state stack.”
“To transmit the contents of the entire structure would make for some unnecessarily large packets. Instead, we hope to take advantage of the animstate logic mechanism to eliminate a large portion of the required data transmission and remove a bunch of what was previously clogging up servers.”
“The end product of this will be simply transmitting the active state and substate GUID’s, and a few associated variables. From there the anim state’s logic mechanisms will take over and extrapolate the whole animation structure. Better still, this will also allow for the character to improvise in cases where data packets are dropped or in cases of lag. The data specifies a target position, orientation, and resulting state: and is then free to figure out how to get there in a convincing way.”
“This will mean that periodic drop-outs or lag shouldn’t cause the character to suddenly freeze mid-frame. The character/zed knows their last state and their desired state, and simply continue running their animation logic in that direction until told otherwise.”
“Say, for example, a character is walking in a straight line at a certain pace. The network feed drops out for a couple seconds. The character does not freeze. They keep walking. The network feed is restored, and we never even noticed it was gone”
“If, however, the remote character changed direction during the drop-out, the character now has to make their way from their current state to the new target state. They may do a 180-turn or even employ a jog/run to get there. It’s up to the anim logic. This should make for much more believable character behavior and make for a much more seamless multiplayer experience.”
“As for the savings this work would have, it’s all dependent on how complex the character’s state is from frame to frame, but we are likely to see anything from a 2x going up to 10x reduction in the required packet size – which alongside the synced MP clock that Mark has been working on and other work elsewhere should make for a far better experience for all PZ MP players once the work is complete.”
This week’s bandana shotgunning from Matthew. A general list of stuff added to PZ, and vids of features being worked on, is kept here – so you don’t have to plough through endless dev blogs for info. The Centralized Block of Italicised Text would like to direct your attention to the PZ Wiki should you feel like editing or amending something, and the PZ Mailing List that can send blogs like this and patch notes direct to your mailbox. We also live on Twitter right here! Our Discord is open for chat and hijinks too!