Game Synchronization

[rommager]

I agree that RTT/2 is not quite enough time to wait, but for badly lagged players, this can slow down the game more for all players.  This is just one of the many challenges for making a timing based game play over the Internet.

At least the days of 500ms lag are not like they used to be

[rommager]

The cursor is moving At has speed of 1 Land each CTU. When has Land is selected by has player, has pause of 4 CTU is done.

While the cursor is moving at a speed of "CTU", the CTU is still calculated by the sub-units of jiffys.  Therefore, one could easily assume that button presses will be accepted for each jiffy of the CTU.  I suppose Kroah will have to clarify this for us but I believe Peter is right here.

I was referring to BTU.  In a tournament game, a CTU is made up of 3 BTU (4 BTU for Standard, 8 BTU for Beginner).

Lets look at it another way: In our case, if 2 players hit the button in BTU 1 of 3, but the higher ranked player chimed in at jiffy 2 and the lower rank hit jiffy 3, should the lower rank rule still apply?  Or should the rule apply only if they chime in on the same jiffy (of 12)?

The only thing I know is that it doesn't seem to be clarified anywhere.  Kroah is out here somewhere.  Maybe he knows?

[Intergalactic Mole]

I agree that RTT/2 is not quite enough time to wait, but for badly lagged players, this can slow down the game more for all players.

My point is that I don't think it's right to penalize players in the form of unfair gaming.  Instead, penalize everyone in the form of slow but fair gaming.  Players DO have the choice of who they play with.  If players are accepting of a high latency player, then they are in agreement that the game will take longer to play.  But at least everyone will have an equal chance at winning.  Maybe people will be more inclined to play with others closer to where they live, which is fine, and it doesn't preclude them from playing a fair game with ANYONE.

I was referring to BTU.  In a tournament game, a CTU is made up of 3 BTU (4 BTU for Standard, 8 BTU for Beginner).

The decompilation doesn't specify any specific time unit is required for pressing the button.  Since every time unit is based on the lowest denominator of jiffy (even BTU) then my assumption is that the button press is accepted per jiffy unless otherwise indicated (in all phases).  Of course, Kroah still needs to clarify.

[Kroah]

Hi all,

Accordong to the assembly code, buttons are checked for selection every jiffy during land grant, so players order is only used if 2 players push the button during the same Jiffy. The game level does not change anything, the cursor only stays longer on the plot.

I will add that computers push the button at the first Jiffy. So if you are behind a computer rank, the only way to beat him is to push at the first Jiffy when the cursor appears on the plot (read here impossible).
If 2 computers choose the same plot, the last one get it.

[rommager]

Thanks for the clarification Kroah!

Sounds like Planet M.U.L.E. is working per spec on my question.  The only other thing I can ask on this subject is why we use RTT/2 as that would penalize people with a more latent (though consistent) connection?

I am with Intergalactic Mole on this one.  I favor slower but fairer gaming versus faster but less accurate.  I also think that the cutoff for getting in the first jiffy on next plot should be if the button is held before the current CTU ends, and not after the grace period begins.

If I understand correctly, the land grant goes as such:
1) Land Plot CTU Begins
2) Clients send back button press results as the buttons are pressed (which frame/jiffy the player chimed in on)
3) Land Plot CTU Ends
4) If no button pressed: Client sends back "no button pressed"
5) Grace Period Begins (plot turns gray), Host waits roughly RTT/2 for any remaining button presses to come in
6) If plot has winner: Host decides who won, awards plot, pauses
7) If more land exists: Restart the process at step 1

Is this roughly accurate?

[rommager]

Wait - I get it.  RTT is Round Trip Time...  Since the client is sending to the host (and host is not asking for a status update), then the amount of time to go from client to host would be roughly half of RTT.  It's a little more than RTT/2 as a margin of error.  Sound about right?

Is an average RTT taken for each player, or is it the average the RTT of all players?  I would think that we should want to take the RTT/2 of the player with the highest average RTT, that's left of those who have not chimed in.

[Intergalactic Mole]

Is an average RTT taken for each player, or is it the average the RTT of all players?  

If I understand Peters explanation correctly, there is no average used.  The RTT used for synchronizing is the RTT/2 of the player who has the highest latency. .....

[rommager]

Is an average RTT taken for each player, or is it the average the RTT of all players?  

If I understand Peters explanation correctly, there is no average used.  The RTT used for synchronizing is the RTT/2 of the player who has the highest latency. .....

