Neuer Wochenbericht - 02.05.2017

Dev Update/Hicks

Greetings Survivors!

As Eugen is covering what the current tasks are, that frees me up to talk about some of the mechanics and systems that we (Peter, myself, the development team as a whole) are looking forward to improving upon in beta and the milestones past that. Given that after checking the various communities centered around DayZ, I noticed a group of posts doing their best impression of the World War 3 style courtroom audience summoned by the Q entity in Star Trek's Encounter at Farpoint when discussing the current state of vehicles, I figured now is as good a time as any to clear up some things when it comes to them, in DayZ. (The vehicles, not Q's apparitions)

While I personally love the work Peter and the design team did on manual transmissions in DayZ, vehicle handling and mechanics as a whole are far from where we want them to be. The biggest culprit of this, obviously, is physics, and their handling on terrain. We did show some of the changes being worked on for that area of the vehicles, but many may have missed it.

It's fair to say that vehicles in DayZ's Alpha phase of Early Access have received the least amount of user visible love. Part of that is due to the complex physics situation in DayZ, as we still currently operate two completely separate physics systems. Another part of that is due to so much of the focus being on technology, and getting it in place to support DayZ as we want it to be. I'm looking forward to that, as from my perspective, vehicles are a critical component of mid-to-late game DayZ gameplay - and quite honestly, without them in a satisfying state, you tend to just end up with a walking simulator ;).

Let me give you guys a look at some of the areas we will be looking at improving into and throughout BETA.

Terrain handling / acceleration
SFX (Engines / Transmission)
UI (Specifically in the toggle-able HUD that we have shown before - so that 3PP players can see the same critical info 1PP can)
Feedback on vehicle damage state (Aside from damage materials, and doors falling off - think smoke from a damaged engine, engine stumble/diesel when running out of fuel)
Proper destruction of vehicle when it has been destroyed (rather than the current state of the vehicle just not turning on)

Don't think for a moment anyone on the dev team looks at vehicles the way they are now and says "Y'know what - that's perfect, ship it" - far from it. All of us are just as antsy and eager to see DayZ's systems start to flesh out and polish as we all want them to be - we just have to knuckle down and understand that the technology to support our vision needs to be ready for us to start implementing this.

This exact reason, and so much more is why all of us are so focused on, and excited to enter the BETA phase of DayZ's Early Access. I'll leave you all with that, as I'd like to put together Peter and I's thoughts on stamina, and weapon sway for the next Status Report. For now, just promise not to kill me on sight when you see me in Severograd.

- Brian Hicks / Creative Director

Dev Update/Eugen

Hey guys, as some of you have noticed, I have omitted listing audio changes as part of 0.62 update in the last Status Report. That was an honest mistake, but it also highlights what a dynamic place game development is. I'll try and have my contribution structured as a goal for the future Status Updates. Usually, I'll begin with a "story from development", just so you can see what kind of decision making is happening everyday, as well as going through the things we have been working on in the respective departments for each patch separately.

0.62 Strike Team Update & Development Story

This time, it’s a story AND a progress update - yay!

0.62 patch was originally planned for delivery (on Experimental branch) during the second week of April, but due to complications and cooperation on engine milestones, it became apparent that we needed to close them sequentially, rather than working on both at once. Remember that only small team is working on 0.62 at the moment, as almost all of us are focusing on BETA/0.63 delivery.

However, back to the topic at hand. Originally, that shouldn't have been that much of a problem. As we started testing the 0.62 update, we quickly found out that when we enable the new positional environmental sounds (basically the reworked Arma 3 tech introduced with the Eden Update that is becoming a part of Enfusion Engine platform), we encountered a crash.

The crash itself manifests when you switch window focus fast enough during startup, but it can manifest at any point, this is just the easiest way to get it. The crash is based around file system and resource management of our engine - one of the last remaining parts that are not rewritten for DayZ yet.

We have a couple of options now: We can either rework the content to work with the old system to make the new sounds function, but lose the ability for positional audio in environments, or fix the bug in the resource management and make the old system work with the new content and data.

We can also rewrite the system completely to get the pattern of these crashes fixed on the platform as a whole.

It might look like a small thing, but the positional environment audio makes the game much more immersive. And the issues go much deeper than that, as the same system might be causing some console performance issues (and more). To get an overview and make a right decision requires fast, but actionable intel. These things happen often when working with older technology, especially when you are in a process of refactoring it as well.

This resource management has been the culprit of many issues in the past, but so far it held the test of time. That might not be the case going forward, and might need some serious looking into.

[img width=700 height=525]http://i.imgur.com/iq8B98d.jpg[/img]

0.63 BETA Strike Team Update

As for the work with BETA Strike Team, I list them below. One line of text / bullet point usually means it's in the hands of a single person working on the feature and handling the ownership. However, be aware that I need to simplify it to make things at least a little bit digestible, so it's hard to strike the right amount of detail without basically reworking JIRA tasks to show them here:

