Jump to content
  • Advertisement
Sign in to follow this  
suliman

Basic lockstep question

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

Hi

Ive read some things about lockstep networking and have a question. It says you should not let the next turn be executed before all commands have come in. How do i know when all commands are recieved?

Will the server simply wait until each player has sent his/hers "commandpackage"? Each player can only send one package, but this can include several ingame commands for that turn. If this is the case its easy to see when the turn is "done" (server just checks in a array that each player has sent its commands for the current turn). Once all commands are in, the game advances one turn and players can send new commandpackages.

If this is not how its done, plz tell me otherwise! (or confirm my speculation)
Thanks

Share this post


Link to post
Share on other sites
Advertisement
Yes, from what I understand, that is how it is done. Obviously implementation details can differ, but your description is the most basic and easiest method of doing it.

Share this post


Link to post
Share on other sites

Hi

Ive read some things about lockstep networking and have a question. It says you should not let the next turn be executed before all commands have come in. How do i know when all commands are recieved?

Will the server simply wait until each player has sent his/hers "commandpackage"? Each player can only send one package, but this can include several ingame commands for that turn. If this is the case its easy to see when the turn is "done" (server just checks in a array that each player has sent its commands for the current turn). Once all commands are in, the game advances one turn and players can send new commandpackages.

If this is not how its done, plz tell me otherwise! (or confirm my speculation)
Thanks




You will need to (if you want to handle 'typical' situations) be able to handle disconnects or program shutdowns on any end (server or clients)
which is usually done with a timeout check that interupts normal operation and decides (when nothing comes in for more than long enough)
that the other side is dead and the program must either attempt reconnect (with or without asking the user) or do whatever is appropriate if the communications/programs have failed.

Some libraries have global timeouts and others on per call parameters (lower level you do it with your own code) .

Via internet there can be long delays/sporadic lags that you will have to consider when you decide 'how long is too long'.

Similarly there are 'controlled' shutdowns wher other data than the normal gameplay is sent to signal the other side that the game is being halted or paused or aborted and that the other side needs to handle those situations.



Even with lockstep data flowing between clients and the server you may be able to pre-process the data that does come in while waiting for all to be complete.
Validation of data or decoding /etc might be done while waiting (a non-blocking network protocol) so that the game turn can be processed faster and the next turns results be sent out sooner.

Share this post


Link to post
Share on other sites
How compressed does this packages need to be?

If i have 8 players running a game, each player need to send one package each multiplayer turn (say 50 ms).

As for now, i need each package to include
12 chars
3 floats (4 bytes each)
(total 24 bytes, very roughly)

Would this get close to anything that would couse problem, traffic wise? (i know there might be problem with floating points)

Thanks a lot
Erik

Share this post


Link to post
Share on other sites

Some libraries have global timeouts and others on per call parameters (lower level you do it with your own code) .


In game networking, you should pretty much never (ever!) think of things as "calls" in the sense of remote procedure calls.
Instead, you should think of queues of messages. Everything should be non-blocking, and asynchronous, and queue driven.

You can make your simulation loop very simple: When you have received commands for turn X from all clients, you execute turn X!
You can also remember the time you executed turn X, and if it's been more than Y amount of time since then, show the user a message saying "simulation is paused because of connectivity."
Keep it up there until you receive all the messages, or a message that user so-and-so has dropped.

Share this post


Link to post
Share on other sites

How compressed does this packages need to be?

If i have 8 players running a game, each player need to send one package each multiplayer turn (say 50 ms).

As for now, i need each package to include
12 chars
3 floats (4 bytes each)
(total 24 bytes, very roughly)

Would this get close to anything that would couse problem, traffic wise? (i know there might be problem with floating points)

Thanks a lot
Erik


Typically, if you are using a UDP based protocol (and I would suggest it), you should make sure your packet is smaller than the smallest MTU. You 24 bytes (plus header) comes no-where near that.

I would also suggest not expecting 50 mS turns, unless you're planning on only playing on a LAN. Start high (500 mS) and work down to a value that you can live with, and it probably won't be below 100 mS.

Share this post


Link to post
Share on other sites

Typically, if you are using a UDP based protocol (and I would suggest it), you should make sure your packet is smaller than the smallest MTU. You 24 bytes (plus header) comes no-where near that.

I would also suggest not expecting 50 mS turns, unless you're planning on only playing on a LAN. Start high (500 mS) and work down to a value that you can live with, and it probably won't be below 100 mS.


IP fragmentation is not ACTUALLY the end of the world. You go from perhaps 99% penetration to 99.9% penetration if you drop your max UDP packet size from 8192 (fragmented, bigger than traditional MTU) to 1400 (mostly not fragmented, below Ethernet MTU) to < 540 bytes (common modem/PPP MTU for dial-up). Most of the time, packet loss isn't really a problem anyway, so the risk of dropping any one fragment isn't any worse than the risk of dropping a UDP datagram.

When it comes to RTS turns, you typically want to run turns at your simulation speed (say, 50 ms for 20 Hz), but pipeline many turns deep. Either set the latency to a fixed number -- 10 turns, for 500 ms, say -- or simply run it based on what you get. When server has delivered all remote hosts' commands for turn X, you simulate turn X. That's a very simple mechanism, and with a minimum of jitter compensation (don't start two turns closer than 49 miliseconds together, say) you'll probably do just fine!

Share this post


Link to post
Share on other sites
Thanks for your input.

Its sort of a flight arcade game with rts elements so too long delay will not work well. Is it possible to keep turns to 50ms if i keep packet size down or is this not related? When i fire machineguns from my plane i can of course play the sound directly but if i dont effect the world in 50ms (or maybe i can stretch it to 100ms) it will not work well...

Erik

Share this post


Link to post
Share on other sites

Thanks for your input.

Its sort of a flight arcade game with rts elements so too long delay will not work well. Is it possible to keep turns to 50ms if i keep packet size down or is this not related? When i fire machineguns from my plane i can of course play the sound directly but if i dont effect the world in 50ms (or maybe i can stretch it to 100ms) it will not work well...

Erik


If you play over the Internet, then latency (round-trip time) not throughput (amount of data sent) is what matters.

If you have first-person-shooter type interaction requirements, then you probably want to go with a FPS style networking architecture, which probably means keeping logs of positions on the server, and verifying shots server-side after the fact, and display the player "ahead of time" locally. Because you keep using estimated locations on all machines, you cannot do this with lock-step networking -- the fundamental trade-off with lockstep is that you give up command latency, but gain throughput efficiency.
Check out the "source networking architecture" article on the web (probably still linked from the FAQ) for an example.

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!