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 <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. _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
