A 225 km2 open world post-soviet state wiped out by an unknown infection. Go Solo, team up with friends or take on the world as you choose your path in this brutal and chilling landscape using whatever means you stumble upon to survive.

This devblog will be focused on describing the progress with one of our biggest issues: Zombie Pathfinding.

Development Priorities and Pace

Our major focus has been on establishing the architecture, both in the team and in the game, in order to deliver best in the future. This involved us drastically increasing the size of the team working on the game. This had a severe short-term impact on our progress as our existing team had to devote time and resources to training and planning. The new zombie pathfinding is a good example of this approach beginning to produce results.

Some examples of future major changes coming as a result of this new focus:

Entirely new rendering system (allowing potential upgrades to DX10 or DX11, ports as well).

Complete refactoring of the inventory system. While not a big change for users, possibly allows some more advanced systems to be implemented and better performance and less bugs.

Background

Zombies have proven to be one of the most difficult to develop components of the game. When we were developing the game we realized that in the time we had, we would need to work within the parameters of the AI already in the engine. In the engine, AI is calculated on a “per agent” basis, with some caching for things like targets (shared target info, etc…). In the mod, this was dropped in favor of calculating visibility and target info on a “per player” approach. This meant that zombies in the mod were simply pawns, activated by players moving around.

In addition to behavior problems we also experienced problems with pathfinding and collision for the AI. We were getting the engine to do things that it was never designed to do, especially regarding interiors of buildings. We attempted to refactor these solutions to accommodate our changes but, as can be seen by playing the current build, they fell short of our expectations. In the end we decided it would be easier to develop a new approach from scratch.

The Challenge

There are many exciting solutions available for pathfinding, it’s fairly standard fare in the video gaming industry. Our problem was not unique, but our situation was: our world is very big yet it requires the same precision as a small one.

The team devoted to solving this decided to use navigation meshes. The serious problem it presented, though, was how to generate these meshes, with nearly 2 million objects on the map doing it by hand would not be an option. So a method was devised to split the world up into grids, and then raycast at a precise interval and generate chunks of navmesh. This is all done during the packing process and “baked” out into data that can be read by the server and client. This uses the wonderful approaches outlined in the open source navmesh project Recast and Detour.

The Results

I spoke to Martin Slavkov, programmer behind the solution, to help me outline the result with some screenshots.

A small program was developed to read through the world, load all the objects, and then work its way through tracing billions of lines to calculate the ability to move. This then works out not only where outside you can walk, but inside as well. It gives great precision while still working for a very large scale world both indoor and outdoor. Having a unified solution for pathfinding makes implementation much easier.

The engine is then able to load the chunks in as it needs. It does use some memory (around 600mb extra, maximum), but it only loads the chunks it needs. However as we are moving to 64-bit on the server side, this reduces any potential issues with memory.

Performance optimizations can be very significant. Currently the team are working on parallelizing the AI pathfinding function so it can operate on a separate core. With all new functionality we are developing in this way, unfortunately that means that it can take longer for us to develop but the results for performance can be massive.

Previously two different systems were used for navigating AI. The exterior one handled navigation around static and dynamic objects, and an internal “path” system was used for building interiors. This involved artists defining paths that AI could follow. We had to drop this interior method because of the massive performance issues with large numbers of agents.

In the screenshot above, you can see a path between two red points. Because the system is now unified it means that more efficient (and more natural) pathfinding solutions are available to the AI, at a fraction of the performance cost as before.

Report from the Lead Artist, Chris Torchia (View Imgur Gallery of new art)

I’m happy to report on the loads of content which will soon hit experimental servers. Recently the Prague and Bratislava studios had our first meet and greet so I was able to get a first hand look at all of the ongoing work by the artists and animators on our new animals. We have a basic implementation of prototype animals that will be swapped out by our Bratislava artist’s work which is looking incredible!

Improvised fishing tackle and a carp were created, which players will be able to catch in ponds. We have also created some filet models which you will eventually be able to cook. This will all add up to be a literal game-changer. Speaking of animals - we also met Big - the office pet tortoise in Bratislava. Hm, that gives me an idea…

Our character artist is further expanding with the addition of a new large-capacity police vest to go along with our ?MON-inspired ???? uniform. We have also started working on EMT, Firefighter, and finalizing the Gorka uniforms.

Fireplaces, Hunting, And being a lumberjack!

We pulled fireplaces and hunting from the previous update in their state at the time, we felt they would hinder gameplay not enhance it. The extra time has been spent improving gameplay aspects and also identifying how we can better support it.

The build to experimental will show the basic structure of how this will work. Chopping wood from trees now gives logs, and after a certain time, the trees will be “expended” and fall over. Tree cutting is done by holding an axe in your hands, and using the mouse-wheel action menu. This is a prime example of why we want to remove the mouse-wheel action system. Instead of this, we envision you simply hitting the tree with the axe and being rewarded with wood - but that is for the future.

Fireplaces can be upgraded with stones, which are recovered from the ground around rocky areas or by hitting rocks with a pick-axe. Fireplaces can be crafted by making a “fireplace kit” out of items such as rags and kindling. Kindling is recovered by searching the forest floor for sticks. All these scavenging aspects need more refinement as part of a new action system, but they’re exciting changes that will pave the way for more complex systems such as horticulture.

Our current targets have us putting out builds to stable once a month, a huge inspiration for approach we aspire to is Prison Architect who do this very well. We have no set timeframe for experimental releases, these are done to assist us with preparing for stable releases.

Above all else, it’s vital that people appreciate several things:

Different tasks take different amounts of time

Priorities for tasks are built around what is needed based on dependencies, not what is most needed to satisfy the game design

Scheduled builds are targets, not absolutes. We will delay and postpone builds where we are not confident in their status.

Devblogs are no longer scheduled weekly, and are done as often as we can to provide background for our progress.

The Final Word

This is an extremely exciting time for us all as we come out of two months of very aggressive growth. We’ve expanded the team a great deal, taking a huge risk in doing so. That risk is paying off, and we’re excited to see the massive impact that the pathfinding and collision changes will have on the DayZ experience.

This is complete nonsense: If it is implemented properly and the game itself is optimised well, the difference in performance will be negligible. All versions should run smoothly, the Windows version very marginally better.

If Valve's experience in porting L4D2 to Linux is anything to go on, the OpenGL version might even run faster under Windows.