Jump to content
  • Advertisement
Sign in to follow this  
sofakng

Why send keypresses to a server instead of player position? (re: simple 2D game)

This topic is 3414 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

I'm trying to create a "simple" networked/multiplayer 2D game and so I've been trying to a read a lot about networking principles, player synchronization, etc. However, it seems like most articles (eg. gaffer.org) tell you to send keyboard/mouse inputs to the server, have the server process them, and send the results back to the client. Why? Is this only done for cheat protection? What is the disadvantage to sending actual player position to the server and doing a sanity check? It seems like this way is better because then players will know their position even while moving and won't require interpolation or prediction. Keep in mind that I'm talking about a simple 2D game with different objects moving around, etc.

Share this post


Link to post
Share on other sites
Advertisement
Quote:
gaffer.org


Physics simulation (FPS) is defined via some initial state and a known and rigid set of rules (usually newtonian physics). Some of these rules are obvious, such as body in motion... etc.

Direct consequence of this is, that in absence of input, such (properly implemented) systems can be advanced for arbitrary amount of time, on different machines, and produce same result. Consequence of this is, such simulation is affected only as consequence of input.


RPGs however have different requirements. The rules are no longer simple, they also aren't consistent nor rigid (nor is it desirable for them to be). If all rules were known, client could wait for favorable RNG before looting.

State is also too large to replicate entirely. As such, client is unable to advance state on its own, and different clients advance state differently.

To ensure integrity, input (while it can be used) becomes cumbersome. Since input depends completely on exact client's state, server would need to maintain exact replica of each individual client.

So using something more client-agnostic than actual input is considerable simplification. By using context-independent actions to describe changes to the state, each client can run local simulation independently, yet still maintain consistent state.

Quote:
Is this only done for cheat protection?


Yes and no. Since such simulation likely requires entire state and all rules to be known to each peer, there is less security. It may however be easier to detect misbehaving client. This can be a problem in absence of malicious intent, due to network problems or participants which cannot keep up with others for various reasons.

[Edited by - Antheus on January 15, 2009 8:17:09 AM]

Share this post


Link to post
Share on other sites
Thank you so much for the detailed reply!

Quote:
Original post by Antheus
Physics simulation (FPS) is defined via some initial state and a known and rigid set of rules (usually newtonian physics). Some of these rules are obvious, such as body in motion... etc.

Unless the game has movement-affecting conditions (eg. a certain spell is cast upon a player in an RPG), then won't all games have the same movement rules? (eg. player holds up direction for 1 second which equals 20 tiles or whatever)

Quote:

Direct consequence of this is, that in absence of input, such (properly implemented) systems can be advanced for arbitrary amount of time, on different machines, and produce same result.

Don't physics simulators produce slightly different results on each machine? (thus the need for synchronization via a server) I agree that inputs are the only changing factor but the results will still be different due to float precision errors, etc, etc. Right?

Quote:

RPGs however have different requirements. The rules are no longer simple, they also aren't consistent nor rigid (nor is it desirable for them to be). If all rules were known, client could wait for favorable RNG before looting.

I agree that clients shouldn't be able to determine the results of certain actions, but wouldn't movement of objects be the same (again, unless certain movement-affecting conditions exist such as spells, etc)?

Quote:

State is also too large to replicate entirely. As such, client is unable to advance state on its own, and different clients advance state differently.

Why would entire state need to be replicated? Also, doesn't the server still need to keep track of each clients state to prevent cheating?

Sorry for so many questions! I'm wondering if you comments are based on an RPG having speed-affecting elements where as an FPS doesn't have this (although, some FPS games increase certain players speeds based on items they may have picked up, so really they both seem the same)...

Like I was saying above, I'm mostly interested in a simple 2D game like Mario Brothers or The Legend of Zelda (eg. characters moving around without too much complexity being involved)

Thanks so much for the help!

Share this post


Link to post
Share on other sites
Why is that though? :)

I understand that it's done for cheating, but I'm trying to determine if it's worth all the extra complexity just so I can make sure the clients are cheating. My game is going to be very small and I do with allowing determined hackers to cheat if they want to :)

However, if there are other reasons besides cheat protection than I'm trying to figure that out...

Share this post


Link to post
Share on other sites
Good programming practices.

You gain absolutely nothing from having a client designed with some modicum of security in mind, if not the knowledge and experience of designing it the right way, from the ground up. Allowing a client to make determining factors about anything (whether it is a game client, chat client, bittorrent client, mail client) leads to poor programming practices with regard to client/server structure. Why stop at allowing clients to determine where they are? Why not let them log in with the wrong password? Or say they have 1,000,000 hit points when they have only 1?

