ZGameEditor forum

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.

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

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.

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

*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

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.

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 )

K

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

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.

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...

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

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.

Yeah, that is a cool bouncer,. how about if we add to spawn;
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; Would be cool if it was made to work always,. more simple mechanics posts would be fun.

@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.

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