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.

In my effort to learn programming I'm trying to make a small RTS style game. I've googled and read a lot of articles and gamedev q&a's on the topic of lockstep synchronization in multiplayer RTS games, but am still having trouble wrapping my head around how to implement it in my own game.

I currently have a simple server/client system. For example if player1 selects a unit and gives the command to move it, the client sends the command [move, unit, coordinates] to the server, the server runs the pathfinding function and sends [move, unit, path] to all clients which then moves the unit and run animations. So far so good, but not synchronized for clients with latency or lower/higher FPS. How can I turn this into a true lockstep system?

Is the right methodology supposed to be something like the following, using the example from above:

Turn 1 start

  1. gather command inputs from player1
  2. send to the server turn number and commands
  3. end turn, increment turn number

The server receives the commands, runs pathfinding and sends the paths to all clients.

Next turn

  1. receive paths from server, as well as confirmation that all clients completed previous turn, otherwise pause and wait for that confirmation
  2. move units
  3. gather new inputs
  4. end turn

Is that the gist of it? Should perhaps pathfinding and other game logic be done client side instead of on the server, if so why? Is there anything else I'm missing? I hope someone can break down the concept, so I understand it better.

share|improve this question
    
RTS is real time strategy, there are not "turns" there, it's easier to make all communication asynchronous and use a preliminary path to use before the server reply comes back –  ratchet freak Apr 25 '13 at 15:47
1  
Well there aren't literal turns as in chess, but in the context of lockstep synchronization people often use the 'turn' to mean something like one iteration of the main game loop. –  user11177 Apr 25 '13 at 15:54
1  
Hmmm, real time chess would be interesting... –  Byte56 Apr 25 '13 at 16:18
    
Some would claim pro level starcraft to be the modern analogue of chess. –  user11177 Apr 25 '13 at 16:44
    
You can always chat with the megaglest devs on freenode #glest - some 0ad coders hang out there too, and might have their own irc channel too –  Will Apr 25 '13 at 17:27
show 2 more comments

2 Answers

http://gamedev.stackexchange.com/search?q=client+prediction

You'll want to do client side prediction to deal with latency issues.

In essence, do everything exactly as you have set up, but when the client sends the command to the server, the client assumes the command is valid and performs the pathing algorithms and begins moving. The server can then validate and send the command to all clients to simulate while the server performs the actual pathing.

The only time you want to send unit data is when the units are taking a new action. IE: When a unit starts moving up after it has been moving left. The clients assume the unit will continue to move up until they are told otherwise. The same follows for attacking and performing actions.

This style is used a lot in MMO style games like World of Warcraft.

another link: http://gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/

share|improve this answer
    
I'm not sure it's a good idea to assume a command is valid, as it would cause some unnecessary confusion when for units would begin executing invalid moves for a second before the server gets to send the valid moves. –  user11177 Apr 25 '13 at 16:38
    
That's where proper prediction comes in, if the move is obviously invalid, the client will know and not perform the action. In the second link I provided, the author implies that prediction isn't the hard part. The hard part is correcting mistakes made by client prediction. The more intelligent your client is, the less likely it will make mistakes, or if it does, the mistakes will be less noticeable. –  UnderscoreZero Apr 25 '13 at 16:45
    
Even if the move is invalid, the client should still send the message to the server, in the case that there is a visible event for invalid moves or to ensure that the unit in question is correctly up to date on all clients. –  UnderscoreZero Apr 25 '13 at 16:47
    
That seems to be an extra step to what I meant in the OP. Since all moves has to be evaluated anyway, validating and executing them only once would make prediction and correction unnecessary. What you are talking about seems more relevant to games where immediate response is absolutely required, like FPShooters. I would imagine that most rts games willingly trade the millisecond response in exchange for better synchronicity. –  user11177 Apr 25 '13 at 20:36
    
Those two options aren't mutually exclusive. Proper prediction only helps with synchronization. Plus what else is your client going to do while it waits for a response from the server? Might as well predict what will happen and correct it if it is wrong. It could take several seconds to get a response. Even a half second response is noticeable (and unacceptable) to many gamers. –  UnderscoreZero Apr 25 '13 at 20:55
show 1 more comment

Here is how I understand it:

In a lock step networking model, the entire game simulation is ran on each client. This includes path finding.

You should be sending each player's inputs to each client. Each client will then need to be able to process the inputs and run the simulation locally.

The benefit here is it significantly reduces the amount of information sent over the wire. In an RTS you can have thousands of units. In the client/server model you have you would have to send the path information for each unit every game frame.

share|improve this answer
add comment

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.