Allegro.cc - Online Community

Allegro.cc Forums » Game Design & Concepts » Sliding Along Solid Walls

This thread is locked; no one can reply to it. rss feed Print
Sliding Along Solid Walls
Kris Asick
Member #1,424
July 2001

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.

--- Kris Asick (Gemini)
--- http://www.pixelships.com

Schyfis
Member #9,752
May 2008
avatar

"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.

________________________________________________________________________________________________________
[freedwill.us]
[unTied Games]

SiegeLord
Member #7,827
October 2006
avatar

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...).

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Sirocco
Member #88
April 2000
avatar

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.

-->
Graphic file formats used to fascinate me, but now I find them rather satanic.

Kris Asick
Member #1,424
July 2001

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. ;)

--- Kris Asick (Gemini)
--- http://www.pixelships.com

Todd Cope
Member #998
November 2000
avatar

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
Member #7,827
October 2006
avatar

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.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

james_lohr
Member #1,947
February 2002

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
Member #12,254
September 2010

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.

Programming should be fun. That's why I hate Java.

Kris Asick
Member #1,424
July 2001

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-)

--- Kris Asick (Gemini)
--- http://www.pixelships.com

Go to: