devtrackers.gg
Hi everyone,
There was a recent bug in New World that drove some speculation on how our simulation works. The bug was addressed quickly, but both the speculation and the bug deserve some clarity in explanation.
New World is not client authoritative - from a simulation standpoint New World is entirely server based. At a high level the model is this: clients dispatch controller inputs to the server, and the server then checks that input for limits that might invalidate it, then if accepted uses it as an input to a character (“actor” is our internal name) within server memory. Physics and game rules are then run (entirely server side), and the outcome is sent back to the original client. Clients will then draw the outcome determined by the server.
Take the example of a player swinging an axe to chop a tree. To the player, they hit a button and the axe swings, which might seem very client based. What actually happens is more complex. The player hits a button, a message is dispatched to the server that says “I pressed a button for a swing”, and at the same time the client starts drawing the visual of swinging the axe on the player display - this part is strictly graphical, and has nothing to do with the simulation. The server doesn’t even know about this graphical representation and hears no information other than the button press itself.
When the input reaches the server, it is checked to see if it is possible, and then the server begins animating an entirely server side version of the “skeleton” for the character with a swing. This is not an approximation or a bounding volume version of the skeleton, it’s actually fully detailed, being fully animated, so we can have precision that if the axe just barely grazes the tree, that is consistent between server and what client perceives as possible. If the result of this entirely server based animation is the axe intersects a tree, then that result is sent back to the client, or a miss is sent back. It’s important to note that only after the server has performed the animation, and that results in the axe intersecting a tree, is this considered a success. We don’t short cut or roughly compute this, we do full physics detail for all such actions. Upon receiving the outcome, either hit or miss, the client will adjust its visual display to match what the server has determined. There are some client side tricks we use here to “stretch” the animation while the client is waiting for the server answer, but the outcome is always based only on the server answer. This same pattern applies in combat and other physics simulation interactions.
We did have a bug, in which given certain circumstances we were waiting server side on input from a client before processing through to outcomes. Combined with an intentional weapon effect that allows for brief invulnerability, this created a situation where players could reach an invulnerable state and prolong it by making the client unresponsive, even though the client has no say in damage (both damage the player creates and damage taken by the player are computed server side based on the results of physics simulation plus game rules). This was a particularly bad bug given our server based simulation, and we apologize for that. We corrected the bug in code the same day we learned about it, then tested to make sure nothing unintended came out of those changes, and published the fix immediately after that.
There are also obvious bugs there we are addressing, in terms of rate limiting and controlling action so the fight remains a playable frame rate. However at no time are the clients making decisions or “freezing” characters in place - if character are frozen it is because the client is behind on drawing, but the server simulation continues.