Status Report - 26 September 2017

With Brian missing this week (no worries, he will be back at full force next time!), Eugen and Peter reflect upon the new features and content presented at Gamescom. Eugen is finally sharing our full 0.63 Dev Log video with 16 minutes of Gamescom DEMO gameplay in Full HD, Peter is reacting to some of the community feedback regarding the missing naked eye zoom and new key binds for firearms, and Martin and Baty share some of the good vibes from our community (both the one at EGX, where they travelled last week, and online!). Let's do some reading and watching folks, it's a juicy Status Report once again!

Contents This Week

• Dev Update/Eugen

• Dev Update/Peter

• Dev Update/Martin

• Community Spotlight

Dev Update/Eugen

The last two weeks had us focused on different issues in the base and core features of DayZ. As previously mentioned, these are tackled through smaller scrum teams that are dedicated to these topics. Currently, we are running ranged combat team with focus on weapons and another one focused on melee combat. More are expected to be set up from vehicles to Central Economy or the infected. These should enable much faster iteration that can deliver on their goals as the technology requires less changes under the hood. This means that we are no longer tied to larger technology changes and can focus on the stuff that’s important to us and players alike: things that tackle immediate concerns that have troubled the game for a very long time. The approach we chose is based around priorities that carry through to other features, so we spend less time going back and redoing stuff over and over. Current priorities started with base movement of the character, which defines a lot of the work that is going to happen in both melee and ranged combat. Once we nail down the details, we can quickly implement and iterate things like player speed changing with rotation or rotation limits in order to cut on the erratic movement that is usually described as"zig-zagging". There are tons of things like these that community cares very deeply about. We take this feedback very seriously. Lot of these things have driven community interaction over these years. Bugs that we didn’t fix, features that didn’t have consistency or detail or were missing entirely. There is a reason behind everything. We spend a lot of time on figuring these out and once we are happy with our solutions we are going to get the discussion going. The process, however, requires you to test them in-game and that is where we go from prototype to full fledged feature. The thing is you try, and go for functionality first before the visuals get polished. It usually does not matter if it looks good if you’re developing the game. But it’s also the reason we don’t show many of these things that are in their early implementation. because they are just functional enough for us to iterate, but not polished enough to present ourselves with. That brings me to the next important thing. Imagine all these great things created with placeholders or skeletons of functionality that we look into and keep iterating on. Ideas are just ideas and they usually change for the better as development moves forward. What seems fun and good on paper though sometimes does not translate well in-game. If the technology used is layered enough to let designers test their ideas, we know we can differentiate the bad from the good. I don’t believe that we