(Todo list for movement code rewrite) |
|||
Line 12: | Line 12: | ||
===Delayed reaction on Being::setDestination()=== | ===Delayed reaction on Being::setDestination()=== | ||
Another problem is that when setting a new destination while the being is already moving along a path does not | Another problem is that when setting a new destination while the being is already moving along a path does not cancel the move immediately but only after the next tile of the path has been reached. | ||
==Server== | ==Server== |
Revision as of 14:22, 11 August 2008
Todo list for movement code rewrite
Client
Coordinate system messup
The position of a being is stored in the being class with different systems: Pixel coordinates, Tile+Offset coordinates, pixel coordinates of the center of the tile etc.
Some are not encapsulated properly and poorly named.
The client should use only pixel coordinates internally (stored in two protected unsigned integers) whenever possible. When the tile coordinates are needed (The only situations I could think of are route finding and path blocking) it should be done by getting the pixel coordinates and dividing them by 32 (the compiler will optimize this by substituting it with a very fast bitwise shift)
Delayed reaction on Being::setDestination()
Another problem is that when setting a new destination while the being is already moving along a path does not cancel the move immediately but only after the next tile of the path has been reached.
Server
unnecessary abstraction
Currently the server allows to move on the same tile for free. I can't see any good reason for this when we want pixel-accurate gameplay but a lot of possibilities for bugs which can be introduced by this.