detecting collision sides of a square etc.. please help

jay2dx

Hi guys, hoping someone can help,

basically i want to detect the side of a square when an actor collides with it. simple huh!!! lol no...!

imagine the four sides of the square are numbered, 1,2,3,4

and

i have actors 1,2,3,4

i want to detect if actor 1 collides with square side 1, and so on, So for instance if actor 2 collides with square side 1,3 or 4, i still want it to collide but i want to know it wasn't with side 2, and the game would end etc..

im assuming this is possible with detecting the squares rotation as a game attribute and using a vector to angle rule, but I'm just not clever enough to figure that out as I'm still pretty new to this

any help would be great, and as a repayment I could do some graphics for you in return

thanks

jay..

Braydon_SFX

The first way that comes to my mind is to constrain actors to each side of the main actor; add an offset so they line up with the edges. If you take the time to really make sure it's close, detecting the collisions is a piece of cake, kind of like this one:

jay2dx

Yeah thanks man, I've tried that and it works somewhat, "need to spend more time one it" but i want to really keep the limit of the constraints down, the games is quite frantic so needs to be fast and smooth! also whatever your linking isn't working

The_Gamesalad_Guru

See my video on scene linking for constrains it's much faster and direct without external game attributes.

jay2dx

Thanks will have a look

Socks

@jay2dx said:

There are lots of ways of doing this, I'd usually go with the suggestion by @Braydon_SFX - to constrain 4 actors to the edges of your square.

If you go down the vector to angle route you run in to a few problems, not least being that vector to angle has less than ideal way of reporting back the angle it finds, rather than the obvious (and easy to use) 0-360°, the angles are reported as 0-180°, and then as you go passed 180°, minus180° to 0° . . . it makes for tricky maths (depending on what you are doing).

There are various other ways, you could ditch vector to angle and use some other method to determine the angle between the ball and the square, maybe use Rotate To (the ball) to point a 'detector' actor at the ball, then syphon off this angle (Rotate to uses a standard 0-360° range unlike vector to angle) and throw a bit of maths at the result to map a value of 0-360 to 1-4 . . . . plus you need a 45° offset in there somewhere as a side is defined as corner to corner . . . .

Hold on, demo time . . . .

Socks

Here you go, this uses the method outlined above - the Rotate To behaviour tracks the angle between the ball and the square - this 'detector' is locked to the main actor (the 'square') when the ball collides with the square (for the purposes of this demo just drag the ball around with your mouse) then it will tell you which side it is touching - which is really just the angles 0-360° divided up to read 1,2,3,4.

Link: https://www.mediafire.com/?493qirn4l16b7w7

Personally I'd still be tempted to go with @Braydon_SFX 's suggestion, it's a lot less complex.

RThurman

Here is another way to do this. The idea is to subtract the square's rotation from the vectorToAngle(). Then you look to see if the angle is pointing to the left, top, right, or bottom of the square.

jay2dx

Wow guys thank you so much what a great community, I'm on my way to work but whipping out the laptop now to have a tinker quite enjoy my train journey since I discovered game salad, have a good day all, will report back with my attempt

jay2dx

Thanks again for the files etc guys, I'm learning ALOT with this, I'm stumbling with the demo from @Socks when attempting to rotate the square with a swipe, i don't know how to let the game know 1 2 3 or 4 is detected, i.e. what actor is hitting what side, as its just a display text rule, ill keep at it though I'm sure i need to send that rule to a game attribute and then read it back as a rule for points and wether it hit the correct side.

the other demo from @RThurman‌ I'm stumbling when trying to spawn new actors as the rules set up in this read the position of the actors within the actual scene, id need more than one of each actor on the scene at times and also they will be getting destroyed, but again, I'm working it out i think,,

@Braydon_SFX‌ your method sounds good, and I'm trying it, but i can't get the collide actors that you mentioned i should constrain to the side of the square to rotate around the square rather than with it! i need the collide actors to stay on the outer edge on all 4 sides, i.e. 1,2,3,4, collision detectors constrained to the squares edge and rotate with an arch i guess, not at the squares centre, i can offset it easily but then they just rotate at the offset position,

ughhh my head hurts haha, keeping at it though,,

thanks Jay

Braydon_SFX

So something like this isn't what you want?

Click the large square to move it - the other actors will position themselves accordingly.

jay2dx

Yes thats it @Braydon_sfx but with rotation possible!! "rotation is what i was stick with, keeping the collision at the outer edge while it rotated..

Ive figured it out with this template as someone asked this question in 2012 so it seems, i didn't know what to search for until you gys offered your help,

http://forums.gamesalad.com/discussion/42815/a-little-geometry-help-for-offset-rotation

Im so happy i can now carry on with the graphics, my fave part!

will post my results when its done and credit all help

thanks again guys

colander

I downloaded @Socks demo a few days ago out of interest and for future reference. I finally got to it and had a look. In the few apps I have done I haven't had any need to do this.

