Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualInferiarum

Posted 23 November 2012 - 07:43 AM

Method 1 is easily hackable, so I would stick to method 2.

The tick rate depends on the game type, mostly they go from 20 ticks per second to 60 ticks per second. Some servers (I read LoL is this way somewhere, can't say if the font is reliable) tick as fast as they can. My network experiments (mostly RPG based) ticked 20 times per second with good results.

If you are worried about latency, take a look at "client side prediction".


If you use method 1 you should run a local simulation on the server to determine the actual result of the game. (You could of course also get the results from the clients and only replay the game, based on the inputs, if there are inconsistencies) And of course determinism in the simulation is important.

In my opinion broadcasting the inputs is totally valid. Of course with this approach each client knows the whole game state at any moment, thus it is possible to do map hacks etc. . In League of Legends, for example, method 2 is used and you only get updates for players you actually see, so is is impossible to use map hacks. I heard fight games like Street Fighter sometimes use an input based network system where they also predict the game state by using the local inputs, but maybe someone else can elaborate a bit more on that subject.

Also if you have a game where dodging projectiles is important I am not sure if client side prediction is a good thing. I guess it is better to use some other mechanic (http://www.gamasutra.com/view/news/177508/The_lagfighting_techniques_behind_GGPOs_netcode.php#.UK9xFeOe9h4) to hide the delay, and show all game objects in the same point in time.

edit: Let me correct on this. Client side prediction together with interpolation for other game objects is probably a bad idea if the relative position of the player to the other objects is important. That is, you could either display everything in the past or if you want high responsiveness you predict not only the local player but the whole game state.

So in short, if it is not important to hide some information from the clients (i.e. you have no fog of war etc.) you could definitely go for method 1, which can give you very good results for a fast paced action game.

#2Inferiarum

Posted 23 November 2012 - 07:43 AM

Method 1 is easily hackable, so I would stick to method 2.

The tick rate depends on the game type, mostly they go from 20 ticks per second to 60 ticks per second. Some servers (I read LoL is this way somewhere, can't say if the font is reliable) tick as fast as they can. My network experiments (mostly RPG based) ticked 20 times per second with good results.

If you are worried about latency, take a look at "client side prediction".


If you use method 1 you should run a local simulation on the server to determine the actual result of the game. (You could of course also get the results from the clients and only replay the game, based on the inputs, if there are inconsistencies) And of course determinism in the simulation is important.

In my opinion broadcasting the inputs is totally valid. Of course with this approach each client knows the whole game state at any moment, thus it is possible to do map hacks etc. . In League of Legends, for example, method 2 is used and you only get updates for players you actually see, so is is impossible to use map hacks. I heard fight games like Street Fighter sometimes use an input based network system where they also predict the game state by using the local inputs, but maybe someone else can elaborate a bit more on that subject.

Also if you have a game where dodging projectiles is important I am not sure if client side prediction is a good thing. I guess it is better to use some other mechanic (http://www.gamasutra.com/view/news/177508/The_lagfighting_techniques_behind_GGPOs_netcode.php#.UK9xFeOe9h4) to hide the delay, and show all game objects in the same point in time.

edit: Let me correct on this. Client side prediction together with interpolation for other game objects is probably a bad idea if the relative position of the player to the other objects is important. That is, you could either display everything in the past or if you want high responsiveness you predict not only the local player but the whole game state.

So in short, if it is not important to hide some information from the clients (i.e. you have no fog of war etc.) you could definitely go for method 1, which can give you very good results for a fast paced action game.

#1Inferiarum

Posted 23 November 2012 - 06:56 AM

Method 1 is easily hackable, so I would stick to method 2.

The tick rate depends on the game type, mostly they go from 20 ticks per second to 60 ticks per second. Some servers (I read LoL is this way somewhere, can't say if the font is reliable) tick as fast as they can. My network experiments (mostly RPG based) ticked 20 times per second with good results.

If you are worried about latency, take a look at "client side prediction".


If you use method 1 you should run a local simulation on the server to determine the actual result of the game. (You could of course also get the results from the clients and only replay the game, based on the inputs, if there are inconsistencies) And of course determinism in the simulation is important.

In my opinion broadcasting the inputs is totally valid. Of course with this approach each client knows the whole game state at any moment, thus it is possible to do map hacks etc. . In League of Legends, for example, method 2 is used and you only get updates for players you actually see, so is is impossible to use map hacks. I heard fight games like Street Fighter sometimes use an input based network system where they also predict the game state by using the local inputs, but maybe someone else can elaborate a bit more on that subject.

Also if you have a game where dodging projectiles is important I am not sure if client side prediction is a good thing. I guess it is better to use some other mechanic (http://www.gamasutra.com/view/news/177508/The_lagfighting_techniques_behind_GGPOs_netcode.php#.UK9xFeOe9h4) to hide the delay, and show all game objects in the same point in time.

So in short, if it is not important to hide some information from the clients (i.e. you have no fog of war etc.) you could definitely go for method 1, which can give you very good results for a fast paced action game.

PARTNERS