Pixel movement: side-stepping obstacles

Page: 1 2
May 4 2012, 8:54 am
In response to SuperAntx
Wow, that looks much better than I expected. I stand corrected :)

I think making it shift by step_size, and having the "correction" take multiple frames really helps make it look more smooth.
May 4 2012, 9:10 am
In response to SuperAntx
SuperAntx wrote:
I plugged FA's code into Simple Move and tweaked a few things. It works pretty well.

Out of curiosity, how long did it take you add to the library? I checked the file creation/update times and it took me 7 minutes to write the code. Clearly this was a huge issue that the BYOND staff must resolve for us.

The only tweaks I had to do was change the bumping distance to the player's movement speed, it looks more natural that way. I also prevented the sliding from activating while moving diagonally.

I'm not sure if this would work or make sense for diagonal movement (BYOND doesn't handle diagonal movement well anyway). I figured it might work to call the code twice if you're moving on an angle (once for each component direction of your move) but I didn't try it. As long as you're not using BYOND's default movement and you slide along obstacles when you're moving diagonally, this feature isn't really needed for diagonal moves.

DarkCampainger wrote:
I think making it shift by step_size, and having the "correction" take multiple frames really helps make it look more smooth.

I think Falacy was asking to have it move you to the side and around the object, which may look strange because you'd be moving extra pixels. This just moves you to the side and you'll naturally move around the object when you've moved far enough to the side, so you're never moving further than you should.
May 4 2012, 9:17 am
In response to Forum_account
Forum_account wrote:
Out of curiosity, how long did it take you add to the library?

Four minutes? It took longer to zip up and figure out a place to upload it than it did to integrate the code.

I disabled the bumping for diagonal movement because it caused the player to suddenly increase in speed. Say you're moving northeast 4 pixels, hit a wall on your right, the wall initiates sliding, suddenly you move north another 4 pixels. Simple Move already has diagonals split into two cardinal steps in order to have players slide along walls. If you walk into a big wall diagonally you get "stuck" to it.
May 4 2012, 9:23 am (Edited on May 4 2012, 9:34 am)
In response to Forum_account
Forum_account wrote:
Clearly this was a huge issue that the BYOND staff must resolve for us.
If anything, everyone's amazement at a simple application of your half functional attempt just goes to further prove that this should be a fully supported built-in default.

I think Falacy was asking to have it move you to the side and around the object
I wasn't.

so you're never moving further than you should.
Only because all of the tiles in that demo are perfectly aligned, and your movement size is a simple multiple. Which is hardly going to be the case in any properly developed pixel movement based game. Simply change the step_size in that demo from 4 to 6 and you can easily see one problem that I mentioned earlier; when attempting to walk through a single tile gap you spaz out and get stuck moving back and forth, instead of into the gap.

EDIT: You can also "walk" on top of walls in some cases with that setup, since you are directly offsetting step_x/y (another problem that I brought up in the previous posts).
May 4 2012, 9:23 am
Whoa, three minutes. That puts us into double digits.

SuperAntx wrote:
I disabled the bumping for diagonal movement because it caused the player to suddenly increase in speed. Say you're moving northeast 4 pixels, hit a wall on your right, the wall initiates sliding, suddenly you move north another 4 pixels.

Yeah, that makes sense. The library's sliding already handles this case. You'd only need to handle it if the mob's bounding box could be rotated 45 degrees.
May 4 2012, 9:33 am (Edited on May 4 2012, 9:39 am)
In response to Falacy
Falacy wrote:
Only because all of the tiles in that demo are perfectly aligned, and your movement size is a simple multiple. Which is hardly going to be the case in any properly developed pixel movement based game.

Could you really call a game which doesn't take the limitations of its engine into account for its game design properly developed?

Simply change the step_size in that demo from 4 to 6 and you can easily see one problem that I mentioned earlier, when attempting to walk through a single tile gap (you spaz out and get stuck moving back and forth, instead of into the gap).

