If any of y'all have played APB reloaded, you might remember the system they used to make an MMO's worth of cars all driven by players. Driving 'on' the server. Basically, you send input to the server, it calculates what happens, it sends it back to you, then you see what happened. I'm aware that this would create input lag etc, but it currently seems like the best way to keep everyone synchronized. Thoughts?
It was suggested before. If every player would have to send the server data (mass, speed, position, rotation, etcetcetc) for each node and beam and transmit to other players, I can just imagine the lag.
What I'm saying is players just send input for turning the wheel, accelerating decelerating etc. all the physics would be calculated server side, then sent to the players.
Although that would happen, it most likely wouldn't be that extreme, plus I'm still not sure of a better way to do it.
Any input lag in a driving simulator is a massive no-no. It's okay in an arcade racer where you don't have to be precise, but the machine's reactions to the input have to be instant in something realistic/precise like BeamNG otherwise it'll be undrivable.
That wouldnt help, you still have huge swathes of data to send even when the physics are done server side. You'd be better off just going the full hog and sending the input data to every player direct and letting their machines calculate it (which come to think of it, may be doable as a plugin). Would desync fairly quickly though.
This is actually how every major FPS multiplayer works. A client only sends his input information to the server which then calculates all the movements, shots etc. You may ask why you don't feel any input lag in BF3 or Counter-Strike then? Because at the same time the client "predicts" the movement. That means your client also does the physics calulations until the server sends his "approved" results back. A very good explanation including a live demo can be found here: http://gabrielgambetta.com/fpm_live.html
this is ridiculously wrong. that type network architecture doesn't work well for complicated, fast paced 3d games. none of the major game engines send inputs in favor of gamestate data. it's also a stupid idea for a car game.
Client side prediction is actually used in almost every AAA title out right now. You are correct in stating they don't use inputs though, the prediction is based on states only. The jerky movement of other players during laggy sessions is caused by their previous state being a running motion in one direction so the prediction will carry them on in that direction either avoiding an obstacle or attempting to dive over it depending on what its normal AI would choose to do (actually that is on the more extreme end, there is a game which does it but I think most go with "hurr durr lets just run into this car door repeatedly"), then the fresh network data comes in and shows actually the player didnt do that at all and instead chose to turn around to run the other way before taking a throwing knife to the face from the other end of the map.
i thought it was obvious we were talking about the input-sending part. of course there is client side interpolation.
deject3d what I wrote is exactly how Counter-Strike works since the Half-Life 1 days: https://developer.valvesoftware.com...rver_In-game_Protocol_Design_and_Optimization That's a pretty old paper from 2001 but if you read through the wiki a little more you will find the same principles being applied in the Source engine as well. Also what exactly do you think "gamestate data" contains? A part of that will surely be input data as well. Otherwise the server wouldn't be able to verify what the client is doing. Maybe you've just mixed up the terms here but client-side prediction is not the same as client-side interpolation.
"that type network architecture doesn't work well for complicated, fast paced 3d games.", I'd say prediction is more fundamental than whether or not they use the gamestate or input state for that prediction (which ultimately makes little difference) so no, you didnt make it that obvious at all. Interpolation and Extrapolation are only a part of the prediction. "gamestate", state data for game objects (of which inputs are not). You will notice that the article you linked shows that its only the fire button states that are sent as inputs, it sends velocities for the player movement.
At the end of the day it's just different terms for the same thing. One way or another the server needs to have some input information if you want it to be authorative. As the movement impulses are directly calculated from the keyboard input this can be considered input data as well. IMO it makes no sense to differentiate between a game state and an input state but to rather see the input state as part of a player controlled entity's gamestate.
