Asteroids style movement with collision-revisit

  • Hey all,

    A while ago I posted a topic about getting an 'asteroids-style' movement to work with a robust collision system. I eventually came upon a solution which I was happy with but its fundamental flaw has become too problematic.

    Here's the capx of that solution. Basically, I use some trig and raycasting to find the angle of the nearest wall, and push off it opposite that angle. It works terrific for all outwards angles. However, as you can see, there are a lot of problems with inwards facing wall angles. On angles between 180 and 90, the player twitches and shakes, and on angles between 90 and 0, the player teleports away and disappears. This isn't unexpected behavior for the code I'm running (read: I'm not asking anyone to fix my bugs!) however I've spent hours trying to come up with a solution to no avail.

    So, does anyone have any ideas?

  • *bump*

  • Could be that angle() doesn't know which direction you are coming from ie angle(x1,y1,x2,y2) is different than angle(x2,y2,x1,y1).

  • newt did you look at the capx? I don't once use angle() in the collision code...

  • Technically you're correct.

    You used it twice.

  • Ehh its hard to tell whats going on with the custom movement mixed in.

    I haven't used it in C2 much, and the angle(0,0,x,y) just doesn't seem right.

    Surely you have a better way to get that angle.

    Anyway, good luck.

  • newt that's just the movement code! it's not even relevant to my question

  • Edit.

    Never mind, Im sure you'll figure it out.

    I didn't have that much motivation to help in the first place, and even less now.

    My apologies.

  • newt all right, that's fine of course

    If anyone else has any ideas I'd be super keen to hear them!

  • *bump* again

  • *bump*

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • I think you'll probably need to consider more than just the one closest wall. One works good like you said for outward angles, but for inward corners you could use the average of the two wall's angles as the angle to push out. Or you could pick the two walls in order of closeness and push out of of each one at a time. Of course with that you'd need to make your own "push out" events.

  • R0J0hound - thanks for having a look. I agree with you there - I toyed with finding the average of the two angles and pushing out, but you run into lots of little problems in things like narrow passageways and such.

    Pushing out of two walls sounds interesting - Are you suggesting doing something at the instance level of the walls (i.e. pick a certain wall instance to push out of) so that I know when I'm done pushing out of one and I can deal with the other?

    hmm... I could definitely give that a shot. What if I cast out like 16 or 32 rays around the player, see which of those rays collide with a solid, build a list of those solids along with the corresponding ray angles, maybe get rid of duplicates, then go from there?

  • I was about to say the same thing as R0J0hound.

    Probably what is happening is that by only considering one wall the player is pushed into the opposite wall, and on the next frame pushed further into the previous wall, and so on... so it spiral out of control.

    I think one way to solve is to instead of generating a push out angle, generate a vector that represents that angle (x,y), and then you just need to sum all the vectors of all the overlapping walls to get the resultant push out angle.

  • Animmaniac that's a great idea actually - very similar to what I've been doing, but I really like the vector sum idea.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)