Best way to have families collide with themselves?

Post reply
0 favourites
From the Asset Store
Zombie Family - Game Sprites
$12 USD
A collection of various zombie characters sprites for creating a 2D platformer or sidescroller game
pzUH's avatar
pzUH

  • this is collision code from R0J0hound

    I'm wondering if this is the best way to do this.. I've made it so objects in the same family collide with each other. Maybe there's an easier way so I don't have to do the "For Each" at the bottom and/or make a second family?

    dropbox.com/s/o6yflozq2qg0qtu/pvp_physics.c3p

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • This looks fine? You can't use one family because of picking issues. If this works then I say fine.

  • There are a few ways to do it a bit different with some trade offs.

    I tend to use one object with one family containing that object. The advantage is you can access instance variables from both. The con is you have only one object type but I find it fine. You can use different animation frames.

    Another option is multiple object types and one family. We can then utilize iids to reference two different instances at once. Then to modify them you can use pick nth instance. The con is you couldn’t use the overlapping events, so you’d have to roll your own which isn’t too terrible for circles and boxes. Although the loop is a bit more nuanced.

    One nuisance of using two families is having instance variables shared between the two. I guess the custom movement behavior is one way around that, but I’ve found that behavior not very useful since applying velocity is fairly simple to apply velocity to make movement.

    But if staying with two families you could have each family have similarly named instance variables and copy between the two. Or maybe use a function to access them instead.

    As is, you can remove the for each in the bottom two events and it’ll still work, since the actions only reference themselves.

  • lionz yeah technically its working.. I just wanted to know the best way to do it.

    R0J0hound

    Another option is multiple object types and one family. We can then utilize iids to reference two different instances at once. Then to modify them you can use pick nth instance. The con is you couldn’t use the overlapping events, so you’d have to roll your own which isn’t too terrible for circles and boxes. Although the loop is a bit more nuanced.

    This was what I wanted but I didn't know if I could do 

    Family1 on Collision with Family1
Family1.IID <> Family1.IID

    that second part I was unsure of.. although I don't think it works... how would it know which to pick?

    I need to have multiple objects, so I guess the best way is to do the 2-family method. There shouldn't be too much overhead with sharing family data in a For Each. The most family members there will be less than 10.

  • you can remove the for each in the bottom two events and it’ll still work, since the actions only reference themselves.

    oh wow, I didn't even think of that!

  • If only two instances were colliding then an overlap condition would work. You’d get either instance with pick nth instance with 0 or 1. That won’t work if more overlap since we want to loop over all the colliding pairs.

    Roughly to loop over the pairs you’d do this: 

    var i=0
