Sliding Along Solid Walls
Kris Asick

So in getting my latest public alpha of Vectorzone ready, one thing I had a surprisingly large amount of trouble with was the collision detection.

The idea is that if the player hits a wall, they will slide along it, just like in virtually any first-person game. Even after coding the heck out of the routine that figures this all out though it still isn't perfect and glitches up when dealing with isolated single tiles. >:(

I'm wondering if anyone has any advice on creating such a system so that the player, from an overhead view, will slide along the walls they collide with.

Schyfis

"Sliding" along walls isn't typically a result of the programmers implementing routines to specifically make the player slide along walls if they run into them. It's a result of collision resolution.

If the player collides with a wall, push him out in the direction of smallest penetration into the wall.
I highly recommend Metanet's tutorials on the separating axis theorem for collision detection and resolution, as well as the presentation they made regarding it. The theorem can also be extended to 3D, if your game is 3D.

SiegeLord

In my tile based TINS entry I did sliding by simply moving the object in the direction of it's velocity, but then preventing movement that would put the object inside a wall. It worked reasonably well (but not without bugs...).

Sirocco

What I'd normally do is base the movement off a vector system, then do a check against the world state when it was time for the object to make another move. Check each vector component separately, and anything that leads you into a barrier halts progress in that direction. Voila! Sliding goodness.

Edit:

Yeah, what SiegeLord said. That'll teach me to read before posting. Or not.

Kris Asick

That's actually what I do presently. The problem I've run into though is dealing with hitting the corners of single tiles.

As it stands, the system uses various methods in sequence to determine what to do in a corner-impact scenario. The trouble is that these methods conflict with hitting single tiles from a side impact.

...now that I think about it, that might be the solution. Only scan for single tile considerations on the corners of the ship, rather than the ship as a whole... which means more variables and more if statements. :P

But hey, if it works... I'll try that out later tonight and let you guys know. :)

EDIT: *faceplam* ::)

...OK THEN. So I figured out how to not only greatly simplify my collision detection routines, but also made them flawless in the process. The solution... was to simply move and scan for horizontal and vertical collisions separately.

The way it works now is that the ship first moves along one axis, collision is scanned and pushing out of the tiles is performed as necessary, then the ship moves along the other axis, scans and pushes as necessary.

I also managed to transform four pages of movement and collision code into two pages.

*shakes head* I knew there had to be a simple solution to my problem. I couldn't for the life of me believe that map collisions were as complicated as my code made them out to be. ;)

Todd Cope

I use precalculated collision objects which divide each side of the object into a set of points with the space in between those points being <= the tile size. This allows me to check collisions of arbitrarily sized objects against the map for collisions, as I can just loop through all the points on whichever side I want to check.

When I move my object, I move it on each axis individually as Sirocco suggested, checking to see if it has passed over a solid tile border. If the object has crossed into a solid tile, I push the object back to the edge of the tile it collided with.

Edit: Too slow. Seems you've figured it out on your own.

SiegeLord

The solution... was to simply move and scan for horizontal and vertical collisions separately.

This doesn't seem like it'd work in a general case. E.g. if there's a gap that can only be traversed by moving diagonally, but not by first moving horizontally and then moving vertically, this way would make your character stuck.

james_lohr
Schyfis said:

..isn't typically a result of the programmers implementing routines to specifically...

Dunno what type of programming you do, but when I code stuff it does exactly what I intend it to. :P

Luiji99

He means that the feature is a byproduct of different features, and thus isn't implemented in its own right. I've found this situation, too. Basically, while moving in the X and Y directions, when something is in the way in the X direction you still automatically move in the Y direction (unless you have some really screwed up code), hence giving you the sliding effect.

Kris Asick
SiegeLord said:

The solution... was to simply move and scan for horizontal and vertical collisions separately.

This doesn't seem like it'd work in a general case. E.g. if there's a gap that can only be traversed by moving diagonally, but not by first moving horizontally and then moving vertically, this way would make your character stuck.

Actually, I'm intentionally designing the size of all objects to be between tile size multiples. Each tile is 16x16, so nothing will ever have size definitions of 16, 32, 48, 64, etc. The player is set to 56, even though the player sprite is larger. Combined with a lack of sloped tiles, this means there will never be a situation where diagonal movement is the only way to pass through something. ;)

I've already tested this by shooting out the appropriate walls to create a diagonal-only situation and trying to squeeze through. Works perfectly fine. 8-)

Thread #611302. Printed from Allegro.cc