Well, i did not play with smooth movement, but according to what i know, deciding *when* in the movement the player is on next square has never been the major issue. Major issues are, i think:
1) All drawing code on client assume a per square position, not half positions of character, need a very big redo on drawing routines 2) All server assume objects on a square, need additionnal code to manage transitions between square of objects. This is not trivial! Espcially for monster following character. The can't go on a square until player left it. however if at moment of tick player is 30% away, monster can't follow the player because square still in use. Also, what happen if after 30% movement destination square is now blocked? Rollback? Will end in graphical artefact, you need a 'reseration' systemn when you start movement, but then this may end in technically player using 2 squares at a time when moving. 3) protocol was never made to send partial positions. Your suggestion just resolve some trivial question on when do player is in a square, this is trivial imho. Deep problems are above :) Lalo Martins a écrit : > Ok, I searched for the original thread to ressurect it, but > couldn't find it, so here goes a new one. > > A few weeks ago, when Mark started talking about his new movement > code, there was some talk about "smoothing" movement - drawing the > image in partial locations between tiles, so that movement doesn't > look so jerky. > > The problem is that everything happens in a tick-based timeframe, > so until you move, there's no way to be sure where you will be next > turn; and starting "smooth" movement only after you already moved > would be worse, because for some time, you would seem to be in one > tile while you're actually already on the next one (if "you" are a > monster, this would cause players to shoot at the wrong tile). > > End summary. > > Now, the solution to this came to me two days ago just before > sleep. I'm surprised nobody came up with it before. Although it > has *serious* implications - it changes drastically the way the > game works - but then it means it's the best time to introduce it > now, together with Mark's other changes. And I think it's a > tangible improvement. > > Basically, it consists on accepting "input" (whether it's actual > input from the user, or a decision from the monster AI code) at a > point in time half a tick before when the object actually gets its > tick. Think of that as neural impulse delay. > > So, assuming the character was still then moves south, and its > speeed is such that it gets one tick at each T (T being global > ticks): > > Time | input | face position | actual > position > ------------------------------------------------------------------------- > T | - | X,Y | X,Y T+5 > | move south | X,Y | X,Y T+6 | - > | X,Y+0.1 | X,Y T+7 | - | > X,Y+0.2 | X,Y T+8 | - | > X,Y+0.3 | X,Y T+9 | - | > X,Y+0.4 | X,Y T+10 | - | > X,Y+0.5 | X,Y+1 (TICK) | > (exactly on the line b/w tiles) | T+11 | - | X,Y+0.6 > | X,Y+1 T+12 | - | X,Y+0.7 | > X,Y+1 T+13 | - | X,Y+0.8 | > X,Y+1 T+14 | - | X,Y+0.9 | > X,Y+1 T+15 | move south | X,Y+1 | > X,Y+1 T+16 | - | X,Y+1.1 | > X,Y+1 ... > > In a future version, this logic could also be useful for > weapon-swing animations, attack sounds, etc etc. > > Does that make sense? > > best, Lalo Martins -- So many of our dreams at first seem > impossible, then they seem improbable, and then, when we summon the > will, they soon become inevitable. -- http://www.exoweb.net/ > mailto:[EMAIL PROTECTED] GNU: never give up freedom > http://www.gnu.org/ > > > _______________________________________________ crossfire mailing > list [email protected] > http://mailman.metalforge.org/mailman/listinfo/crossfire > _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
