0
\$\begingroup\$

First of all - I know some networking concepts and I coded couple games with GDX/Kryonet/Unity/UNET. I've read all the Gaffer's, Gambetta's and Valve's, but still, can't decide which approach should I follow.

Network engineers say that for the game to be truly 'safe', we need a fully authoritative server. To shorten the definition:

A fully authoritative client-server system is when the client sends the input only, and the server runs the physics.

There are exceptions to this. Client-side simulation these days is required to maintain a real-time experience. It's impossible to achieve a real-time smooth movement without the interpolation, extrapolation and other prediction mechanisms.

I've integrated a small UNET network, where I can move my players around with a click-to-move. The synchronization is made through the built in commands and transmissions (syncvars). I perform the logic myself in callbacks. To fix the jitter, I combined all the knowledge from the websites above and coded a buffer which is blocking enemies coordinates for 100ms so I have some data to interpolate them on the clients. It basically views the enemies 100ms in the past.

I know that modern RTS games networking mechanisms are far more advanced than just buffering & interpolation, but it should be enough to create a concept similar to DOTA/LoL/Diablo 3 smooth feel.

As far as I get it there are two approaches:

  • Authoritative Input - sending inputs, receives positions & own corrections so the client can fix wrong predicted values
  • Non-authoritative Input - sending Transform values (position, rotation).

The second approach is believed to be non-deterministic, not authoritative and way easier to implement. Comes with a risk of cheating.

Of course it does come with a risk, but the server is the one with a head here. He owns all the objects, he checks their movement speed, teleportation, everything and transmits the correct data to the rest of the crew, not the cheated one.

From the other point of view, the first approach with input safety applies only to deterministic-lockstep simulations. I don't really know if modern games use this approach (I read that Blizzard's HoTS does, Valve's CS does, but I'm not sure of MOBA's).

My question is:

Is this unwise/unprofessional to transmit positions/rotations/transforms from the client to the server even, when the server decides what to do with them and passes through anti-cheat mechanisms? Writing a simple anti-speed/teleport hack seems a way easier than fighting with floating point determinism and making the server & client's simulations fully equal.

Is there something I'm missing?

\$\endgroup\$
  • \$\begingroup\$ I think you've conflated "the server's simulation based on the players' input is the sole authority" with "the server is the only one allowed to run a simulation." There's nothing inherently wrong with also running simulation on the client, but crucially the results of the client's simulation are not used to determine what happens for other players. Where the simulations diverge due to non-determinism, network delays, etc, you correct the player's local sim to match the authoritative description from the server. So a client that sends only input can still coexist with client-side simulation. \$\endgroup\$ – DMGregory Jul 9 '17 at 12:35
  • \$\begingroup\$ Yeah, so if my client has no control over enemies (interpolates them only upon receiving their server's transform) - it doesn't matter how do I transmit the input - I just need to make it secure and non-exploitable server-side. Am I correct? \$\endgroup\$ – Jacob Jul 9 '17 at 12:56
  • \$\begingroup\$ Sort of. There's still the question of how to make it secure and non-exploitable. Doing that with raw input is easy - validate that the input is in the range you accept (eg. no "Use Ability 5" when the abilities only go up to 4), then run your gameplay logic on that sanitized input. Validating the results of that input is much harder - anytime you tune your gameplay behaviours (say now the dash move is 20% faster, but costs 10 more energy), then you also need to ensure your validation logic accepts transformations resulting from this updated gameplay as valid & permitted, adding complexity \$\endgroup\$ – DMGregory Jul 9 '17 at 13:45
  • \$\begingroup\$ Cross that bridge when you get there. \$\endgroup\$ – S. Tarık Çetin Jul 9 '17 at 23:19
  • \$\begingroup\$ Easy to say, much harder to code :0 \$\endgroup\$ – Jacob Jul 10 '17 at 9:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.