Car Collisions

BlitzPlus Forums/BlitzPlus Programming/Car Collisions

Ryan Moody(Posted 2004) [#1]
Hello again,

I'm currently coding a 2D racing game, and I need to come up with a simplistic and yet realistic algorithm which determines the movement of a car after colliding with a wall or another car.

The algorithm needs to take the following into account:

1: The car(s) angle(s) - This determines the resultant angle(s)
2: The point of contact - This also determines the resultant angle(s)
3: The car(s) speed(s) - This determines the resultant speed(s)

Any suggestions for such an algorithm (preferably in psuedocode) would be most appreciated!

Thanks,
Ryan


poopla(Posted 2004) [#2]
Look up 2d rigid body physics. I dunno beyond that.


Rob Farley(Posted 2004) [#3]
Personally I'd just go for cheap tricks, I'm assuming this is going to be a top down racer.

For steering pivot the cars around the back axil to make it steer more realistically (rather than in the centre)

If a car hits another car take the x and y speed of the hitter divide it by a number (play to see what looks right) and tranfer those velocities onto the car that got hit.

If you want to add spin to cars that have been hit, just do a quick bit of where the impact was reletive to the centre of mass (pivot point) and see it you need to throw some spin into the tin, again, just play until it looks about right.

Of course, if you're looking for really realistic physics forget all of this, but if you're wanting something GTA1 style then just look at fudges.


Ryan Moody(Posted 2004) [#4]
Cheap tricks are tempting, but as my game is lacking in the graphics department, I want to redeem myself with realistic physics...anyone got a more substantial algorithm?


Rob Farley(Posted 2004) [#5]
http://www.learner.org/exhibits/parkphysics/bumpcars2.html
http://www.physicsclassroom.com/mmedia/momentum/trece.html
http://ffden-2.phys.uaf.edu/211_fall2002.web.dir/Ben_Townsend/PhysicsofCarCollisions.htm


Ryan Moody(Posted 2004) [#6]
Thanks again for the help Rob, but the links you gave me mainly focused on using mathematical models which, although giving realistic results, were far too complex for my simple game! I think I will resort to cheap tricks after all as my game is rather retro and could get away with a basic collision routine. However, if anyone has actually made a 2D racing game, I would be very grateful if you could provide me with the relevant algorithm(s) to enhance my game's quality (Note: I'm not actually using BlitzPlus - I'm using its predecessor - BlitzBasic, so I may need a psuedocode version of your algorithms in case there's any incompatibilities between the two languages)

Thanks,
Ryan


Ryan Moody(Posted 2004) [#7]
I really need help now! I've made an algorithm, but it treats the cars as dimensionless particles, so it will not work. The fact that a car is not a particle creates the problem of determining which car is pushing and which is being pushed in a collision.

See below for an example


Ryan Moody(Posted 2004) [#8]
Example:

Situation 1

<<<<CAR2
///////^
///////^
///////C
///////A
///////R
///////1

Situation 2
^
^
C
A<<<<CAR2
R
1

In both situations, Car 1 is going up, and Car2 is going left. However, Car 1 is the 'pusher' in Situation 1, but Car 2 pushes in situation 2. The 2 collisions will have different outcomes...the question is, how do you determine what these outcomes will be?

Any ideas will be most appreciated!

Ryan


Ryan Moody(Posted 2004) [#9]
Come on people, I need help!


WolRon(Posted 2004) [#10]
What's wrong with this webpage? 2 dimensional collision

If you don't know how to use these formulas (Pythagorean theorem, SOH CAH TOA) then look them up.

What you are asking for requires some understanding of physics and trigonometry.

Definition of SOH CAH TOA

Good explanation of how to use the Pythagorean theorem

Trig Course


Ryan Moody(Posted 2004) [#11]
I've studied Maths & Further Maths at A-level and I'm predicted an A grade for both (results tomorrow!), so I'm quite familiar with Pythagoras and Trigonometry!

The 2 dimensional collision webpage you provided was good WolRon, but it still assumed that the cars were particles - it doesn't address the problem stated in my previous post regarding the 2 different situations (see above).

Any other ideas?

Thanks,
Ryan


WolRon(Posted 2004) [#12]
This page may help or at least lead you in the right direction...

Instead of brakes, think of it as an opposing force (collision).


Ryan Moody(Posted 2004) [#13]
You misunderstand me WolRon! My problem doesn't concern braking, it concerns the fact that 2 cars moving along fixed vectors can collide in many different ways, as illustrated in the 2 situations given 5 posts ago.

Any solutions people?

Ryan


Perturbatio(Posted 2004) [#14]
I may not fully understand you either, but presumably you store both the cars vectors and rotations/current rotation speed?

Couldn't you create collision zones for the cars, something like this:



WolRon(Posted 2004) [#15]
No, I think I understand you. You want to know how to handle the collision depending on where the car is hit.

I think what has been said so far could still be used. The only thing I would add is to maybe have TWO points of reference for each car, one in the front and one in the back. Then when a collision occurs, you can check the distance and angle from the collision to each point of reference to determine how much of the colliding force to apply to the front and how much to apply to the back. This should (I'm hoping) cause the car to react in a realistic way.

For example, if the first car was broadsided in the front, you would expect the front half of the car to move sideways more than the rear. Likewise if the first car was broadsided in the middle, the entire car would shift sideways fairly equally.


QuietBloke(Posted 2004) [#16]
here is another link you might want to look at

http://uk.geocities.com/olivier_rebellion/

Plenty of tutorials and sample code ( in C I believe ).

The polygonal collision and response link might help.


Ryan Moody(Posted 2004) [#17]
Hi Perturbatio, WolRon and QuietBloke (how do you come up with such names?!). I've considered each of your ideas carefully, but I've found potential flaws:

Pert's idea of applying 'collision zones' would be rather inefficient as you would have to create a 72 frame image for each zone to allow collision checking for all of the car's 72 frames (My cars consist of 72 frames, where the car is rotated through 5 degrees from frame to frame). Another point is that if a car has say 8 collision zones, at least 64 (8*8) different 'types' of collisions could occur, so a lengthy table telling the program what to do in each situation would be required. (I say 'at least' because a car may collide with another in more than 1 zone, especially at the cars' vertices).

WolRon's idea of using reference points would pose a similar problem as these points would change their positions when the car rotates. Although the equation of a circle could be used to calculate the points' positions, one still needs to find out the point where the actual collision has taken place to make use of the reference points, which is a near impossibility!)

And QuietBloke, I'll be honest, I didn't really check out the zip files contained in your link as I doubted from their names whether they would address 'spinning', and I wouldn't be up to translating potentially mathematically complex C code into Blitz.

I'm going to extend my search for a solution outside the Blitz community, but suggestions are still welcome. If all else fails, I'll resort to cartoony style collisions (i.e if 2 cars collide then the slower one is spun out of control and others can drive through it whilst incapacitated) as my game is very basic and is based on the cartoon "Wacky Races".

Thanks for the help and keep the suggestions flowing in!

Ryan


Pongo(Posted 2004) [#18]
Actually, you really need to check out those files,... they are the best answer you have gotten so far. The 3rd from the bottom is probably the best for learning.


Ryan Moody(Posted 2004) [#19]
Hi Pongo,

I checked it out, and I agree it's a good resource, but as it was C orientated, I didn't understand some of the terminology - psuedocode would be prefered. I want to keep the algorithm as simple as possible and obtain 'basic' realism without applying complex physics, too.

Sorry to be difficult, but keep trying!

Ryan


Pongo(Posted 2004) [#20]
I agree about the C code,... I'm in the same position as you are on wanting to learn this. I have a racing game of my own I wish to work on, and I need to have proper collisions (with rotations) working. I don't want to use a system like Tokamak, because: a) I want to control and understand it myself, and b)I'm not all that excited about most physics systems car setups.

These examples looked almost simple enough to understand though, and I was hoping to get a better look this weekend. The worst part for me interpreting C code is the amount of source files involved, and having to jump around so much.

Anyways, maybe someone will be generous enough to make a blitz physics tutorial based on those that would cover things like this from a VERY basic level, but until then I think that analyzing those examples are your best bet.

Edit: What would be really nice would be a tutorial that continues from where this one leaves off, and covers through rotational forces. http://www.blitzcoder.com/cgi-bin/articles/show_article.pl?f=gamesnickbull02272002.html

also, check out the 2d Verlet library by andreas_blixt here. http://www.blitzcoder.com/cgi-bin/showcase/showcase_showentry.pl?id=andreas_blixt10032003205007&comments=no


Ryan Moody(Posted 2004) [#21]
Yes, the continuation of that tutorial would probably have been useful. Yet, I couldn't get the Verlet program to run for some reason...oh well. You mentioned Tokamak in your post and I've heard about it a few times before - could you tell me a little more about this system please?

Thanks,
Ryan


Ryan Moody(Posted 2004) [#22]
Hi everyone. I think I've found the best resource for this topic: http://www.myphysicslab.com/collision.html . The maths is heavy in some places, but it seems implementable and provides 100% realistic collisions.

Hope this helps!

Ryan


Ryan Moody(Posted 2004) [#23]
Me again!

I've come to the following conclusion: It's simply too difficult a task! Consequently, I've resorted to 'cheap tricks'...and I must say, they are actually quite realistic. The algorithm I've coded certainly isn't perfect, but for an arcade racing game, it's quite acceptable.

Even so, I would like to see continued discussion in this field of physics, not for my game, but for the benefit of future coders.

Thanks everyone for your help,
Ryan


Rob(Posted 2004) [#24]
Shame. All you needed was snooker physics. Look for ball to ball, or snooker physics.

Then you need Oriented Bounding Box collision. It might even be in code archives?


Rob(Posted 2004) [#25]
You can also use TOKAMAK for 2D games. It calculates the physics in 3D but it is up to you how you represent the results.

You can also correct tokamak each frame to keep the cars on the floor for the top down racer. It also comes with car sample.

http://www.blitzbasic.com/Community/posts.php?topic=36626
And www.playerfactory.co.uk (click forums)


Ryan Moody(Posted 2004) [#26]
I found "Ball Collisions" in the code archives, but as balls are circular, the algorithm didn't take spinning cars into account. Regards Tokamak, it sounds useful, but the process of integrating one program into another sounds daunting. I'm happy with the algorithm I've just made now - it's realistic enough and doesn't spoil the gameplay.

Ryan