Basic lockstep question

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.

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.

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

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.

Thanks
And regarding my question about traffic load (see above)?
Erik

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.

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!

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

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.

[quote name='wodinoneeye' timestamp='1317036195' post='4866013']
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.
[/quote]

I was just talking about subroutines that have parameters vs globals set by other calls.

I wasnt even considering remote procedure calls type of mechanisms.

The real intent was specifying timeouts and hooks for those contingencies so that you can have your App handle situations
better than in the generic ways many protocols do (like doing throttling in a smart way and being able to call up to the App level
to handle the game better -- the game itself can compensate for a network slowdown without being an obvious stall to the player or
the server can adjust its game turn increments (coarser granularity) to lower the generated traffic equally to all players, etc..)

Thats the reason I did my own UDP 'reliable' protocols to have direct control of such things even beyond a standard hook in
someone elses library.