Currently, a server detects whether it is in pixel/tile movement mode based on whether objects in the world have a step_size/bound_x/y/w/h setting that is not tile-aligned. This can be problematic due to accidentally kicking a world into pixel movement mode because you have an object in the map with a step_x/y value set, or if you want some objects to be able to move as though they were stuck to the grid like in tile movement mode.

This is largely due to the fact that when pixel movement was built into the engine, it was considered to be "tile-movement plus", instead of tile-movement being rightly seen as a subset of pixel movement with special rules.

Changing this behavior is hard because of the existing implementation and its effect on legacy games. However, I think we've managed to hammer out all the details so that this won't affect legacy projects at all:

world.movement_mode: possible values:

LEGACY_MOVEMENT_MODE (0) //Default value, all current behavior.
TILE_MOVEMENT_MODE (1) //Objects are not allowed to move off of the grid globally.
PIXEL_MOVEMENT_MODE (2) //Objects are allowed to move off of the grid globally.
MIXED_MOVEMENT_MODE (3) //Same as PIXEL_MOVEMENT_MODE, but allow the use of TILE_STEPS.

The default value being LEGACY_MOVEMENT_MODE would essentially disable the four changes that would need to be made to allow pixel movement / tile movement weirdness to go away once and for all:

glide_size de-deprecation

glide_size should be permitted in PIXEL_MOVEMENT_MODE, TILE_MOVEMENT_MODE, and MIXED_MOVEMENT_MODE to specify how many pixels an object is permitted to glide during a pixel, OR tile movement per frame. Making glides happen in either pixel or tile movement mode would bring this feature into compliance with all modes of movement, and make it much more intuitive to use as a whole. LEGACY_MOVEMENT_MODE would ignore this, making all pixel steps behave like they currently do, and only do client.fps-based gliding.

SYNC_STEPS de-deprecation

SYNC_STEPS is only useful in TILED_ICON_MAP, which is deprecated. Let's recycle the value for SYNC_STEPS when using MIXED_MOVEMENT_MODE, by defining another flag with the same value as SYNC_STEPS, and include a compiler warning when trying to use it in TILED_ICON_MAP format, or when using SYNCS_STEPS in MIXED_MOVEMENT_MODE format to prevent pollution of the two meanings. Let's call this new animate_movement flag "TILE_STEPS".

This animate_movement flag would mark an object as a tile-mover, when in MIXED_MOVEMENT_MODE. Essentially giving us a way to specify per-object, which objects are locked to the grid, or which objects are free from it. Discussion on grid-locking below:

Grid-locking:

* When the world, or object is grid-locked, it will fail to make changes to bounds, and step_x/y that do not amount to a perfect tile-sized offset. This will act as a check in the changing of an object's bounds, whether the object is loaded from a savefile, initialized from a prototype, or changed manually in code. This should prevent bad data from getting into the system.

* When a grid-locked object moves, the movement will attempt to step by a minimum of one tile's distance in the specified direction. If the movement fails due to a dense blockage that stops the object off-grid, the movement will back up to the last grid-aligned place that it could have stopped, regardless of obstacles it would now be overlapping in the process. Bump() should be called for the objects collided with normally, but Crossed()/Uncrossed() behavior should avoid being called on objects we once had to cross over in order to reach the obstacle, but ultimately were pushed away from.

Movement state considerations:

By allowing glide sizes and step sizes to play together, we can now use ceil(step_size/glide_size)*world.tick_lag to calculate exactly how long a a movement should take, and therefore, how many frames to leave the movement animation playing.