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.

Since I found out Box2D, I'm using it for kind of any game-like application I try to write, from very small prototypes or small programs to test something, to actual projects.

Thanks to it it's so terribly easy to handle anything from collisions, to the actual physics.

Sometimes, though, I have some doubts about it: if I only have to handle circles or AABB, and don't need advanced physics tools (joints or stuff like that), I think that a physics engine could add a sort of big, unneeded overhead.

To reassume my question: would you use Box2D (or other physics engines) in a game where physics is really simple (like Super Mario, let's say)? And, if not, why?

share|improve this question
2  
Do what feels right. Do you think your game needs a physics engine? Do you think Mario would benefit from Box2D? The newest Mario certainly has a nice feel to it with nice physics, but it doesn't feel anything like anything I've seen built in Box2D. –  Jeff Dec 1 '10 at 23:14
    
+1 Jeff, short but good answer –  Vishnu Dec 2 '10 at 10:15
    
@Jeff: That depends on if the question "When should I use Box2D?" or "When should I use a physics engine?". The new Mario certainly contains a physics engine. –  user744 Dec 2 '10 at 10:53
1  
@Joe Wreschnig: Yeah, but is there ever a case a physics engine isn't used? Only time I can think of would be a text adventure, or point and click. I guess it depends on how general you want to make your definition of physics engine –  Jeff Dec 3 '10 at 3:58
    
@Jeff: Few (non-physics) puzzle games need one, e.g. Tetris, Bejeweled. In action games, I could argue that most 2D shmups don't benefit from a physics engine, as they generally do just need AABB/circle overlap checks, no collision response, absolutely fixed movement paths, and constant velocity. Platformers, though, are all about physics. –  user744 Dec 3 '10 at 23:43
add comment

4 Answers 4

up vote 7 down vote accepted

If the memory, disk space, development effort, or processor time used for Box2D is too much for your purposes, then don't use it. Otherwise, there's no reason to avoid it if you find it useful.

share|improve this answer
1  
This is all it really comes down to. If it makes your life easier and doesn't block you from the platforms you want, it's a win, even if you don't use parts of it. –  user744 Dec 1 '10 at 20:17
    
Or, in other words - "The only reason for reinventing the wheel is learning about reinventing the wheel." –  sarahm Nov 29 '11 at 20:35
add comment

Something as easy as Super Mario no, as it doesn't really have much physics. (Mario does not affect other object's physics with his jumping)

if you are using physics in the sense of multiple items (more than one) using physics to affect the outcome of other objects, then I would use an engine.

share|improve this answer
    
On the other hand, Mario does have momentum, acceleration, a variable size, and directional collision, all of which you get "for free" with a physics engine, and are not just simple bounding overlap checks. –  user744 Dec 1 '10 at 19:06
    
I agree - I think most of the time a physics engine will give you a lot of things that would be a bit of a waste of time to implement yourself. –  Christopher Horenstein Dec 1 '10 at 19:13
3  
True it's always better not to invent the wheel, I just find that if I want just a wheel, I am not going to take a blueprint for a car. On top of that, you will know more about your game as a whole, and easier to alter/change the physics. –  Spooks Dec 1 '10 at 19:34
1  
That's a really horrible analogy. This is more like, you want a wheel and axles and maybe a steering column and motor but perhaps not the dashboard or power windows. –  user744 Dec 1 '10 at 20:17
3  
who wouldn't want power windows? –  Spooks Dec 1 '10 at 20:24
add comment

My answer is yes, absolutely use a physics engine like Box2D for simple stuff, because you shouldn't spend unneeded development time implementing some of the features that you quickly get from a physics engine. For instance, define a static body and drop a dynamic body on it, and apply force to your dynamic body for directional input, and you've got a platformer in a few minutes. I don't think that an engine adds enough overhead to make this not worth it.

share|improve this answer
2  
though, one could say that figuring out how to implement and use Box2D would take longer then to create simple physics. (though I guess this depends on the extent of the use of physics) –  Spooks Dec 1 '10 at 19:37
1  
@Spooks: I can't imagine anything "easier" than Box2D that is still useful. –  user744 Dec 1 '10 at 20:18
    
I am in full agreement with Joe here; there's just no simple replacement for the usefulness that comes along with using Box2D. I can't imagine coding up something that will fulfill one's needs faster than learning how to create some fixtures and defining gravity with Box2D. –  Christopher Horenstein Dec 1 '10 at 22:43
add comment

If the "physics" in a game is simple there is no need to import a physics engine.

I use the term physics loosely since there is a difference between modeling physics and simulating phyiscs. A very important thing to differentiate.

For example, in Mario Bros. when you run and stop you will slide a bit. Think about how you might implement that.

You can model it by defining all of the necessary variables: eg. mass, gravity, co-efficient of friction, thrust, etc. and then calculating your new velocity, acceleration, etc.

but is it worth it? You can simulate the same effect by diminishing the players' speed while they aren't moving...

Something like:

if( pressing movement key ) { 
 speed = 5; 
} else { 
 if(speed) speed--; // slide!
} 

The difference is one is physics the other is not. There are pros and cons to both. But as a general rule for simple games it is much easier to fake it.

share|improve this answer
1  
That kind of physics is gross. If you are going to fake it, might as well make it look nice. friction = .9 or some number below 1. speedX *= friction; speedY *= friction; –  AttackingHobo Dec 1 '10 at 19:58
2  
Of course, by the end of the project it turns into "if (pressing movement key and not moving and on ice and not underwater and you have this special powerup and you're not riding in a boot and ...)". –  user744 Dec 1 '10 at 20:20
    
@AttackingHobo: The point of the post isn't about making a nice sliding algorithm.. It is to illustrate the difference between a simulation and a model. –  aaronfarr Dec 1 '10 at 20:23
    
@Joe: Those are just modifications to your friction variable.. perhaps you and @AttackingHobo should chat :P With a physics engine you have to define properties for every object in the game. My point is that plugging in a physics engine for simple games shouldn't be automatic. Its situational. –  aaronfarr Dec 1 '10 at 20:27
1  
@aaronfarr: There is no difference between a simulation and a model; for these purposes they are synonyms. All you've shown is that an isolated part of a toy model/simulation is less code than the entirety of Box2D. –  user744 Dec 1 '10 at 20:28
show 5 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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