Creative Director Brian Hicks shares the latest info on where we are at in the development process, Mirek and Peter are talking about removing SQF and Adam wants to share with you our progress with trees – the biggest change Chernarus has received in the past years.
Dev Update: B. Hicks
I don’t have too much for you this Status Report, fortunately Adam from the Environment team, as well as Peter (Lead Designer) and Mirek (Lead Gameplay Programmer) are joining us this time around – so there should be plenty of new info for everyone to dig into.
Recently I sat down over on our forums to discuss some of the questions or confusion we get around addressing issues on the Steam branch while development moves forward internally on upcoming builds. I encourage everyone to take a look at it – as it might serve to relieve some confusion around what gets fixed, when, and so on. In addition, our Producer Eugen wrote up a forum post covering the internal milestone we recently reached towards Beta, eliminating support and dependency on the old SQF scripting language that so much of the DayZ Alpha had throughout it. This was a huge step for us internally, and something many of us have been talking about and looking forward to for years. I’ll make sure to link both forum posts at the bottom of my portion of the Status Report.
We’re continuing to push new builds through Experimental/Unstable branch and on to Stable branch as we try and address the remaining critical issues with .61. Since the last Status Report we’ve been able to address several issues with memory management on the client, pushed several improvements to server performance, resolved a few known server crashes, resolved several of the performance issues tied to light sources, and we are continuing to address:
- Invisible Infected
- Additional Client Crash issues
- Server Memory Consumption (Which can sometimes cause issues with player stuttering, battleye time-outs, and so on)
- Server crashes tied to vehicles and/or AI
We’re hoping to be able to show some teaser video content at PAX East over at the Astro Booth showing off some of the progress on the visual overhaul of wild Chernarus for .62, rest assured this will also be shared through our standard channels if we’re able to have this available in time. As I mentioned earlier, both myself and Eugen made two forum posts that are very helpful reading to understand what our priorities are internally, as well as the impact the internal milestone of finally being able to move away from SQF has on development. Check out these posts here (you do not need to make an account to view them, don’t worry 🙂 ):
I see a lot of folks getting upset that bugs in legacy stuff isn’t getting addressed at the speed they would like, isn’t getting prioritized right now, or in general the move to Beta isn’t moving at the speed they would like (or in some cases – systems they are waiting for are not in game just yet). I’m sure for some of you this post will be a rehash of things I’ve said before (and I commend you for keeping up to date and informed on development 😉 ) but for those that may have missed some of this stuff, I’d like to go back over it…
This week, we’ve reached an important internal milestone of completely deprecating our old SQF scripting language (it’s been with us, in some form, ever since the first Arma got released). From now on, our internal branch of DayZ only runs modules written in the Enforce Script. Since I wanted to cover that internal milestone and explain its implications, I`m going to be more outspoken than usual, but before I get slightly more in-depth, the most important part for majority of our fans is…
We know the road to the next few major builds hitting Steam might seem long, but the work going into reaching Beta is extensive – and a major change for DayZ as a whole. I know I personally (and I’m certain the whole team as well) appreciate everyone’s patience, and feedback as we move towards it. I’ll see you all in Chernarus – and remember, gunshots attract attention 😉
Dev Update: P. Nespesny
Last week, we reached one of our internal milestones, specifically the removal of SQF, the high level scripting language which was introduced back in days with Operation Flashpoint. When we started to work on the standalone DayZ, we heavily relied upon SQF with its rich API of commands built over years of usage across the Arma series. Our original plan was to prototype and implement systems and mechanics we wanted to have in DayZ in SQF, and then then hard code them to Real Virtuality engine directly to gain back some perofrmance. This changed once the decision to build new Enfusion engine was made, based on previous RV and Enforce engines. The Enforce engine (used in Carrier Command or Take On mars) used a powerful and fast low-level object oriented scripting language with its own IDE and therefore it was a logical step to carry it over and improve it.
Once the newly established Enforce script was production ready, we started rewriting all of the gameplay and support scripts from the old SQF script, which offered us to become largely independent on programmers and to keep the game open for modding. This process was quite difficult and tedious, mainly because of missing backwards compatibility, specific design and technical dependencies, limitations found down the road, and all that mixed together with our commitment to release playable version of DayZ in Early Access program. All that led us to maintain and develop basically two versions of the game side by side – obsolete one for public to play in the meantime, and a new one for us developers to make the game as good as possible – one that you, players, would enjoy later.
Recently, the new animation system also began to be synchronized between server and client, which was a long awaited impulse for us to switch exclusively to “all new” mindset to push things forward internally. Now every piece starts to finally fall into place, forming something I like to refer to as DayZ 2.0. The King is dead, long live The King… see you in Chernarus folks!
Dev Update: M. Maněna
In the last status report, I mentioned that we started removing the legacy scripting language. We’re done with it now, so Enforce Script is the only scripting language which runs on our internal version. We will continue removing other legacy systems: the next stop is the animation system.
Synchronization of the new animation system is done, now we have to apply new synchronization rules to the user action system and to events performed only on server side. New player controller is now receiving support for melee combat, which will allow our animation team to tweak the combat animations in-game.
Also, it’s important to note that our Bratislava team is applying the new animation system to AI units. This will allow us to have much better interactions between players and infected/animals.
Otherwise, we are still working on some major issues for 0.61, which we also need fixed for the 0.62 update, so every important fix is directly merged into the 0.62 internal branch, too.
Dev Update: A. Franců
As many of you already heard, the upcoming 0.62 update will introduce a first set of audio-visual changes to the environment of DayZ. You may remember that we’ve already shared some progress on this matter last year. In this status report, I would like to touch on the subject of updating forests in Chernarus a little bit more. This is by far the biggest change Chernarus has received for the past years of its existence within Arma 2 and DayZ. This would be really tedious and unwise thing to do manually (there is a lot of forested areas), so we have internally developed a forest generation tool that will allows us to generate most of the forested areas on Chernarus. While the whole process of getting generated forests on top of anexisting map (that has all kinds of other objects already placed) requires some polishing work of course, we are very satisfied with the results so far.
One of the most important things for new forests was to have enough variety. There are four key features that allowed us to have more varied forests. First, we have got roughly 6 different generation templates for each tree species (you can imagine this simply as young, mixed, older forests and so on). Achieving such variety would not be possible with the old models, so we have got at our disposal a completely new set of vegetation that contains roughly 3 times more models than the old one (and it is still growing). To give you an idea, lets take a look at the standard beech forest case (Fagus sylvatica). Following picture shows an example of available models for beech forest.
This is quite a big change when compared to the old vegetation set (where we had like 3 available models for this specific species) and the picture is not even showing all models (we also do have dead tree variants). I should also mention that this is not just the case of beech trees, we do have similar-sized sets for oaks, pines, birches, larches and spruces. Just imagine combinations that can be done within just one species alone, not to mention what can we do when we combine them. We of course have some other types of species prepared too (for rarer use within forests and of course for solitary ones within fields and settlements).
The third thing (that helps us achieving forest variety) is the tree colorization feature, which we already announced in one of the last years status report. This feature enables us to differentiate individual trees by changing their color ever so slightly to achieve a better autumn feel. And finally, fourth is the addition of 8 forest surface textures. This allows us to greatly increase variety on the ground level, because configuration of randomized miscellaneous objects is done per one surface texture (we can have one with more grass, one with taller ferns, etc.)
Please keep in mind that what you see here is still work in progress and does not represent final look, these two are here to give you an idea of how the transformation from old to new forest could look on a small patch of forest within Stary Sobor fields.
We are well past of setting up the generation process of the whole map and tweaking the visual feel of individual forest templates (assigned to forest parts on the whole map). Our primary focus now is to make sure we won’t introduce any major performance problems. There is no question about the fact that while the new vegetation models were done to be much more performance friendly, we won’t just aim for the same density as the old forests were. The introduction of Enfusion renderer with .60 provides us with an opportunity to go further.
We are currently working with roughly doubled object count (that equals roughly 2.6 mil of vegetation objects). Our PCs are running map benchmarks overnight (multiple times on multiple machines if necessary) to get an overview of how does the current version of Chernarus with new forests perform. We can then use this information to make additional changes to the generation (forest density). Following picture shows what kind of results we get from one type of benchmarks that we do.
There is still lot of work ahead of us, but it is awesome to see that things are finally coming together. We cannot wait to share more info about things to come with 0.62 update (yes, there is definitely more to talk about).
Feedback Tracker :
Hicks Forum post on Development:
Eugen Forum post on SQF Script change: