Game Synchronization

[Intergalactic Mole]

   IMO Planet MULE is currently a completely different game from the original MULE, simply because it is not synchronizing clients throughout the game.  It affects almost every aspect of the game, from the land grant to the auctions.  Currently the person with the lowest ping (the host) is always given priority.  In many cases players state they were in different spots on the screen as compared to other players, which can give some players unfair advantage at various points of the game.   Despite the barrier of latency over the internet, this problem can and should be fixed to match the specifications of the original game.


Some notes about the original game:

1) In Land Grant, if multiple persons click on a plot, it's the person who clicked the fastest that gets it.  If two people click exactly the same time, its the poorest person that gets it.  

2) In auctions, if multiple players meet the auction line simultaneously, the poorest person takes priority.

3) In auctions, there is slight delay before a unit is bought or sold once the lines are met, giving the player the opportunity to move beforehand.  This is especially important when people are moving up and down at the same time in the middle of the screen.  It adds what you might call a "haggling effect".


   In the original game, the lowest denominator of units of time was referred to as jiffys (see Kroahs reverse engineer document).   Above that was a base time unit, or BTU, which was used to determine the amount of time for everything else.  The amount of real time a jiffy took was based on whether the user was playing in NTSC or PAL.  The same system can be used to deal with latency.  In other words, players with higher latency would have less jiffys per BTU, while players with lower latency would have more jiffys to compensate.  The calculation should be performed every second to assure that all clients are synchronized throughout the game.  While this could potentially make the game speed up and/or slow down dynamically throughout the game based on fluctuations in latency, I believe that the fluctuations in players latency are normally minimal enough that the amount of difference in time calculated wouldn't be significant enough to cause a problem.

   While I understand this may require more packets to be sent back and forth between the clients and the servers, in turn requiring more bandwidth to play the game, I believe it is absolutely necessary to synchronize the clients in some fashion, whether it be by using the above suggestion or some other devised method, in order to make Planet MULE as close to the original game as possible.  At no given time should any player be on a different part of the screen than what other players are displaying.

   Of course, I don't expect many newcomers to understand or even agree with any of this.  But anyone who spent a considerate amount of time playing the original game back in the 80s will probably concur with this.

[Soldier Ant]

I agree. This is a major problem specially for Land Auctions.
I think Mole's solution would work, but if it didn't, then my suggestion is to simply slow down the game, so slow down player movement at auctions and the reaction to events like auction lines meeting.
But I think this would make the game awfully slow...

[Intergalactic Mole]

The following post was a reply to this thread. Not sure why it was moved into another topic.

Me agrees too: The game needs some logic for ping lag compensation or ping lag transparency. Other online multiplayer games have these issues too and implement such logic to compensate the usual ping lag for internet games.

In the case of MULE I suggest:

1. The time a player needed to claim a plot should be calculated client side. When the player hits the button not only the button hit should be transfered to the server but also the time he needed to react to the plot marking. The server collects these times and chooses the right winner. How long a player took should not be calculated server side. This also has the plus that the claim marker could move at the original speed of M.U.L.E. and not slowed down like right now.

