MERGED: Auction Speed & Lag of Trade Line

[arghman]

(ref: game = http://www.planetmule.com/sector-map?mycolonies&game_id=11740)

We just played a game where the network lag was moderately high (150ms ping) and it made clear that there is an advantage to the game host in the way that the auction currently works. With long time lags, the host's view of who gets to buy/sell first is different than the other players'. I assume this is because the local copy of each game doesn't wait for the host server to determine all the timing, it adjusts player positions on screen to give an approximation of what's happening on the host (even though this is really incorrect, the "true" timing must happen on the host only).

The player who was hosting was able to outbid 2 of us for food/energy on the later turns because he hosted the game, even though we both held the up arrow key the whole time and were lower-ranked players.

Please consider slight tweaks to the auction to fix this issue. Since it takes a while for the sellers to reach the store or buyers, and buyers to reach the store or sellers, I think it's possible to allow fair auctions even considering network lags, without slowing the game down too much. This may take some programming subtlety, depending on how it's implemented right now. My guess is that this is solvable if there are discrete timeslices (perhaps 100-150msec), where for each of those timeslices each player's computer must transmit to the host computer whether the player has moved up, down, or stayed at the same position. This would allow the host computer to determine player position compensated for network delays (e.g. player 1's movement in timeslice 1 arrives after player 2's movement in timeslice 1). Don't bother slowing the game down for round-trip communications UNLESS there's close player-to-player positions and it is time to determine which player gets the buy or sale -- then wait a longer timeout to reconcile the timeslice movement decisions and make sure player positions are synchronized properly.

e.g. if player 3 is the host, and player 2 is about to sell to the host in timeslice 100 but player 1's net connection is slow and the host still hasn't received player 1's command for timeslice 100 **and** player 1 is close to the sale price, then wait to see what player 1's command for timeslice 100 is. If player 1 is NOT close to the sale price, it doesn't matter and player 1 can be safely eliminated from the sale.

The players move too fast in the auction anyway, and in the original, time and position were more quantized.


The other problem with the auction at present, is a little more subtle. Let's say some players have some type of good (say food or energy) and are selling it to the store. Then after their selling binges start, another player X decides, oh, hey I'll buy some of it, and moves up to the store price. It's too late, though. Player X is locked out of the buy/sell process unless there is an instant where none of the sellers is selling to the store.

Not sure how to solve this problem; maybe it isn't a problem since player X waited before deciding to buy. But you should warn people that this can happen.

[BubbaBrown]

Two ways to handle this from my thinking.  One is a slight adjustment and the other changes the system greatly.

1.  Delay everyone equally.  Based on average ping times between the host and players, introduce unique and appropriate amounts of artificial lag on the input controls of the host and other players so everyone has roughly the same response time.

2.  Introduce the ability to dial in a price to "charge" ahead to before the auction starts.  When the auction starts the player's auction icons will move forward either at or 1 above another player's price.  (At or ahead depends on the rank.)  The player icon will not move pass than the dialed in price unless prompted by the actual player.

[Intergalactic Mole]

I would like to see a grace period implemented in the auction phase.  In the original game, when the buy and sell lines met, you had about 1 second to pull away from the line before any goods were transacted. With no delay, I frequently find myself buying or selling at an undesirable price.

[Soldier Ant]

I agree. And walking speed during auctions should be slower.

[Big Head Zach]

With the lag compensation in place, I see there's at least half a second, maybe more, to pull away from a line. Not sure what you're perceiving as instant trade.

[Intergalactic Mole]

It's instantaneous on my computer. There is no delay whatsoever.  The moment the lines touch, a transaction takes place. There is no time to retreat. I guess I don't have any lag.  In comparison to the original, there was much more time to "play" with the lines or fake people out.

[GabrielPope]

It varies a bit. The problem is, due to lag it's often hard to tell exactly where other players "really" are at any given point in time because what you see on the screen does not always sync with the current server state. Sometimes you'll perceive a gap of $20 and start moving up to meet the other player, when actually the other player has already moved down to meet you and it hasn't updated on your client--so you start moving up and before you even seem to get there the trading mechanism kicks in and suddenly you've started buying. When you're hosting, or playing on a smooth enough connection, there's usually a bit of a delay.

[Intergalactic Mole]

I've hosted 2 of the 3 games I've played so far, and in all 3 games the transaction was instantaneous upon the lines meeting.  My connection is 6Mb/s down and 1Mb/s up and I wasn't using the connection for anything else.  That should be more than sufficient to host a game of MULE.  I haven't experienced what you mentioned about trading before the lines even meet.  I am sure there is a way to synchronize the players and the server better than this.  It's definitely not the same as the original game.  In the original game I would frequently wait for someone to meet my line, and then fake them out by moving upward or downward to adjust the price a little bit.  Here that doesnt work because the transaction happens too quickly.  This can certainly be improved or corrected.

[Mega Byte]

Game speed is a function of 2 things: Connection speed, and latency.  Speed is only an issue if you are on a REALLY slow connection, (like 512k/less).  Not much data is actually transacted, since the client is local, it's just sending position and price details, a few other bytes.  Doesn't need much.  The bigger problem is latency.  If you are playing with people in other countries (which I always am, as have not yet found a single MULE player in Japan), that latency will vary, and is the result of the number of connections between your location and the host location (or host to guests connections).  I have found that anything in the ~350ms range works pretty good.  The lower the better.  I had one game that had a ping rate of 1925ms, which was a bit painful.

The "instantaneous" problem can't be experienced in a 6ms or even 100ms latency.  As host, you will never have high "ping" rate, but those attached to you may.

[Intergalactic Mole]

Thank you for trying to explain.  However, I am a network engineer, so I already know how these things work.  Regardless of what you believe to be the cause of the problem, the problem still exists and can be fixed.  Case & point: If you play the original Atari MULE with someone over the internet using Kaillera, you will see the grace period exists for everyone, no matter whether they are the host or not and no matter what the latency.  Obviously higher latency clients will not be able to respond as quickly, but the grace period is still there.

[Big Head Zach]

The tightrope the developers have to walk is how much delay to allow so that lagging players have a fair chance at reaching the line, but not let people who are simply way behind in reaction time have an equal shot.

While the original was pretty strict in only giving it to the lowest-placed player who got there exactly on time, I actually wouldn't mind giving a tad of delay, simply because of the perceived issue with lag, and that the current price movement is a lot more responsive than the original; if we're going to keep the increased speed/responsiveness, we should balance it with some reaction-time forgiveness. This isn't a twitch game, IMHO.

[Intergalactic Mole]

My friends and I have done much twitching in MULE over the past 25 years, faking each other out on the buy/sell lines.  It's like playing poker and is an integral part of the game IMHO. For example, the store may not have any resources that a player needs, and I am the only person selling.  Well I might fake people out making them think I will sell for a certain price, just to get them to move the line up toward mine.  When they finally reach it, I might raise the price at the last second.  Since they already wasted their time moving all the way up to the line in the first place, they may be more inclined to continue a little bit more as opposed to if they had just sat at the buy line the whole time.  I understand that latency causes a difficulty in accomplishing this, but I am confident it can still be done.   Perhaps the game can be made to dynamically adjust delays based on individual player latency.  Might be farfetched, but it's an idea nonetheless.  If the goal is to replicate original game conditions, then this should not be ignored.

[PandaMan]

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.

[Salinga]

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.

[cpt0]

Unfair host advantage is downright [terrible] when it's being exploited for cutthroat moves. Best example is the host rushing up ( like everyone) to get food on round one but because he has host advantage :
- Gets to the line " first"
- Buys everything in stock ( starving strategy)
- The other players who actually reached the line and should be included in the buy distribution cannot buy.
- Host buys all food, leaving nothing for the others.

Whoever is on the "buy line" should be recalculated every other second or something, to allow for "latecomers" to be able to get some goods.  This way buy/sell strategies can still be used, but host advantage cannot be used to exploit to a buy-all.