In a real-time multiplayer competitive game where you control a vehicle, is it feasible to simulate the whole thing on server side, such that the client only sends controls and receives sensor results? I mean like the client doesn't even know its own precise rotation, just the readings of a gyroscope and an accelerometer which are both susceptible to errors, and deduces the "down" direction from those two and approximate control forces. This would both solve hacking (writing a good robot is just as challenging) and lead to fun results like an attitude indicator going crazy from a gust of wind.

how long does it take for an answer from the server?

If I remember correctly, @Root used to be a game dev, so she might have some insights on that proposition of yours.

That being said, many games have tried many approach but none can say to be "cheat-proof".
One of the most recent example would be Valorant. The competitive FPS made by Riot Games doesn't give all the enemies' positions to the player unless they are in close range (read as they could see him), but that doesn't stop certain programs to still work.

Now, I lack the knowledge to discuss it further, but it's an interesting topic nonetheless!

Edit: As @stop mentioned, the server load would be pretty big in the situation you explained.

@stop The real question.
@Lor-irc It's the coin about two sides.
You cannot just go with constrantly sending all physics from server and expect it to be fast enough with heck a lot of objects.

AFAIK the typical is that player vehicles are always client side simulated but the server does sanity checks on the changes in player coordinates or even runs the simulation on both sides and compares results. I imagine the game can become very inaccessible to most if its entirely server side.

@stop Depends. Players are expected to host their own servers for casual games, so probably a while.

@Lor-inc the only games that have server-side-only are the ones where the gameplay is async, for example card games, because the rtt (round trip time: client to server and back) is irrelevant.

Okay, as an indie gamedev, what's the highest rtt that I should expect from player-hosted sessions? 100ms? 200ms? 1s? Is there some resource or statistics to make an informed choice?

it depends, but 100 ms and more is usually bad.

Keep also in mind that additional delay time between control input and system reaction can make the whole thing unstable. Like when you control the temperature in your shower, but forget about the delay of the hose to the shower head.

That's especially bad if the thing is supposed to be fast and not something like steering a ship. For a racing car, the control would feel like chewing gum with a 100ms of additonal (!) delay, and network latency is an issue especially for mobile connection.

And a round trip between SF and NY at the speed of light is already 30ms.

GOOOOOOGLE STAAAAAAADIA

Introducing: Rocket League.

Yes, the client still processes stuff, but the server enforces the actual state.

@Fast-Nop It's not a car and it's well automated, much like a plane. You don't have to constantly interact with it, in fact if you operate it well you only have to touch the controls every few seconds and during encounters. So it's not like players have to steer and take turns with .1s latency throughout the match.

Depends on how much money and development time you have for a server

@Root
Reminder to respond

As many people here have mentioned, serverside-only simulations are expensive, and are highly susceptible to latency.

If you have any sudden changes in movements, e.g. turbulence, bouncing on terrain, impacting birds/aircraft/aliens, sudden movements from players, etc. that will reflect extremely poorly if it’s only simulated on the server. It’s quite literally arbitrary amounts of input delay.

You are correct about not trusting the client, however. The number one rule is that all user-input is toxic. So the solution to this is what many games are doing, and as mentioned, Rocket League makes a great example. Both the client and the server simulate the physics. The client, with its superior processing power, makes longer-term predictions for all of its simulations (player, other players, other objects) and tweens the movements. The server sends updates every so many ticks, which override the client’s positions, and resets the affected predictions. The best implementations only invalidate the affected aspects of the predictions (e.g. keep velocity, recompute angle and rotations) to reduce load. Some implementations attempt to counter latency as well by having the server make predictions based on the average player ping. This can help high-ping players, and often considerably (and negatively) impacts low-ping players. It can also lead to all sorts of issues. See: Battlefield 5.

When the client predicts poorly, especially in the case of data loss, this results in imperceptible snapping (best case) or game-breaking rubber banding (worst case).

I like the idea of not exposing all data to automation attempts; however, moving your memory around at arbitrary intervals should be sufficient to block all but the most stubborn attempts. I’m also not sure how you could hide e.g. the current player’s position from the client, even with a server-only approach. The client still needs to render everything.