Author Topic: Collision in Games  (Read 6325 times)

0 Members and 1 Guest are viewing this topic.

Offline Munchor

  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 6199
  • Rating: +295/-121
  • Code Recycler
    • View Profile
Collision in Games
« 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!

Offline LincolnB

  • Check It Out Now
  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1115
  • Rating: +125/-4
  • By Hackers For Hackers
    • View Profile
Re: Collision in Games
« Reply #1 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.
Completed Projects:
   >> Spacky Emprise   >> Spacky 2 - Beta   >> Fantastic Sam
   >> An Exercise In Futility   >> GeoCore

My Current Projects:

Projects in Development:
In Medias Res - Contest Entry

Talk to me if you need help with Axe coding.


Spoiler For Bragging Rights:
Not much yet, hopefully this section will grow soon with time (and more contests)



Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: Collision in Games
« Reply #2 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 :)