Beiträge von saiboT

This week, Brian is addressing how walkie talkies in DayZ are the new server-wide chat. Eugen is touching upon the complexity of DayZ, as well as some of the recent tasks of the entire team. We also feature Peter who shares exciting news about changing the inner workings of loot spawns (this will be an extra crunchy topic for any future DayZ modders out there!) Next up are our map designers Mark and Adam, and yes, they have some screenshots for you this time!

To finish it all in style, Baty is sharing a couple of photos from our trip to the real Chernarus, where we were filming the upcoming Q&A video last week. Let's get to it, it's a long one folks, but full of great development news!

Dev Update/Hicks

The last time we spoke I mentioned discussing the impact of sway, and the implications on gameplay. I think one of the overlooked aspects of replacing the animation system, and legacy player is the fact that this isn't just a "change" in how sway / hold breath, and the likes behave. With the legacy setup, early on Peter and I both supported adjustments to try and refine where it was sitting as an experience in game. Pretty rapidly we realized that where we wanted it to be, and what the technology would allow us to do were two things very much apart. Rather than wasting development time trying to iterate and iterate upon a system that was slated to be replaced, the focus was placed on functionally where we wanted to be with the final product.

Its important to understand that as I said earlier - this isn't just a change. This is a replacement of the technology and player - so the old methods for sway, stamina, and such are gone. As we move towards beta, and start getting those builds into the hands of players - then we can refine the new methods of sway, and get it to a point in which you still need to be aware of your stance, weight (hopefully!), and the amount of sprinting you are doing - but that it is entirely manageable and does not feel like this daunting and overwhelming rigid inflexibility it can become in some situations with the current legacy Steam builds.

In addition to this, Peter and I have also been spending some time discussing the implication of server wide chat (specifically VOIP). I've noticed aside from strong private shard communities like DayZ Underground - folks don't seem to be utilizing radios in game. While on servers such as that, I find the communication across the map with random players occurs far more often. Personally, I'm a firm supporter of radios being starting gear so that every player can opt-in to server wide communication should they choose it - but I'm still working on converting Peter to this mindset. One of the limiting factors I've noticed the community discussing is the rate at which radios consume batteries, and the hunt for batteries themselves being both unrewarding and difficult.

I know a lot of folks have expressed a desire for the old global chat (which personally I do not miss at all) - and some have also expressed an interest in the old kill feed. A default on global chat is just not something we ever felt had a place in DayZ. That said, it can easily be turned on for mod authors, a kill feed as well shouldn't be difficult to put together.

For Peter and I - the immersion of the radios themselves, paired with the fact that they effectively serve as an opt-in global VOIP, is incredibly attractive. As I'm sure you all recall - we increased their range greatly several builds back. Aside from availability of the radios themselves, and consumption of batteries, I think they represent where we'd like global VOIP to be. So I encourage you all to utilize them more, so I can convince Peter that they should totally be player starting gear.

C'mon - do it. You never know who will be on the other end.

- Brian Hicks / Creative Director

Dev Update/Eugen

Hey guys! First things first, I want to share the conclusion to the story I mentioned here the last time! We managed to fix the crash - yay! This means that everything seems to be in place for 0.62 on Experimental and I can't wait for you guys to play with the new environment visuals and sounds. There is still space to improve and make things more distinct, but the work does not stop there after we send 0.62 to Experimental/Stable. It's the first step to get visuals and audio where one would expect them in 2017.

To continue with stories from the development front, large part of our daily routine here is planning for BETA, and doing recaps with the aim to refocus the development, structuring our team into smaller feature teams. In the last two weeks, we revisited mind maps of these feature blocks to set up a core functionality of DayZ - starting with larger ones, and working our way down to smaller, more actionable items that we can "close" as development items.

DayZ is a complex game. It's a system sandbox where its gameplay loop starts working only when all the small details are in, and start interacting with each other. It's one of the hardest genres to iterate upon, as you can't structure the features easily, and every single thing can break the gameplay ecosystem. I highly recommend the original Deus Ex postmortem that was featured at GDC 2017 by Warren Spector himself.

