trevor wrote:Although an admirable idea, it still suffers from the problem of slowing down over time. I expect the size estimates are a bit low (there's a lot more than 8 directions
).
Not from a single square. And all movement happens by exiting a single square and moving to a new one. If the movement continues in the same 1-of-8 directions, it creates a single vector, but if the 1-of-8 direction should change, a new vector entry is started. Add up a bunch of segments and you get the full movement.
Basically, if a creature were to move 8 squares horizontally and 3 squares vertically, there would be 5 or 6 vectors, depending on how each portion of the move was broken down. In any case, that's 12 bytes if the values are packed into 16-bit
shorts. And vectors don't have the problem of specifying absolute grid coordinates who values are essentially unbounded and hence could eventually overflow any chosen data type.
It probably doesn't matter, though. Assuming that whatever format is used allows for a 16-bit value to represent some segment of movement, it would require a thousand segments to see a noticeable drag (0.5 seconds) on a 56K dial-up connection.
