🔒 Locked

RTS lockstep method

Started by xxdaggerxx Jul 9, 2006 at 12:39 AM 7 replies 3.1k views

Original Post

Jul 9, 2006 at 12:39 AM

Hi guys i have been reading around about network programming for RTS, mainly the lockstep method and i have a few questions. How do you make sure all network frames are exactly synchronized with each other?(executed at the same time) Is it even necessary? Is it possible to synchronized the frames even if clients join the game later on? Will this method work?: 3 clients connected in a P2P manner(star). 1st net frame - (Exchanging of commands) client A broadcasts commands to B and C client B broadcasts commands to A and C client C broadcasts commands to A and B (executing and incrementing frame) If client A recives commands from all clients, execute all commands. Move to nxt frame. If client B recives commands from all clients, execute all commands. Move to nxt frame. If client C recives commands from all clients, execute all commands. Move to nxt frame. Each net frame will be a fixed length, abt 50ms. This way the game will have the exact same thng going on on all clients, but at slightly diffrent paces. Some may be a few second behind or ahead. What are the problems with this method?

blaze02

Jul 9, 2006 at 2:26 AM

Lock step sounded confusing to me the first time I heard about it. But, its actually one of the easiest ways to implement networking in a game.

Basically, you have a host and some clients:

Clients send their input to the host.
Host receives input and applies it to each player/object/whatever.
Host sends position/velocity updates to each client.
Clients receive updates from host and update their players/objects/whatevers.

The client is simply a portal to the host's game. The problem with the method is that it is not responsive. You hit up, sends msg to host, host applies up to your player, sends msg back to you, you receive msg, and finally, your player moves up.

Deyja

Jul 9, 2006 at 7:37 AM

If you look back at the game StarCraft, they found ways to keep it responsive. For example, entering a command gives you an immediate audio cue (though it may be another moment before the unit starts to move). Then, it can proceed to do the pathfinding locally, so it's ready to start moving immediatly as soon as the host replies back.

The big advantage of this method is that, when it lags, everyone slows down, so players on better connections don't have an advantage. Team Ninja did the same thing in their latest fighter, Dead or Alive 4.

cbenoi1

Jul 9, 2006 at 7:49 AM

You may want to read this article from Terrano on Gamasutra (registration is required, but free). Mark explains how multiplayer networking was done in "Age of Empire" and discusses his lockstep implementation.

http://www.gamasutra.com/features/20010322/terrano_pfv.htm ( Clicky )

-cb

hplus0603

Jul 10, 2006 at 4:37 AM

The "archers" article doesn't answer the questions that xxdaggerxx asks, though.

The peer-to-peer architecture you're suggesting will likely work. However, if there's one player with more lag than the frame time (200 ms won't be uncommon) then your game will run awfully slow.

You can get around that by making frames longer, and by pipelining frames -- i e, when simulating frame X, you're accepting input from the user for frame X+N for some N > 1. The drawback is longer command lag, but you really can't get around that with the lockstep method.

Yes, you can do this peer-to-peer, with the caveat that bandwidth requirements will be higher, and doing NAT punch-through will be more cumbersome.

You can also join in later in the game, if all the other players pause while the joining player downloads the entire game state (so that there's a known starting point).

Void

Jul 11, 2006 at 2:33 AM

I have a similar question here

http://www.gamedev.net/community/forums/topic.asp?topic_id=402172

xxdaggerxx

Jul 14, 2006 at 6:43 AM

Quote:
You may want to read this article from Terrano on Gamasutra (registration is required, but free). Mark explains how multiplayer networking was done in "Age of Empire" and discusses his lockstep implementation.

http://www.gamasutra.com/features/20010322/terrano_pfv.htm ( Clicky )

-cb

Yea i've read that alredy

Quote:
The "archers" article doesn't answer the questions that xxdaggerxx asks, though.

The peer-to-peer architecture you're suggesting will likely work. However, if there's one player with more lag than the frame time (200 ms won't be uncommon) then your game will run awfully slow.

You can get around that by making frames longer, and by pipelining frames -- i e, when simulating frame X, you're accepting input from the user for frame X+N for some N > 1. The drawback is longer command lag, but you really can't get around that with the lockstep method.

Yes, you can do this peer-to-peer, with the caveat that bandwidth requirements will be higher, and doing NAT punch-through will be more cumbersome.

You can also join in later in the game, if all the other players pause while the joining player downloads the entire game state (so that there's a known starting point).

I think i got it now, thanks hplus0603 for the clearup.

Bob Janova

Jul 15, 2006 at 11:42 AM

Quote:
Original post by hplus0603
You can also join in later in the game, if all the other players pause while the joining player downloads the entire game state (so that there's a known starting point).

Can the server not send the entire game state at the frame at which the new player requests to join, and then send the commands in subsequent frames to the new client as well? That way the new client immediately has to run several frames of other people's commands once it's cleared its network buffer, but that shouldn't be a problem and it won't lag current players.

hplus0603

Jul 16, 2006 at 2:45 AM

If the simulation is simple (doesn't cost much CPU) then you can catch up on join. However, if the simulation (especially the AI and pathfinding) takes most of the CPU for a low-spec machine, then you won't have enough slack to be able to catch up.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.