Hicks_206 (DayZ)

- You'll have to ask folks like Ivan Buchta, as we inherited Chernarus from the Arma 2 project. - Simply put, because the way that specific dynamic event works right now is tied to a master list of fixed positions. The creation of the event is dynamic, however where they can spawn is static (albeit a very, very large list of potential spawn points). The intended design (and where we would like to be at launch) relies far more on a safe detection for the spawn (checking for required free terrain size, and potential collision with existing models) and thus, actually fully dynamic. - The way they work right now is essentially just creating the wreck. Initially we had ripped out any form of support for creating an actual flying craft with pilot AI that would fly a bit and then crash - we've looked at changing the way this operates in the future. I'd very much like to have the event created as a flying craft that eventually crashes, we'll see if we can get that done sometime before launch. - Magnets. - Tight pants are awesome, don't you like tight pants?! - Novigrad, I suspect! Although, Chernarus does have plenty of wonderful wilderness trails that are perfect for running. - That is the eternal question, is it not? I'm not sure I'm qualified to answer such a profound question. - Amusingly.. the model is based on the FN Trombone. I've yet to personally test out how it sounds in the new sound system, I'll have to give that a try. I suspect it won't be *so* quiet in the future. - All forks and spoons have been removed from Chernarus to prevent overpopulation in the apocalypse. You know the old saying.. spooning.. leads to forking. - .. Exactly how big is your tongue? Can you actually reach both terminals? That is *impressive* - Touche sir.. touche. Although, I do know that Andrej our Sound Designer has been working on unique foot step sounds tied to the type of footwear you are wearing. If we end up going down that route, I suppose they could have their own value - as one of the quieter forms of footwear for trendy and fashionable survivors. - I honestly don't know - I had a bad experience at Black Lake with Mr Moon back in 0.45 and I haven't gone back. - Biggest scam in all of Chernarus, I have yet to get my compass. I should go straight to Peter about this and find out what gives. - What do you think your characters do while you're logged off? DayZ Survivors are shy poopers with shy bladders. The second you log off - bam, they are off to the closest bush. - Dean took all of his balls and went to New Zealand.

That remains to be seen. The issue with vehicles being at the number they are right now (around 15 total) is purely due to the fact that we haven't really done too much server side optimization. Once we start switching our resources from mostly feature work, to mostly bug fixing - I expect to see more attention focused on that area.

