Neuer Player Controller

So - a week or so back I was talking to a survivor outside of Grishino, and I realized that he (and probably many others) weren't exactly sure what DayZ's new animation system, and player controller really effected via way of the development pipeline.

I wanted to take a moment on the forums to give people exactly what changes are pending the useable state of the new animation system, and in tandem the player controller.

First off - straight from our animation department, Adam will give you guys a brief explanation of what and why in regards to the new animation system.

"Why switch to the new animation system versus the old animation system

We switched to the new system because it became necessary with the things that we wanted to do with the player character in DayZ. Over the years, the older animation system has seen a lot of use, but with such a company wide use, there's a lot of features that get added to the animation system. Those features often don't have a thought out design behind them, and after a couple of years you end up with a less cohesive system that has a lot of small quirks.

The issues that we started to encounter quickly rose in numbers and they become increasingly hard to iron out, since something essential might be dependent on a smaller, but seemingly unimportant, feature. As the new player character required more actions, gestures, guns, vehicles, and other functionality, those quirks gets really hard to get past for us animators. In other words, everything was being kept together with glue and duct tape.

On top of this, the old system also consumed a lot of network traffic simply because of how it works. While 2 kilobytes of data seems insignificant over networks, any desynchronization with that much memory hinging on the player character being properly animated and responsive is dangerous. You can see the limitations of this in DayZ at the moment, as the animations don't feel responsive, and rather laggy most of the time.

In contrast, the new system has been through a heavy trial by several animators to see if we could do the same things as in the old system and how fast this system can operate in comparison. Within just a few months of us working on the player system we've been able to get most of the player functionality in, plus the additions of being able to arm/disarm yourself while moving and changing stance, or walking around and eating and still breaking into a sprint which then interrupts your tactical bacon feast."

From a design perspective, there are countless areas that are dependent on, or will touch the player controller itself - and thus on hold pending the new system being in game and functional internally.

- 3rd Person toggleable UI overlay
- 3rd Person overlay when in vehicles
- Character Soft Skills
- User Actions (change from the old style "start anim - finish - success" style to a more fluid per-time style system)
- Character Lifespan (Weathering / Beards)
- The move and rewrite of all base game actions to Enforce Script
- User controls balancing / audit pass
- Weapon Handling / Character Stamina

To name a few!

In addition, I frequently get asked why a specific bug might not be resolved yet, or why something hasn't been addressed yet in development that from a players perspective might seem critical.
There are a lot of things to take into consideration in development when weighing a bugfix, not to mention when you're dealing with a title transitioning from one engine, to another one that is *in development* Lets take a quick look into a brief break down of how the thought process goes:

- First off - what is the risk of this fix at the current time?

What are the goals for the upcoming build? Does this potentially represent larger issues that will push the build back?
Is this issue tied to a technology that is going to be replaced?
For example - Is this an issue tied with the legacy renderer?
Is this issue related to ongoing investigation of a larger issue with wider sweeping impact on the title?
If this issue IS tied to a system scheduled to be rewritten or replaced - what is the estimated time involved in:

Work resolving the issue itself
Test pass on the issue
Overall BVT test pass to ensure related issues are not encountered
Regression testing on the issue
A lot of issues consumers see in the way of:
Duplicating (Old action system)
Glitching into models
Damage / Projectile cheats
Balancing / etc

Are all things that are slated to be resolved, or at least mitigated with new technologies that are being worked on *right now* - so the hard decision has to be made - Do we potentially waste valuable development time and resources on something that will *not* end up in the shipped title? Honestly - we try to do that as little as possible. We still end up going a very large amount of it to try and keep the consumer steam branches as playable as possible, but frequently the unpopular and hard decision has to be made to stay the course, and dedicated those resources towards the final product / final systems / final technology.