If you separate the work we have done over the years, you can simplify it into three layers: engine, data and gameplay. Engine is the core base and modules upon which we want to build this game, data are visual assets (e.g. models) or audio that support the features, and gameplay is represented in both code and script. That’s why we have technical designers writing script, and gameplay programmers doing the same for the DayZ codebase.

Over the course of the last two years, these two groups (programmers and scripters) have been focused on closing core support systems for the architecture of gameplay in the new engine, and haven't had the chance to see their individual parts of the game work together. It's exciting now that what you could previously see only in a debug mode, or under parameters for internal client, is now finally able to support actual gameplay, and can be seen inside the game in a broader context. It’s a start of something much bigger for everybody in here.

Instead of focusing on systems and technology, we are finally making a game. The core gameplay loop is our focus now, split into melee combat, ranged combat, player character and its interaction with the world, and the infected (and their interactions with the world). All these pieces we have been building are slowly getting playable. There are still hurdles along the way and ahead of us - but that’s how development works.

What we're doing now is obviously one of the most critical parts of DayZ development, but all these previous decisions to create tech first, and focus on enjoyable experience later, are going to benefit the game (and gameplay) in the long run.

To give a glance at the currently open development items in our teams :

Programmers

• AI script implementation
• Zombie behavior script representation
• Inventory and item conditions
• Item spawn definition
• User actions in multiplayer
• Network traffic optimization
• Sound event manager
• Performance optimizations and multithreading changes
• Input changes
• Navigation changes
• Hit reactions on player
• Tons of crash fixing
• Tons of bug fixes

Animators

• Weapon mechanics animations polishing (unjamming, reloads)
• Inverse Kinematics poses
• Hit reactions on player
• Melee combat prototype
• Ranged combat prototype

Designers

• User actions in multiplayer
• Player representation
• New player and item spawn definition
• Inventory UI refactor
• Radial menu for gestures
• Soft Skills
• Player action targeting

Audio

• Positional environment audio
• Infected audio recording preparation
• Player and weapon animation events setup

QA

• Playtesting the 0.62 update
• 0.62 feature testing
• Internal client stabilization

Art

• Tree fire geometry
• Buildings optimization
• Doors unification

- Eugen Harton / Lead Producer

Dev Update/Peter

In regards to Central Economy, there were some changes made in terms of loot spawning and its definition for BETA version that we are working on. Till now, loot placement was defined directly as specific point per one item in .p3d files, grouped in named selections (which are paired with categories and tags in configs and areas in area map later). There has been a need to pay close attention to dimensions of given items against each other, and available space around them to avoid unnecessary clipping between items, or between item and building itself.

This process was tedious as it lacked sufficient spatial orientation in object editor, leading to prolonged time needed to populate a building (for example, the school building has tens of thousands of spawn points defined in the old system). Not to mention that packing and exporting proxies was mandatory in order to be able to see new/adjusted spawn points working in game, stretching the time even further. You can see how it was set for the police station on the screenshot below.

[img width=700 height=434]http://i.imgur.com/yvtsHaB.jpg[/img]

Instead of exact points, the new loot placement uses ranges. Range simply defines a circular area within which item can be spawned. During placement of these ranges, they are checked against each other and building itself in real time. This approach avoids any clipping and collisions of items during spawning. Placement output is stored as XML directly in the mission folder, so it's very convenient for modding, it also can be loaded and edited.

The best part of this new system is that it's completely defined and visualized directly in game, from free-fly camera. Additionally, everything is real time, which (coupled with independence from addons) cuts down the time required for setup dramatically.

[img width=700 height=432]http://i.imgur.com/yqOrXuV.jpg[/img]

After introduction of this new system, we managed to get from more than 1.000.000 spawn points (mind that was after massive reduction for 0.61 version from 4.000.000+ spawn points) to current ~130.000 used, and at the end, what matters the most is the increased server performance.