We're all very much aware that network sync of vehicles in current Steam branches is not working as intended, hell - you could say that outside of a perfect situation it is just plain not fun. That said, we've been working on it - and will continue to work on it throughout Early Access. Helicopters really require this to be at an enjoyable state, because -NO ONE- wants to deal with the rage that would come from losing a super rare functioning helicopter... to sync issues. :( Hang in there, we'll get it to an enjoyable point before we release. :)

Unfortunately, removing 3PP is not an option at this time. That said, we do operate plenty of 1PP servers. Restricting experimental to 1PP only would mean we could miss an extensive amount of possible issues that are only present in 3PP. I do have some plans to *try* and make 1PP more popular as we move closer to beta, but we'll have to see how that works out.

We have a van in the works, the Multicar.. well, you can blame that on me. We have them all over the Czech Republic, and I fell in love with them.

This.. is not the type of post I expected when I saw someone had mentioned me.

Unfortunately, that is not nor has it ever been our goal. Fortunately - it CAN be something you or a likeminded individual can create through modding when that support comes. This thread however, is doomed.

Recently as I've been enjoying my travels across Chernarus in 0.60 experimental I've noticed a few comments, or questions regarding availability for server resources such as food, ammunition, and such. I thought taking a few moments to talk about that might help everyone understand our direction, and goals. For those of you who were around for the 0.55 build you'll recall the unintended side effect a few economic based bugs had on the gameplay for that build. The struggle to survive was "real" for certain - and interestingly enough, a good portion of the community has expressed nostalgia for it. So, for those folks - they'll be happy to know to a certain degree - an experience like that is what we've been aiming for. Let me elaborate a bit. Peter and I both share a passion for DayZ being a struggle to survive. Infact, there are game mechanics that just *don't work* without it being the case. The balance for us, the goal we're constantly iterating towards is a playable experience that is that struggle for survival. You should be able to find the basics for survival within your first few moments in game. Be it scavenging for some basic food, or finding the basic supplies needed to get off the coast. Within your first hour in game you *should* be able to find a firearm, and basic set of matching ammo. The coast is not intended to be an easy viable location to survive. We want you to need to move inland to exist, we *want* to push players to move across the map. Deeper inland you will find the high risk, high reward areas for players that want to push themselves towards that. For those that don't - surviving off the land, and setting yourself up for sustained survival through creating camps, and living off of renewable resources should be just as viable. Mechanics such as horticulture, or even such desperate measures as harvesting meat from fallen player corpses just won't ever be viable if we don't have that balance - that survival part of the survival game present. We track via heatmaps and server logging data such as global server quantities, and even exactly where things are concentrated and how evenly things are distributed across the server. Even with this however, bugs occur - and we rely upon player reports via the feedback tracker to properly track these down. I'm rambling again - so let me get to the next part of this post I wanted to hit. I, *we* recognize that an honest to god punishing survival game might not be the DayZ experience everyone wants, or even knows. Through the robust modding community on Arma 2, to the countless different type of content creators that are out there - DayZ can, and is something different to each person, and this ties into why we talk so much about providing people the tools to make the DayZ experience they specifically are looking for. This extends past modding, to robust control over the server economy for privately hosted shards (when server files and CLE/Database tools are released) with a lower barrier to entry than traditional hobby based development via modding. That said - I'm very aware of the concerns some members of the community have expressed in regards to so called "5000 vehicle servers" and "Spawn w/ AS50 HighLoot PvP Mania" type situations. These concerns were first a foremost on my mind when our Lead Designer, Peter Nespesny and I sat down to lay out the design of our final Main Menu, Server Browser, and Launcher. Maintaining the character centric view in our Main Menu, so that your "Official DayZ" character and his or her successes, statistics, and overall status is one of the first things you are presented with. In addition to this, our Main Menu ties right into the new server browser design - which is intended to segregate the Official DayZ experience from community run experiences, and modded servers. There is a point in UI/UX design that is discussed in the industry - that basically put covers the "clicks to gameplay" count. Maintaining a low click count to gameplay for us is one of the key points in the Main Menu, and to that end - where you end up through these clicks is critical. Separating the "Official" servers from the community run, and modded servers is more than just a filter. Our focus is very heavily on ensuring that the first gameplay experience someone has (unless they intentionally navigate past it) is on Official DayZ servers, with the original and intended DayZ gameplay design. - Main Menu "Play now" or "Quickplay" type option that dumps you into the lowest ping / highest pop Official DayZ server (or the last one you played on) - The first tab you see when opening the server browser is *only* Official DayZ servers - Community servers kept on their own tab - Main Menu character data and statistics are Official DayZ servers only Sure, these might seem small in the grand scheme of things - but the little things add up when trying to ensure that the base DayZ ("Vanilla") is protected, is the first type of gameplay a new user is presented with, and continues to thrive past the introduction of modding and private run hives/servers. As usual, I've ranted and rambled a bit - but again, I just wanted you all to have a little insight into the thought process. Peter and I (and the entire team) are always very focused on the unforgiving survival game DayZ is intended to be - and while it might not seem like it from development build, to development build.. every decision we make during development is focused on making sure the *final product* is exactly what we all dreamed it would be.

Afternoon Survivors, This week our Creative Director gives a status update on where we are with our hotfixes, as well as our .61 milestone goals, and Viktor our Lead Animator talks a bit about the new animation system. Contents This Week Dev Update/Hicks Dev Update/Viktor Dev Update/Hicks Greetings Survivors, Today we're going to take a quick look at the status of hotfixes for Stable branch, and talk a bit about where we are with development of the .61 milestone goals. - Character Gear Loss (On reconnect): Hotfixed to Stable - Tent Lifetime Refresh: Hotfixed to Stable - Tent Position/Orientation: Hotfixed to Stable - Vehicle Position Orientation: In Test - Animation/Sync Issues: In Test 0.61 Milestone Goals: Server Login Queue: Technology supporting this has been merged in and is in test with internal QA. UI Element notifies user of position in queue. As of the current status report, there are only minor bugs remaining. Will need further QA to be certain - and of course, plenty of experimental testing. Merge of New Audio Technology from Arma 3 Eden Update Technology successfully merged into DayZ branch. Configuration testing on existing audio configs under way. Update of Weapon Sounds for New Audio Technology Nine weapons ready, work continues on remaining firearms. Youtube channel dev log preview upcoming (Not of the full list, as some still require a little polish)! SKS Sporter Trumpet Repeater AKM AUG FAL SVD MP5K Dynamic Spawning of Infected Technology implemented into main internal branch. Basic area configuration is set up. Restock timer current disabled for testing. Programmers currently working on per-player configuration support. Predators (Wolves) Predator AI Sync working properly in offline mode, synchronization issues are present in network play. Triage is currently isolating these issues to legacy animation system. Programming, design, and animation teams are focused on investigating risk and cost effectiveness of fixing legacy animation sync issues for predators, or focusing on pushing animals operating with proper support on new animation system. - Brian Hicks / Creative Director Back to Contents Dev Update/Viktor In recent days and weeks there were many discussions about the new player controller where we talked about camera, aiming, IK, combat, controls, and other related features. Although it is coming together quite nicely we are still missing some major things like climbing ladders or overcoming obstacles. On the other hand there is now much more of wounded character. While new features are being added we are polishing the existing ones in the player graph and the animations itself are being adjusted less or more. Many items have been moved from the graph to a new layer of config which gives us a great way to quickly iterate changes in the character behavior and most importantly the animation graph doesn't have to solve unnecessary logic like in the old animation system. Also we are finishing first phase of extended animation sets for guns. At the moment almost all of the existing firearms have chambering animation and updated magazine reloads. At the same time we have started working on another pass by adding jamming/unjamming anims. There will be one for each gun. Each animation is divided into three parts with in, loop and out to give our designers better control over unjamming process. I think it will be a great addition and interesting game mechanic. - Viktor Kostik / Lead Animator

Vehicle persistence is fine. Vehicle position/orientation saving is the issue.

Just an FYI - New animations won't come until new animation system / player controller.

DayZTV is a fansite - and one that tends to datamine. We're not ready to talk details about electricity - when we are, we will - through official channels.

Not cool - it is there because of a bug. Soon as the bug is resolved, they will be 8 days as they should.

Lifetime counts as long as the server is offline. Most items are 30 minutes. Barrels are 8 days Tents currently 45 Backpacks are 4 hours last I checked.

8 days for barrels 45 for tents (as they don't currently refresh their lifetime unless you pack/pitch)

Hey guys - I know a lot of folks were giving me guff about using imgur and jpg Steam default for the 4K images I shared a few days ago - so I took some new ones. PNG Lossless - and Uploaded to Flickr. https://www.flickr.com/gp/143594186@N03/aUg659

Heads up everyone - I just want to get ahead of the E3 hype train and derail it straight away. Just so everyone that participates in the development of DayZ is aware - Our presence at E3 will be limited, but what presence there is - will *not* be new information for those active folks. E3 is primarily a media/retail show, and the small presence we will have there will be discussing what most of you already know - that we're getting ready to move 0.60 from Experimental to Stable (as soon as the blocking issues are resolved) and exactly what 0.60 is (Direct X 11 Enfusion Renderer, Economy Updates, Reload Mechanics changes). We're aiming to hit those who might have taken a break and not checked back with the information regarding 0.60, and hoping they'll take another look so we can see any other potential issues caused by the new tech changes. No console news either - Console platforms will come - when the primary platform for DayZ (PC) is stabilized, and those platforms are ready. That said - I know the Arma team will also be at the PC Gaming conference with us - I can't wait to see what they have up their sleeves :) That said, I hope you're all as excited as we are for 0.60 Stable!

Hey guys, Pretty often we get a lot of inquiries as to why Experimental/Unstable branch servers are not online, or requests to revert to the last playable build so people can play on the Experimental/Unstable branch servers while they're offline. I thought I'd take a brief moment to try and explain exactly why when they are offline to the public they can't just be turned back online. As you all probably know, especially if you keep up to date with our Status Reports (Biweekly - found at devhub.dayz.com) the team has been working hard on resolving the current primary major blocker for testing 0.60 build on Experimental/Unstable branch - servers unable to accept client connections past 10(ish) players at a time. This is just one example of the many different type of type of issues that can and will come up during the development, testing, iteration, and regression of a new build in DayZ's development cycle. "Just reverting" is far more of set back than just simply renaming a few files and pasting in the last known good build to the gameserver root folder. - Each iteration on an Experimental/Unstable build entails more than just the executable and data folder for the game server - Database structure, Servlet functionality (Central Hive), and Central Loot Economy are all also often iterated within this update process and are not often backwards compatible with older versions of the DayZServer software (In simple terms, the language changes a little bit each update and DayZServer.exe versions don't often talk properly to newer versions of the database, servlet, and CLE) - Internal testing for Experimental/Unstable updates occurs *on the Experimental/Unstable database/servlet* and if we revert, then we shut down the internal testing process on the next update - Even if the public Experimental/Unstable branch servers are offline, we are often running internal tests on unlisted servers on the Experimental/Unstable environment in an effort to resolve any blocking issues and get the next update to Experimental/Unstable branch out there for public testing I know I might have gone off on a bit of a tangent there, as I am often doing in these type of posts - but I thought some of you might like to know a little more why its not as easy as just rolling back a build when we're working on getting Experimental > Stable.

Greetings Survivors, As those of you participating in testing on the Experimental/Unstable branch on Steam are aware, we have been working hard on iterating 0.60 towards a stable branch candidate. We've received outstanding support from the community, through both extensive bug reports on our Official Forums, and large amounts of server crash and performance data on the Experimental Branch servers themselves. The team has been working hard on isolating several specific server crashes from the experimental branch servers that we are unfortunately unable to reproduce internally. To that end, as frustrating as it may be, your consistent testing on the builds that have these issues has generated a large amount of crash dumps and logging for the team to analyze. We'll be using this data on Monday, but in the mean time we will be switching the Experimental Branch servers to the last known good 0.60 build for the weekend. No ETA as of this moment on experimental server downtime, but we will let you know just as soon as they come back online and the client update is ready. Thank you again for your continued support!

Servers are now back online, the experimental branch client update 0.60.132940 should be live momentarily. If you do not see the update, make sure to close and restart Steam. Thank you!

Recently I've noticed some discussion and confusion centered around our Communication Process. Now, I'd spoken on this in previous Status Reports - but it looks like it might be in everyone's best interest for me to go over this again. We made some changes to said process a few months back, starting with handing over responsibility for our Status Reports to Dhawkz, our new Brand Manager. I'm pleased to say that has been very fruitful for us, and we've had the Status Reports out on schedule without issue for quite some time now. That specifically is not what I was intending to think out loud about today, so let me get back on topic. We have two people full time on community and external communication, and part time each of the leads contribute to it as well. - SMoss (Community Manager) - Dhawkz (Brand Manager) Past the staffing responsibility we have 3 main methods of sharing external development information. - Status Reports (Biweekly - Tuesdays (Anytime on Tuesday) - Trello (No schedule, as assets are available to show) - DayZDevTeam Youtube (No schedule, we show things that are ready to be shown (Dev Logs), and we are trying out developer Q&A videos - Design coming soon!) In general you can see a theme above. As development is fluid, it can be hard to predict with certain accuracy exactly when a specific system, tech, or feature will be playable or even showable. We can give our goals, or even our estimates - but we'll always end up upsetting at least one side of the crowd. Not to mention the fact that showing things while in development that aren't *on the docket* for the very next stable release only tends to end up causing confusion - and in some rare cases, frustration. Often you can end up with a render, preview animation, or prototype system that is dependant upon significantly more moving parts to be playable or even testable - and that tends not to trickle out through all human/organic communication channels of mouth to mouth. So moving forward we've been following a principle of only showing things in our YouTube channel that are coming up in the next stable build. We've allowed for more loose communication style with the Status Reports - as they can tend to be very text heavy and dry, the developers can take some liberty to talk about more long term goals and tasks. In addition, our recent change in how we communicate "deadlines, goals, and targets" will bring milestone review briefs to the Status Reports - starting with .61 development. Our Trello is very irregular, and I'd like to improve that - I just need to figure out how to combat people misunderstanding a model preview for something that is ready to be in game, or even will be soon. ;) When it comes to "dates" - well, as I've said a few times before - We're just not doing that with our communication any more. Things come up, dates end up getting pushed, and we end up with both developers and early access users frustrated. So, we're taking a different approach - one that gives a bit more transparency into what systems / changes are targeted for a given stable update, what the progress is towards said build, and what got pushed and why. We have our firm date for Status Reports, and the guideline of "when its ready" for showing things on our YouTube channel - paired with the above mentioned milestone reviews in Status Reports - I think for those that are interested in following DayZ development towards its 1.0 release, there is a lot of information to be had. I'm sure this rambling post will upset some, maybe please some others - but I thought it needed to be said, and if I didn't care - I wouldn't be here writing it :) See you all out there in Chernarus!

