Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'm working on a multiplayer Flash game with a Python server and I have a quick question regarding how I should send positional updates for tanks for other players.

Should I choose

Option A:

When the player presses the move key, send the new velocity to the server and let the server calculate the new position per tick?

or

Option B:

When the player presses the move key, send the new position to the server and calculate the velocity clientside?

Which is the best option, in your opinion? What is most common? What will have less issues?

Other suggestions are welcome, I don't really know what I'm doing here. ;)

share|improve this question
1  
2  
+1 " I don't really know what I'm doing here. ;)" –  DaGhostman Dimitrov Apr 11 '13 at 22:02
    
@LukeSanAntonio Yeah, I've skimmed through that before - thanks for giving me the link again. I'll throughly read through it now that I actually have a project. –  Jishaxe Apr 11 '13 at 22:02
    
@Jishaxe Yeah, I read it a bit ago too and it stuck with me, it seems to apply perfectly here! –  Luke San Antonio Apr 11 '13 at 22:08

3 Answers 3

up vote 6 down vote accepted

My understanding is that you should never trust the client in a multiplayer game and therefore aim to do any gameplay critical processing server-side. The disadvantage of pure client-side logic is that there is no verification

In other words you should probably go with a third option; send an abstract representation of what the player wants to do to the server. For example you would send a 'move key' event to the server, which would then calculate the velocity/position of the player and then update the view on the client.

However, you don't want your clients to be waiting on the server before updating the game state as this could cause lagging issues. A better solution may be to update the game state on the client as well, whilst treating the server state as authoritative and overriding the client if necessary.

share|improve this answer
    
Sure - but then if the client had a high latency, they would feel a delay between pressing the key and moving the tank. I suppose I'll have to go with both ends of the stick - simulating the movement on the client and the server, and the server corrects any mistakes.. –  Jishaxe Apr 11 '13 at 22:07
    
You're right, in fact I was just about to edit my answer to say something along those lines. I believe most games actually work how you described (but I could be wrong). –  Alex Apr 11 '13 at 22:10
    
Yes, that is what is called lag ghosting. A lot of games use predictive models in order to 'guess' where the player might wind up based on their last communication. Dark Age of Camelot was famous for this. –  RobCurr Apr 11 '13 at 22:29

What you are looking for is 'Client-Side Prediction'.

Basically each client predicts where everything is going to be until it receives an update from the server telling it where everything actually is. This way the host is the authority on all movement, but the client doesn't have to wait for a server response before updating the positions of objects.

You will want to combine this with some smoothing so that objects don't appear to teleport every time they receive an update from the server as well.

One thing you may want to do is have the clients be authoritative of their own positions - in other words the clients tell the host where they are, then the host distributes these positions to everyone else. You will have to add checks on the host to ensure no-one is cheating (moving too fast, teleporting and so forth). This will lead to a more responsive game, but can be trickier to implement and fine tune.

It's a bit too long to go into all the details here, but at least I hope I've given you a place to start from.

share|improve this answer

I would send the key they pressed and have the server determine what action this relates to and take the appropriate actions.

For example, the player pushed the 'w' key. The server gets sent "Hey, this guy pushed the w key". The server would look and see what the W key should do for the player. It finds that this means the player should move forward. The server then moves the player forward in the world.

At the same time, the client is predicting what is going to happen based on the assumption that what it is being told to do is valid. Then, every so often, the client receives data from the server and everything is set to what the server says.

This is actually what causes the rubber band effect you can see sometimes in network games. The client is predicting where things will be at but gets it wrong. Then when it receives new data from the server, it snaps everything to where it should be (IE what the server says).

You should, ideally, never send any significant data from the client to the server because of cheating.

For example, if you sent velocity the player could be altering the data to be something it shouldn't. Even worse would be sending the position to the server. Even if you send just a bool value saying, hey I want to move this way, this could be done automatically by a hack of some sort. Even sending what keys were pressed is still vulnerable, but you can't get anymore unrelated from data than that.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.