Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

The most advanced games I've made are a 8-ball pool game made with the physics engine Box2dFlashAS3 and a platform game with levels.

When I did platform games, I've always wished to know how to make an engine, so that I could re-use it. When I see games that have slopes, curved slopes, perfect gravity and real-life physics, I've always wished I knew how to code the engine.

Please suggest techniques and articles for whatever relevant knowledge-base is necessary.

share|improve this question
    
@Answerers: Links aren't answers. –  Anko Feb 24 '13 at 13:23
add comment

closed as not a real question by Byte56, Trevor Powell, Sean Middleditch, bummzack, Josh Petrie Feb 25 '13 at 17:35

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

6 Answers

up vote 12 down vote accepted

While I recommend against rolling your own physics engine for anything other than the experience of doing it (just realize you probably should throw it away when you're done -- it's really hard to get all the edgecases and numeric limit/stability issues sorted out, and your time may be much better used by contributing to an existing engine), here are a few resources:

Pool Hall Lessons: Fast, Accurate Collision Detection Between Circles or Spheres discusses circle/circle and sphere/sphere collision.

The N Tutorials are wonderful for a basic understanding of Separating Axis Theorem-based detection and response.

share|improve this answer
    
thankyou for th N tutorials –  Vishnu Nov 2 '10 at 10:59
add comment

Erin Catto has all the GDC lectures about Box2D's implementation online. Box2D also has straightforward code to read, in my experience.

share|improve this answer
    
the pdf's are really tough materials. But, when I read through the cpp and h files, as you said, they are "understandable".Thank you. –  Vishnu Oct 18 '10 at 12:52
    
+1. Box2D also is very careful about stability, one of the things that is very difficult when you are rolling your own. –  leander Oct 18 '10 at 17:00
add comment

I think this could be useful: http://gafferongames.com/game-physics/integration-basics/

share|improve this answer
    
not bad, but It doesn't take me anywhere,much. –  Vishnu Oct 18 '10 at 11:11
add comment

Probably the most comprehensive tutorial style resource:
http://www.wildbunny.co.uk/blog/2011/04/06/physics-engines-for-dummies/

See also these related articles from the same blog:
http://www.wildbunny.co.uk/blog/2011/04/20/collision-detection-for-dummies/
http://www.wildbunny.co.uk/blog/2011/03/25/speculative-contacts-an-continuous-collision-engine-approach-part-1/

share|improve this answer
1  
The wildbunny blog entries are great. +1. –  The Communist Duck Jun 5 '11 at 9:22
    
Very good resources. Easy to understand. Thanks –  noobcode Feb 28 '12 at 8:21
add comment

Here's how you might do it:

Approximating movement

Every physics object needs these vectors:

  • Position: Where the object is.
  • Speed: How its position is changing.
  • Acceleration: How its speed is changing.

So, intuitively, you need to do this sort of thing every frame to every physics object a:

a.speed    += a.acceleration
a.position += a.speed

Pitfalls: This is known as the Euler method of integration. This approximation is better for small speeds and accelerations and with small time-steps. In a game, this is normally true. But if an object moves really fast toward a thin wall or directly toward another moving object, it may skip collision with that object when its position is incremented by a large enough amount to cross it entirely. If you have fast-moving objects, you may need Continuous Collision Detection to get away with this.

Collision

Collision can be approximated with this sort of sequence:

  1. Detection: It is detected that two bodies intersect.
  2. Resolution: The position of each body is changed so they no longer intersect.
  3. Physics: The speed of each body is changed to account for momentum, friction and restitution (bounciness).

This is known as Discrete Collision Detection, as it happens at discrete points in time. Each step deserves attention:

Step 1: Collision detection (Are things colliding?)

For two circles: Just check if their centres are more than the sum of their radii apart.

For two rectangles: Check if any of their corner coordinates are within the other rectangle.

For anything involving more complex polygons, you'll need the Separating-Axis-Theorem, which is a topic for another question.

Pitfalls: There are really many other collision types you might want to consider. Some are really complex: Convex polygons might intersect multiple times!

Step 2: Collision resolution (Moving them apart.)

A simple method to resolve a collision is translation by minimum penetration, using values obtained from collision detection. This essentially involves moving the objects apart with the minimum possible distance of movement.

As an example, consider circle-circle collision where one of the circles is fixed in place. The minimum displacement vector has the same direction as the difference between their midpoint vectors. Its length is the difference between the sum of their radii and the distance between the centres.

This idea easily generalises to other shapes.

Pitfalls: If both colliding objects are moveable, you may have to move both of them by some fraction of the overall distance to get a believable approximation of their movement. They'll obviously have to move in different directions.

Step 3: Collision physics (Other changes.)

The most obvious thing that tends to happen is that one or two of the objects changes direction i.e. rotates its speed vector. This is pretty easy to implement.

Pitfalls: Objects might be elastic, but they might not be, in which case the total energy in the system is reduced. You might need drag due to air resistance. Friction (particularly static friction) are notoriously complex to implement.

Some conclusions

Simulation of reality is exponentially harder the more if it you want to simulate. You're walking into a minefield of countless edge cases, mindblowingly difficult formulae and ever-growing stacks of research papers.

If your needs are simple or you're eager to learn, try it.

If your needs are complex or you don't like maths, get a physics engine to gloss over the details for you. Box2D and Bullet are pretty popular in games.

share|improve this answer
add comment

The best resource for learning game physics I have ever come across is due to Chris Hecker of "Spy Party" fame:

http://chrishecker.com/Rigid_Body_Dynamics

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.