2. For auctions each player should always see the situation the server sees, not a mixture of the client and server like it is right now. So every player will see the ping lag in its actions (if he moves up, the player figure will start to move up depending on the ping lag because the client only shows it when the server transfers the clients current position on the server back to the client). Currently a player has to calculate the ping lag into his action in his mind, because the game does not show him how the ping lag affects his position. It may look not very good to the player but it makes the lag transparent so every player can change his actions since he knows how big the delay is. I had several times the problem that I sold or bought one or two units more than intended because my position showed by the client did not actually reflect my position on the server (or did not get a plot in an auction although the client showed me in head position, but I wasn't on the server).

3. The server list should always show the ping, so players can decide before the connection, if the ping lag is bearable. Maybe even allow a serversetting that only allows clients with low ping (100 and under) to connect.

[Big Head Zach]

1. The time a player needed to claim a plot should be calculated client side. When the player hits the button not only the button hit should be transfered to the server but also the time he needed to react to the plot marking. The server collects these times and chooses the right winner. How long a player took should not be calculated server side. This also has the plus that the claim marker could move at the original speed of M.U.L.E. and not slowed down like right now.

If we're for certain that we want to reward players quick on the draw (or that hold down their button after the cursor leaves the last plot)...what's the epsilon on this? How precise are we going to be? If someone buzzes in with a time of 386ms, and another player buzzes in with a time of 387ms, do you feel the game should give it to the first guy? Or should there be a reasonable threshold of what we consider "at the same time"? If the cursor is moving slow enough that reaction time of buzzing in on the correct plot is not an issue, what remains?

Those kinds of questions mixed in with the issue of lag just make me think that the phrase "at the same time" should refer to which plot the cursor is on in general, and not that the game tries to determine who was first to notice that cursor moved from the previous plot to the next plot...that's like having a quick draw contest when you know what the trigger motion is - if you're looking for it, how much merit is there in being quick, especially if you can hold down the button in advance of the actual event?

(If cursor movement during land grant was random, I'd be more inclined to reward the twitch player, FWIW.)

2. For auctions each player should always see the situation the server sees, not a mixture of the client and server like it is right now. So every player will see the ping lag in its actions (if he moves up, the player figure will start to move up depending on the ping lag because the client only shows it when the server transfers the clients current position on the server back to the client). Currently a player has to calculate the ping lag into his action in his mind, because the game does not show him how the ping lag affects his position. It may look not very good to the player but it makes the lag transparent so every player can change his actions since he knows how big the delay is. I had several times the problem that I sold or bought one or two units more than intended because my position showed by the client did not actually reflect my position on the server (or did not get a plot in an auction although the client showed me in head position, but I wasn't on the server).

I totally agree with this, with the caveat that if the average ping to a player is known, then some amount of leniency be given to his location with regards to the trade line - if he actually reaches the trade line on time when you add the lag back, he should be considered in the contest for who trades first. So when the server detects that someone has reached a trade line, it should wait for a period of time equal to the average ping of all players to that host, then cut-off any updates after that delay that claim to be at the trade line; those that got in before that, are considered for first-to-trade.

It doesn't have to be big either...I'd say 150ms at the most, which is half the time of the average hand-eye reflex (as tested by me through numerous trials playing Wild Gunman for the NES, lol).

3. The server list should always show the ping, so players can decide before the connection, if the ping lag is bearable. Maybe even allow a serversetting that only allows clients with low ping (100 and under) to connect.

Always a good idea.

Oh, and it was me who moved the reply, merging it with the discussion on auction trade-line issues. Thought it was relevant, but considering the recent hoopla about lag tolerance and auctions, it deserves its own thread after all. Bwah.

[MrBrown]

The time a player needed to claim a plot should be calculated client side. When the player hits the button not only the button hit should be transfered to the server but also the time he needed to react to the plot marking

Having mostly played online shooters in the last years, I can only say that it's a very bad idea to let the client decide anything, because it makes cheating very easy. While it might not be a problem for PlanetMULE right now because it's not the typical online shooter community here, I'd say "better safe than sorry". Especially for a Java Application, which is basically "Open Source by Design".

If we're for certain that we want to reward players quick on the draw (or that hold down their button after the cursor leaves the last plot)...what's the epsilon on this? How precise are we going to be? If someone buzzes in with a time of 386ms, and another player buzzes in with a time of 387ms, do you feel the game should give it to the first guy? Or should there be a reasonable threshold of what we consider "at the same time"? If the cursor is moving slow enough that reaction time of buzzing in on the correct plot is not an issue, what remains?

Those kinds of questions mixed in with the issue of lag just make me think that the phrase "at the same time" should refer to which plot the cursor is on in general, and not that the game tries to determine who was first to notice that cursor moved from the previous plot to the next plot...that's like having a quick draw contest when you know what the trigger motion is - if you're looking for it, how much merit is there in being quick, especially if you can hold down the button in advance of the actual event?

I personally dislike the "quick draw contest". It shouldn't matter if someone presses the button a few milliseconds later or earlier in an online game. So I think if multiple players select the same plot, their rank should decide who wins.

Does anyone know for sure how the 8-bit Versions handled this? The OP says timing did matter, but in which boundaries? If it's really a matter of a few milliseconds, I think it's a bad idea to stick too close to the original in this point.

I totally agree with this, with the caveat that if the average ping to a player is known, then some amount of leniency be given to his location with regards to the trade line - if he actually reaches the trade line on time when you add the lag back, he should be considered in the contest for who trades first. So when the server detects that someone has reached a trade line, it should wait for a period of time equal to the average ping of all players to that host, then cut-off any updates after that delay that claim to be at the trade line; those that got in before that, are considered for first-to-trade.

I think the host will still have an advantage in this scenario. Assume that player A ist host. If player B moves, then player A will see that movement and can react accordingly before players C and D can do so. And not only can the host react faster, his reactions take effect immediately. So if the ping is 100ms, players C and D recognize the situation 100ms later and then the actions they take are delayed by 100ms again.

Dedicated servers would be the perfect solution for this problem, an alternative would be to penalize the host's movement with some kind of "artificial ping".

[rommager]

Having mostly played online shooters in the last years, I can only say that it's a very bad idea to let the client decide anything, because it makes cheating very easy...

Yes, client side calculation opens up opportunity for cheating, however, I think it should be possibe to curb (but perhaps not eliminate) cheating.  The host can somewhat validate the results sent back from the client.  The server can send a randomly generated token to tell the client to advance the cursor and begin timing the user response, broken down into BTUs (Basic Time Unit, see below), the client can then send back an immediate response when the button is actually pressed.  At end of the CTU (Cursor Time Unit, see KROAH spec), send the token as validation, along with actual client timing in ms.  The host can then validate the results by taking latency into account and verifying the results are consistent with the actual time the button was hit (within an error margin).  The host can also keep stats to ensure the user responses are not always the same (i.e. if the client always sends the same or similar ms values then that's suspicious).

Security can also be heightend at the start as the host can send a random salt value, then the client can run a hash on the actual game code + the salt value, and send it back.  This helps to authenticate that all clients' game code actually matches the host.  I think this should be possible since I believe Java should compile the same regardless of platform.

I know any of these measures can be circumvented by a clever cheater, but the measures are meant to make it more difficult to cheat, not to completely prevent cheating.

If we're for certain that we want to reward players quick on the draw (or that hold down their button after the cursor leaves the last plot)...what's the epsilon on this? How precise are we going to be? If someone buzzes in with a time of 386ms, and another player buzzes in with a time of 387ms, do you feel the game should give it to the first guy? Or should there be a reasonable threshold of what we consider "at the same time"? If the cursor is moving slow enough that reaction time of buzzing in on the correct plot is not an issue, what remains?

The original spec used Base Time Unit or BTU.  Accoring to Kroah, this came out to roughly 80ms in PAL and 67ms in NTSC.  For all intents and purposes though, we could simply pick a short frame of time.  I imagine 100ms would work fine (after all we need a little more time for latency).  If two users buzz in on the same BTU, then award the land to the lower ranked person.  After all, that's what's in question here.  Even if a cheater were clever enough to defeat anti-cheating measures, they may not always win if a lower ranked player with a quick trigger finger hits the first BTU.

Still, I think the net result is to get as close to the original game as possible, and not worry as much with cheaters.  If someone is going to invest the time to crack anti-cheating code *just* so they can get the plot of land they want, something tells me that they are also clever enough to code in a computer generated button press to get the response back to the host as quickly as possible.  Besides, just because someone always gets the 3 mountain land, or the high crystite plot, doesn't mean they have the skill to win.   

[Peter]

It has popped up lots of discussions on the networking model of Planet MULE and ideas on how to improve it. Here's the facts on how it works and our motivations for doing it this way:

General

The game runs its logic at 60 frames per second. A frame takes around 16 milliseconds. Only one button press can happen in a frame so there's a 16 millisecond window where it doesn't matter at what time the button is pressed.

RTT (or ping) is a roundtrip time, the time it takes for a message to go from a client, to the server and back again. A lagging player may have over 500ms, half a second, RTT. The host always has close to 0 RTT. When I refer to RTT below it means the largest RTT for all players in the game.

Land Grant

Players have a fixed number of frames to press their button to take a plot. No matter the latency players always get this time to press their button from the time when the marker is moved on her screen.

On a button press the client sends the frame at which she pressed the button to the server. When the server receives a button press it waits a litter longer than RTT/2 for any other button press to arrive. The button press with the lowest frame wins, or if they are equal the lowest ranked (poorest) player gets the plot. This makes it fair in the sense that the quickest player to press her button in relation to what her screen shows is the winner. Being +/- 16 milliseconds doesn't have an effect.

After granting a plot or if nobody wants the plot all clients are synchronized to start on the next plot. We call this the grace period and the marker turns gray. To make the land grant smoother the synchronization always takes a little more time than the RTT. It can however take longer if the RTT changes during the land grant and the marker stays longer than usual at one plot.

In version 1.2.0 you can hold your button pressed during the grace period to ensure you're first on the next plot. We're thinking of changing this in future versions so you must press your button after the marker has moved to award fast players with itchy trigger fingers.

You can always hold down your button after a player has taken a plot to ensure you're first on the next plot.

Note: It has been reported in the bug forum that the marker immediately moved on after granting a plot to a player making another player by mistake take the plot after. This should never happen. However, we haven't confirmed the bug yet. After a plot is granted all players see the granted plot blinking for quite a long time before moving to the next plot. Latency does not affect this waiting time.

Development

Very simple networking. All game clients replay the commands of the current player resulting in the same thing happening for everyone but with a delay proportional to RTT.

Auction

Current version 1.2.0 introduced a bug which favors the host. Sorry for that. It was the result of fixing a bug which caused the auction to freeze.

In version 1.2.1 this is fixed. Also players should start more synchronized i.e. the players with lower RTT wait a few frames for the players with high RTT to receive the start message.

Movement in auction is asynchronous. You immediately move on your own screen and all other players see your movement some time later depending on their individual RTT. The latest position/price which the host received from you is what counts. That position is roughly your own RTT/2 milliseconds old.

When auction lines meet at the server a trade will happen after 250ms + RTT. In a laggy game this can be 3/4 of a second. The timer stops when a trade is about to happen. During this time any other player has a chance to walk up to the line and take over.

You can only take over if your rank is less than the rank of the player already standing there. For example if Player Rank 1 (PR-1) is trying to sell to PR-2 and PR-3 enters the line, then PR-3 takes over buying. If seller PR-4 also enters the line she takes over for PR-1.

This means that if all players are running to buy from the store the last ranked player should get to buy first.

The RTT used in the auction is estimated pessimistically, meaning that if a lag spike would occur players still have a good chance to take over a trade. However it is possible that a player loses a trade during some longer temporary network problem.

Land Auction

Even in 1.2.1 the host has a small edge here. If two players are standing on the same price and the host takes one step in the last second the other player won't have time to react.

Players can somewhat counter this by walking a little up and down and make it harder for the host to know what to do.

Our plan to solve this is by allowing a few movements by other players after the time has run out but before they have seen the hosts final position. Roughly an extra RTT/2 time to move. Then neither the host, nor the clients can be sure they've seen the last position of the other players and they have to guess if they should go up/down in the last minute (or rather last milliseconds). Here we're only taking about fractions of a second.

Auction Networking

Auctions in Planet MULE are more like an action game and less like a typical real-time strategy game. We've chosen to make it more responsive and less predictable/synchronized. If you press your button you move, you don't feel any lag, and the game doesn't slow down.

As suggested in some discussions it's possible to wait for commands from all players and advance the game more synchronously. You can make all players see the exact same scenario. It can be done in many different ways and I've read some colorful suggestions in the forum.

The drawbacks of such network models are the same though. The game can halt for all players and wait for more commands, the game can slow down, and there can be a delay between pressing a button and something happening on screen.

We think that most players would find it frustrating to press a button and not immediately move on screen. The price you pay for complete fairness is probably not worth it. So instead we've chosen to add some grace time to certain events, trying to make the game fair enough to users on slow connections.

Still there may be some bugs left which can make the game unfair even under reasonable conditions. Please report it if you feel badly treated by high latency.

Questions are welcomed but I'm usually busy so it may take some time to get an answer.

[MrBrown]

We think that most players would find it frustrating to press a button and not immediately move on screen. The price you pay for complete fairness is probably not worth it. So instead we've chosen to add some grace time to certain events, trying to make the game fair enough to users on slow connections.

Still there may be some bugs left which can make the game unfair even under reasonable conditions. Please report it if you feel badly treated by high latency.

Questions are welcomed but I'm usually busy so it may take some time to get an answer.

Did you ever think about using dedicated servers to solve these problems? Is that an future option for PlanetMULE or is it impossible without a complete netcode rewrite (which I assume is not an option  ).

[Intergalactic Mole]

The drawbacks of such network models are the same though. The game can halt for all players and wait for more commands, the game can slow down, and there can be a delay between pressing a button and something happening on screen.

The drawbacks are not the same IMO.  Timing is of the essence in almost every aspect of the original game.  Without using a full synchronization network model, the timing will always be somewhat off.  As such, the game will never play like the original one. 

When playing the original game on the Atari emulator with Kaillera, if everyone has a ping of less than 100ms then there is no delay for anyone and the game is perfectly synchronized.  For each 100ms added to someones latency they have a 1 second controller delay.  However, even with that delay, they were able to predict when they needed to press the button or move the controller with great accuracy in all phases of the game.   That slight delay for higher latency players is a small price to pay for an exact duplicate of the original mechanics of the game.

The problem with playing the over the internet with the emulator is that it simply isn't easy to guarantee duplicate emulator settings on all players computers.   Incorrect settings or changes in the emulator mid-game would cause desynchronization.

[Salinga]

First of all thanks for taking the time and clear things up.

In version 1.2.0 you can hold your button pressed during the grace period to ensure you're first on the next plot. We're thinking of changing this in future versions so you must press your button after the marker has moved to award fast players with itchy trigger fingers.

But don't forget when someone got a plot and the marker moves to the next one. AFAIK in the original game you could hold your fire to claim the next plot while the marker still was on the plot the other player got. So if you're changing the behaviour there maybe you need to make a difference between taken and not taken plots.

As suggested in some discussions it's possible to wait for commands from all players and advance the game more synchronously. You can make all players see the exact same scenario. It can be done in many different ways and I've read some colorful suggestions in the forum.

The drawbacks of such network models are the same though. The game can halt for all players and wait for more commands, the game can slow down, and there can be a delay between pressing a button and something happening on screen.

We think that most players would find it frustrating to press a button and not immediately move on screen. The price you pay for complete fairness is probably not worth it. So instead we've chosen to add some grace time to certain events, trying to make the game fair enough to users on slow connections.

Well, why not make it optional: Each player can decide if his movements should be client side predicted or should always reflect his "real" position on the server (and make the first one the default state). So players can decide by themselves if they put accuracy above "frustration".

[Peter]

In version 1.2.0 you can hold your button pressed during the grace period to ensure you're first on the next plot. We're thinking of changing this in future versions so you must press your button after the marker has moved to award fast players with itchy trigger fingers.

But don't forget when someone got a plot and the marker moves to the next one. AFAIK in the original game you could hold your fire to claim the next plot while the marker still was on the plot the other player got. So if you're changing the behaviour there maybe you need to make a difference between taken and not taken plots.

The sentence below the one you quoted, namely "You can always hold down your button after a player has taken a plot to ensure you're first on the next plot", was meant to describe the behavior you're referring to. This will be true in future updates also.

[rommager]

I forgot to ever chime in on this one a day or two ago.  Peter, thanks for the awesome explanation!

Personally, I think holding down the button during the grace period should be changed.  If the button is initiated during the grace period, then it should have to be released again before the player can choose the next plot.  As far as holding down the button from the point where the game pauses after the other player won the plot, make it follow the original.  I'm just not sure if this tactic worked on the original versions or not.

I think especially when there is a laggy player, it gives some players an unfair advantage if they press and hold their button as soon as they see the plot turn gray.

Also, I had games before where I thought I pressed the button and the other player won, then I immediately got the next plot by accident.  Maybe this was the way the original played, but I was thinking that there was supposed to be more of a pause which gives players time to rethink their strategies for lands lost.

According to Kroah:
Lands grant Cursor speed - The cursor is moving at a speed of 1 land each CTU. When a land is selected by a player, a pause of 4 CTU is done.

Does Planet M.U.L.E. follow this?

[Intergalactic Mole]

I'm just not sure if this tactic worked on the original versions or not.

It works this way on the Atari version, though I can't speak for the Commodore version.

I think especially when there is a laggy player, it gives some players an unfair advantage if they press and hold their button as soon as they see the plot turn gray.

The netplay code that Planet MULE prevents this from happening.  According to Peter, the timing of button presses is dependent on the video frame # on the client.  However, this is contradicted by the fact that you may have a different # of video frames than the other players, if your latency is higher than the "pre-determined" timing of each video frame.

Also, I had games before where I thought I pressed the button and the other player won, then I immediately got the next plot by accident.  Maybe this was the way the original played, but I was thinking that there was supposed to be more of a pause which gives players time to rethink their strategies for lands lost.

The players screens don't actually synchronize their markers until the beginning of each grant marker movement, so it's probably going to jump quickly for players with higher latency after someone grabs a plot.  This is one of the "cons" of the way the netplay code is implemented.

According to Kroah:
Lands grant Cursor speed - The cursor is moving at a speed of 1 land each CTU. When a land is selected by a player, a pause of 4 CTU is done.

Does Planet M.U.L.E. follow this?

Since the video frames are not dynamic based on player latency (where as CTU's in the game were based on sub-units called "jiffy's", which were dynamic based on players video speed/type), there is frequent desynchronization in the land grant (and other aspects of the game).  The timing of video frames are pre-determined so if latency is more than the pre-determined amount, the screen may appear to jump for some players and not others.

Unfortunately, Planet MULE cannot simply use the timing from the original code because the original code had no mind of latency.  However, the original concept of jiffys, btus, ctus, ptus, can be adapted to accomodate for latency.  However, it is the developers opinion that people will not like it that way.

We think that most players would find it frustrating to press a button and not immediately move on screen. The price you pay for complete fairness is probably not worth it. So instead we've chosen to add some grace time to certain events, trying to make the game fair enough to users on slow connections.

Still there may be some bugs left which can make the game unfair even under reasonable conditions.

[rommager]

The netplay code that Planet MULE prevents this from happening.  According to Peter, the timing of button presses is dependent on the video frame # on the client.  However, this is contradicted by the fact that you may have a different # of video frames than the other players, if your latency is higher than the "pre-determined" timing of each video frame.

That has always been unclear to me in the original spec.  The spec states that the game actually worked using BTU (Base Time Unit) which is 4 jiffys.  What it doesn't say in Kroah's spec is what the logic considers to be "buttons pressed at the same time".  Does it mean the button presses have to be in the same jiffy, as Peter said Planet M.U.L.E. is designed, or do the button presses have to be in the same BTU (a window of 4 jiffy or frames)?  This could make a very real difference in the perceived play mechanics of the game, since we're talking about a window of roughly 17 ms versus a 67 ms window.

There has to be a "noticable to humans" window of opportunity to recognize that the lowest ranked player rule applied.  Also, as mentioned in another thread, we could always display a message that says this happened.

Since the video frames are not dynamic based on player latency (where as CTU's in the game were based on sub-units called "jiffy's", which were dynamic based on players video speed/type), there is frequent desynchronization in the land grant.  The timing of video frames are pre-determined so if latency is more than the pre-determined amount, the market may appear to jump for some players and not others.

It doesn't sound like latency should be an issue, unless the player is just lagged badly.  The client tells the server which frame the player pressed the button, then the host figures out who has the lowest frame:

On a button press the client sends the frame at which she pressed the button to the server. When the server receives a button press it waits a litter longer than RTT/2 for any other button press to arrive. The button press with the lowest frame wins...

The only way I see latency becoming an issue in this model is if the client is unable to have the button press result back to the host in time (slightly over RTT/2).

Am I misunderstanding?

[Intergalactic Mole]

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.

The client tells the server which frame the player pressed the button, then the host figures out who has the lowest frame:

Yes, and then the clients synchronize.  Unfortunately, the player who has the highest latency is still producing video frames while everyone else is synchronizing (due to RTT/2).  See below for explanation of this.  And so, if he presses his button while he is still producing video frames, but everyone else has stopped, he will in fact have pressed his button while the host is already into the next plot, causing him to take the wrong plot.

The only way I see latency becoming an issue in this model is if the client is unable to have the button press result back to the host in time (slightly over RTT/2).

Am I misunderstanding?

I think you are.  RTT/2 is half the amount of the highest latency player, which means that if Joe Schmoes latency is 800, his game is expected to respond in 400ms.  Since it can't, he will always produce more video frames then everyone else, causing his game to always be desynchronized if he takes actions past 400ms.

I don't quite understand the logic behind dividing the highest latency in half as a reference.  If anything, the highest latency should simply be the point of reference without dividing it.  To quote Peter:

So instead we've chosen to add some grace time to certain events, trying to make the game fair enough to users on slow connections.

Slightly unfair is not fair enough IMO.

In comparison with the original game over Kaillera, I suppose player-aware-desynchronization is better than unaware desynchronization.  If clients become desynchronized when playing over Kaillera, they usually don't realize it until the end of the game, when everyone has declared themselves the winner.