Hi, as you might remember I am writing a master''s thesis on how to cope with the delay in multiplayer games on the Internet. Focus is on fighting games. Would you please take a look at these select parts of it and comment on any errors, stupidities or improvements? Also, is this new? or has someone already done what is described in this report? Clicky // Tobias

Good read Tobias, Some ideas which might be of intrest.

Multiplayer fighting games are the most demaning interactive multiuser applications from a technicial standpoint i can think of, good choice. Some of the ideas :

-alternative approach to pinging for solving 1 way latency calculation. In this method each player ( only 2 in this case ) would stream a series of reguarly spaced time ticks to the other. The reciving machines would try to create a model for this input stream, using its local clock. Once a model is sufficently accurate they exchange models and use the median to estimate the one way latency. The assumption is the latency from A->B is the same as B->A.

-in your thesis you would resolve late packets by not allowing them on the reciver side, I would argue diulting the games accuracy of simulation is much worse. If people cannot expect their actions to count, due to something beyond their control or anticipication, they cannot form a consitent model of the gameplay thus, never progress. It''s better to let the action progress, and it will be accepted overtime that some cheap "lag" hits will occur, rather than always have the spectre of null action which desychronize the players expections and views.

-the issues with combo, are they are a sequences of events which the player must input with the approririate timing to achive a series of desired attacks. Some combos are pretty automated, in that they dont require any specific state from the opponenet, from start to finish. Usually they are inputed within a span of .5 secs or less. Depending upon the span of the combo, and the update rate of your simulation, you cannot count on proprogating the raw events on the network and have a reliable detection of a combo sequence occuring on the server side due to latency. So combo detection and initaition totally resides on the client side, i think.

-Alternative network topology, for a fighting game. The clients can connect to each other directly as well as the server. The events are sent to both server and clients. The client events are semi-authoritive, that is they can initate action but those actions can be overriden by events from the server. It might reduce latency by not having to go through the server for everything.

Good Luck!

-ddn

Thank you ddn... I see, from your suggestions, that you have actually _read_ the document . I was afraid it was too long and boring for anyone to bother.

1. Yes, some alternative way of synchronizing the clocks would be nice. This is not the focus of the thesis though, so for now we have chosen Naylor & Kleinrock's approach because it is simple and have only two variables. Variables which will have to be adjusted when testing this on actual people (Which we will do). Unfortunately, there seems to be no way of dealing with asymmetrical delays short of synchronizing by GPS.

2. Very valid point. People's actions should count. But also, people should be given enough time to react on actions as well. And also, there is always the possibility of cheating by delaying one's packets. We would like to keep the server's authority absolute. Do you have any suggestions on how to do it otherwise?

3. Well, yes and no... the server checks the start and completion time of the individual actions in the combo to verify it. Actually, it could all be done on the server since every action has a timestamp independant of the latency.

4. Yes, I've been thinking about this and I would like to do it that way instead. But, it's the cheating again. Give out the players' IP numbers and eventually there is a denial-of-service attack against someone. Well, maybe not.

If we don't care about (D)DOS attacks, the algorithm in my thesis can be adjusted to involve semi-authoritative clients and a server to check the legality of every event. I'll think about it, and if given enough time I might include a section about this.

Thanks for your great feedback, please keep it coming if you think of anything else.

// Tobias

[EDIT] Point 1: Taking the median, as suggested by ddn is of course a lot better than taking the almost biggest delay when synchronizing clocks, I don't know what I was thinking. Thank you, ddn... I will change that. [/EDIT]

[edited by - Tobbe A on September 30, 2003 4:00:54 PM]

Tobbe A:
Thanks a lot for the link... If you have any more of this kind, please share

Instead of synchronizing through GPS, you can synchronize through NTP. It''s usually quite accurate, even if you''re in the tird stratum, and it''s freely available to any connected computer. And if you''re not connected, well, the multiplayer lag problem goes away :-)

Hi,

DGtalx: I will post a link to the complete thesis when I am finished writing it, should be sometime in december.

AP: yes, NTP is quite accurate, but it too can not handle asymmetric delays. There is no way to handle asymmetric delays unless you have a clock that everybody can look at, independent from the network.

thanks for the comments
// Tobias

December has come... Still waiting for the complete document ))

me too

Hi,

the thesis is hopefully finished in march. This is because we are implementing a prototype game for evaluation purposes, and this is going a bit slow. Thanks for your interest... I hope the report will be even more interesting when we actually have some results to show off.

// Tobias

Tobbe A, march has come... still waiting ))) Any progress? The document was really precious, because information of such kind is quite rare in internet, that is why i''m waiting for the complete version