Bounce collision action

If there is something important you think is missing in the current version of ZGameEditor then you can post a feature request here!

Moderator: Moderators

Post Reply
User avatar
Lupo
Posts: 76
Joined: Wed Sep 09, 2009 6:21 pm
Location: Montevideo, Uruguay

Bounce collision action

Post by Lupo »

Hi Kjell/VilleK,

First of all thanks VilleK for all the hard work in the collision area, It would be very useful.

At the moment we have 2 action/behavior for the collision:
1. Collision
2. Stop

I dont know if it possible (but It would be great) to have a third action: Bounce.

Imagine we are working in a Breakout/arkanoid style of game, and you define your blocks and your ball, and then define the collision for the balls<->block as bounce, so the ball bounce into the blocks and walls (you could add some friction in the On Collision) handled by ZGE.

In order to calculate the normals, it needs to take into account the kind of collisionStyle, bounds, velocity of each model. I know it would be an approximation of the collision (it only take into account the Collision Volume), but I think it could be, very usefull.

Thank in advance for give it a thought.

Lupo.
Close, but not there yet.
User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

Hi Lupo,

Personally I never use the build-in Collision features of ZGE ( for a whole slew of reasons .. sorry Ville ). Anyway, before we can have Bounce, the Stop behavior needs to be fixed. Try the attached file to see what I mean ( press spacebar to reset ).

At this point I'd just do my own collisions, or use a physics dll.

K
Attachments
Stop.zgeproj
(1.74 KiB) Downloaded 806 times
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

Ah yes, Kjells example shows that stop collisions are not behaving correctly when objects have high velocity. This should be fixed but is difficult to solve.
User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

:roll:

Actually, the behavior is always incorrect regardless of velocity, the incorrectness just becomes more profound / easier to see at higher velocities* :wink:

*This is because the behavior uses the velocity to offset the model, while the correct solution would always position the sphere against the top-left corner of the box regardless of velocity.

K
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

The last time I was tuning the stop-behavior was when testing the FpsDemo-project. When the player hits a wall at a diagonal angle, instead of a full stop I want to keep the velocity of the axis that did not cause the collision, so that the player keep moving. I also had to make plenty of changes that would otherwise cause an model to be stuck inside another. That's the background why it works like it do today. It works quite well in the FpsDemo however it does produce strange results when approaching a corner, like Kjell illustrates. Another general problem with the collision is that models moving at a speed higher than their collision volume will pass right through each other with no collision detected, that's what I was referring to about a problem with high velocities.

The collision algorithms in ZGE are very basic and not realistic at all, however since they are more or less the same like those used in games 20 years ago they do quite a good job at simple arcade games. Kjell you are very welcome to suggest concrete improvements to the stop-behavior in particular, the relevant bits are in the InStopMovement procedure in Collision.pas.
User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

:)

Ah, I wasn't referring to the pass-through-obstacle-at-high-velocity thing no. But, the problem doesn't just occur at corners, the same thing happens when you hit a obstacle straight on ( see attached ). The sphere should end up against the left side of the box, but instead it ends up at a different distance each time depending on the velocity & delta-time.

And, 20 years ago was around the time that Sonic came out ( which actually has excellent Stop & Bounce behavior ) :wink:

K
Attachments
Stop.zgeproj
(1.65 KiB) Downloaded 595 times
User avatar
Lupo
Posts: 76
Joined: Wed Sep 09, 2009 6:21 pm
Location: Montevideo, Uruguay

Post by Lupo »

Hi,

Maybe its not perfect, but it works fine for the protos I made IMHO.

I really not good at this topic, so I can't help to developed anything :(


Lupo
Close, but not there yet.
User avatar
jph_wacheski
Posts: 1005
Joined: Sat Feb 16, 2008 8:10 pm
Location: Canada
Contact:

Post by jph_wacheski »

Yeah I am glad the collision stuff is in there,. simple as it is. I just hack around the reactions that are there and seem to be able to come up with some workable games,. Of course improvements would be welcome!

With the new beta scripting additions, makeing some bounce and other object interaction reactions should be a whole lot easier.

Including hysics dlls are an alternative,. for sure. just a lot more complecated to get setup and work with.
iterationGAMES.com
User avatar
Lupo
Posts: 76
Joined: Wed Sep 09, 2009 6:21 pm
Location: Montevideo, Uruguay

Post by Lupo »

Now that I have the collided model, could someone of the math gifted people of this forum (you helped me before!), help me to solve this?


I have model m1 hitting model m2, each of them are 2D circles (defined by the collision bound, collision style).
If m2 is static, how can I calculate the bounce vector (velocity.x, velocity.y) of m1 ?

thanks in advance...
Close, but not there yet.
User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

Hi Lupo,

In case you want to use the build-in Collision functionality, the attached method is probably the best way to go. Left-click ( and hold ) to spawn a circle, then drag the mouse to set the velocity vector and release to shoot.

K
Attachments
Bounce.zgeproj
(3.75 KiB) Downloaded 624 times
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

Great example Kjell!

I modified it to use the new CollidedWith-property so it supports multiple targets.

Use right mouse button to create new targets.
Attachments
Bounce20.zgeproj
(4.21 KiB) Downloaded 614 times
bounce20.png
bounce20.png (34.47 KiB) Viewed 13410 times
User avatar
jph_wacheski
Posts: 1005
Joined: Sat Feb 16, 2008 8:10 pm
Location: Canada
Contact:

Post by jph_wacheski »

Yeah, that is a cool bouncer,. how about if we add to spawn;

Code: Select all

Sz=random(1,.5);
CurrentModel.scale=Sz;
Where do we change the bounce to take this into account? I tryed hacking around in there and found some cool (but wacky) reponses but not the correct result.

Also adding the self collision works somewhat;

Code: Select all

ZZDC<?xml version="1.0" encoding="iso-8859-1" ?>
<DefineCollision/>
Would be cool if it was made to work always,. more simple mechanics posts would be fun.
iterationGAMES.com
User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

@jph - Multiply the position offset with self.radius+obstacle.radius.

The only way to make it work the way it should, is by not using the build-in collision system ( and calculate the exact intersection point(s) + delta ). This method is just a inaccurate hack ( which gets increasingly inaccurate at smaller radius / higher velocity / lower frame-rate ) unsuitable for pinball / snooker etc.
User avatar
Lupo
Posts: 76
Joined: Wed Sep 09, 2009 6:21 pm
Location: Montevideo, Uruguay

Post by Lupo »

Thanks everybody!!!

It just work great for what I'm doing.
Maybe at the end of the week I could post the results...

Its a proto of anti-shooter, you can bounce enemies shoots against them if the polarity of the shoot==polarity of your ship.

Its a cross between ikaruga and other indie game I cannot recall name...


Regards,
Lupo
Close, but not there yet.
Post Reply