Collisions??

chosenonestudios

Hey guys, I was wondering how I could make it so when an actor collides with another actor they have to be like 5-15% over... because it "appears" to be hitting nothing.... but it just transparent..... if this isn't the correct way to do it or you have a better idea please let me know thanks in advance!

rebump

1) Make sure you don't have too much transparency around your actors.
2) Sometimes switching to a round collision shape from rectangle/square will yield a tighter collision (depending on the actor that is and whether or not it would make sense).
3) Use magnitude() to check distance upon collision with the actor. This would allow precise distance checking but then you have to use game level attributes to tell the actors who is colliding with what but that introduces issues if there is no particular order and/or timing of when the actors might be colliding (i.e. who with who since many may be trying to share the game level attributes). With falling games, rpg, well timed actor games, this would probably work pretty well. With a screen full of randomly spawning and/or moving actors, probably not too well. Even if you use lock or semaphore programming methodologies, the timing in GS seems to not allow the most precise control of sequencing.

chosenonestudios

there is very minimal transparency, but I changed the collision to circles and poof! worked pretty much exactly the way I wanted it too, thanks rebump!

synthesis

This is why I want Gendai to build into GS a separate collision zone sizing option from the actor size.

Right now...the actor size is the collision size.
If you want a smaller zone...you have to use a transparent "shadow" object that links to the visual actors XY position. This invisible tagalong can then be smaller (or bigger) and have the collision settings on it while the actor drives. it can also follow along with different motion settings than the main actor...kinda like a hook and ladder firetruck.

A more detailed explanation is here I just wrote today:
http://gamesalad.com/forums/topic.php?id=4179

Its a very similar situation...

@ rebump...
Are you suggesting that my logic above is mis-informed?
Can you actually prevent edge collision by tweaking settings and override this and control the amount of collision overlap required to trigger a collision switch?

I am not familiar with "magnitude" settings (if there is such a thing).

pre-Thanks if you can elaborate for me!

chosenonestudios

"This is why I want Gendai to build into GS a separate collision zone sizing option from the actor size."

I second that.

Thanks synthesis!

firemaplegames

magnitude is the distance, in this case, of a line segment. it's in the expression editor.

you could try to use that for a different collision shape...

when magnitude(abs(myX-yourX),abs(myY-yourY)) < 10
Collide

(that's pseudocode - you'll have to set the attributes up properly)

you can also check out my magnitude demo...
i'm in the car right now.. i ca elaborate further when i get home...

synthesis

Oh man...FMG...you're killing me. Talk about a convoluted way to achieve something that should be quite simple. If you had multiple actors in play...it would take eternity to coordinate all of that and debug it I would think.

Is there a demo out there that show a simple (or perhaps elegant) way for 2 actors involved in a physics collision at an interior target zone rather than at the edges...

In other words...the two jolly fat guys bump when their belly buttons (or ghostbuster's logos on their T-shirts if you prefer) touch and not when the sides of their belly's (or body's) touch (in 2D front elevation view).

chosenonestudios

@Syntheseis, I was reading another forum that you had posted on... and you were talking about alpha switches? Could you elaborate exactly what this is and how you would utilize it, because right now my game only utilizes spawning actors... (yes Im a noob haha) thanks in advance!

rebump

[Synth: No, your method is ideal, I wasn't really thinking much I guess. That is a commonly used design methodology in GS.]

I forgot to mention the constraining a smaller invisible actor for the collision zone to the visible actor as Synth suggests. That is a sure fire way around it. This can allow for a smaller collision zone, an offset collision zone, or even multiple collision zones.

But with all things constrained, it adds a little overhead to the system. If you use this method on many, say enemy, actors, it can add up.

However, I have used approximately 100 constrains in a scene (not for collision as in this post but for movement) and I'm still eaking out greater than 24 frames per second. I wouldn't recommend that many...this first project was a test to put GS through its paces.

synthesis

@Chose...
Use the alpha settings (0 and 1) like a light switch for your actor.
If the actor has "Touch" properties connected to it...you will need to move it off screen temporarily while it is off (to avoid having it tapped by the gamer).

RULE:
when self.alpha = 0
self.position.X = 1000 (or more if necessary or use Y)

otherwise.
self.position.X = (wherever you need it)

synthesis

@rebump
My solution would work if you have a 1 actor game...such as a racing game or a tank shooter or something where everything is trying to collide with one actor (the player).

Otherwise...you are right...if you tried to have dozens of actors trying to collide into each other this way...better stick to standard collision controls.

synthesis

TSB
But my way would also work....no?
you make the marble hole a dumb graphic stand-in actor (for looks) and you use a much smaller invisible trigger actor for the hole center and to detect collisions.

This way you could even incorporate the holes into the background png and just drop an invisible hole trigger on top of the background (since you are importing those background anyway).

Am I right?

synthesis

Ahhh TSB.
YOU SO CLEVER...LOVE YOU LONG TIME!

(sorry its late)

chosenonestudios

I am enlightened! thanks guys!

synthesis

I think I would have used an oversized spawn trigger wafer at each hole to activate the hole collision sensor when a ball was close and destroy if not....all happening invisibly of course. This way I can see it happen on screen when developing and make sure all my switching was right. I like booleans and integers whenever possible...

I just don't like those game-fly formula solutions...they cause bugs and are hard to figure out where the breakdown is.

firemaplegames

i wasn't suggesting using magnitude, only that you can.
just one of the many hacks and workarounds...

synthesis

Of course FMG...
I guess I need to read up on it and better understand it.
Does the reference section cover it well?

firemaplegames

@synthesis:

It's just the distance between two points.
I find it pretty useful.

Since I am usually always keeping track of the main player's X and Y, I can use that to trigger different animations, sound effects, and behaviors in other actors.

The other actors in the game simply listen for the magnitude to be less than a certain amount. i.e. if distanceBetweenMeAndMainPlayer < 100 then attack the main player.

Or in your case, the other AI drivers could get more aggressive when the main player gets close to them, or simply honk their horns, or throw projectiles or whatever...

You can use it for a smaller collision area vs. actor size, and you only have to keep track of the main player's x and y. The other actors just compare that to their own x and y. Of course the collision would work better for circular actors.

It's another thing that always running, so like timers, constrains, etc., use it sparingly. However, you could use it to actually improve performance if you wrapped Rules that were CPU hogs from only running when they have to. i.e. only check certain rules if the main player is within a certain range.

Anyway, I can tell from your posts that you know what you're doing codewise, magnitude is just another nice tool to have at your disposal.

The formula for magnitude is:

magnitude(abs(x1-x2),abs(y1-y2))
(the abs functions are in there to make sure the result stays positive - as it is a distance calculation)

synthesis

Very good.
It may not work for me on my current project...but on the surface...does appear very handy.

Thanks!!!
BTW:
Are you a Gendai guy? Or an indie dev?

rebump

Just to clarify: If you use "magnitude()" for many to detect one (i.e. enemy ships or their projectiles hitting player), it is not a big deal in terms of game attribute use. If you use "magnitude()" for one to track many (i.e. having player missile track the closest enemy), then the use of game attributes can get to be a pain as I highlighted above.

[I really shouldn't post in the middle of the night like I did above.]

firemaplegames

Just an indie dev... And I've only been using GS since December, so please take any of my thoughts/advice with a grain of salt!