# When should I use a physics engine? [closed]

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?

## closed as primarily opinion-based by Alexandre Vaillancourt♦Mar 11 '18 at 23:23

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

• 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
• @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
• @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

## 5 Answers

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.

• 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." – Exilyth Nov 29 '11 at 20:35

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.

• 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
• 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
• 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
• who wouldn't want power windows? – Spooks Dec 1 '10 at 20:24

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.

• 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
• @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

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.

• 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
• 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
• @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

You must decide according to the situation

Pros using your custom engine

• Software under control (no change due to new release)
• Suited for your game (only the features that you need for your game, in the way you need them)
• Flexibility (any crazy dynamics you want can be encoded, any future feature would not rely on the engine)
• Learning Experience (maybe one day you need to improve an engine and you need how to build one)
• Less studying and programming for simple features (sometimes to do something with an engine may require to understand its structure deeply.. and may be not worthy)
• Higher performance for simple features (for simple specific features you may obtain higher performance than with a quite general purpose engine)
• Less memory (the object and the code may take much less space and memory when only the necessary features are used)

Pros of off-the-shelf physics engine:

• May adapt to new hardware and new OS without much effort
• Less studying and programming effort for complex features
• Higher performance for complex features