Bad:
I am at location 100,100, and I am moving to 101,100. (Client could be hacked to teleport through obstacles.)
Good:
I am requesting to move one tile in the positive X direction. (Server mandates where the client is at all times, and simply tells him whether his move request succeeded or failed.)

Bad:
I am logging in with my friend's account, username JoeSmith password IHatePasswords, so I can mess around with his characters. (Player can get away with blue murder, and all you can do is let him.)
Good:
I am logging in with my friend's account, username JoeSmith, and I hope this is the password. (Failed login attempts equate to temporarily locked accounts, notification via email to the account holder of the attempts, etc.)

Bad:
I am about to take one more point of damage, which will kill me. But hey, I actually have 999,999 left. Flame on! (Client modifies character stats, enabling him to ruin the game for other players.)
Good:
I died. (Server mandates at all times, all states of all clients.)

Don't forget that cheaters don't necessarily only make the game fun for themselves. With a little creativity, they ruin the fun for other players too. If your game isn't fun, then you've failed as a game designer.

Share this post


Link to post
Share on other sites
Quote:
Original post by sofakng
However, if there are other reasons besides cheat protection than I'm trying to figure that out...


World consistency, player a hits the go right button but do to lag/dropped packets/etc the server doesn't see him move right for another two seconds. Where is the player located? Two players shoot at each other at almost the same time now because of transmit time between the two each sees themselves as having shot first who is right? You can't just tell the server what happened the server must decide what happened on its own. It can't tell unless it gets inputs, not after the fact reports.

Share this post


Link to post
Share on other sites
Cheating is a good reason and doesn't justify the use of the word 'just', in my opinion. But in addition, if you're running any sort of physical model with collisions, or magic spells that can slow or speed up characters, or weaponry with recoil, all that simulation has to happen on the server and therefore it has to have the authoritative state. If the client just says 'I moved from (x,y) to (X,Y)', there's no way to know what it should have interacted with in between, even if you 'sanity check' it to make sure the move isn't downright impossible.

Share this post


Link to post
Share on other sites
Thank you so much for all of your help. I hope you folks know how much I appriciate it.

I now understand what you're saying about only sending inputs to the server for player movement. What about other actions such as opening a chest? I now know that I would send a request to open the chest, but would you typically wait for the server response before informing the client or would you let the client pretend it succeeded and "rollback" if neccessary? It seems like any action besides movement should wait for the server to respond before the client displays or does anything at all.

One last question (I hope!):

Let's say a client presses forward and informs the server. Could the client just start moving forward and wait for the server to respond? If you had to wait for the server to respond before displaying it on the client then it would be very ugly looking and would control very poorly.

So if we allow the client to move forward and tells the server, what would the server response be? Would the server just say "OK, I acknowledged your movement"?

Would the server then send out packets every xx milliseconds updating the clients position? The problem with this seems that if the client moved on it's own before the server started his movement, then by the time the client got the new position from the server, the client's position would be ahead of the server (since he started moving before the server started him moving).

Do I need to send velocity with the movement inputs or anything like that? (this seems very complicated) It also seems very complicated to keep track of "rollbacks" if I need to rollback actions, etc.

I'm really sorry for so many questions! I've honestly read many articles on this (and have searched) but you folks have helped me a MUCH more than any article.

Share this post


Link to post
Share on other sites
Sending key states is a lot smaller than sending state.

For example, if I have move 4 directions, run modifier, crouch modifier, and two weapons fire modes, then that's 8 bits. If I have XYZ with 32 bits precision per coordinate, plus velocity with 24 bits per coodinate, plus HP aim with 16 bits per axis, plus two weapons fire cycles with 16 bits of state each, sending that will take 37 bytes. Think of it from the point of view of the server. If you send updates 20 times a second, then you have the choice of sending, to each player, for each player, one byte times the number of players, or 37 bytes times the number of players.

It's common to send the full state every so often (say, the full state of one player, per player, on a round-robin fashion), and use the input command state as network compression for the intervening state sends.

If you have 32 players on a map, then the numbers are:

32 players * 31 full 37-byte states * 20 Hz send rate == 734 kB/sec (just for updates -- there are other things you want to send, too, plus header overhead!)

32 players * 30 key bytes + 1 37-byte state * 20 Hz send rate == 43 kB/sec

32 players * 31 key bytes * 20 Hz send rate == 20 kB/sec

Now, take a look at the upstream of your DSL or cable modem, and figure out which of those you can serve, and which you can't :-)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!