[crossfire] Lag
When a player moves, there is currently a delay of one round trip until anything starts happening. Whilst for most modern Internet connections this does not pose a significant problem, when interacting with other players the lag seems to accumulate. They have 900ms lag, I have 1200ms lag, now between us we suddenly have 2100ms lag. Since a player can cover many tiles in 2100ms, it becomes very difficult to keep track of any other player when travelling, and in general to coordiante with others successfuly. This limits the useful multiplayernes of crossfire. Parties 5-6 players in size start to fall apart as players can not keep track of each other. Similar problems exist for persise stopping of movement. Laggy connections tend to make you overrun your destination. For example if I am running, and want to stop, it will take another 3-4 screens (at 20x20 tiles) before I come to a halt. 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? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Lag
On 1/26/06, Anton Oussik <[EMAIL PROTECTED]> 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? 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 (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. 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. 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. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Lag
Brendan Lally wrote: > On 1/26/06, Anton Oussik <[EMAIL PROTECTED]> 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 (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 ' command could be added such that you follow player . 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@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Lag
On 26/01/06, Mark Wedel <[EMAIL PROTECTED]> wrote: > Brendan Lally wrote: > > On 1/26/06, Anton Oussik <[EMAIL PROTECTED]> 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 (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 ' command could be added such that you follow player . > 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
Re: [crossfire] Lag
Anton Oussik wrote: > On 26/01/06, Mark Wedel <[EMAIL PROTECTED]> wrote: >> Brendan Lally wrote: >>> On 1/26/06, Anton Oussik <[EMAIL PROTECTED]> 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 othe
