I am writing a game-server and a game-client. In the client there is a game loop that has a delay of ~16ms (because that would be nearly 60fps). All the logic is at the time handled at server side so I need to send the latest frame to the client every 16 ms. Is this a good solution? I know that I probably have to do some game logic at client side just to smooth things out but this is an early version.

Is it possible to make the server send frames to the client each 16ms? Each client is handled in different threads (or actors, as the server is written in Erlang).

  • \$\begingroup\$ Over LAN? WAN? It all depends on you network speed. One packet per frame can probably work more or less over a high-speed LAN but I don't think it can be viable over the Internet (yet?). You'll have to interpolate to smooth things out. \$\endgroup\$ May 7, 2014 at 20:46
  • 1
    \$\begingroup\$ Please accept the answer below or provide some more information to help us recommend any alternatives. \$\endgroup\$ Jul 21, 2014 at 9:36

1 Answer 1


It's a question you must answer yourself, depending of what do you send.

In TCP/IP, you can send any kind of information, your client will get it (until it is wired), but the protocol check takes some time, resulting in a lag when you have a low band-width.

In UDP, you just get rid of all the checks, so you have the max speed of transfert (less lag). But some data could be lost and never be fetched.

You must first know what kind of information you need to send, their priority, and if they are critic or not.

You may be able to sent at ~16ms and have a kind of smooth moves, without interpolating or applying a velocity, but you'll certainly not reach 60 packets by second and you will have your entities acting like jumping between positions.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .