Theory of a client/server game
Author
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,
http://www.angelfire.com/creep/stuband
cheers,
stu xxx
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.
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
Bjørn
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
Bjørn
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
