GameMaker Need help with a collision glitch!

G

goosegooseduck

Guest
Hey friends! Disclaimer - I'm fairly new to GML.

I've been trying to get platforming to work in a 2D, top-down game. I've looked at a few tutorials from a few different YouTube sources, but primarily this one by Backspace Cadet:

It works some of the time, but if you look at the images, you'll see my problem.

For reference - the green blocks have a 'z' value of 8, and the purple have a 'z' value of 16.

When the player (orange) approaches the purple block from the bottom (A) or from the bottom while on top of a green block (B), the collision works fine. But when the player approaches from the TOP of a green block from the LEFT (C to D), it crosses into the purple block.

The interesting thing is, I downloaded Backspace Cadet's actual project file, and it has this problem. Maybe I'm just too much of a noob to be able to troubleshoot this, but I'm hoping that the fact that the original project file experiences the same glitch means it can be fixed...

Thank you for reading. :)

gamemaker.jpg
 
G

Gillen82

Guest
No one can help without first seeing the code relating to the issue
 

NightFrost

Member
Yeah, without knowing anything about the code, it is hard to tell. Since this is a 2.5D effect collision system, I assume it has some sort of grid collision thing going instead of actual collision commands being used The actual bug would then possibly be player's elevation causing a grid being read from wrong position, allowing for overlap.
 
G

goosegooseduck

Guest
This is the Step Event:

Code:
//par
event_inherited();
//z jump (when space pressed)
if (zjump == true)
{
    z += zspeed /*z pos goes up*/
}
//if not ontop of block
if (!instance_place(x,y,o_block_par))
{
    zfloor = 0; /*zfloor is ground level*/

}
//if not on ground
if (!z <= zfloor)
{
    z -= zgrav; /*apply downforce on z pos*/
    zgrav += 0.2; /*grav gets stronger each step*/
}
//stop falling when you hit zfloor
if (z <= zfloor+1/*+1 for sticking glitch on ground*/)
{
    z = zfloor;    /*snap z pos to on ground*/
    zgrav = 0; /*stop applying downforce*/
    zjump = false; /*no longer in the air*/   
}
The keyboard inputs are all done as separate events. Here's LEFT, for example:
Code:
///move left
//update instleft
instleft = noone;
//instance in path
instleft = (instance_place(x-spd,y,o_block_par))
if (!instleft) or (instleft.z <= z)
{
    x -= spd;
}
And here's the collision event with a parent object that handles all the blocks:

Code:
///update zfloor
instbelow = instance_place(x,y,o_block_par);
zfloor = instbelow.z
A parent object sets the player to depth = -y, as does the parent object for the blocks. The draw event subtracts the player's 'z' from its 'y'.

This is Backspace Cadet's actual code. At first I followed the video, but was encountering the glitch. Then I downloaded his project file and still encountered it. I've also tried putting the keyboard inputs into the step event rather than in separate events but I don't really know what I'm doing. The 2.5d-platforming is really cool to me but I think I should probably just abandon the idea given that I'm not proficient enough to troubleshoot a complex concept.

Thanks again for reading!
 
G

goosegooseduck

Guest
No one can help without first seeing the code relating to the issue
I assumed as much. I wasn't sure if I should just post a big wall of code without first explaining the problem.
 
G

goosegooseduck

Guest
Yeah, without knowing anything about the code, it is hard to tell. Since this is a 2.5D effect collision system, I assume it has some sort of grid collision thing going instead of actual collision commands being used The actual bug would then possibly be player's elevation causing a grid being read from wrong position, allowing for overlap.
Could the problem be that it's only using a basic 2D collision system? The issue only arises when the player object approaches a block with a higher z-value from the left side. I wonder if the player object isn't recognizing two collisions at the same time - the 8-block beneath it and the 16-block to its right.

Sorry if I'm not being clear about things... I'm very new to this.
 

NightFrost

Member
Ok, so it IS using collisions and instead simulates z-depth. Looking over the code, one problem that sticks up is collisions with multiple blocks at the same time. As can be seen from your image D, player is touching two purple cubes at the same time, though one is obscured by the other. Two collision boxes are however encountered, and only one is handled. GM just happens to pick the lower box, checks against its z-value and sees you can walk over it. The code would need a rewrite to take into account all box collisions before allowing movement.
 
G

goosegooseduck

Guest
Ok, so it IS using collisions and instead simulates z-depth. Looking over the code, one problem that sticks up is collisions with multiple blocks at the same time. As can be seen from your image D, player is touching two purple cubes at the same time, though one is obscured by the other. Two collision boxes are however encountered, and only one is handled. GM just happens to pick the lower box, checks against its z-value and sees you can walk over it. The code would need a rewrite to take into account all box collisions before allowing movement.
Thank you for the reply. That was QUICK!

I apologize for lack of explanation, but that purple object is ONE object. It looks like two layers of four blocks (the size of the green ones) but it's actually one sprite/object. The collision masks for both the green and purple objects covers only the 'shadow' area, aka the bottom half. Sprite origin is middle-left for the blocks and centered on the player's collision mask. I've played around with the sprite origin but I didn't have any luck.

Thanks again.
 

NightFrost

Member
Hm, so one object... I lack the time right now to look closer at the code, but one thing you could do to debug is to have the player and the cubes draw on screen their z and zfloor values, that can tell you pretty quick if the problem is in them getting set incorrectly.
 
G

goosegooseduck

Guest
Hm, so one object... I lack the time right now to look closer at the code, but one thing you could do to debug is to have the player and the cubes draw on screen their z and zfloor values, that can tell you pretty quick if the problem is in them getting set incorrectly.
Thanks for the tip.

I've been drawing the player's z and zfloor. When the player is overlapping the purple block, it still registers as being on the green block's 'z'. The blocks don't actually have a zfloor value - only a z value.

I don't know if it's worth noting, but when the player overlaps the purple block, it can only go about half-way through (towards the right).

Thanks for your time, and please - don't worry about responding so quickly. I'm in no hurry. I just appreciate the help. Cheers.
 
Top