This morning after having a coffee and catching up on e-mail I started going over tweets people had sent to myself, and the official DayZ Dev Team twitter account and I noticed some statements, albeit from a albeit small portion of the community, but ones I thought needed addressing none the less. First off however, let me take a moment to thank the overwhelming support the DayZ community has given us thus far in our efforts to iterate on 0.60 experimental branch. You guys have helped us isolate a large amount of issues that didn't come up under the first stage of testing with our internal QA teams and that is outstanding. Hats off, applause all around. You guys *rock*. Now, while going through the tweets this morning I did notice a good deal of frustration from this vocal minority in the community surrounding a lot of issues (Requests to push the current 0.60 build to stable right away, Frustration that experimental servers were not online at all times, Anger over experimental branch servers not being increased to ensure all those interested could log in, Misunderstanding over allowing content creators to show 0.60 to their audiences, Requests to take stable branch official servers offline and switch them to experimental, etc) - but the core of the issues all pointed back to one shared root: Availability of player slots on Experimental Branch. While I sympathize with those who are frustrated that they cannot get on to an experimental server due to demand, as it is regrettable that the nature of experimental branch does not allow all of you to be guaranteed access I think it is important we revisit this stickied forum post from 2014: "This branch is by its own definition "Unstable". In simplest terms, the purpose of experimental branch is for the development team to experiment with builds in a larger userbase than our internal QA. Sometimes that results in us finding issues we cannot catch internally, sometimes that means we can verify fixes on issues with very low repro rates. Sometimes the builds are very unstable. (As mentioned prior) The branch exists for load/volume/stress testing. Those who go through the process of manually opting into this branch (its not super visible - by design) and dealing with whatever issues the current build on it may have, get to sometimes see content and systems not quite ready for prime time. However, that does not mean that is the purpose of the branch. As the nature of the experimental branch is for the above mentioned testing methods, neither uptime, character data, nor stability is guaranteed." Experimental Branch usage is (like the rest of development) an iterative process. We (the DayZ Dev Team - and specifically Production, QA, and Build Management) start small and scale up as we identify critical issues and gain more confidence in the build's performance in stress scenarios. You might have seen this visible in the next day update to experimental branch, and the increase of player slots per instance to 60 players. To those who don't follow experimental testing closely this might not be super obvious, but this has provided us with *VERY* valuable data. I'm going to try and answer/explain a few of the topics tweeted at us over the span of last night below: Why won't you just push 0.60 to stable now? / It has to be better than 0.59: Well, simply put we just can't do that. There are quite a few issues that would flat out prevent a large amount of the userbase from playing DayZ at all. From the ever present "Application Error" to black screens on launch, server crashes, and many more - The build *has* to stay on experimental so we can get it to a state that allows the vast majority of the DayZ playerbase to play and test it on stable branch. Lets not forget that all branches of DayZ Early Access are testing branches! The testing base and goals scale up from our Internal QA, to Experimental Branch, and finally to the Stable branch as the default build you play when you install DayZ on Steam. I know it is not the popular thing to say, and the less fun part of my job involves having to take the brunt of passing on bad news - but your patience, participation, and feedback is and will help us get this build to stable as soon as possible. Why are the experimental servers down in my region? / Why aren't the devs saying anything about the server being down in my area?: Keep in mind the DayZ Dev Team operates out of Central Europe, and depending on where you are in the world there is a high chance the developers are in bed / haven't had time yet to analyze the issues causing the outage. Time Zone differences can be confusing, trust us we know! Pair that with the fact that server availability, distance from the Prague offices, and latency can fluctuate greatly depending where you are in the world - and it can and will lead to server downtimes in your region. A good example of this is the Oceanic and Asia regions - of which we've been fighting server issues and connection speeds throughout experimental branch usage. So please, be patient with us - we haven't forgotten anyone and will get the servers up as soon as time, and process allows. As well, sending tweets out every time a server crashes or goes offline due to a bug or server hardware issue isn't practical given how frequent this can happen on the experimental/unstable branch. Why aren't there more player slots? / Lots of people want to play, let us all play: The experimental branch testing phase is *not* set up to ensure availability and accessibility to all. Besides it not being practical on an infrastructure point, the nature of how we use experimental branch means we need to be able to create false stress situations for the game server instances, the central hive, and in some cases even the server hardware. Now, as experimental branch testing moves forward on any given build we slowly increase the player slots for that branch whenever possible. Be it actual game server instances slots, or allocating additional hardware when possible. Simply put, especially at the initial stages of a build being on experimental branch, we *need* to see how the build operates under extreme demand, we need to see it fail, and we need to analyze that data and make changes where necessary. That said, we are looking into increasing the branch player capacity within reason. Don't expect several thousands more player count capacity, as that is what stable branch is for - but we recognize the demand and are doing everything we can to help alleviate the issue. Why are streamers given special treatment? / I should be able to play there too: Early on after the first build of 0.60 was pushed to experimental I realized we just didn't have the infrastructure or hardware available to let everyone who wanted to see 0.60 on experimental branch that wanted to, and we wouldn't be able to flex up to accept all of the demand. Realizing this, at the end of the work day a development box that I use to capture footage for our Youtube Channel, and bug bash internal development builds was taken offline and converted to point to the experimental branch in the hopes that we could at least through allowing content creators to showcase the build let those who couldn't get onto an experimental branch server *see* how 0.60 was operating, performing, and moving along. The hardware used was not powerful enough to actually operate an actual experimental branch server, and would for certain buckle under the demand, but through reallocating this one small instance we could at least provide 30 or so content creators from across the globe, and across multiple languages give thousands more people a look at how things were looking on the march towards 0.60 stable branch. Creators of all audience sizes, and regions across the globe were given access to the box and asked to use said access to help alleviate the stressed demand on experimental branch by sharing their experiences on their distribution methods (Youtube, Twitch, Twitter). Through this method we were able to allow thousands of additional people to see and experience 0.60 experimental branch that we would not have been able to otherwise. Some people seem to think that experimental server resources were diverted to allow content creators access to 0.60, or player slots that could have been used for general experimental branch usage were given to these users. Simply put that is not the case, as mentioned before the server utilized was my personal work box and would not be able to handle such a demand. This was easily demonstrated earlier this morning when some enterprising folks acquired and distributed the IP address to this PC and the game server rapidly failed and stopped operating for several hours. No one was being denied playable server slots on experimental, and while we did ask content creators to be discrete so as to not compound the issue with experimental branch being at capacity that plan upset a small portion of the community, and for that I am sorry. It was never my intention to make anyone feel less important than anyone else in the community, the intent was explicitly to allow as many people as possible to at least *see* 0.60 experimental. Why don't you just take stable servers offline and convert them? / No one is using stable servers, switch them over: While it may seem that way to some users, DayZ has an active player base of several hundred thousand that cycle in and out (call it turnstile if you will) and it is important that we not just switch off game servers that users call home. We already fight issues with this in the case of some stable branch official servers, you may have seen it visible in forum posts asking where a specific official branch server that went offline was, and how users could get their camps, vehicles, etc back. As we move forward with development and push changes such as the final redesign of our server browser out, increasing visibility and thus reliability in these stable branch servers becomes even more paramount. For a game that is effectively a service in some definitions, like DayZ can be, we need to provide a certain amount of stability and reliability with the official DayZ servers. Switching them off and converting them to experimental branch due to a short term increase in demand is - in short, as I like to call it - "A bandaid on a broken leg". We all recognize that as we continue to move forward with major engine updates to Enfusion/DayZ demand will likely increase on this branch, and while we still have to keep the experimental branch within a certain limited capacity compared to stable branch, we *are* working on being able to increase (flex) experimental branch player slots to try and alleviate the demand as best we can with resources that do not compromise the integrity of stable branch official servers. I hope the answers above help you understand why/how things are done the way they are. I know some of the answers might not be what some of you want to hear at the time, but I felt it was important to address the questions and concerns raised via twitter over last night. Thank you all for being so awesome, and joining us in this incredible and sometimes stressful journey that is the development of what I think is one of the best gaming experiences of all time.