I played around and came up with two methods using VectorToAngle(). The first one uses rules to detect the side, the second one uses a large equation in one Change Attribute action.

I got back here and realised I am late to the party and the thread has moved on. My methods don't account for rotation.

EDIT: The equation is large but simple it takes the conditions from the four rules in Hero 1 and puts them in four blocks. It only looks big and complicated. I saw a demo in a thread about score keeping. I think it was @RThurman who posted in it (Maybe he can confirm that) which showed an example and explanation of equations. I have been using them in some areas, it cuts down on number of rules need to preform a task/routine. But as he warned it can be tricky finding bugs so be careful and throughly test them.

Socks

@colander said:
I downloaded Socks demo a few days ago out of interest and for future reference. I finally got to it and had a look. In the few apps I have done I haven't had any need to do this.

I played around and came up with two methods using VectorToAngle(). The first one uses rules to detect the side, the second one uses a large equation in one Change Attribute action.

I got back here and realised I am late to the party and the thread has moved on. My methods don't account for rotation.

Neat ! I've done the whole vector to angle thing defining the start and end angle for each side and I could never get it to work, I'd always hit an issue where you go passed 180° and the angle flips over to negative values, but you seem to have nailed it ! Good stuff.

LumpApps

Adding 180 to the angle and you are fine. See attached example. Hover the mouse around the white box and it displays the angle between the mouse position and the box. Hit the red switch to add 180 to the value and you have a "normal" range from 0 to 360.

This community can indeed be great, but your question was interesting. That helps a lot

Socks

@jay2dx said:
Yes thats it Braydon_sfx but with rotation possible!! "rotation is what i was stick with, keeping the collision at the outer edge while it rotated.

Here is the method used by @Braydon_sfx (4 edge detectors) but with rotation factored in - you can grab the 'Square' (yellow) and throw it around the scene - the same deal with the small (red) 'ball', click on it and throw it around - when it hits the Square the Square will display which side has been hit.

One obvious issue occurred to me . . . what to do when the ball hits one of the corners of the square - as it is at the moment it detects two sides being hit (and displays two numbers), I left it like that simply because I couldn't imagine how you'd decide what to do in these situations (which are surprisingly common once you've spent a couple of minutes throwing stuff around).

Maybe make the corners 'dead' - returning no hit - with the collision detectors shrunk in size so they don't meet at the corners . . . . ?

Anyhow, here's a square you can freely rotate and it will still know which side has been hit.

EDIT - did a quick bit of editing, reduced the side detectors so they only occupy the central 80% of each side - helps with corner collisions detecting two values - but ultimately this is a game design question for you (rather than a GS programming question).

link: https://www.mediafire.com/?ifi2tg1j6j240a3

Braydon_SFX

Pretty neat stuff, @RThurman‌ and @Socks!

RThurman

@Braydon_SFX‌ Thanks!

Very fun thread!

Here is yet another stab at the issue. This demo uses an angle attribute instead of a real attribute. Angle attributes 'normalize' any derived angles to an expected 0-360 degrees. (None of that +180 / -180 stuff.)

This demo also shows how to use spawned actors.

It does not use constrained actors for hit boxes, it only uses the angles to determine which side has been hit.

http://www.mediafire.com/download/n515ebavz3ci812/DetectSidesOfSquareFromAngleOfSpawnedActor.zip

Socks

@RThurman said:
This demo uses an angle attribute instead of a real attribute. Angle attributes 'normalize' any derived angles to an expected 0-360 degrees. (None of that +180 / -180 stuff.)

Excellent ! I've often looked for a quick an easy way to normalize the whole +180 / -180 thing !

jay2dx

Wow I didn't realise this thread would interest so many people will post what I ended up with when Ive a chance tonight! I really wish I knew more technical aspects of game salad and threads like this help us all I guess

jay2dx

It seems that maybe just MAYBE @BIGDAVE has seen this tread and release a game based on discussions here its too much of a coincidence, feeling quite annoyed by this as he never offered any help towards the solutions discussed here, his game has been featured on apples best new games, so I guess good luck to him I'm not bitter or anything! lol, I know it’s not a totally original game on my part, as its basically a rhythm game like DDR or Beatmania, I’m a great fan of these games,, but it just annoys me that this happens!

Anyways my game is coming along nicely and has a lot more to it, so I can be happy about that!..

I guess it’s probably best to not ask questions with so much detail on the forums in the future!

Thanks again for all you guys that’s helped me with this, its submitting to the app store tonight so fingers crossed 

If any of you who helped me need some graphics or game play testing etc “I used to test games for PlayStation for 7 years so pretty good at that lol” or anything else you think I can help with maybe give me a shout!

Jay

here's some images from a few days ago, not final though as not posting them until its on the stores

BigDave

@jay2dx‌
looks good man!

jay2dx

Thanks, @bigdave again good luck with your game