Ahh my bad - I'm getting who said what mixed up.  I thought Peter referred to the average ping (RTT), but when I went back and looked, it was Zach who referred to average ping in auctions.   I guess I assumed that the RTT would be an average for all packets because you always get some stray packets that are unusually late.

[-Lee-]

hold on it seems nobody tried to think of a better way of doing speed based response things, so I say the response time should be generated on each client, then that response time sent to the host and compared, but it should be cut off when the player with the highest ping runs out of time, it would make the time between movement between land plots lag in accordance to the person with the lowest ping but it would be the fairest way to do it. I've only partially looked into any networking programming but I believe this is a viable method. TBH I couldn't really be bothered to read through many post on this thread but read peters and main and briefly looked over the rest and nobody else seemed to come up with anything better than what peter said.

[Intergalactic Mole]

hold on it seems nobody tried to think of a better way of doing speed based response things

This was suggested on P1

TBH I couldn't really be bothered to read through many post on this thread but read peters and main and briefly looked over the rest and nobody else seemed to come up with anything better than what peter said.

An opinion based on what you admit you did not even read and which I humbly disagree with.

[Keybounce]

I will add that computers push the button at the first Jiffy. So if you are behind a computer rank, the only way to beat him is to push at the first Jiffy when the cursor appears on the plot (read here impossible).

In the spirit of fairness, can the internet MULE be changed to have the computer "press the button" on the second frame (possible to tie) instead of the first (impossible)?

[Peter]

NOTE: I removed the two last posts which I don't think were relevant to the discussion.

Here's a clarification of the inner workings of the land grant in Planet Mule with some more details added:

First, Planet Mule doesn't adhere to the cursor speed described in Kroah's decompilation (CTU's and jiffys).

A plot can be claimed for 25 frames = 0.42 seconds, if claimed the marker stops for 80 frames = 1.33 seconds. Then the grace time is added which is the period when the plot marker is gray and you can't claim the land. The grace time is calculated once at the beginning of the land grant and doesn't change even if player RTT's change:

grace time = (Max Safe RTT in seconds) * 60 + 5

The Max Safe RTT is the worst case estimate of round trip time from the host to the most laggy player. It can be for example 400ms which makes grace time = 29 frames = 0.48 seconds. Since RTT changes all the time the laggy player in the example could have an RTT varying between 200ms and 450ms.

All players send a Ready Message (READY) to the host when they either pass the 25 frames in the claiming period = they didn't press their button, or immediately when they press their button during the claiming period.

If no claim occurs:
When the host has received all READYs it sends a Continue Message (CONTINUE) saying that all clients can go to the next plot. Typically it should arrive at all clients within the grace time, i.e. during the grace period when the plot marker is gray, but if it doesn't the game will halt for a short time. If there still is grace time left (usually it is) each client wait that time before moving to the next plot. This makes it look smoother by trying to always have the same waiting time between plot cursor moves.

If a player claims the tile:
When the host receives a claiming READY (player pressed her button) the message also contains the number of the frame it was claimed. This number is always between 25 (first frame) and 0 (last frame). It is a frame countdown started at each individual client when, on her screen, the marker is moved to the next plot. If no other claiming READY, with a higher frame number or same frame number from a player with lower rank, arrives within half a grace time (grace time / 2) the plot is given to the player in question. When granting a plot the host sends a Granting CONTINUE containing the winning player. Upon receiving that message, clients stop their marker for 80 frames before continuing.

For all this to work smoothly it is important that the land grant is started somewhat synchronously and that the Granting CONTINUE arrives somewhat synchronously. This is done by taking the latest and most accurate RTT for all clients (not worst case estimate described above) and delaying those message for a number of frames so that the total time, delay + time it took for message to arrive, equals the largest RTT / 2 of all players.

If the land grant starting message or Granting CONTINUE should arrive unexpectedly late then lagging players will have a disadvantage. The lagging player's claiming READY might not arrive before grace time / 2 has passed at the host from another player's claiming READY and thus the plot is given to a player it shouldn't belong to. I've seen this happen in a few logs and we aim to improve the code in future versions. However I can already now say it will not be in the next update.

Any questions on that?

[Intergalactic Mole]

NOTE: I removed the two last posts which I don't think were relevant to the discussion.

If the land grant starting message or Granting CONTINUE should arrive unexpectedly late then lagging players will have a disadvantage. The lagging player's claiming READY might not arrive before grace time / 2 has passed at the host from another player's claiming READY and thus the plot is given to a player it shouldn't belong to. I've seen this happen in a few logs and we aim to improve the code in future versions. However I can already now say it will not be in the next update.

Thank you.