var j=0
For “i” from 0 to family.count-2
For “j” from i+1to family.count-1
— set i to loopindex("i")
— set j to loopindex("j")
— compare abs(family(i).x-family(j).x)<32
— — do something

    The collision expression is basic here. It don’t have a better one off the top of my head atm. But the idea is you use an expression to see if the two objects collide instead of the overlap condition. Then to modify the instances you pick the nth instance using i and j.

  • oh I see what you mean by square or circle. yeah my objects will use collision boxes and won't be primitive shapes. So I guess the 2 Family method will work then.. Thanks for the help!

  • original thread: construct.net/en/forum/construct-3/how-do-i-8/someone-help-calculating-145005

    R0J0hound revisiting the collision formula you gave me and I'm wondering if I got it wrong somewhere.

    This all started when I tried to make the collision happen when one of the objects is using the Orbit behavior. I want the collision to knock the orbital object out of orbit to then start using the bullet behavior.

    So I did a back-of-the-napkin translation of the orbit movement to a bullet "moving angle" by adding 90 to the rotation (in degrees). So if it's in orbit at 0 degrees and moving CW the moving angle is roughly 90 degrees. but it's not working very well.

    However, I noticed some other weird interactions with even non-orbit obstacles. A lot of times when the player is moving up/down, hitting an (non-orbital) obstacle that is moving up/down the collision seems wrong. So I wonder if this exposed something slightly off about the formula, because sometimes its works perfect (so that smells of doing a + instead of - or * instead of / etc..) I tried to mess with it, but I only made it worse!

    Also one other issue is that I am setting a max speed for all objects, could that be a factor?

    check it out here: dropbox.com/s/w3tjtks272tkzaf/orbitHitTest.c3p

  • Looks ok as best I can tell by just looking at the events. I may be missing something though.

    The action to set the speed of the object when it leaves orbit is incorrect. It should be:

    LinearSpeed = angularSpeed*radius*pi/180

    And I’m pretty sure the orbit speed is an angular speed.

    The angle of motion looks ok. It works for cw rotation. It would be -90 for ccw, and you’d probably want to put the speed calc in an abs().

    As far as the bounce calculation itself, it bounces whenever the objects collide. You can modify it so it only bounces when the objects are moving toward each other.

    Set vrel to (obst.vx - player.vx) * cos(a) + (obst.vy - player.vy) * sin(a)

    If Vrel <0

    Set j to -(1+e) * vrel / (1/player.mass + 1 / obst.mass)

    ...and do rest of bounce stuff.

    Other than that the bounce may not be exactly what was expected since it’s treating the two objects as circles with the collision point directly between them. Boxes usually can have the collision point all over the place which will change up how it will bounce.

    That and the bounce won’t change the angular velocity as is which adds to making the bounce not look right.

    Both can be solved with more logic to calculate the collision point, as well as modifying the equations to take angular velocity into consideration.

  • LinearSpeed = angularSpeed*radius*pi/180

    R0J0hound

    ah thanks for this! I was testing hitting a key to disable the orbit and transfering the speed to bullet and now that looks exactly right!

    I'm not worried about the bounce as much. The problem is, sometimes there's no collision and the objects just go right through each other. It's usually when its a north/south collision. like shown in the GIF in my previous post. It's almost as if there's no collision detected, which seems very odd.

    As far as circles vs boxes, the way I'm ultimately using them is probably closer to circles, but most sprites in games (unless you are using actual primitives) are drawn art (characters and things) usually have some depth to them, collision polygons are not drawn right to the edge and are usually smaller than the sprite itself. Even if the angle is off slightly it doesn't matter. However, if it goes in the complete wrong direction, or there is no redirect at all is when it doesn't look right.

    the bounce won’t change the angular velocity as is which adds to making the bounce not look right.

    I don't understand this part at all. why wouldn't it, if I transfer it to bullet.speed before the equations?

    all the side to side (east/west) collision work great.

    I thought maybe you set it up that way since your original response was to a question about how to make something like this happen:

    currently this happens (north/south collides):

  • When I was talking about the angular velocity I meant that the hits won't cause the objects to spin with the current math.

    Anyways, made a simple test of the bounce math and it seems to be working in all directions:

    dropbox.com/s/cuy6zjurxm4u2q0/bounce_math.capx

    The only difference is it utilizes a min() so it will only bounce when the objects are moving toward each other. Otherwise I guess you'd want to test your conversions to and from the bullet and custom movement behaviors in your project.

  • oh! I always assumed Custom and Bullet speed/angleOfMotion were the same. Maybe they are not?

    I will do some testing around this, I hope there's no major discrepency.

  • R0J0hound okay I found its not Custom vs Bullet that is the issue. The issue still happens when I try a bullet vs bullet bounce.

    It works great from angles 0-180 but not 90-270

    Do you think the .AngleOfMotion could that give values that don't agree with sin() or cos()? (movingAngle is -90 when going up)

    I honestly don't know how its not working...

    here's a simple test

    dropbox.com/s/c7butfk0ceoqccl/BounceTest.c3p

  • DiegoM not sure if you know the answer. Is cos() and sin() compatible with bullet angle of motion?

    the math here is not working for bullet when object are going up/down, but work left/right

    dropbox.com/s/c7butfk0ceoqccl/BounceTest.c3p

  • Found what was causing the issue.

    You had:

    set a to angle(player.X,player.Y,obst.y,obst.y)

    it should be

    set a to angle(player.X,player.Y,obst.x,obst.y)

Post reply
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)