ID:2130532
 
Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
Now that pixel movements can glide with a higher client fps than the world fps, it's time to deprecate tiled movement.

Now, before you guys jump all up in my mangina about this idea, hear me out.

Pixel movement deprecated:

glide_size
animate_movement

Tile movement is super wonky with:

step_x
step_y
bound_x
bound_y
bound_width
bound_height
step_size

It seems to me that the decision to consider these two modes separate was the wrong decision. Instead, I propose that it would have been wiser to consider tiled movement mode a special type of pixel movement.

But stop and think for a minute, if pixel and tile movement were no longer separate world-wide modes, we could very easily* solve that problem as well as the problem of worlds kicking into pixel movement mode on accident because of a poorly placed line of code, or a silly map nudge.

We could stop thinking of pixel and tile movement as separate entirely with a small tweak:

1) glide_size should not be deprecated. Instead, it should affect the speed of pixel as well as tile glides according to the step size.

2) animate_movement should not be deprecated. Instead, it should gain a new flag (TILE_MOVEMENT (4)) that indicates whether a movable atom is a tile-based entity or a pixel entity.

Currently, the main distinction between pixel and tile movement is that collisions don't just happen at the tile bounds. This can cause movements to stop short and misalign from the grid on step coords != 0.

If we build gliding and tile-based movement behavior into the existing (deprecated) features of the language, we can essentially make tiled movement toggle-on per atom. When a movement that fails part-way is detected on a movable with TILE_MOVEMENT flags on in animate_movement, the movement will be normalized to a grid-aligned movement. If any change in coordinates occurs, the Move() will return successful.


Benefits:

* This would fulfill the long-standing feature request the SS13 guys have been fervently bumping regarding a specific mode-based toggle for pixel or tiled movement worldwide by simply considering the outer bounding pixels of any bounding box as filling the whole tile for any atom that uses TILE_MOVEMENT as a flag instead of a massive sweeping change to the language.

* This would also allow us to have more or less partial pixel movement very easily by setting glide_size to a specific value.

* This would also allow non-uniform pixel movements to be less jerky by implementing across-frame movement delays like we can in tiled movement mode, allowing for an overall better user experience.

* This would also allow pixel projectiles in a tile-based project.

* This would simplify quite a lot of the internal code for handling collision whosawhatsits.

* This would eliminate the split between pixel and tile movement code, where general developer tools have to target one or the other.

* This would better allow tile-based games to have pixel-movement based minigame sections or mechanics while still having "tile movement" for some parts of the game.
animate_movement=4 would be a difficult way to handle this, because the value of animate_movement is actually encoded in the appearance bitflags as a 2-bit value.

On the whole though I like the idea of being explicit about tile movement. I'll have to think about this some more.
Couldn't you simply set the number of pixels to traverse to equal the number of pixels per tile if you wanted tile based movement in a world using pixel movement?
That's what Dragon Universe has done. Step size is still 32 but pixel gliding looks so much better.

I just ensure that step_x and step_y will always be zero so that it never deviates from the tile it is on when bumping something offset from its tile
See, I've been thinking of moving in the opposite direction.
set animate movement to 0, stick to tile movement, and animate() pixel_x/y on move
In response to MrStonedOne
MrStonedOne wrote:
See, I've been thinking of moving in the opposite direction.
set animate movement to 0, stick to tile movement, and animate() pixel_x/y on move

I tried that, with client_fps it might work better than when I last tried. But before, it looked not so great. I should retry