Hey guys, We'll have a small presence at PAX East this year - taking the opportunity to show the latest build of .60, meet and greet some Chernarussian survivors, and answer questions about the upcoming ,60 experimental release. We'll be working again with Astro Gaming, MrBlack0ut, and Anthony Kongphan. Our schedule for the weekend looks like such: Friday: 2:00 to 3:00 - Meet & Greet w/ Creative Director Brian Hicks, Brand Manager Dustin Hucks, Anthony Kongphan, MrBlack0ut Saturday: 2:00 to 3:00 Meet & Greet w/ Creative Director Brian Hicks, Brand Manager Dustin Hucks, Anthony Kongphan, MrBlack0ut Saturday 2:30 to 5:30 Live Stream w/ rotating guests on latest 0.60 build - Gameplay, Discussion, and Questions (Creative Director Brian Hicks, MrBlack0ut, Brand Manager Dustin Hucks) Sunday: 2:00 to 3:00 - Meet & Greet w/ Creative Director Brian Hicks, Brand Manager Dustin Hucks, Anthony Kongphan, MrBlack0ut We're obviously all excited to get .60 on to experimental branch and in the hands of the Early Access users, so we're keeping it light this year - but rest assured we'll be showing live gameplay, handing out sweet DayZ swag, and doing our best to answer your questions during the weekend event. Live Stream: http://www.twitch.tv/astrogaming Tweet your questions to: @dayzdevteam (Hashtag #PAXEast) (All times are US EST) PAX East: east.paxsite.com

