player collision issues

[Anonymous]

This problem seems to be pretty well known and I'm sure my question has been asked a million times, but what the hey.

Is there anything that can be done to make collision detection function properly when using a player sprite which is larger than your collision layer tiles? I understand the problem, just wondering if there are any clever work arounds.

Against all odds I attempted making my game like this, and it's the #1 most annoying feature to watch play testers jump through floors and exploit your game.  

-Zindel-

[bluemonkmn]

It's all in the level design.  I can't think of any quick fix (unless you call this a quick fix).  You just have to design your levels so that there are no areas with solidity that allows the player sprite to move where you don't want it to, taking into account the fact that only the corners are being checked.  You shouldn't be able to jump through floors anyway, though, unless you approached the floor from the narrow end and straddled it first.  You just have to make sure that all your narrow surfaces have "fat ends" so that the player can't straddle them on the approach.  If the player can't straddle the narrow walls' tips, there shouldn't be any other problem with tiles being smaller than sprites.

[Anonymous]

Unfortunately that solution limits the various types of jumping puzzles im using. If I double the collision the player would need to jump higher, he would hit his head on platforms above and never make the spanning jumps, or the player could exploit new areas.

The straddle problem is the only problem I have. What is more weird is, it's worse going from left to right than vise versa.

Would be nice if your character sprites could have 2 additional points

.  .
.  .
.  .

[bluemonkmn]

You don't have to make everything twice as thick, just the ends (not sure if that helps).  Here's an illustration:

Old map

Code: [Select]


        /XXXX
    /XXXX


XXXXXXXXXXXXXXXX


New version

Code: [Select]


        /XXXX
    /XXXX  XX
    XX

XXXXXXXXXXXXXXXX
XX            XX


Notice that the extra blocks hanging down on the ends doesn't take the whole length of the platform, just enough to stop the player from straddling the end.

Indeed there may be a problem if your platform was too close to the ground (as shown above) and the player can't get through underneath any more.  But like I said, there's no quick fix for this.  You might just have to space out the level a bit or solve each problem a little differently:

New version 2

Code: [Select]


        /XXXX
    /XXXX  XX
    XX

XX\       /XXXX
XXXXXXXXXXX  XX


[bluemonkmn]

On the other hand, maybe there is a quick fix involving scripting, depending on your other requirements.

1) Change your player sprite to be half as tall and only contain the player's bottom half.
2) Create a new "Scripted" or "Inert" type sprite representing the player's top half
3) In the Player_OnAfterMoveSprites event, move the scripted sprite to be right above the player sprite, and set the state to match the state of the lower half (facing left or right).

Some drawbacks to this approach: Collisions involving the top half of the player will have to be handled separately if they are required.  The player will be able to walk though anything so long as his lower half can fit.

[Anonymous]

I've thought about all the possible solutions including splitting the sprite into two halves. I guess what I'm wondering is, can you change the program or somehow script more than just 4 corners for a player sprite? Also, the problem is inconsistant.

1. It only happens between a sprite and a tile. Two sprites of different sizes don't apear to have this problem.

2. It only happens when moving from left to right.

If it wasn't too late in the game I could redesign, but it would be a total redesign, as many of the jumping puzzles wouldn't work the same.

[bluemonkmn]

The collision detection between sprites is completely different than the collision detection between a sprite and a tile.  So that's why you're observing that difference.

I was quite suspicious at the belief that it behaved differently when moving from left to right than it did from right to left.  So I tried it myself, and you are indeed correct.  There is still a problem moving from right to left, but it's not as severe as when moving from left to right in a game where there's gravity because the code apparently forces the player to go "uphill" when you're moving from left to right when straddling a solid, but not when you're going from right to left.  The complexity of the function that handles interactions between sprites and tile solidity has evolved beyond my ability to maintain it over the decade that I've been working on it (this piece of code evolved from code that existed long before the kit itself), but I noticed that it wasn't symmetric.  When I added the symmetry I was able to at least get it to behave the same going from left to right as it does from right to left.  Unfortunately, I don't know if code modifications are going to help you at this point unless you want to compile your own GDPlay for your project.  In case you do want to do that, I will describe the fix:
In the Sprite.cls file there is a function called "ReactToSolid".  In there is a block of code that begins with "Do While (DX > 0) And _".  Inside that block of code you will find code similar to what I've shown below.  But the code below has some modifications to make it symmetrical so that moving left to right will work the same way moving right to left does.

Code: [Select]

       ' Check uphill (rightward) stuff
        If rDef.SolidTest(X + DX + W - 1, Y + H - 1.5 + DY) And _
            (Not rDef.SolidTest(X + DX + W - 1, Y + H - 1.5 - DX)) And _
            (Not rDef.SolidTest(X + DX + W - 1, Y - DX)) And _
            (Not rDef.SolidTest(X + DX, Y - DX)) Then
            DY = -DX - 0.5
            Exit Do
        ' Check down-ceiling (rightward) stuff
        ElseIf rDef.SolidTest(X + DX + W - 1, Y + DY) And _
            (Not rDef.SolidTest(X + DX + W - 1, Y + H - 1 + DX)) And _
            (Not rDef.SolidTest(X + DX + W - 1, Y + DX)) And _
            (Not rDef.SolidTest(X + DX, Y + H - 1 + DX)) Then
            DY = DX
            Exit Do
        Else
            DX = DX - 1
            If DX < 0 Then DX = 0: Exit Do
        End If


The other option is to try to correct the problem from script by adding your own logic on top of what's already happening by using ProjectObj.GamePlayer.PlayerSprite.rDef.SolidTest on various points around the edge of the sprite, and manipulating the player sprite's DX, DY, X, and Y properties appropriately.