Advanced Zedonometry
1 1

11 posts in this topic

Recommended Posts

az-712x462.jpg

Happy Thursday all. First things first:

PROJECT ZOMBOID 40% OFF, NOW AND ALL WEEKEND. TELL YOUR FRIENDS. ALL YOUR FRIENDS. Etc. Etc.

(Sorry about all this.) 

So anyway, it’s been a week of fixing stuff on the animations build generally this week – and usually we’d be doing a ‘sorry, dull blog today’ blog.

HOWEVER some of you might find the deeper elements of the animations system interesting, and we’re also secretly hoping that a fair few of you will be interested in digging into the dev/modding tool yourselves once AnimZed is released alongside Build 41.

Sooooo… Zac has kindly written something up for us that’s a bit more technical than we usually talk about – but thankfully RJ has also provided a quick vid of something fun he’s implementing before we get into the nitty-gritty.

 

LIMPIN’

What you can see in the vid below is our first pass on the various animations that can impact on your walking and running – all of which will get some balance love before any test release.

First off the video you see a scratch cause a light limp – and a limping run. Burns will also have the same impact, alongside cuts – a new injury type that’s somewhere between our existing scratch and deep wound.

After this: a deep wound that triggers heavy walk limps. You can still try to run, but it’ll be slow – on a par with the walk speed with a light limp. Finally in the vid: a fracture. This is currently a heavy limp, but it will forbid a run. This will also be the case if you have glass shards, bad burns or a leg bite.

Okay, with that all explained: here comes the science.

Over to you Zac.

THE ANIM PROBLEM

The Animation system needed a big quality pass. Plagued by dozens of tiny issues with snaps and odd transitions, the system was functional – but a rough diamond in need of refinement.

 

THE ANIM OVERVIEW

So, basically, the Animation system is divided into three layers: the AnimState, AnimNode and AnimTracks.

The AnimState handles the big picture: what the character is currently doing. For example, the character is standing idle, walking, sneaking, and so on. The character can only ever be in any one state at a time.

Next layer down is the AnimNode. These handle the middle-detail of what the character is up to, like walking while holding a crowbar, sneaking while walking sideways, etc. The state determines what nodes should be active, and assigns a weight to each. As nodes come and go, their weights are faded in and out.

Finally, the bottom-most layer is the AnimTracks. These are the fine-grained animations that get mixed and applied to the character’s bones. Tracks are also weighted and transitioned, similar to nodes.

One of the common issues we had was visible snapping between nodes. For example, when a character goes from strafing to sprinting, while holding a 2-handed weapon, the weapon would go from being nearly vertical to suddenly snapping to being horizontal, in under 3 frames.

image-1.png

THE FIX

The first step was to refactor the code itself. From the ground up, the code was tidied and tightened up to be cleaner and more efficient.

Next, it was a matter of finding out exactly what the weightings were at the time the issues were occurring.

There was no easy way to make the game stop and show us the data. There was no crash, no exception, no stackdump.

So, a recorder was written up to take the values of weights and times, and dump them out to the console in a comma-separated format. Next, it was a simple matter of putting it into a spreadsheet, and having a close look at the various curves.

image-2.png

It was immediately apparent that the curves were not smooth. The blending algorithm needed some work.

So, we needed to use math(s).

THE MATH(S)

image-3-1024x474.png

A set of quadratic tweening functions were written up, called EaseOut, EaseIn, and EaseOutIn. A square-root function was also written, but turned out to be too CPU-intensive for what it was intended.

image-4.png

The AnimNode weight transitions were upgraded with these easing functions, and pretty soon we had some nice and smooth transitions between nodes.

image-5-1024x356.png

The AnimTracks got the same treatment, and transitions between tracks became much smoother as well. The number of snapping issues greatly decreased, and much joy was had. However, a few issues continued to stubbornly evade us.

Deciding to focus on one issue at a time, we chose the crowbar strafe->run transition. A video was taken, alongside the recorded weight data for states, nodes, and tracks. The individual frames were then painstakingly arranged alongside the generated curves, and then closely examined.

image-6-1024x451.png

Once the track weight curves were stacked and normalized, a problem became visible. There was a rogue Idle animation sneaking into the mix. Its weight would reach barely 40% before it disappeared, over a period of just 10 frames. This made us intrigued, but also sad and weary.

image-7.png

THE SOLUTION

With this clue, the field of possibilities was greatly narrowed. The cause was soon found. As the strafe node was transitioning out, it was still processing its blend-field. Even though the character was now in the sprint state, its strafe state was still active, and it thought that the character was standing still.

So, in its few last dying frames, the strafe state would blend in the Idle animation, just before snapping it off again.

With the root cause discovered, the solution was simple. Stop any transitioning-out nodes from applying their blend-field. The fix was made, and the last remaining snapping issues were conquered. HOORAY!

image-8-1024x351.png

 

LESSON LEARNED

There were a few lessons learned. Firstly, Math(s) is great – even when we got down to brass tacks and went old school on this issue.

zac-maths.png

The second was how helpful it was to observe, reproduce, and document every known issue in a visible list. Then performing a ground-up service and tune-up, systematically fixing each issue one at a time.

Finally, that it is important to have visibility on the internal workings of the system. Instead of relying on stop-start debugging, we need a mechanism for recording all state data as it changes over time, and present it in a human-readable format.

Thing was, the spreadsheet and curves were incredibly useful, but were slow and cumbersome to use.

So! We are now building a fully-fledged recording viewer as a part and parcel of the AnimZed dev and modding tool. Huzzah!

FrameAdvance.gif

We’re sorry this has been such a technical Thursdoid, easily the most involved one we’ve ever done, but in amongst all the cool vids we’ve been showing in past weeks we wanted to spotlight some of the work that’s been happening that’s not quite as sexy. (Well, not mainstream sexy anyway.)

We also know that there are some among you who really dig this sort of thing – but apologise whole-heartedly if you’re not. We’ll be a lot less clever-clever next week, and that’s a promise/inevitability. 

This week’s winter that’s coming from eHxAtoMiic. 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 hereOur Discord is open for chat and hijinks too!

Share this post


Link to post
Share on other sites

Thank you to help us understanding all the other side of your work! Go on you're making a very good game! 

Share this post


Link to post
Share on other sites
Posted (edited)
4 hours ago, nasKo said:

This made us intrigued, but also sad and weary.

I did a laugh/cry at this as I debug my own stuff at work. Very sexy 'doid.

Edited by trombonaught

Share this post


Link to post
Share on other sites

Really digging this thursdoid:wub:

 

It's great to get more insight in the technical stuff that's needed in order to get the shiny things done.

 

It's also good to highlight how much complex calculation is needed for Game logic.

Share this post


Link to post
Share on other sites

I understood as much as a zombie would from this post.

 

All jokes aside this goes to show what a good and smart team this game has and what type of effort it takes for things to get done.

Share this post


Link to post
Share on other sites

I love reading these technical posts, I know a few indie devs that do it.

Factorio guys do it often and Starbound Devs used to do it in Early Access

 

So if you want to do more, no issue from me.

Share this post


Link to post
Share on other sites

The limping  animations looks interesting I hope to see some zombies with a limping animation as well to show its condition.

Share this post


Link to post
Share on other sites

Studying to be a game and software developer in school, and being a huge nerd, I really enjoyed reading about some of the work that goes into one of my favorite games. I know most people won't like this stuff, but I hope we can occasionally get more dev blogs like this in the future, at least occasionally.

 

I haven't been signed in here in quite some time but when I read this on the website I just had to let my thoughts be known. :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
1 1