Omnimaga

General Discussion => Other Discussions => Miscellaneous => Topic started by: Munchor on September 06, 2011, 05:45:46 am

Title: Collision in Games
Post by: Munchor on September 06, 2011, 05:45:46 am
The very first games I coded were made in Axe, so I got used to doing pixel-level-perfect collision, because it was the best way for it. However, as I want to start developing games on larger scales, I need some help understanding how collision is done on engines that have objects moving at speeds faster than one pixel at a time.

For example, the attached video is a program of mine own, made in Python. It's a simple physics engine, but the block never has a speed bigger than one pixel, and I am using Fixed Point (x256) to get more precision.

I know, though, that on larger games objects need to move faster, but collision still works pretty well.

Code: [Select]
X = X + HORIZONTAL_ACCELERATION;
Y = Y + VERTICAL_ACCELERATION;

Basically, what I thought was. Instead of doing the code above, do:

Code: [Select]
While i < HORIZONTAL_ACCELERATION
  Check_Collision();
  X++
End

So, I thought I could add a bit of acceleration at a time, and check for collision all the time. However, I'm not sure if this is a very good idea, because I can't do X++. Sometimes, acceleration is negative.

I'm wondering if any of you has any idea of how collision is done on games, thanks!
Title: Re: Collision in Games
Post by: LincolnB on September 06, 2011, 07:09:42 pm
I hate to say this, but Collision Detection is kind of a black art. You ask for advice, people tell you there thoughts, but no one has a perfect system for perfect collisions, every time, all the time. I'm not good with this kind of stuff, so I can't really help you out, but...yeah. When it comes to collision detection, you're basically on your own.
Title: Re: Collision in Games
Post by: Builderboy on September 06, 2011, 08:10:21 pm
A simple solution to your problem would be to keep the pixel by pixel method, but also increase the number of simulation steps per frame.  So if you wanted your object to have a speed of 5 pixels per second, you would give it an internal speed of 1 pixels per second, and run the simulation at 5 sub itterations per display frame. 

Another solution is to step your object ahead the full 5 pixels, and if it collides with something, move it backwards until it is out of the object.  This is much faster than the previous method, but has the side effect of making the object sometimes 'jump' over an object if it has enough velocity to move it completely over the object in one frame.

In general, there is no custom way to make physics work, for example in my engine Zedd, I don't even make the objects come into full contact when they collide.  After a frame of movement, if Zedd detects a collision, it doesn't do anything special, it just moves the object back to where it was before, and messes with the velocity.

Like buttsfredkin said, there is no 1 rule for collision physics, and as such, people are rarely going to be able to give you code.  But we can give you concepts and ideas that can help you develop and engine of your own.  And over time, as you write more and more collision engines, you will learn to be able to create a dedicated specific engine for any game you need :)