What you could do is divide the sliding step size by two when nudging the player over. I went and tried it and I actually think it looks a little better than moving them at full speed. Though, I guess to really fix this bug it's going to need a way to position the player just one pixel past its bounding box when sliding them to the side.
May 4 2012, 9:39 am
In response to SuperAntx
SuperAntx wrote:
Could you really call a game which doesn't take the limitations of its engine into account for its game design properly developed?
First off, random pixel offsets on objects in a pixel movement game are in no way beyond the limits of a BYOND game. If anything, they should be considered the standard now that pixel movement is built in. However, pushing the limits of the engine is what I would consider proper development. Just because BYOND never supported on-screen text, HUDs, interfaces, macros, pixel movement, whatever else in the past - it doesn't mean any of the games designed within those limits were doing it right.

What you could do is divide the sliding step size by two when nudging the player over. I went and tried it and I actually think it looks a little better than moving them at full speed.
You could, and I probably would. Actually, I would just have a separate variable for that to begin with. But that doesn't fix the problem anyway.
May 4 2012, 10:49 am
I think the terminology has gotten bungled here. I would say sliding refers to the diagonal movement where you slide along an obstructed edge in the unobstructed direction. Stepping around an obstacle when moving in a cardinal direction would be a sidestep.
May 4 2012, 10:50 am
SuperAntx wrote:
What you could do is divide the sliding step size by two when nudging the player over. I went and tried it and I actually think it looks a little better than moving them at full speed. Though, I guess to really fix this bug it's going to need a way to position the player just one pixel past its bounding box when sliding them to the side.

That's probably more than sufficient. The solution is to create maps where there aren't such tight spaces the player has to navigate through. With BYOND's rigid system where you move the number of pixels determined by step_size with every step it's easier to create situations like that, but this is quite a roundabout way to avoid the problems created by that.

You can also modify the front_left and front_right procs to return the number of pixels that you'd need to shift to get around the obstacle and use that to adjust the value you pass to the shift_left/right procs.
May 4 2012, 10:57 am
In response to Lummox JR
Lummox JR wrote:
I would say sliding refers to the diagonal movement where you slide along an obstructed edge in the unobstructed direction.
That issue could be resolved by fixing BYOND's failure to take multiple key inputs at once. If you can hold up and right to move "norhteast" (which is technically a step north then east) this issue would pretty much resolve itself, as well as making controls generally better in the process.

Stepping around an obstacle when moving in a cardinal direction would be a sidestep.
Side-step is what this request is for


Forum_account wrote:
The solution is to create maps where there aren't such tight spaces the player has to navigate through.
That's not a solution, that's a poor design decision in an attempt to avoid a missing feature.

With BYOND's rigid system where you move the number of pixels determined by step_size with every step
If your step size is 8, and there is a random object 3 pixels in front of you, you will only move 3 pixels. This could essentially offset your entire "grid" layout for the rest of the game if you build around that.
May 4 2012, 11:05 am
In response to Falacy
Falacy wrote:
That issue could be resolved by fixing BYOND's failure to take multiple key inputs at once. If you can hold up and right to move "norhteast" (which is technically a step north then east) this issue would pretty much resolve itself, as well as making controls generally better in the process.

BYOND's method of having you stop moving when stepping diagonally into a solid is technically correct. You aren't moving north or east, you are moving northeast into a solid so it's going to treat it like a wall and stop you from moving. If you want to avoid that behavior just split diagonal steps into two cardinal steps and you're fine.

That's not a solution, that's a poor design decision in an attempt to avoid a missing feature.

I agree with this, you may want secret passages and whatnot which have tiny openings. The correct solution would be to sidestep the player just as many pixels as they need to walk past the wall.
May 4 2012, 11:08 am
In response to SuperAntx
SuperAntx wrote:
BYOND's method of having you stop moving when stepping diagonally into a solid is technically correct. You aren't moving north or east, you are moving northeast into a solid so it's going to treat it like a wall and stop you from moving. If you want to avoid that behavior just split diagonal steps into two cardinal steps and you're fine.

Isn't that what I said? The problem is that BYOND's default control scheme is horrible. In most cases, there shouldn't be diagonal movement to begin with, especially not clunkily mapped to the numpad. Because BYOND can only take 1 key input at a time, if you are holding UP, and then hold RIGHT, you will stop moving up, and instead move right. This is not what should happen, you should move both up and right, not diagonally, but north and then east.

You can create loops to handle movement, which are more effective and efficient in pretty much every way, especially with pixel movement, but almost no games do this as far as I know (aside from my own).
May 4 2012, 11:11 am
Clearly BYOND should come pre-installed with Simple Move.
May 4 2012, 11:12 am
In response to SuperAntx
SuperAntx wrote:
Clearly BYOND should come pre-installed with Simple Move.

