• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

Collision Woes

T

TheUnsungChampion

Guest
Hello, everyone. Another question for the community. I am in the middle of making my first platformer, and I am having collision problems. Maybe someone here can help, if so, thank you so much in advance.

I am using the following code block to handle collisions. Unfortunately, it isn't working at all; it's acting as if the wall simply isn't there.

if (place_meeting(x, y+vspd, obj_wall))
{
while (!place_meeting(x, y+sign(vspd), obj_solid))
{
y += sign(vspd);
}
vspd = 0;
}
y += vspd;

if (place_meeting(x+hspd, y, obj_wall))
{
while (!place_meeting(x+sign(hspd), y, obj_solid))
{
x += sign(hspd);
}
hspd = 0;
}
x += hspd;

For the record, neither my character nor my "solid" objects has the "solid" flag set, and hspd and vspd are my character's current horizontal and vertical speeds, respectively.
 
D

Docker

Guest
First thing I notice is the fact you have obj_wall AND obj_solid in your vertical/horizontal collision checking which I don't really see a need for however that's not your problem.

I've just stuck this straight into my platformer I'm working on that happens to have all of the same objects and variable names (pretty standard really) and it works perfectly fine.

Which means your problem lies somewhere else.
 

Roderick

Member
If I were to hazard a guess, I'd assume that one of your objects is a parent class, with your actual walls as children, and you forgot to set the parent for the wall that you're passing through.
 
T

TheUnsungChampion

Guest
Actually, the instance of "wall" up there is the result of it being so darned late when I did this. I didn't copy-paste my code, but rather, reread it and typed it as I went, because I wanted to be sure that the logic of each statement checked out in my head as I typed. Forgot what I had named my obj the first time in between glancing at my code and typing it out. The actual name in both instances is "obj_solid", at least, in my code. Also, the game is treating both vertical and horizontal collisions as non-existent; I wasn't able to test the side walls until temporarily taking out my gravity handling script, because the player kept falling through the floor on game start. The fact that it is somewhere else at least gives me a place to start; if other people are using the same/similar code, then there's gotta be something else I overlooked. Thoughts as to what that might be? By the way, thanks for your thoughtful replies so far. We haven't solved the problem, but now at least I have a better idea of where not to look. :)

EDIT: I actually figured out the initial problem. I had snippets of legacy movement code in my state scripts from back before I decided to retool my movement system that was making the player move through walls so fast that there wasn't time for collision checks to go off before it was already through. Now, however, I have a slightly different problem. Collisions work now, however, because my "standing" sprite is much narrower than my "walking/running sprite", when my player goes from "standing" to "walking/running" when standing too close to a wall, the bounding box of the respective sprites switches, locking the player inside the wall. Since I know what is causing this problem, what I am asking this time around is "what's the most elegant solution to this problem that doesn't involve changing the sprites (I love how my animations look)?"
 
Last edited by a moderator:
D

Destroy

Guest
You might consider editing bounding boxes of your sprites (and possibly modifying their offset, but I guess you have that already done if your animations look well). For example, if your standing sprite is 64x32 with origin x offset 0 and running is 64x48 with origin x offset 8, you'd set the running sprite's bounding box to be 8 from the left (0 + x offset) and 39 from the right (standing sprite width - 1 + x offset).

Alternatively, you could consider using the move_outside_collision function, setting the direction to 180 if you start moving left and 0 if you start moving right. I'm not really sure which of these would work better for you. You can ping me if there are any problems :p
 
T

TheUnsungChampion

Guest
Thanks so much. I am curious about this offset... I actually currently have allowed GM to handle my bounding boxes automatically. Are you talking about the x-origin of my sprite being moved away from the center of my sprite? I will, in the meantime, give the move_outside_collision function a look in help and see if that will do what I am looking for. I really appreciate the help. :)
 
D

Destroy

Guest
That's what I meant about the x-origin, but well, if you have all your sprites centered (I assume they're same height :p) then it means you don't have to bother with that. You'll just set "left" (under "modify mask") of the running sprite to half the difference between width of running sprite and standing sprite, and "right" to what it currently is - half the difference between the widths.

And you're more than welcome ;)
 
T

TheUnsungChampion

Guest
I eventually made the bounding boxes for all of the sprites the same size, without changing the sprites themselves. While this makes things look VERY slightly weird when my character is "walking/running" against a wall (looks like he is very slightly overlapping the walls), it fixes some other graphical problems that were really bothering me, and only someone who was being terribly nitpicky about things would be bugged by the tiny overlap. Thanks so much for helping me to work this out. I may tweak the x-origin of the running sprites as you suggested above, to fine tune out that lingering last bit of graphical weirdness, but for now at least, I am good. Thanks again; I have a fair amount of experience with GM, but even with all of the things I have tinkered about with in the past, this is my first attempt at making a serious, complete project, and I am finding that writing and testing a lot of isolated code is very different from making a cohesive, consistent project.
 
Top