This week, Brian and Mirek are explaining our decision to push vehicles to Stable branch early, Peter is teasing bits and pieces about our recent effort to improve the melee weapons combat, and Viktor reports on the progress his team made on animations used with that new melee combat system.
Dev Update: B. Hicks
We appreciate everyone’s patience with this Status Report coming out a day later than normal as our Brand Team works on recording the next of our Dev Spotlight videos for Viktor Kostik, our Animation Lead (Baty shares more on that in the Community Spotlight).
For this Status Report I’d like to lead off briefly talking about vehicles on the Steam stable branch, then take a quick look at the critical tracked issues on 0.61 and hand off to Peter, Viktor, and Mirek for the rest of this report.
As many of you may have noticed, we went ahead and re-enabled the spawning of vehicles on the Stable branch servers. We’ve gone through a good deal of iteration on these over the last few months on experimental branch. While we’ve been able to tackle a great deal of the issues discovered in testing on the Exp/Unstable branch, there are still obviously critical issues with the existing implementation.
Vehicles are a pillar of the DayZ experience, and one that we’re far from being happy with in their current state. Their push to Stable was a measured decision based upon the limited number of active players on Experimental/Unstable branch (to be fair, the draw to participate in Exp/Unstable is obviously lower on hotfix builds compared to full updates) and the data we received through the feedback tracker, and repro steps provided.
Not an easy decision to be sure, but given the option of leaving them on Exp/Unstable only and not getting the larger pool of users getting hands on with it – the call was made. Mirek will elaborate upon some of the technical points below, but I want all of you who are concerned about the operation and systems behind vehicles to rest assured.
Where we are now, and where we want to be are two separate points and vehicles -will- get the attention such a core pillar of DayZ deserves. Like many things right now, all that is required is patience – as the push to Beta is a massive undertaking for us, and every in game mechanic and gameplay system is impacted by it in one way or another.
As far as 0.61 work goes – we’ve continued to push builds through the Exp/Unstable branch over the last few weeks – and today we should be pushing another update to Stable branch from Exp/Unstable. For today’s Stable update we’re looking at changes that should hopefully address:
- Characters/Infected not dying under certain conditions (Eg: Unconscious players & headshots)
- Disappearing bodies of unconscious players when disconnecting
In addition to these, we are still investigating several issues related to the reintroduction of vehicles onto stable branch – such as but not limited to:
It’s critical to understand that poor server performance can be the root cause of a significant amount of issues that you as players encounter. While this may seem concerning, as we are approaching the limit of what we can do with 0.61 and the legacy technology – the Beta milestone, and introduction of new technology on the Enfusion side opens up a lot more opportunities for us. Not to mention being able to move the server away from having to track two physics systems, which in and of itself is very resource intensive.
Dev Update: P. Nespesny
Since new player character got on stage, we started to prototype a new melee combat with animators and programmers. Through the time, whatever we did with the melee, it still ended being just unsatisfying.
In past, we bet everything on tracing actual swings and finding their collisions with geometry. While this system has its own positive aspects as it simulates real trajectories, it just doesn’t behave well in such broad multiplayer environment that DayZ offers, where you need to fight server-client synchronization foremost. Even if that side of things worked flawlessly, there are other issues connected with such system. Most notably it’s very difficult to predict where hit lands, or even if it reached its target, which results in uncertain behavior and ends up as frustrating for players.
With all that in mind, we decided to look at it from a different perspective and build a new melee combat from scratch. Instead of simulating trajectories, we’ll experiment with evaluation of successful hit, right after attack is initiated, based on variables such as distance and direction to target, speed and others. Everything in that system is reevaluated throughout the action to avoid possible misinterpretation (e.g. opponent being hit and thus receiving damage, even when he fell down from cliff before action was finished).
This approach should ensure fair hit detections, and also when combined with new full body animations of melee attacks, where character is moving forward during attack, it will allow us to utilize slight rotations and drags of attacker towards his opponent, which should results in proper visual contacts of hits.
What remains the same is the rule ‘every item is a melee weapon’ with some exceptions applied. Especially heavy items as vehicle wheels or barrels with their separate set of movement animations will be omitted from that rule for logical reasons. It’s also still valid that there will be possibility for melee attacks with ranged weapons like pistol whips, buttstock hits and bayonet stabs.
More attack animation with same melee weapon were added, resulting in more visual variety and combos, however we don’t plan to take advantage of combos from the gameplay perspective yet. On the other side, we want to add dashed attacks from sprint. We are considering to add charged attacks and eventually a push move in case it will be doable (do not confuse with current issue of infected pushing player characters around, which is caused by interaction of two independent physics simulations), to deepen melee combat mechanics. New animation system also allow us to play proper impact animations when character being hit.
New damage system has already been deployed and it’s used exclusively with the new character, providing straightforward configuration and clear damage outcome from hits per weapon, properly affected by clothing. I bet new melee combat will prove to be worth the wait and it will yield satisfying results for you, players, and together with other systems which are being worked will create best possible overall experience.
Don’t lose your grip on the dreams of the past… see you in Chernarus folks!
Dev Update: V. Kostik
New player character is progressing well. We are now testing and iterating the new melee combat system in game. This includes cooperation between animation, design and code departments – designers are giving us their thoughts on how the combat should look like, we are adjusting attacks to that, and programmers are taking care of controls and giving us features we ask for. We are still testing on a basic set of attacks for bare hands and two handed item though, so we are still rather prototyping, but once we are satisfied with the results we will add more variations to attacks as well as unique animations for some items. Of course a lot of polishing is also expected.
As the player actions are now working in a new system with new scripts, we are changing some of the old “one time” animations to looping ones. We have also started to work on more unique animations for interesting actions. To name few, we have recently created stitching, animal skinning, starting fire, washing hands and other animations to improve overall experience when interacting in the world.
Dev Update: M. Maněna
Today, I won’t have anything new about 0.63, we’re still working on tasks which I mentioned two weeks ago, but because we enabled vehicles last week on 0.61, I would like to clarify and describe issues which they have and how we will solve them.
First, I would like to describe how vehicles are different than vehicles in Arma 2 / DayZ mod. There are two major changes:
DayZ Standalone is using Bullet Physics Engine, which allows us to create better vehicle physics behavior, but on the other hand, simulation is much more complicated. We’re still working on better vehicle simulation which we would like to introduce in 0.63. But the worst issue about vehicles in 0.61 is collision detection of dynamic physical objects and terrain (you can also observe this issue when you throw some item to ground) and engine programmers are currently investigating this issue.
DayZ Standalone is using a client-server architecture instead of peer to peer and since 0.61 there is full server authority over player/vehicle transformation, which is preventing against cheating (teleportation/flying/speedhacking).
In DayZ mod, vehicle is simulated on player’s client and results (position, orientation, etc.) are sent to other clients, but in standalone version, player/vehicle is simulated on both (player’s client and server) and server sends results to other clients and to player’s client as well for correction.
When simulation result are different, player’s vehicle is corrected and that is the stuttering you are observing. This can happen when some vehicle state between player’s client and server is desynchronized (f.e. gearbox state) or when server performance is too low. We’re looking for state desynchronization now and as I wrote in past status reports, server performance optimizations are a long term process (we already have some improvements ready for 0.62). Anyway, we will implement better smoothing algorithm, so the correction wouldn’t be so aggressive.
Now, you can see that vehicles in Standalone are completely different than in Arma / DayZ mod, so a lot of issues can arise. Vehicles hit experimental on December 23rd, several days after 0.61 hit stable. We thought that vehicles would be the reason to stay on experimental branch for a larger number of players, but the result was that experimental servers were almost empty.
That means we didn’t have enough data of how they behave on full servers or in different situations. We’ve fixed some issues which players had found on experimental servers (server crashes and some bad behavior of remote vehicles) and then we needed more data, so we enabled them in central loot economy (we can always disable them again without any update) and are now gathering more data to fix / improve the vehicle simulation.
Eugen Forum post on SQF Script change: