Game Physics Use Cases

Game Mechanics
#1

Something that’s been on my mind for quite a while now is figuring out how to simplify the use of physics engines in games, as generally speaking, they tend to be relatively complex to learn and use, surprise the user quite often, and in many places require extensive boilerplate cut and pasting, which is all Very Bad.

Since I’m a bit too close from dealing with the internals to have a fair view of what the average user might expect, I’d love if anyone that’s interested could share some example use cases for physics, i.e. in an ideal world, what code would you like to write to add physics to objects, and how would you like to be able to manipulate them afterwards? I’m particularly interested in what the highest priority features are, from an external point of view.

#2

Interesting subject, but it’s hard to answer.

So far, I only work with body that can’t rotate so the physics is much more easy. But, if I use a physics engine I would like him to handle the collision detection for me. Not only the easy thing :

if(circle.intersect(line)){return true;}

but also giving me usefull information about where the collision happen. For example, in a line vs circle collision there is 3 places on the line that the circle can hit : in the middle and on each end. If the collision happen on one of the end it’s like a circle vs point collision.

There is more to it. Take for example the case where you have 2 line touching each other with an angle of 180 (so they are making a longer line). If you have a circle hitting the end of one line and that end is above the other line, you would wan’t do desactivate the circle vs end of line collision, or you circle would hit a flat area and bounce with an angle which is weird.

In conclusion, collision detection is the essential for me. I still like to deal with the movement personnally, it’s not like if F = ma is really hard… I know that the search for collision (checking every body against every body) can be an hard part too and it’s almost always the same, but you lose a great deal of flexibility if someone else code handle it for you.

N.B. My opinion is subject to change as I progress in game development.

#3
  • side view platformer game or something similar where there’s gravity.
  • top view game like an RTS or Grand Theft Auto style game - no gravity.

If you’re trying to think of a way to make JBox2D more accessible, one thing i thought might help is to have a simple example that just uses java2D to paint (rather than Processing which people have less experience with). I’ve made a small example which does that and I’d be happy to contribute. Also, the less abstraction that’s used in the examples the better.

Another thing, JBox2D doesn’t do things the usual java way - like there is no ArrayList bodyList - there’s a single body with a link to the next body, so it’s kind of a linked list. I suppose that’s what’s done in C but in Java it seems a little weird.

But obviously keeping it like the C version makes it easier to port, so that’s good.

By the way, JBox2D rocks! 8)

#4

I’m not to familiar with any particular physics engine, dabbled with odejava, joode, and started to port bullet (until jezek2 did the work for me ;)), but as far as I would like to see is something along these lines:


Body b = new Body(shape, mass, location);
engine.add(b);

and that’s all it takes to get something in the physics engine, depending on how hard it is to specify the shape. Primitive shapes would be pretty easy to include in the one-line constructor still.

As far as using goes, I think the standard engine.step() or engine.step(dt) is perfectly usable. The important thing is how to update the body and get at the collision information. Maybe something like:


b.setLocation(l) or b.setVelocity(v) or b.applyForce(f); // and similar getters
b.getCollisions() -> list of contact points

I guess a lot of this stuff feels pretty standard, so I don’t think I’m helping too much.

Maybe a nicer thing would be to have collision listeners addable to bodies, but instead of calling them in the middle of an update, etc. it could just be at the end if a collision changed (it might help reduce newbies confusion at getting at and updating bodies from contact information).

The final thing is that it would be nice to have an easy framework built into the physics engine for moving physics transforms into the transforms of the graphical objects. That way it’s not necessary for a graphics engine to come out with a physics wrapper, and the transform handling could have options to interpolate transforms if the step times are slow.