That said, I'm not sure I agree that doing it "after the fact" would work well. It would be a noticeable change for players who have a good sense of timing for leading their shots. A change like that could be frustrating for some players, particularly if the gameplay "feel" has already been somewhat established.
Ah. Yeah, I mean, it's not something as deep as p2p itself, i.e., it's not something that has to be thought about at an architectural stage. From a technical perspective, it's a solution that's equally easy to adopt at any time.
Obviously I'd mention it (if it's still appropriate) as soon as I have a good look at multiplayer, which will be long before most players see the game. I'm expecting to have the "make it as p2p as possible" fight somewhere between proving grounds and beta.
Identifying who is being shot at is probably the big difficulty here, sometimes I'm not even sure myself who I'm shooting at exactly
Well, a naive approach (doing it for everyone) would multiply the number of shots by the number of players . . . which still isn't that big a number, in modern computer terms. The obvious clever thing to do to make it more efficient is only create a lag-delayed shot when a shot comes within a cube or so of someone.
the effective ping to another player becomes the sum of the ping of both players instead of the ping between them.
Yeah. That's the server-induced lag I was talking about that this doesn't help with. I have some bad
ideas for what to do about that, but no good
For example, you can try similar approach: you can send position packets directly to the other guy, and the server can adjust you forward or backwards in time to simulate what p2p conditions looked like for the purpose of collision detection. The information is all there to do it that way, but that is a lot of moving parts and complication in server code, and it still has to trust you for what your connection to each other is.
You could make position and shots p2p and hits client-side, and let the server handle everything else with the world (like doors and kills and stuff). That makes cheating a lot more technically feasible, but as above -- the server theoretically has sufficient information to detect it, and players won't be anonymous.
I would be much more likely to go down either of these paths than I expect the DU guys to be, though. To me, shaving 25 or 50 ms off a connection is worth an insane amount of work . . . I kinda doubt they share those priorities. But we'll see.
So anyway. Yeah, I have some bad ideas for server-induced lag.
I'll keep thinking about it and see if I come up with any good ones, but it's a harder problem. Fortunately, the client-side hits is the bigger of the two pain points, and that's the easier one to fix in a clever way. I'm really hoping I can sell that, that'd be an easy thing to do and a big win.
I'd like to see P2P support, since it would allow fair transatlantic games, but I don't think they will have the time to implement and thoroughly test it if it isn't already supported by UE4. By the way, a disadvantage of P2P I haven't seen mentioned is that the upload bandwith required grows with the number of players. This could become a problem in big games with most people having an asymmetric connection.
Yeah. This is already a problem sometimes with 8 players. There are ways to mitigate it. For example, you can slow the update rate way down for people who aren't close to you and who you can't see, or even fall back on C/S in those cases.
It doesn't help if you have 32 people in a single battle, but I'm thinking you might expect performance problems there for other reasons, and at any rate, you'd never have 32 people in a single battle for very long
, and I somehow doubt lag would made it very high on the list of things causing chaos in that scenario.
With regard to aiming/lag-lead, I still think it would make sense to only show the own shots once they are fired on the server
That's certainly an approach you could take, in the 'telling you about it' class of strategies instead of the 'fixing it' class. Other things could be done along those lines -- for example, lag lead indicators on targets. Personally, I think that approach would drive me crazy
. I fire a lot more shots than I observe hits, so breaking the verisimilitude on the former would bother me more.