Timeline for FPS networking with server sending input instead of gamestate
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 9, 2012 at 10:25 | vote | accept | user782220 | ||
| May 24, 2012 at 12:10 | history | edited | Kylotan | CC BY-SA 3.0 |
formatting
|
| May 23, 2012 at 13:31 | comment | added | Kylotan | I summarised some of these issues in the answer, anyway. | |
| May 23, 2012 at 13:30 | history | edited | Kylotan | CC BY-SA 3.0 |
Added elaboration on various issues.
|
| May 23, 2012 at 13:23 | comment | added | Kylotan | No, because sending input would never 'fail' - it's just harder to do well, because (a) not everything has a simple representation as 'input', and sometimes it's as expensive as sending the state itself, (b) not every algorithm is trivial to run in exact synchronisation on different machines, (c) not every game is suited to fixed timesteps, (d) stacking extra input in the case of error is less efficient in the face of high packet loss than sending new state. | |
| May 23, 2012 at 10:00 | comment | added | user782220 | I read all the comments but I'm still convinced. The network model I'm proposing would seem to avoid having to carefully manage bandwidth by dealing with input instead of gamestate. Can someone give a detailed example of a hypothetical situation where what I'm proposing just fails horribly. | |
| May 22, 2012 at 21:02 | comment | added | Roy T. | Not really trying to make a point, just trying to understand your answer better since it contradicts partially with what I know. Your final comment clears a lot up though :). | |
| May 22, 2012 at 20:59 | comment | added | Kylotan | I'm not sure what point you're making - I'm not suggesting it's impossible to use that networking model in a game that has a 3D view and a gun in it, just that generally it is not done because it's both more complex to avoid latency. Note that your linked presentation contains many animation hacks to cover for server acknowledgement delays. | |
| May 22, 2012 at 20:07 | comment | added | Roy T. | re (a): true that is one of the main concerns when using these algorithms. (b): this being in the past isn't a real concern as long as it's only a few dozen miliseconds. For example Halo Reach uses lockstep, see this great presentation downloads.bungie.net/presentations/… | |
| May 22, 2012 at 19:44 | comment | added | Kylotan | (a) The same algorithm can work differently across different computers (eg. floating point calculations), (b) each player sees a different world state since their local changes are only known to them - this means the outcome in each case can be different. You would fix this by using 'time steps' where all the information is known but that means running the simulation in the past, not the present - this is why it's only done for strategy games, not shooters. | |
| May 22, 2012 at 18:04 | comment | added | Roy T. | AI routines that change values directly do this because of some rule in their algorithm. That algorithm is the same on all clients and on each client the same rule will be executed in the same time step, so once the AI becomes active it doesn't need any more synchronization. All the other state, that might affect the AI indirectly is kept in sync via input. | |
| May 22, 2012 at 16:48 | comment | added | Kylotan | AI routines don't typically create input, they change values directly - so sending the 'input' is equivalent to sending their state. Also, AI routines run in the past as far as clients are concerned because they only receive information about them after the changes have already made, which can affect the client's local input (because the target may have moved or changed significantly in that time). The lockstep concept is irrelevant for most FPS games because it's not a practical idea where client prediction is in place. | |
| May 22, 2012 at 14:33 | comment | added | Roy T. | Maybe you should expand your answer some more because this doesn't make sense to me and I know that you know more than I know ;). NPCs that aren't affected by the player directly are affected by their AI routines and physics, since these routines should behave deterministically on all platforms (for a correct implementation) the 'input' of these doesn't need to be send. As for interaction between clients with the 'input' approach the usual solution is lockstep, where all clients together take a step after all client's haven taken their previous step and the server has received all new inputs. | |
| May 22, 2012 at 12:17 | history | answered | Kylotan | CC BY-SA 3.0 |