> 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. > >Does that make sense?
It does. But I think that's just the first issue of the whole problem, and not the most complex one to solve, unfortunately. The first issue is with the protocol itself. Currently, the server basically sends the client a "gird of objects" that are strictly square-positioned. What about the "transitioning" objects (those who are in the middle of a move, at a position like (X+0.3;Y)) ? Two solutions: - Either you do not strictly synchronize the client with the server. You just send the same messages that are currently sent (thus no "transitioning" marker of any sort), let the client compute the supposed position of the character and backtrack if necessary when the server sends the next map update. You'll have to face synchronization problems at some point, obviously. - Or you include synchronization messages in the protocol - but then, you'll have to make drastic changes to it, which will require a complete redo on the redrawing side of the client. The second issue that's not really adressed is about what I call the "square conflict problem". Suppose that your character attempts to move on a square S, but that a monster attempts exactly the same thing. With the current square-by-square gaming system, there's no problem: the faster one is moved on the square. Now, with a smooth move system, it means that you'll see one character being suddenly stopped at the edge of S, while the other is moving into it. It could lead to the rather strange situation of a character being hit by a monster that's not even right against you. I think that the question of knowing where the character is on the map while transitioning is a rather simple one; I see the major issues more in the client/server sync and with the current communication protocol, which doesn't seem to be easily adaptable to handle a "smooth moves" situation. _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