Don't waste time doing unnecessary things... see you in Chernarus folks!

- Peter Nespesny / Lead Designer

Dev Update/Adam

Hello everyone, I hope that you enjoyed this SR's contribution from Mark, our map designer, who has showed a great passion for such whopping task as transforming the nature of Chernarus is. He spend countless amount of time designing and configuring how the new forests and individual vegetation looks and we are all excited for the day when you finally be able to experience new Chernarus too.

We are currently really busy with map tweaking to make sure we can deliver the new Chernarus in best possible shape we can in given time. Please keep in mind that update .62 has touched almost every corner of Chernarus and while we do our best to make sure everything will look just like we wanted, there will be some minor map-related issues. Also, keep in mind that update .62 contains initial changes to the whole western border, completely getting rid of old terrain and object layout and replacing it with much more detailed landscape and layout. This work, labelled as western expansion, is however split into several phases and more additions and fixes are planned for later updates.

[img width=700 height=393]http://i.imgur.com/sCCqUv0.jpg[/img]

In addition to many great improvements to the way grass, trees look and behave in wind, our programmers also went and fixed many issues related to lighting and sky. One of the major things was that before 062, shadows were turned off too early / too late and that impacted the quality of scene (mainly interiors) in a very bad way. This issue was fixed along with many more (like smoother sky-fog transition, reduced size of the moon and sun, moon visibility, horizon look, and more...). These changes have enabled us to focus on lighting config for Chernarus, which saw some great changes. While we do not consider it to be final, we hope that it will prove to be a very fitting addition to the visual update coming with 0.62.

[img width=700 height=393]http://i.imgur.com/Z2DSdBG.jpg[/img]

Additionally, in January 24th SR I promised you that I will show you the new railway stone bridge, so here it is! Coming in 0.62 along with many additional changes to the railway network of Chernarus!

[img width=700 height=393]http://i.imgur.com/Xu1ApDz.jpg[/img]

See you in Chernarus!

- Adam Franců / Senior Map Designer

Dev Update/Mark

Hi everyone, Mark Gill here! I'm one of the map designers who has done many tasks for Chernarus, but more recently I've been focused on developing the new Chernarus forests for this 0.62 visual upgrade. This has been a lengthy, challenging, but also rewarding process. I will try to share some of the thought process behind the changes that were made.

[img width=700 height=393]http://i.imgur.com/Niat8Be.jpg[/img]

With the new forest overhaul, we hope the survivor experience in DayZ will be greatly enhanced. We tried to make traveling through forests a more immersive experiance. Repetition can quickly become boring on a map of our scale, so as you traverse through forests across the map, the visuals will change at a fairly rapid pace. This was a large undertaking, but it was important to keep the visual stimuli changing in unpredictable ways.

[img width=700 height=393]http://i.imgur.com/D693piO.jpg[/img]

We were able to increase the number of tree variations thanks to our talented artists to create types of forest that display different characteristics. The overall shape, size, and canopy development gives sections of forest a sense of age. These sections can vary from close spacing of younger variants. to farther spacing of older variants. There are limits to density due to the performance impact, but hopefully the amount of variables at play will keep you on your toes as you travel across the map.

[img width=700 height=393]http://i.imgur.com/KXZNUD6.jpg[/img]

Broadleaf hedgerows and forest edges now have a lower profile than in the past. This looks more natural and adds more coverage at a lower height. With this change, sections of forest are more self-contained with this "bushier" egde-line. This helps block some sight in and out of deep forest. While much thinner then reality, this balanced result is an important improvement to the visuals as well as gameplay. Moving as an individual or group in and out forest should be a more significant shift as well as hiding. While you may feel safe and hidden within deep forest sections, there is also the opposite of not knowing who may be nearby.

[img width=700 height=393]http://i.imgur.com/gefYWfW.jpg[/img]

[img width=700 height=393]http://i.imgur.com/PhrVstf.jpg[/img]

We hope you will enjoy your freshly upgraded playground!

- Mark Gill/ Map Designer

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

