Lately a part of the community has become very virulent about DayZ on social media. In part because of the huge hype around upcoming features but also, and especially, because majority of players know nothing about the development process of a game. To overcome this problem, Dean Hall often respond to criticism. But few days ago “Rocket” was in good shape and argued a series of responses on reddit (here and here) worthy of a real interview.
Cheaters, hackers, scripters seem as prevalent as ever. Are you going to deal with this problem?
That is an extraordinary claim to make. I’m not aware of any scripts that do anything useful any longer. Certainly, the majority of the hacking effort has moved to memory-hacks rather than scripting. If you check the popular hacking websites, as I do, this is clearly stated everywhere. I’m actually not aware that anyone is making or using script hacks such as:
- parachuting cows
- spawning items
- teleporting players
- and so on…
It is far easier, and less risky, to exploit using hacks than scripts currently. There is little you could do with scripts in DayZ, as most things are conducted client-side. Instead, hackers are using memory injection and other normal techniques that are common across most games. This is what VAC is traditionally targeted against. BE was also designed, specifically, to deal with scripting issues. But such scripting problems existed because Arma had to be a very trusting game.
However, hacking is still something we are very concerned about. But we’re also very proud we’ve pushed it back into ESP, aimbot, wallhacks, etc… There are some unfinished areas of work – such as local management of magazines on weapons. These are being worked on.
At the same time there are other issues still plaguing this game such as the desync (Guaranteed messaging system?)
The guaranteed messaging system has enabled:
- Increase for loot spawning from 10,000 items to 35,000 items.
- Effective doubling of server FPS
- Made it possible for the first time, for us to run more than 100 players on a powerful box. This was not physically possible before.
- Allowed us to enabled a true physics SDK, with all calculations run on the server, and being distributed to the client realtime.
- much, much more.
What about the Path finding?
This is being worked on by a new studio we setup in Bratislava. Previously, we spent several months trying to make the current system work. Once we were finished with that work, we decided it would be easier to start again and write a new system – than to try and make the current engine system work better. This is a serious undertaking, and as I have said in the last two devblogs, we are close to testing early parts of this new system out on experimental.
I’ve overviewed the new collision system developed at bratislava and it blew my mind. A procedural system as part of packing the game raycasts to generate the navmesh in grid across entire terrain. This means navmesh is generated for the entire map, including buildings and trees and fences. The data was almost completely clean. It was beautiful.
What happens now is our programmers use this new system, with a new method, to ensure that zombies only walk on this global navmesh. This will revolutionize the zombies, imo. It not only changes their behavior but reduces their performance overhead. The engine only needs to check if the zombie is inside the navmesh and not to constantly raycast for geometry collision.
This does not solve dynamic objects (other players, zombies, animals), but we can deal with that next (source).
There are obviously enough people making assets for the game, why have some of them not been moved to other projects at BI
That is not how development works, the work would then suddenly need to be completed very quickly at the end. How are they supposed to generate all that content suddenly at the end of the project? Also, many of these people are hired specifically to work on DayZ, and they might not have any interest in working on other projects. In some countries, that would be constructive dismissal. Imagine joining an airline and being told you’re flying a 747-400, only to be moved to piloting a Cessna 172.
- Does it hurt you to receive content (for free) while waiting for more important fixes?
- Does it hurt development of the more important fixes for artists to make content?
I’ve indulged this one long enough. The artists have a list of tasks to do, and they are doing them. These are independent of much of the activity of programmers.
- They do not harm development of fixing core issues
- They do not harm the enjoyment of the game (I would argue they increase it)
I cannot see a single reason why we should send artists on paid/unpaid leave and not have them producing content. Adding more programmers only works up until a limit. Please check out the Brook’s law link I added. The more people you add, the slower things can become. Three people on the project were on it this time last year. Now there are well over 70 people working on DayZ. I don’t even know everyones name.
Software development is not simply a matter of “add more people”. Removing artists will not help get more programmers. Whenever we find a suitable programmer we are hiring them. We have current vacancies, in fact.
What kind of project management is DayZ under save for your oversight? Do you have a project plan?
The project following Bohemia’s project management processes, which follow Agile methodology. This see’s us with an overall roadmap, which is then broken into line items which form a project plan. This plan has then been broken down by resource, and is the rough budget. Although, I must stress, the budget is not about money: it’s about making sure the right resources are available at the right time.
Are IPRs held with BI to go over the overall project, timeline and issues that need addressed, if not why?
Assume IPR: you mean initial project requirements, or perhaps intellecutal property rights. Bohemia own the rights to development video games using DayZ. I am contracted to assist them in this process. The project requirements have been generated mainly through discussion with the team, with both myself and the senior management at Bohemia providing input and direction as required.
It’s managed and owned by Bohemia, and I participate as part of this process. As project lead, I consider myself ultimately responsible for the delivery/non-delivery of any targets.
Do you follow any documented industry best practices? also Is DayZ being developed under any type of well documented and formal software development life cycle?
I believe we’re making good use of Agile methodology, which is very important to our development. Given the very changing nature of the product (it did not exist two years ago, for example), and the rapid growth (only three people currently on the project, were working on the project this time last year) – agile is extremely important.
We’ve been changing direction quite a lot to respond to changes in scope (for example, based on the massive sales, redeveloping our plans to be very broad).
Beyond that, I would say the project is managed in a similar fashion to other projects I’ve worked on, such as aircraft acquisition with the RNZAF, and the RPDP prison project in NZ. There’s not much room for PMP, or such input. We’ve tried getting very formal but the only real success has come when were have been very flexible and adaptive with our approach, not being frightened to replan when we identify a weakness or flaw.
tl;dr : Agile /SCRUM
Is any kind of regression testing even performed on the patches that are pushed out or are they just put on the experimental servers for a few days and let into production from there?
We have about 20-30 testing staff who work 9-5. Their responsibility is mainly to test the current (internal) development build. They prepare a daily report of the state of the build against a “traffic light” listing of core game mechanics, and key testing targets. They can also be assigned important tasks directly from the team, such as testing new functionality or (most likely) producing good repro steps/missions for bugs reported from the community.
Prior to release of a build, it goes through at least 24 hours testing with this team. However, I do have the authority to order the build to be released (which generally pisses the QA lead off), and I have done that on occasion. We’ve only done that once with Stable, but we do it sometimes with experimental because we hope that it will become our development build reasonably soon. This means that people will be able to try out what we are working on, right down to the very day. This will also allow QA to focus on regressing bugs and also preparing for Stable updates – so we can (internally) stop worrying about experimental.
I understand that ‘we’ are the testers but why was Hicks ‘testing’ a patch in the production environment? Do you actually have proper dev, test, and staging environments?
When you hear of Brian testing in production, most likely this means on the central server side. Generally speaking, this means we are changing a value (such as login timeout). Our famous “cock up” with stable patching, when we had to hotfix like crazy, was because we made an assumption that a bug associated with the experimental central server, would not appear on the stable central server. Since then, a final step before production has been to do a “hot” test of these kinds of high-level, central server changes prior to a full deployment. Since moving to that process, we have not had any more incidents.
The update process of the central server is not linear like the game is. Technically, it is updating all the time as it has full-time engineers at our provider conducting performance changes, load balancing, hardware replacement, DNS changes to cope with DDOSing, etc… We are replacing our experimental architecture (which is much simpler) with the exact copy of the central server architecture. This will provide us with more robust “like” testing. However, we will still likely include a small “hot” spot test, live, of central server changes prior to mass rollout (which can occur completely independently of a game update, or a game server update).
Can we see the original and current project plan?
The internal project plan is not available, for what I hope are obvious reasons. But here is the official Roadmap:
- Playable vehicles
- Wide variety of native animal life
- Player created constructions in the environment
- Extensive interactions with the environment and crafting options
- Streamlined user actions and interface
- Upgraded graphics and physics engine (including ragdoll, etc.)
- Control and animations expanded and improved for fluidity
- Support of user mods
Some people have slammed the development of the game these days. What do you answer them?
I certainly agree that the game spent to long in pre-alpha, due mainly to my own mistakes and shortcomings. I’ve learnt from that and, as I said above, I’ve apologized for that on several occasions. Let me take the time here to admit that there were many things I could have done much better after DayZ blew up, such as much more planning (particularly contingency planning for unbelievable success). I talked about these in my GDC and GDC China talks, although I am not sure these are available online.
However, criticism of the current development would be criticizing the current team for their current actions. I disagree and do not accept those criticisms. I think we have a good plan, our roadmap addresses many of the issues that people have outlined here. Some people are unhappy with the speed, however, as in the statements from Undead Labs about State of Decay multiplayer – I don’t think what we are doing is particularly slow.
While I can understand it might be frustrating that I do not accept all your criticisms, I believe that the current plan is good, the progress of the team has been fantastic, and I think the success of the project is due to their efforts and that is why we are where we are now.