Programmers

• AI script implementation
• Zombie behavior script representation
• Wind rework and debugs
• Inventory and item conditions
• Item spawn definition
• User actions in multiplayer
• Exhausted and hurt player animation support
• Network traffic optimization
• New version check (to prevent edge cases of connecting to a different build of a game)
• Lightning fixes (new lightning setup)
• Sound event manager
• Tons of crash fixing
• Tons of bug fixes

Animators

• Weapon mechanics animations polishing (unjamming, reloads)
• Inverse Kinematics poses
• Mocap (Player turns and more)
• Hit reactions on player
• Animation plugins
• Cow and Bull refactor for the new animation system

Designers

• User actions in multiplayer
• Player representation
• New item hierarchy definition
• New player and item spawn definition
• Inventory UI refactor
• Lifespan
• Tree fire geometry
• Tons of bug fixes

Audio

• Positional environment audio

QA
• Playtest 0.62
• Door rework priority assignment (standardized door sizes)
• Performance profiling in 0.62
• Client performance benchmarks in 0.62

[img width=700 height=525]http://i.imgur.com/WePCbGp.jpg[/img]

I know that a list is not the best way to present the progress, but might be interesting for the development folks out there. However, I would also like to make it much more representative. There are tons of things happening at the same time, and we are in process of visualizing the sprint in very near future and I`ll try and share our overview of BETA progress when things settle down.

- Eugen Harton / Lead Producer

Dev Update/Peter

Along with upcoming changes to doors behavior I wrote about in the past, another issue which we definitely need to address and solve is the wide variety of different widths and heights of door openings. It may sound like a marginal issue, but I encourage you to continue reading, and discover how it affects gameplay.

Nearly every opening in DayZ is unique, which is caused by historical reasons and non-existing metrics back then (we are using a mixture of different structures collected from Operation Flashpoint, Arma 1, Arma 2, and some new ones made exclusively for DayZ). Apart from the fact that doors with dimensions below ideal standard just look bad and out of place (not to mention handles placed in above knees height) and feel odd (especially from the first person camera), they are also hindering the "fluency" of player movement.

Character collisions coupled with old clunky locomotion are introducing unwanted challenge in such simple action as going through the door, turning doors into an obstacle. Internal tests made with both old and new characters show us that a minimum clear opening of doors in DayZ should have clear width of 120cm and clear height of 220cm, and these dimensions were established as required metrics.

[img width=700 height=239]http://i.imgur.com/DvKzbXw.png[/img]

Everything below causes issues with character navigation, and feels odd especially in first person camera, where opening seems very narrow and low due to camera FOV and perspective. Also the third person camera then shows unnecessary jumping down while going through the door (if their opening height is under 220cm). New doors metrics with their new behavior will add a lot to responsiveness and smooth movement through the environment and its obstacles.

As we are continuing to work on 0.63 version AKA BETA, programmers are getting rid of old systems down the road. Lastly, old player has been completely removed internally, and with it also firearms handling (that includes firearms action like chambering, reloading, shooting… etc.) and aiming model (which means sway, recoil, dexterity, aiming, holding breath…), together with melee fighting (traced swings…) are gone forever as these were integral parts of the old player.

This untied our hands as now is the time when prototypes based on design I mentioned in past Status Reports (8 March 2017 and 28 September 2016) start being implemented in close cooperation between programmers, animators and us managing the design and script side of things.

Rewrite of firearms also allows us to introduce mechanics like changeable gun barrels (we have 2 more barrels for AUG ready to experiment with), different muzzle speeds for the same ammunition type depending on barrel length (which helps balancing firearms between each other, or vice versa), different muzzle speeds for different ammunition type used in same firearm (pellets vs slugs anyone?), switching between scope and sights if possible (like AK family, AUG…) and refinement of, and more importantly, connecting already introduced firearms mechanics like unjamming, mechanism manipulation, chambering and others to the new animation system.

I just can't wait for the moment these systems will be fully re-implemented, as it will change the combat experience a lot in general.

- Peter Nespesny / Lead Designer

Dev Update/Mirek

We have finished network part of user action system as I described in my last Status Report contribution. It's worth to mention that this change has decreased network traffic from clients significantly and now our client on 0.63 sends (with some small exceptions) only input packets. This change will help a lot to resolve issues like late hits registration and it also should help to overall game responsibility.

Weapon system has received some new features, like changeable barrels and muzzles and support for attached grenade launchers. Basic implementation for weapon jamming is ready since last week.

And another small new feature - we're working on a system that will select communication channel for chat and voice automatically, so players won't have to change channel using keyboard cursor keys.

Apart from that, most of our time is still being spend on the new player implementation - tweaking movement and collisions, creating new weapon aiming system and connecting it all to other gameplay systems - we'll talk about these later on, when they are ready.

- Miroslav Maněna / Lead Gameplay Progammer