Pretty much. If they don't want to build all of this stuff themselves, then they should just setup official built-in library support.
May 4 2012, 11:20 am
In response to Falacy
Falacy wrote:
Lummox JR wrote:
I would say sliding refers to the diagonal movement where you slide along an obstructed edge in the unobstructed direction.
That issue could be resolved by fixing BYOND's failure to take multiple key inputs at once. If you can hold up and right to move "norhteast" (which is technically a step north then east) this issue would pretty much resolve itself, as well as making controls generally better in the process.

I was simply referring to terminology, not whether the behavior is "right" or not. As a default I don't think stopping diagonal movement is any better or worse than sliding; sliding is certainly intuitive, but not sliding could be intuitive for many cases as well.

Stepping around an obstacle when moving in a cardinal direction would be a sidestep.
Side-step is what this request is for

Not to nitpick overly, but I would have called it "Pixel movement: step around obstacles" or something for clarity.

Forum_account wrote:
The solution is to create maps where there aren't such tight spaces the player has to navigate through.
That's not a solution, that's a poor design decision in an attempt to avoid a missing feature.

With BYOND's rigid system where you move the number of pixels determined by step_size with every step
If your step size is 8, and there is a random object 3 pixels in front of you, you will only move 3 pixels. This could essentially offset your entire "grid" layout for the rest of the game if you build around that.

I would argue that in most cases stopping at the 3-pixel point would be correct behavior. For objects you could push, maybe that's not quite right, but it's otherwise sound in most cases. Going "off-grid" is part of the point of pixel movement in the first place anyway; narrow openings presenting a problem would tend to be more of a failure on the game designer's part, but might in some cases actually be used as a challenge to the player (i.e., much like jumping challenges in 2D platformers tend to require precision).

Mind you I am in agreement that sidestepping would be useful to support, or at least have some more built-in routines to allow you to implement it more easily. I do not agree it should be the default; I can see too many cases where that'd be considered a poor choice, and I dislike the idea of objs and mobs having different behavior in this (as I'm sure Tom would as well).

From what I've seen, sliding is relatively easy to implement in soft code, sidestepping less so.
May 4 2012, 11:32 am
In response to Lummox JR
Lummox JR wrote:
I was simply referring to terminology, not whether the behavior is "right" or not. As a default I don't think stopping diagonal movement is any better or worse than sliding; sliding is certainly intuitive, but not sliding could be intuitive for many cases as well.
Again, it is not even a case of true "diagonal" movement. If you are moving north and then east, when you walk into a wall to your north, you will just naturally continue along to the east.

Not to nitpick overly, but I would have called it "Pixel movement: step around obstacles" or something for clarity.
Edited the first post

I would argue that in most cases stopping at the 3-pixel point would be correct behavior. For objects you could push, maybe that's not quite right, but it's otherwise sound in most cases. Going "off-grid" is part of the point of pixel movement in the first place anyway
I was saying that was the correct behavior

narrow openings presenting a problem would tend to be more of a failure on the game designer's part, but might in some cases actually be used as a challenge to the player (i.e., much like jumping challenges in 2D platformers tend to require precision).
Jumping puzzles may require precision and skill, but walking down a hallway or into a doorway shouldn't be challenging to the player.

I do not agree it should be the default; I can see too many cases where that'd be considered a poor choice
It would just be a few extra lines in the default pixel movement code file that is already created.

and I dislike the idea of objs and mobs having different behavior in this (as I'm sure Tom would as well).
They wouldn't behave any differently than say the density=0 setting on objs vs the density=1 for mobs.
May 4 2012, 4:28 pm
In response to Lummox JR
Lummox JR wrote:
From what I've seen, sliding is relatively easy to implement in soft code, sidestepping less so.

Both are easy. Sliding is easy though breaking a diagonal move into its component moves isn't exactly correct. It's easy to get an implementation that is likely to be sufficient. Side stepping takes a little more work, but there's not much that BYOND could provide to make it easier. I posted the code for it earlier in this thread and while obounds can get a little confusing, I can't think of a way to change it that'd make this any easier.
Page: 1 2