Latency compensation can be abused.  It's been done in shooters, mostly in the early days of online FPS.  If the compensation is dynamic, then the player may be able to retract a bad move before it "happened", or leap up to the line and sit on it before you can "see" it.  If a percentage of the latency is used as the compensation, and averaged over time, then perhaps something could be done.  Just a rough guess, as i'm not a developer of network software.  The ultimate compensation is to only accept a connection to someone with a low (sub 200ms) ping to you.  Perhaps the program could detect and warn of high ping or widely varying ping times.

Please note that I said PING, but using this maintenance tool as a measure of responsiveness is a BAD IDEA.  Cisco, and most other routers will delay or drop ICMP (Internet Connection Management Protocol) requests in deference to actual important data.  The proper method for determining latency in-game would be peer to peer latency IN GAME.  This is commonly done, and may already be the route taken here.  It's advantage is that it bypasses firewalls, useing the game ports, and takes into account every factor that affects the real world turn around time in getting from one application running on one machine to the same app on another.  Now, a ping to the game port could be used, but we are still stopping short of fully measuring the latency, or bypassing ICMP.

If I am misstating, please advise, so that I may learn something new.  It's been years since I had to consider net latency and system lag from an admin standpoint.

I will say that a warning from the program that an attached client (s) is getting highly varied latency and/or dropped packets would be a welcome help.

I played M.U.L.E. on the C-64 back in the early/mid 80's, and later through emulation, with my kid (only my younger daughter, 8, was interested), and always wanted a few changes.  Here's a simple list:

1.  More land plots.  
2.  Updated graphics.
3.  Possibly 1 or 2 more resources (no idea whether randomly demand or usage demand oriented....)
4.  More players, especially with the ability to tie off player's resources into pairs.
5.  Basic gamepad support.  This one is actually pretty critical, as the Atari 2600 joystick(and later custom joys) could support 8 directional movement.  I may remember incorrectly on that, but i'm pretty sure.
6.  More turns as an option, along with game-state saving ability.


I will note that the C-64 version was subtly different "feeling" than the C-64 version.  I preferred the C-64 version's sound, graphics, and feel.  Of course, I may be biased.  The C-64 machine code was also pretty easy to read, although there were a lot of register tricks that could be used to shortcut or produce desired effects.  As far as an all-new iteration with expanded players/turns/resources and races, I think that the spirit of the original code should be there, but adherence to it would be out the window.  With enough random events, game balance on a razor's edge wouldn't be as much of a requirement.

Finally, I am obligated to admit that as a player of shooters and RTS games, and father of three like minded children (After age 7, it is a requirement to play the current FPS in my household!), I am proud to say that this game is the only non-conflict, non-violent game to have such a strong impact in my household.  I would turn my back on Borderlands in a heartbeat, to play an 8 person M.U.L.E. game.  So would my wife and kids.