So, one of the topics that is frequently on my mind is difficulty. Where we fall on the spectrum, and if you'll forgive the expression - "What we can get away with". Peter (Lead Designer) and I frequently spend a lot of time thinking about this, talking about this, hell even arguing about this. There will be times where I swing from one side to the other, the game developer side of me wants to make things as hard as they can be, the side of me that spent thousands upon thousands of hours playing and streaming DayZ Mod on twitch.tv is very aware of the border of playability. Fortunately we have a Lead Designer that is willing to do whatever he needs to do to survive when in DayZ, so he is *in tune* with struggling to survive. :) DayZ suffers (at times) from a small amount of double personality. We've been known for a long time for being a punishing survival experience. Obviously that shifts from build to build during development, but the titles identity as a whole has always had that associated with it. That said, because of the uniqueness of the DayZ experience - be it from the stories you experience and pass on to others, or the tension that comes from the uncertainty of potentially losing it all over the smallest of choices, DayZ has carried a very large identity in the consumer market outside of the typical personality type that might enjoy something punishing in his/her survival. You can see it in the countless hours of Youtube videos, twitch streams, and reddit posts. DayZ has become (and potentially always was) something different to many different types of people. So where does that leave us, the developers, with the base game experience? It can be daunting combing over user feedback and trying to take that into consideration when paired with the intended game design of DayZ. Let us not forget that happy consumers rarely feel compelled to get up and let their feelings be known (for the most part, there is always the exception to the rule) they are too busy playing the game, and experiencing their own stories. The vocal userbase is more often than not those that are unhappy, and with DayZ (aside from the time it takes to develop the title) you can frequently see the vocal masses pipe up when the title gets too difficult (see: 0.55). This is where our strong commitment to game modification (modding) comes into play. The decision to "hand the keys to the kingdom" over to the DayZ community once the base game and engine are at a point of stability allows us to do our best to stay firm to what DayZ is, and do our best to keep it difficult without having to make those types of users feel ignored and neglected. A good portion of the userbase has expressed concern about this - citing the fractured userbase of DayZ Mod once the binaries (or hell even the old Hive.dll) made it out into the public ecosystem. Mods such as Lingor, Namalsk, Taviana, Epoch and many others certainly did split the userbase up. There is no denying that - but there is also something to be aware of, a lesson I'm sure many of my favorite game developers when I was younger had to learn (see titles such as Ultima Online, Shadowbane, Asheron's Call, etc). You can't force people to play the way you want them to. You can design the path to go the direction you want, and iterate upon it, and refine it time and time again - but given enough time, people (life, heh heh) WILL find a way (around it). Not to mention the fact that the industry, and the ecosystem in this genre is already large, and only growing larger. If you don't give people the option or the tools to play how they want to - they WILL find another experience that does. In the end, you have to get ahead of the bull - so to speak. So that leaves us with a few key points. - Keep the experience as punishing as you can while maintaining the core gameplay loop. - Do your absolute best to ensure that the users are combating the environment, the antagonists, the struggle for survival - and NEVER the gatekeepers to those areas. (UI, Usability, etc) - Provide the community with the tools they need to take the work we the developers have done, and craft it to their own style of experiences. - Continue to iterate upon the base game past 1.0 - keep it fresh and compelling, like watering a beautiful house plant you do your best to keep the base game community thriving and interested. I apologize if I've rambled - I like to sit down and type out my thoughts at times to let you all see a bit behind the curtain.

