[crossfire] Lag

[Mark Wedel]

Anton Oussik wrote:
> On 26/01/06, Mark Wedel <mwedel at sonic.net> wrote:
>> Brendan Lally wrote:
>>> On 1/26/06, Anton Oussik <antonoussik at gmail.com> wrote:
>>>> Is there anything that can be done to improve movement on laggy
>>>> connections? Could the server send the client a matrix of what tiles
>>>> on the map can be moved to, and send updates of that as they change
>>>> for example? Any better ideas?
>>   I'm not sure that helps out.  What it gains is that the client can 'move' the
>> player to the space they are attempting to go to so that client is slightly more
>> up to date.  However, you will get syncrhonization issues - if your lag is 500
>> ms, any update on that array of spaces is still 4 ticks out of date.  So you can
>> certainly get the case where the client thinks it can move to some space, but
>> someone else has already moved there, and thus what the client displays is not
>> just out of date, but erroneous.
> 
> Yes, I too see that flaw. However most other online RPGs deal with
> that issue in a similar way to this, using server updates as the
> reference, and it seems to work for them.

  There are a few differences in crossfire.

  One is that in crossfire, the client is presumed insecure - the server 
shouldn't trust anything the client says

  The other is that in crossfire is the amount of real estate covered.  If you 
have 500 ms lag (4 ticks) that means you can be 4 spaces behind.  If you are 
running with a 25x25 space display, you see 12 spaces in each direction from the 
central player, which means you move 1/3 of your visible spaces just from lag.
Compared to most all the other games, I think this is a huge portion of the display.

  One problem with the array of spaces is also the case of how this really works.

  For example, the player is running east.  The player stops running, at say 
space 15,5.  By the time the server receives that the player has stopped moving, 
the server thinks the player is at 19,5.

  You can't really undone that change - imagine any exits, traps, or other 
special spaces the player runs over (as well as what other players see) - so in 
this case, the server really has to keep the player at 19,5.

  Sending the grid of spaces to the client I don't think actually makes much 
difference - as I think about it, I am not really sure how it helps anything - 
the only thing it really helps out on is if the player is running into a wall - 
the player can change direction a bit faster.


>>   The slightly more complicated part is that ideally, you'd want the server to
>> send the client the proposed route (so the client could display it in some
>> format, so if it is completely bogus, the player can interrupt it and re-route
>> manually.
> 
> Is there really much point in this? Clicking anywhere you can see
> should (travelling in more-less straight line) get you there in about
> a second, which is not enough time to cancel a route.

  You're probably right in that regard.

> 
>>   One consideration is the case of alternate routes.  One tricky part also,
>> relative to players using that code, is you don't want the player to cheat too
>> much.  IF the player is in a maze, they shouldn't be able to click some spaces
>> away and the server now routes them there even though as a player they had no clue.
> 
> Maybe limit the length of route to 20 or 30 tiles?

  Or a very stupid code could be used - basically, the 'move to x,y code' 
doesn't look beyond one space.

  IT looks where the player currently is and figures out the best space to move 
to to get the player closer to the goal by basically using a direct line method. 
  Thus, such a goto x,y would probably avoid simple blockages, but not anything 
very tricky.


>>   Yes, but here are some other random thoughts:
>> 1) Player movement is perhaps to fast - with most all players moving about 1
>> space/tick, this obviously results in keeping in sync harder.
> 
> Slowing down players is a bad idea. Slower movement gives the
> impression of lag, as players see no notification that their character
> intends to move for a while. This is to do with the fact that
> movements in cf are quantum, and therefore there is no smooth
> transition when moving from tile to tile. Maybe one solution to that
> would be to make all tiles one pixel, and all objects into multi-tile
> things? Then speed up all movement speeds 30-fold or so, and maybe one
> day you end up with something with nice smooth movement, and
> appearance of no lag.

  One issue right now is very fast players are really very fast, and slow 
players are really very slow.  A player have a 1.5+ speed probably isn't that 
uncommon, but a slow player could have a 0.2 speed.

  I'd personally like to moderate those, so typical speed range is 0.25 to about 
0.75, with magic allow that extra speed, but perhaps still capping it at 1.0

  Splitting spaces into smaller pieces has been talked about before, but gets 
into other complicated/odd issues.  One of the big ones is objects still have to 
belong to a specific space - not an issue for object, but gets more complicated 
regarding players or monsters - if a player is moving onto a space (and say is 
0.4 there) and another monsters moves onto that space (0.6), the player can't 
move there anymore, but the placement could still appear odd.

  I think a major rewrite of the code would be needed to support partial/smooth 
movement.  To do it right, it isn't as much what space creatures are on, but 
rather, keeping a proper gap between monsters and player  (thus a player at 
24.5, 18 is fine if the monster is at 25.5, 18 as there is still that 1 space gap).


>> 3) Currently, the server processes all the objects/players, sleeps for 120 ms,
>> then does that again.
>>
>>   Lag could be reduced by some amount (average 60 ms) if we process data from
>> players immediately when it arrives.
> 
> This sounds like a great idea for reducing lag in low latency
> conditions, making cf pretty much real-time for the user. I think all
> the people playing on private servers will want this implemented.

  Yes, but it adds some complication.  On the bright side, it could have other 
nice effects.

> 
> Now if everyone could get a low latency connection... How about
> distributing the server? This is at the moment not viable to
> implement, but maybe some time in the future, could a number of
> servers in geographically distant points act as one super-server, and
> allow clients to join to any of them, and be part of the same world?
> They would only need to send updates from time to timeand only when
> several players (on different servers) are on the same map. Then they
> would need to solve issues like what random items resolve to, and what
> a state of a particular object is. Random map synchronisation would
> also be an issue.

  This has been talked about, but gets very complicated.

  It wouldn't be that hard to have these different servers take care of 
different parts of the world (server A does scorn, server B navar city, etc), 
and thus, as the player moves about, they automatically get transferred to 
different servers.

  But having two different servers handle the same area gets into all sorts of 
synchronization issues - the ones discussed above still apply (player on server 
1 moves to 5,5, and player on server 2 also moves there, but because the inter 
server lag is 500 ms, so each server thinks it is fine, etc).

  I'd say for the complication trying to handle that adds, it really isn't worth it.

  Another random thought:
Right now, the server processes player events as the player has time execute 
them, and processes them in sequential order.

  It adds some complication, but ideally it would be nice for the server to read 
all the pending commands from the client and see about executing some commands 
out of order.

  I'm not sure how this would work - it's almost like you would want to allow 
some handling of priority to the player (eg, the apply healing potion should be 
a top priority most likely).  But one could also envision a 'cancel' type 
command to ignore all the previous commands.

  Thus, if you're moving slow and do something like 'east, east, east, apply, 
east, say chain, ..'  and something interrupts that flow, you could hit the 
cancel but and it discards all the queued commands.

  that doesn't really help in lag, but does help on slow connections when 
something bad happens.