Posted 07 September 2016 - 10:21 AM

Hey Rebas,

Rebas Kradd, on 07 September 2016 - 07:37 AM, said:

What I'd be interested in, is hearing more specifics about how this sets MWO apart from other games

I can't speak on behalf of all other multiplayer games, but in my experience, predicting and lag compensating projectile weapons is generally a much harder problem to solve and so is usually avoided. This would be something that sets MWO apart. As I mentioned in the Gamasutra article, the nature of MWO movement gives us the opportunity to do something smart to lag compensate projectile weapons efficiently. In a twitch style FPS where you can instantly change the direction of your velocity in a single frame, the non-iterative solution I have described will not work correctly, and you will likely need to fallback to some kind of iterative solution which can be very complicated and/or expensive.

Rebas Kradd, on 07 September 2016 - 07:37 AM, said:

how much more calculations are being run on the server than your average FPS

Again, it's tough for me to say what all other games do, but I can give you a sense of the extra work MWO does in order to lag compensate weapons. When you fire, the server needs to rewind all 'eligible' targets--including friendly targets. This is because if you don't rewind all targets, you may strike a 'present' target and incorrectly detect a hit on the wrong target. Rewinding 23 mechs (because you don't rewind the shooter) every shot is really inefficient, so what we do to optimize this is build a set of eligible candidates based on a bounding box that encapsulates the entire rewind period for a target. You can imagine a rectangular box that stretches along the velocity vector of the target. It extends from the position of the rewound target position ping seconds ago to the present target's position. We can ignore all targets whose stretched bounding box does not intersect the firing vector. This is a very important optimization, because the actual rewind operation itself is relatively expensive, and this optimization often culls the number of targets that need to be rewound to one or two. The worst case is when every mech is lined up in front of you when you shoot. All these targets would need to be rewound.A projectile rewind is this same rewind check plus a little more work. Instead of rewinding by ping, we need to rewind by an adjusted ping that is based on a line test of an adjusted velocity vector against each potential target's geometry. This is better explained in the Gamasutra article, so I won't repeat everything here. This amounts to 23 additional line checks against target geometry. We can't only use the bounding box of the target here, because we need an accurate hit time to get the correct adjusted ping value. Of course, the bounding box is used as a broad phase optimization.So to summarize the extra work the server does for lag compensation:- For a trace fire weapon: 23 line box tests + N (usually 1 or 2) target rewinds + 1 world ray trace- For a projectile weapon: 23 line target tests + everything else a trace fire weapon doesKeep in mind this is per shot, and in the case of a laser, this is sustained the entire time it is firing. With all our optimizations, the servers ends up being able to manage this extra work without too much trouble, even in an intense firefight with many people firing simultaneously.

Rebas Kradd, on 07 September 2016 - 07:37 AM, said:

what demands it places on map design

I wouldn't say this has any direct affect on map design. It's still important that maps be within their appropriate budgets to ensure client performance isn't negatively affected. And it is generally ideal if a map isn't designed to clump everyone together into tight corridors. As I mentioned earlier this can make rewind checks more expensive. But generally speaking this isn't a problem that requires adjusting map design.

Rebas Kradd, on 07 September 2016 - 07:37 AM, said:

and examples of how it affects other systems.

This biggest system affected is of course the weapons system. As you can imagine, this system is very sensitive to weapon mechanics. What might seem like a simple change might have serious impacts to the rewinding implementation. If, for example, design wanted to add a warm up animation to a weapon before it fires, this could seriously mess up the timing of the current implementation and would probably need to be handled specially.The next biggest related system is movement. If design decided to suddenly add a game mechanic that allowed a mech to stop on a dime and turn in the opposite directly, this would have drastic consequences for the rewind implementation--even to the point of breaking it.The physics system is also affected. Depending on the way your physics engine works, it may not like the idea of moving a single object outside the regular physics simulation for a rewind. This was the case for our version of CryENGINE and we had to make some adjustments to get this working correctly.I hope that answers your questions