Evening Survivors!

This week, you'll hear from our Creative Director Brian Hicks and our Lead Producer Eugen Harton - as the department leads are fully focused on catching up on their tasks after a short Easter holiday, both Brian and Eugen are doing their best to report for them. Both also explain why some of the long-announced content isn't in the game yet, and what needs to be done to have it available during BETA.

Mind you, while our today's Status Report is a bit of a long read, it's also full of vital development information on the upcoming 0.62 and BETA updates, so get comfy, pour yourself a drink of your preference and reserve some time for reading - it's worth it! Also, Baty has some nice eye-candy bonus at the very end, so those who make it all the way through will surely be rewarded

Dev Update/Hicks

Greetings Survivors.

I watch a good deal of DayZ Twitch streams and YouTube videos in my free time - and over the last week or so, I saw something that concerned me: hearing conversation in regards to gameplay mechanics or systems currently implemented in the most basic form, and if they are intended (by developers) to ever change.

Between the new user actions and rewrite to Enforce script, and the decision for designers to stop writing new systems in SQF and focus entirely on creating new gameplay systems in the new tech - it can easily seem (to those who don't closely follow development) that we just don't care about the issues currently on the Steam build, or don't ever intend to address them. That couldn't be farther from the case.

For example, Peter and I have been going over functional issues with the central economy we want to see addressed for BETA and beyond - these aren't things that are being ignored. Far from it, but as always, the goal for the team is getting to the final product as quickly and efficiently as possible.

While the economy functions at a playable level and much of the technology required for the final product is there, the priority for the programmers responsible for the Central Economy of DayZ moves on to the next piece of the puzzle - in this particular case, support for public access to server files and required software, modding, and off-line mode.

When those critical technology tasks (that are being worked on by those specific programmers) are implemented into the internal version of the game, that's where we can shift our focus on iterating upon some of the functional issues of the Central Economy.

What kind of functional issues with the economy? Well - just to list a few:

Dynamic Event spawning behavior
Dynamic Event item spawn quantity control
Zone/Area restricted items bunching up in specific towns after extended persistence uptime
Repeated spawns of the same item types in a structure
Consistent availability of early game basic supplies

Also take a look at Peter's contribution to the last SR - it's a good example of how the current state of things is not final, how our features and systems will be iterated upon and improved.

To be honest, there isn't much of anything in the Alpha phase of DayZ that is functionally (from a design perspective) "complete". Nearly every gameplay system or mechanic the player touches is at a basic functional level, meaning the tech/script/animations are present and it operates in one way or another. Fleshing it out, addressing functional and gameplay issues - that isn't something we should be wasting time and resources on, especially when so much of it is being replaced.

"What about all that cool stuff you guys have shown for years but never ended up in the game?" You might ask - "What happened to that?!" - While I know both Eugen and myself have discussed this before, I can't fault anyone for missing it - it certainly is not easy trying to search or go back through Status Reports on DayZ.com at the very least.

Nearly everything that has been discussed since we stopped prototyping gameplay mechanics in SQF, stopped creating animations for new items on the old animation system, and so on is, and has been worked on. I know it can seem like cool things like base building, soft skills, or player facial hair growth has disappeared because we haven't publicly associated it with a specific release.

The reality of the situation is, with pretty much everything on that proverbial list being dependent upon the new player, and the focus for BETA being on getting the game stable and playable on the new engine modules - we're playing our cards close to the chest.

While we may end up with a BETA candidate build that has a huge chunk of the content and gameplay systems backlog functional in it - it's just as possible that we'll end up with a smaller chunk of the backlog content and systems in that first BETA build, and the rest of the list will follow up as quick as possible (which should be at a much quicker pace, having shed a good chunk of our nasty tech debt and overhead from supporting legacy and new tech).

We're in that situation because it is the technology - the foundation of everything inside DayZ that you guys experience - that is setting the pace and progress towards our goals right now.

As we get closer to these core components of DayZ's underlying technology being functional and usable in a multiplayer state, we can better gauge what the gameplay and content ingredients of the BETA milestone are.

I know for some of you, a good deal of this is information is something you all already know, as Eugen and I both have spoken on it several times before (and I couldn't have put it better than Eugen's contribution to the last SR), but for as many of you that may follow development closely and know all this already - there are just as many that might have missed some of this down the pipe.

You know what they say: now they know... and knowing is half the battle.

- Brian Hicks / Creative Director

Dev Update/Eugen

Hi there survivors, since some of you appreciated my last Status Report contribution, I'm going to try and keep them as regular as possible. While knowing that my wall of text is not going to be an easy read for everyone, I do believe it's necessary to try and write stuff in technical detail in order to have an provide an honest coverage of what's happening in the DayZ Dev Team offices.

There will be a lot of stuff happening over the coming months, and I want to guide you through it with as much information as possible. At this point, there are two large releases scheduled for this year. and we're fully focused on those. The development is divided into strike teams - a smaller strike team is working on the 0.62 update, which we internally like to call a "Visual Upgrade". It contains tweaks to lighting and new forests, as well as general world fidelity improvements (we have more to come in that department for follow-up/future updates as well).

As far as what that means in a bit more detail, the Visual Upgrade coming with the 0.62 update will feature:

New tree models
Denser forests
New clutter (grass, small plants)
New surface textures (roads, plains and such)
Improved wind behavior
New shader for the wind, affecting trees and grass
Tweaked and changed lighting for the world (for a more apocalyptic feel, yay!)
Small improvements to satellite textures
Rain affected by wind and refinement of its behavior in general
Many reworked locations on Chernarus
Reworked ghillie (to be consistent with new tech
Small bugfixes to some issues from 0.61

The 0.62 update will NOT introduce:

Any changes to gameplay
Any changes to buildings and structures (in terms of model graphical fidelity)
Any changes to player model fidelity
Any changes to animation fidelity
Any of the gameplay changes, or new content that we've been occasionally mentioning in Status Reports
(those are all scheduled for BETA/0.63)
After this milestone, the strike team for 0.62 will merge with the current 0.63 strike team, and join their efforts to reach BETA on our Steam branches as soon as possible. BETA/0.63 will be a major change for the game as a whole. That is the update that you guys have all been waiting for, and we have been working hard to reach that goal for the past few years. What does that mean in more concrete terms though?

All the new engine technology we have developed for DayZ, along with the content of the current game - all merged in and improved, as it has been refactored from functionality point, design-wise, and in terms of fidelity as well. Moreover, additional content and features that we couldn't properly implement on the legacy tech.

Besides all the refined features, content and overall improvements to the DayZ experience, we also aim to release a handy toolset very near to (or along with) the initial BETA/0.63 update. This toolset will contain the much-requested server files.

I know you are all asking: But when?!?! As much as I would love to tell you now, we want to be able to deliver a seamless core gameplay loop without bugs breaking it at first. Our main goal now is to get the melee combat and ranged combat work on the new technology, and in a real game environment, not only in a debug mode.

A lot of work has been done already (like new synchronization, damage system, player representation, and more), so this means mostly adding support in synchronization, and adding content for new features in the animation system are ahead of us, but it's still a lot to handle.

So just so you get the idea of what work is being done at the moment (from the perspective of disciplines):

Gameplay team

Refactor of hard coded world interactions to script. There were still a couple left (opening doors for example). Creation of core synchronization model for these
Moving VOIP to server authoritative completely
New weapons API for weapon script implementation
Inventory conditions implementation for item states and more
Optimizations of item spawning for server performance
AI script API for behavior modification
New player spawn definition
New item spawn definition
Vehicle behavior in new technology
Backend toolset (srvlet) for central manipulation of economy, and server management (community version)

Design team

User actions manager for the new synchronization model
Player representation refactor and debug functionality for new player (visualization and toggles for testing and manipulation)
New hierarchy of item configurations (includes new technology like damage system, procedural coloring and such)
Data re-structuralization to suit the new setup (file structures at the moment)
Inventory refactor and optimization according to internal version
Integration of soft skills to actions in game
Electricity and its implementation
Placing of items in world and its implementation

Animation team

Implementation of animation player turns
Polishing new weapon animations (unjamming)
Implementation of hit reactions to melee combat in the new system
Work on inverse kinematics and item poses
Tweaking player graph
Implementation of detailed user actions animations

Engine team

Toolset refinement
New inverse kinematics implementation
New physics representation for non-player entities
New shaders for trees and grass
Hit reactions in animation system
Synchronization of new animation system
Player turns
Aiming model

Art team

-New models (sorry, don't want to spoil stuff! (smile))

As you can see, there is a lot of work ongoing, in order to implement all the new technology and content. Most of the tasks are now aiming to get things working together as seamlessly as possible, and a lot of them are playable in different debug environments.

- Eugen Harton / Lead Producer

Good evening survivors! This week, Viktor shares the second part of his animation Q&A video, Eugen is expanding upon his recent talk on a game dev conference here in Prague, Peter provides an example of the new car damage visualization for BETA and we've talked Adam into making some new comparison images of the new forests!

Additionally, we have Mirek talking about another important milestone we've currently reached with our technology and Baty (among other things!) looks back at a pretty cool April Fools' joke from one of our community members.

Dev Update/Eugen

I don't usually contribute to Status Reports, but since Brian is out of office this week, I'd like to change that and touch upon a topic of DayZ development and Early Access development in general. Brace yourselves, as this will be a bit of a long read (but there's also a video embedded below).

For the start, I understand that a lot of you have concerns about DayZ development. I also do believe there have been some inherent issues with what is, and what is not viable for Early Access development phase, as this is something that was not tried a lot before, and most of it is pioneered (process-wise) as things evolve.

Early Access is a dynamic environment that is quite different from the traditional closed door development. I’m gonna get quite technical, so for those who do not feel like reading a wall of text, I had a presentation at White Nights Prague conference that takes on the subject of this Status Report contribution with less detail:

http://www.youtube.com/watch?v=BZgMjWXuEpg#ws

That said, I do stand by the development decisions we made as a team, but also see major flaws in how one can present changes in games’ underlying technology, where most of these changes are actually the base building blocks which, in time, will be able to provide a significant change of the overall player experience.

All these engine changes are, in the case of DayZ, developed with the aim to keep the game moddable at all levels, with expanded scope. The engine changes for DayZ include

Renderer
Networking system
Controls
Script
Sounds
Physics
Tools
Server-Client architecture (in most systems!)
Consoles
Animations
All gameplay systems written inscript (to a certain degree)

We need to work on all that while we create data and iterate, while we’re slowly trickling some systems into the live game (the public Experimental/Stable branches of DayZ) to test them. That creates a certain lack of visible progress as things are in motion and need time to settle down. These days, many of the base systems are in-game internally, and we are spending a significant amount of time removing a lot of old systems, while interconnecting the new ones.

Let's compare that vision we have for DayZ with the live game that’s out there right now, just so that you have an idea of what it all means in practice.

Live game runs old physics system, where collisions are a giant hog on server performance. To replace that, you basically need to replace everything else, as many of these old systems were hard-coded to a large degree. You need to make an originally monolithic application into a modular one, where all these old systems are interconnected. You almost, almost start from scratch. And as small as it sounds, server performance can break anything. Most of the systems above have not been part of live game because of this dependencies in old structure.

Every issue in DayZ has a reason. Most of those issues that trouble you are known to us, and have a solution somewhere in all this work that we have done, and want to bring to you. Like the stairs killing you, which is a combination of many, many factors: Issues with data binarization, physics, collisions, server-client architecture and even script and player itself.

To fix a “simple” issue like that takes years of work because we really can’t take on any more technical debt and “hack” these fixes into the game to save the day. We play for the long haul, not for the short term gain. And as such, there lies the inherent issue of how to approach early access.

Things take time, and you can’t buy patience with a wall of text. You just can’t. And I get that now, when we have to face the truth here, as all these things that we worked for are not in a state to make for a fun game. Yet. That point (where we will present a fun to play game) is BETA for us.

Yes, we could probably, eventually set up a deployment to show each different technology change part by part (like we did with the renderer), but unless you have base the game loop present in a game, it’s just a tech demo. Even if we have all the parts ready, these details (bug fixing, connecting pieces together…) matter a lot.

I’m going to use a simplified story of a decision making that happened around one simple upgrade. How player sounds should work in the future:

Sound in games has a lot more to it than one would imagine at first. Besides the sound data itself (which has to be prepared in context of the technology, as in supporting its data structure, and also allows further data modifications by the underlying game technology that plays the final sound for the player) there is also the important part of letting the game know when it should play a sound. Let's call that an event.

You also need to edit all this in some way, to put events in gameplay that plays the sounds, and edit the sounds themselves, and don’t forget the pipeline for building the game that puts all this in some structure. Events have to be called from script, animations, items, environment... There has to be some logic to it. You need tools to visualize the data, a script to play it, have logic that decides how and why…

Many of these systems were originally hard-coded - hard to tweak, hard to change. So the goal was (and is) to bring them in line with the rest of the DayZ vision, and to make the game modular, editable (visually, if possible) and expandable in the future. So we’re talking about tons of disciplines that are affected, and you can’t do one part of it and think the whole thing will still function.

As you prepare the new technology to be compatible with rest of the new stuff, it is often impossible to keep things compatible. And more than often, you just need to move on and focus only on the new technology.

For example with player sounds, we’re now in process of writing the sound event manager, and then we will need to connect the sounds into data structure, and define events that launch them for new animations of player moving. Meanwhile, we’re also reworking all the textures to prepare the game to recognize surfaces better, or to recognize when a sound is played in interior/exterior. At the same time, we’re implementing a way to edit the data in animation editor, in order to be able to set up these events visually, not just by playing a loop like in the old system. At the end of all this, there will be sounds playing when the foot of the player touches the ground.

It might sound silly at first, but all these things and changes can expand the scope heavily for us and the modders alike. Its not going to be easy, but as I said, we're not going anywhere.

- Eugen Harton / Lead Producer

Dev Update/Viktor

Our focus in the animation department is still mostly on melee combat and animations for new user actions. We are still iterating and adjusting animations and the game design to make the combat feel good. However, there is the second part of the animations Q&A video that got finished just minutes ago! In the first part, we were filming at our Motion Capture and studio talking about animations in DayZ in general.

This time, I am trying to explain our upcoming animation system and how it helps us improve the game. You can watch both parts right here:

http://www.youtube.com/watch?v=jn5BQACzTeo#ws

http://www.youtube.com/watch?v=68CY4gBEa2Y#ws

- Viktor Kostik / Lead Animator

Dev Update/Peter

After the new inventory was publicly released, we were continuously adding and implementing features to it which are directly connected to our ambitious revamp of how systems works with user actions, crafting, attachments and inventory management (you can check Status Reports from 1 March 2016 and 29 March 2016 to find out more about this effort to unify and simplify different behaviors).

As we were integrating all that stuff, current inventory implementation of scripted UI got bloated and finally became unsustainable. Currently, it's being rewritten from scratch, which may seems scary at first, but it's the right step for a better, cleaner, more functional and most importantly faster inventory UI.

System of gestures was implemented in Enforce script and it's not a hard-coded part of the engine anymore, which offers more possibilities. Powered by the new animation system, it brings smooth controls and seamless transitions from ending part of gesture animations directly to character movement. As over time number of gestures exceeds available function keys, we started the work on a new radial menu UI for gestures picking (binding gestures to function keys is still possible though).

With upcoming changes to vehicle physics and simulations, we are also enhancing visuals for different damage states of vehicles, as well as how to make new abandoned and wrecked ones from all these driveable models we already have. Large attachments like doors, hoods and wheels will be removable from these abandoned and wrecked vehicles, which can be combined with different color and damage states. The fact I like the most is the possibility to interchange all of these per attachment, or on different parts of body, depending on the direction of impact.

[img width=700 height=437]http://i.imgur.com/4mmAbeQ.jpg[/img]

For more variation... see you in Chernarus folks!

- Peter Nespesny / Lead Designer

Dev Update/Mirek

Last week, another major milestone has been met - we've moved animals and infected to the new animation system, which means the internal build of the game is only using one animation system now. This is great, because we can now focus only on one type of implementation, and can remove a lot of the legacy code, which will make our lives a lot easier.

Now we just need to connect existing game features to the new implementations of player and AI entities, and solve issues like AI pushing players etc.

Interaction system with game environment is heavily modified, too. In current 0.61 (and future 0.62) updates, the client side is asking the server side for possible interactions and the server returns a list of these actions. In 0.63, we've decided to get an action list on the client side, so there won't be any latency lag and there will be less network traffic between the client and server.

Also, there is going to be a client side prediction for each performed action, which means that you will see direct response when you press interaction button and server will be able to interrupt these actions in case of faulty prediction (e.g. two players are picking up some item at the same time) or in case of cheating.

Another major change in our internal version was the Voice over Network communication. It's now using client/server architecture as well. This allowed us to optimize voice data traffic, and more importantly, there will no longer be any peer to peer connections between players.

Together with these changes, our scripters should be able to begin with the Enforce Script implementation of new advanced communication features (like public address system or static transmitters).

- Miroslav Maněna / Lead Gameplay Progammer

Dev Update/Adam

We've made serious progress on an important milestone task for the release of the 0.62 update - color tweaks for all the new vegetation assets. This task is focused on making sure that all new assets blend together and look just right. In addition to that, we are also utilizing colorization feature that brings much needed local color variety between individual assets.

Please consider content of all pictures in this status report as work in progress. They do not represent final state yet as we are still working on additional color tweaks and other things such as configuration of clutter (grass) and surface mask. Following two pictures show how the color tweaks affected the overall feel of the new Chernarus.

In first picture, you also have the option to compare it with current (0.61) version of Chernarus:

[img width=700 height=393]https://dayz.com/files/images/MOcDZJF.jpg[/img]

[img width=700 height=393]https://dayz.com/files/images/4OcqY5T.jpg[/img]

[img width=700 height=393]http://i.imgur.com/SEsxUo8.jpg[/img]

We've also added younger conifer forests to the layout of the new Chernarus forests. In our previous iterations, only older conifer forests were used for all conifer generation shapes. We have prepared a layout and included these younger parts everywhere we thought they would fit.

That not only includes denser spruce, larch and pine forest parts, but also clearings with really young trees. This change should give you an idea that many of the conifer forests on Chernarus were actively harvested for wood, and thus many resemble un-natural shapes.

Following pictures provides an example of young conifer forest parts near Devils Castle (which is one of the more harvested areas on new Chernarus). Again, you have the option to compare following pictures with current (0.61) version of Chernarus.

[img width=700 height=393]https://dayz.com/files/images/t7UbrxU.jpg[/img]

[img width=700 height=393]https://dayz.com/files/images/SLkOnDD.jpg[/img]

You may remember that I mentioned a western expansion in earlier status reports. This task is still very much active and just last week, we have replaced all prototype forest on the western part by the generation output. This basically means that the western border now has properly generated forests, same like pretty much the rest of the new Chernarus.

With this, I can happily say that you will be able to enjoy the whole new look of the whole western part of Chernarus in 0.62 update (time to say good bye to the empty lands with few trees!). That being said, this is just the first iteration, expect many changes with future updates.

This picture is meant as a small teaseer of what you can expect on the western border. Direct comparison to the old Chernarus does not make sense in this case, as the terrain is now vastly different:

[img width=700 height=393]http://i.imgur.com/OxykWQX.jpg[/img]

- Adam Franců / Map Designer