Neuer Wochenbericht - 04.04.2017

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