# Elastic Collision

• How would one get the current acceleration of a moving object?

I know that A = dv/dt, but I'm not sure how we would get dv. Can someone help me with this?

EDIT: Here's my current line of thought.

I have an object with a set acceleration of 120 and a max (capped) acceleration of 320.

As long as the up arrow (causes player movement) is down, I would add 120 to the variable.

As long as the up arrow is not down, I would decrease this variable by the built-in deceleration rate (hand-chosen amount, since I can't use physics friction coefficient without knowing what that deceleration rate actually is).

As long as the down arrow is down (braking), I would decrease this variable by the braking deceleration amount.

So really I would be tracking keypresses to track the (supposed) acceleration, and not actually getting the actual acceleration.

Does this sound right? Is there a better method?

• Is there a specific use you have for the value of the acceleration?

You can track the delta of the Velocity by storing the velocity in an old variable one tick, then comparing it to the velocity in another tick, but I'm just curious what you plan on using it for.

• ## Try Construct 3

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

Construct 3 users don't see these ads
• I'm trying to create a realistic collision between two moving objects, causing them both to bounce backward. I'm using it for my space game:

Space Game

Basically I'm trying to get the acceleration so I can apply a correct force to the collision.

• I'd think that using the momentum equation would be better in this situation. You're talking about an elastic collision, like this. Basically, you'd want the mass and velocity of each object (rather than acceleration) and use the formula at the bottom for a head on elastic collision.

It's very simple of both objects are the same mass...they simply transfer their velocity to each other. It gets complicated when they are of different mass.

• So I've used the Apply Force at an Angle property in Physics for each object.

For example:

Player: Apply physics force (Player.Physics.Mass - EnemyCrescent.Physics.Mass)/(Player.Physics.Mass + EnemyCrescent.Physics.Mass) * Player.Physics.VelocityX at angle cos(Player.Angle) * (-1)

I've done this for the Y direction, and then used the second equation for the Enemy object.

However, I'm still not quite getting the effect I want.

When the two objects collide, they appear to be stuck together. I've updated the live example above with my current version.

Here's what my event sheet looks like for this part:

<img src="http://i.imgur.com/T8UneT1.png" border="0" />

• Couple things:

1. Use impulse instead of force. Impulse is used for sudden direction changes like collisions.

2. Adding the X and Y velocities will get your total velocity. Trap these in local variables to make sure you don't get the velocity after the impulse of the collision is applied when to the first object.

3. If you're just wanting them to bounce directly away from each other, you can fudge and use the angle expression to save time and headache. It won't be pixel perfect realism, but IMO it's close enough for a game.

I'd do something like this (you'll obviously have to add in all the other relevant parts for your particular game)

<img src="http://www.infinitepossibilitygames.com/demos/elasticcollision/elasticcollision.PNG" border="0" />

• When I use impulse, the result of the collision (the two objects 'bouncing' off each other) is sudden. One second the collision happens, then suddenly the two objects are a considerable distance apart from each other. It doesn't look 'smooth' but looks more like teleportation.

Here's my project with impulse instead of force - you'll see what I mean.

ImpulseCollision.capx

• Your Player sprite's collision area is much larger than the Enemy's collision area. The Physics.Mass expression uses the sprite's collision area times the density to figure out mass.

With that in mind I was able to get semi-realistic bounces by multiplying the impluse by 2 for the player ship, and dividing the impulse by 6-7ish for the enemy ship. Also, you have it the player ship figuring out the momentum with it's own velocity, not the velocity of the enemy ship. :)

I'd play with adjusting the impulse amount like I did until you get something that "feels" realistic.

• Also, you have it the player ship figuring out the momentum with it's own velocity, not the velocity of the enemy ship. :)

Isn't that correct though?

delta v1 = (m1 - m2) / (m1 + m2) * v1

delta v2 = 2m / (m1 + m2) * v1

If we say that v1 = Player velocity and v2 = enemy velocity, then delta v1 = player momentum change and delta v2 = enemy momentum change, so it would be:

Player apply impulse of [delta v1] at angle Player.angle + 180 at Image Point 0.

Enemy apply impulse of [delta v2] at angle Enemy.angle + 180 at Image Point 0.

<img src="http://i.imgur.com/dfVXRZA.png" border="0" />

The impulse still is very strong, with some cases where the enemy ship teleports across the screen.

• Here's an updated version of the .capx that features a text overlay showing the enemy and player forces applied upon a collision.

ImpulseCollision.capx

I'm starting to wonder if the physics library is bugged. Sometimes the force seems to be applied and the objects 'bounce' off each other, other times literally nothing happens and another collision happens between the two because neither has moved.

• You should move physics objects with the the physics actions (apply force/impulse/torque). It's generally a bad idea to mix physics with the other movement behaviors. It can mess up the physics simulation.

scirra.com/manual/98/physics[/url]]The Physics behavior simulates physics separately to the Construct 2 layout. Construct 2 will try to keep the Physics and Construct 2 "worlds" synchronised if one changes but not the other, but this can be unpredictable. For example, setting an object's position or angle will cause Construct 2 to teleport the corresponding object in the physics simulation to the object's new position, which does not always properly take in to account collisions. The same is true of using other Construct 2 behaviors at the same time as Physics.

• 11 posts