Jump to content

  • Log In with Google      Sign In   
  • Create Account


tufflax

Member Since 13 Jul 2005
Offline Last Active Sep 16 2014 09:17 PM

Posts I've Made

In Topic: Any way to make this simple tennis game more OO?

26 April 2014 - 12:42 PM

This is all you need: http://www.infoq.com/presentations/Simple-Made-Easy


In Topic: Catching illegal movement with partial data

15 April 2014 - 02:27 PM

I see. Still, 60 updates per second seems like a lot, hmm...

 

Thanks guys! You have given me things to think about.


In Topic: Catching illegal movement with partial data

14 April 2014 - 04:58 PM

 

- run input and simulation at 60 Hz (good initial estimate)
- send packets at 20 Hz

 

So would I just send 3 input states per packet, or what's the difference between these two rates?


In Topic: Catching illegal movement with partial data

14 April 2014 - 03:33 PM

 

if I could not actually change my position faster than the simulation ticks, what would be the point of updating the rendering?


You can render an interpolated version of the world. Popular console FPS games may run at 30 or 60 Hz for rendering and physics, but typically runs networking at 10, 12, or 15 Hz.
For a sketch, see the canonical game loop: http://www.mindcontrol.org/~hplus/graphics/game_loop.html

 

I have interpolation for other players. But interpolation (or extrapolation) for the player himself, surely that must be noticeable. And besides this problem (sending a lot of movement information) I have no need for a simulation frame rate that is different from my rendering. Maybe extrapolation would work OK if I ran the simulation as 20 FPS or something. Hm...

In Topic: Catching illegal movement with partial data

13 April 2014 - 11:46 PM

 

The server runs at 10 FPS. But the client can run at 100+ FPS, or whatever really.


Rendering frame rate and simulation frame rate doesn't need to be the same (and often isn't.) Best practice for action-like games is to fix a simulation tick rate, and run that rate on both client and server.
There are many other ways of creating a fun networked game, some of which have different trade-offs in consistency, latency, cheat resistance, ease of implementation, etc.

 

What would I include in those simulation frames, and what would be updated every rendering frame? And also, if I could not actually change my position faster than the simulation ticks, what would be the point of updating the rendering?

 

What you have isn't really server-authoritative, therefore not secure. You need to send all the inputs of the clients to the server, as well as the client's predicted position every now and then, so the server can correct the client if needed. If you send partial inputs, you leave yourself opened to exploits. If you send all the inputs, then you know exactly what the client tried to do, where it landed, and if you need to send a correction. Then the client can 'rewind' his input stack, and correct himself.

 

https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Input_prediction

 

Client->server bandwidth is at a premium but luckily, if the client only has to send inputs, commands, and sometimes positions, that bandwidth usage is actually very low, even at 100hz. Do the maths, see how much data that actually is. e.g. 100 fps x 100 byte / input = 10kbytes / sec = 80 kbits / sec (plus TCP packet overheads). Secondly, since you will send your inputs reliably, you can use compression techniques to further reduce that bandwidth. 

 

And since you use TCP, if you start sending too much too fast, the TCP frame will drop (i.e. the send() command will not complete, or will block). But in any case, short of a network issue, you should be easily be within the bandwidth limitations of home broadband. What you can do in case your TCP stream starts breaking up, is pause the game on the client side, to let the stream recover enough. 

If I'm gonna send stuff every frame, I might as well just send the position and direction, because as long as the server checks for speed and collisions, it's fine. No? And it's easier for the server to do that.


PARTNERS