Complaint: Pixel Movement

ID:829216
 
Jun 22 2012, 3:50 pm
When the pixel movement mechanic was introduced, I thought it was an optional thing for new games. A new capability for BYOND, nothing more.

Recently, however, we(BS12) have been experiencing problems where our entire server would switch to abrupt, roguelike movement. We quickly figured out that it had to do with the pixel movement system and that it's sufficient that only one object's step_x is modified, to screw up the entire game.

I looked for a solution. Some way to tell the game that no matter what, we want tile-based movement. Instead I only found:

Gliding is a "glitz" effect applied by BYOND to > cover up the visual sins of tile-based
movement, by making objects and the map appear
to move smoothly from one tile to another
instead of immediately jumping. Because pixel
movement is now an option, gliding is
deprecated; it is supported for legacy projects.

What?! Do you mean to say that if I want to make a tile-based game, that's a "legacy project"? Maybe I'm completely misunderstanding here, and there's a perfectly easy way to make a tile-based game with the pixel movement system. But if so, it is not being made clear enough.

I don't see why the whole tile-based system should be deprecated. It's simple. It's efficient. It makes for games that are robust to any kind of lag. Most importantly, it is inherent part of game-design and game-mechanics, not just a visual effect.

Many games on BYOND are tile-based. These games should not be viewed as deprecated or "legacy". They should be viewed as one type of game you can make with BYOND, and pixel-movement games as another. That's all.
Jun 22 2012, 4:01 pm
Can you explain exactly what "abrupt, roguelike movement" is?
Jun 22 2012, 4:03 pm
When it was first introduced, pixel movement was a per-object thing. They changed it since, and I forget why.

Can't you put some of your own effort into preventing any pixel variables from being changed?

step_x/y, bound_x/y, bound_width/height, bounds, step_size. I think those are the only variables you should make sure aren't being changed.
Jun 22 2012, 4:03 pm
In old BYOND terms: A pixel_step_size of 32. There's no gliding animation, you just pop from one tile into the other.
Jun 22 2012, 4:53 pm
I'm a little confused by this, as my game presently does, and always has, displayed the gliding animation despite being tiled-based in nature ( moving in 32 pixel blocks. )

world
    icon_size = 32
mob 
    step_size = 32
Jun 22 2012, 4:58 pm
In response to Deathguard
Pixel movement only happens when at least one of the pixel movement variables are different from default. It explains everything pretty clearly in the reference.
Jun 22 2012, 8:30 pm
In response to Kaiochao
I think you can also get away with changing a few of them (such as bounds) so long as it's done in multiples of world.icon_size. Unless they changed that recently...
Jun 22 2012, 9:21 pm
In response to DarkCampainger
Oh, that's correct. Still, there probably needs to be a better way of handling gliding and pixel movement. What I'd prefer, but would break all past projects, is make pixel-movement the only way but have built-in (and client-sided) procedures to do gliding (or have Forum_account just make us a "Tile Movement" library).
Jun 23 2012, 2:13 am
In response to Kaiochao
I'm aware of this. Also, I have object/step_size set to 8 or 16, I don't recall which.

Still. Mobs glide around in tile increments just like they should; I simply don't have the OP's problem.
Jun 23 2012, 7:16 am
CIB wrote:
We quickly figured out that it had to do with the pixel movement system and that it's sufficient that only one object's step_x is modified, to screw up the entire game.

So don't change an object's step_x var. It's not ideal, but if you search your code for "step_x" it should be pretty easy to make sure you're never changing it.

Still, I agree that the staff didn't handle this well. They were pressured into thinking that pixel movement was better and it's not - it's just different*. There are plenty of uses for tile-based movement and even some cases where you'd want to have tile-based movement and pixel-based movement in the same project (suppose you create a menu using turfs and want to move the cursor a tile at a time and have it glide, but then the game uses pixel movement).

* It actually looks a little worse. Tile-based movement with a world.fps above 20 looks better than BYOND's pixel-based movement because or how jerky it looks.

It doesn't make sense to have the movement behavior of all objects determined by a single object's variable. You might get some strange behavior if you mix tile-based and pixel-based movement but that's the developer's problem. If they want all objects to have to use the same movement scheme there should be a world var to determine which scheme is used, that way the developer has direct control over it.