[crossfire] Lag

[Mark Wedel]

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.

> 
> One thing that might work for this, is something I have been idling
> toying with concerning movement.
> 
> I was looking a few weeks ago at adding a 'goto' command so that the
> player could send a command goto <x><y> (relative to the player) and
> then, as long as they had no further commands sent, they would go
> towards that point. (in terms of controls, this would map to clicking
> on the map view somewhere). - the stupid implementation of this is
> quite straightforward, getting the routing to work properly is harder.

  I'd think the straightforward approach would be a good first step.  Routing is 
more difficult, but there is already code that monsters use for this type of thing.

  IF anything, using that same code for players would just be a good thing - it 
would probably mean that code would become better as players would see actual 
bad routing issues.

  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.

  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.

> 
> In any case if that became the defacto standard way of moving (as it
> is in most graphical RPGs), then it would be possible to figure out
> what route the player would take, and send the moves they would make
> to the other players in the room early. - this would still lead to the
> ocassional de-sync issue (when they change direction, or something
> moves in the way) but it would be a noticable improvement over what is
> currently there. (the extension to that would be to have an attackto
> command (or a flag to goto) so that monsters could be targeted to get
> the player to follow them and attack when they are in range. -
> probably such advance telling of commands should only occur if the
> ping time is bigger than the tick time though.

  I think goto would be very good - simply if when loaded down and heading to a 
shop that is going to take moment, being able to click it and have your 
character end up there is certainly more convenient than having to hit the run 
in that direction.

> 
> In general though, if your ping time is over a second, you need a
> better internet connection, most games are difficult to play when you
> are that laggy.

  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.

2) A 'follow <x>' command could be added such that you follow player <x>.  Maybe 
just allow it in parties, with commands like 'lead party' and 'follow party'. 
Everyone who did 'follow' follows the 'lead'er.  The leader would automatically 
slow down as needed so as not to get too far ahead.

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.

  However, this only helps out in cases where the player is idle (basically has 
an action to use).  If you're running, it won't make a difference - in that 
case, the code will look for commands from the socket before it has the players 
character do anything, so there is the entire 120ms for that to arrive.


> 
> _______________________________________________
> crossfire mailing list
> crossfire at metalforge.org
> http://mailman.metalforge.org/mailman/listinfo/crossfire