Advertisement Jump to content


This topic is now archived and is closed to further replies.


Theory of a client/server game

This topic is 5431 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

hi all, just joined up cos i have a question about game programming and this looks like the right place!! Im developing a LAN version of ''Joust'', the arcade classic, and wondered if anyone knows the best way to achive this. The idea is that the game world will be persistant on the server, and clients will use a client application to log in and out as they please. while there, they can engage in te game till they run out of lives, then log back in for another go. At present, i''m simply sending out key presses from the client to the server, which does all the game processing. The server will then send the positions of all other players to the clients every frame. is this a good way of doing it? There''s more info on it at my website, cheers, stu xxx

Share this post

Link to post
Share on other sites
Sending an update every frame is way too much I think. You should send them much less often and probably do some prediction for things like player positions.

Share this post

Link to post
Share on other sites
If you are "limiting" yourself to LAN and do not expect the high ping times youøll find on the internet, you can make the application truly client-server. This certainly limits the amount of technicalities you have to deal with.

In that case, continue doing what you are doing. Send keystates every frame (or every time it''s changed, it which case you''d have to send that packet guaranteed) and let the server handle all the processing. Every time the gamestate changes on the server, send an update packet out to all clients, who will then update their own state accordingly.

If, on the other hand, you want this games to work on the internet, you''ve got to put some logic client side. The server is simply "too far" away to process everything without the game feeling unresponsive. In that case, put as little game logic as you can get away with on the client and have the server and client run a synchronized game clock.

For movement:
Send keypresses+(time these keypresses happened on the client) to the server (makes it harder to cheat) and store those keypresses in a list clientside together with the time they happened. When the server receives a keypress it processes them, thinking "if client started pressing left at time (then) then where is he at time (now)". The server then sends this update to the client, saying "at time (now), the client is at".

This packet naturally takes some time to get to the client. When the client does receive the packet, it thinks "If the server told me I was (there) at time (then), then put my player there and redo all the moves that has happened since (then)".

Note that the server sends position at time (now), but once that has arrived at the client, (now) has become (then) because the packet takes some time to arrive.

For bonus, pickups etc:
The server detects when the client has picked up the bonus and informs the client that it has picked it up. This prevents the client from modifying the executable and telling itself "you just picked up the Rocket of Doom & Hellfire".

Naturally there are many other ways to synchronize a game, but this should at least get you started.

Best regards

Share this post

Link to post
Share on other sites
Sunbeam mentioned about everything.

But I''d like to add that you are on the right way. Sending keypresses is good. Relaying positions back to the clients is good.
Though, one little thingy, what do you mean with "every frame"? If you mean every frame the screen is drawn, or every loop your server goes through, you might send way too many packets. You might want to have two kind of "framerates", one for display and physics, and one for network updates relaying gamestates to clients. Then your servers display and physics runs at a framerate of 1000 fps, and your "network framerate" for example on 20 fps. Saves a lot of bandwidth and is especially handy when you plan going over the internet.
Technically this can be done using threads or not executing the network frame every cycle.

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!