[crossfire] Lag

[Anton Oussik]

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.

> >
> > 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.

I like that idea.

>   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.

>   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?


> > 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.

Sounds like a good idea, but complicated.

> > 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.

Runescape and AO work wel over my connection...

>   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.

> 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.

I'm sure pet code could be used for that...

> 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.

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.