Hey guys, I wanted to sit down this evening and go over a few thoughts I was having in regards to publicly viewed roadmaps, developer stated goals, and things along these lines (anything projected release based). Obviously - everyone involved, be it developer or consumer goes through the experience of gnashing of teeth when things come up that change, or in general push these back. We've tried annual roadmaps, quarterly goal roadmaps, we've tried heavily disclaimered target goals for a build - but in the end, it always ends up with one of us - the community around DayZ's development frustrated. One of the great opportunities of allowing folks access to the development via Early Access is that we can experiment, see how things work, and change them up. Usually this is restricted to gameplay, and infrastructure - but it can also extend to how we interact with the community and discuss/release information. Most folks might not know that as we move from one version to another (the two digit value before a build number . eg - 0.59.######) the leads from Prague and Bratislava spend a day and a half meeting, planning, and discussing what are target features and changes are for the next version. What we're going to do moving forward is take that information, and bring you guys - the players - into our "milestone goals" for the version that happens to be being worked on at the time. So we're looking at the following: Compile a master list of our intended major feature set for 1.0 At the first Status Report after the Leads Meeting include a list of our milestone goals for the next version Each subsequent Status Report include a break down of our progress towards completing the milestone Per Major Feature Any major bugs we are tackling at the time Once said version (milestone) is moved to Stable branch include a break down of what milestone goals we hit AND what goals were pushed (and why) We're hoping this will increase visibility into what our immediate goals are, and remove some of the speculation - as well as let you guys understand a bit more about what is going on "under the hood" at DayZ.