When to use Box2D?

[Seltzer]

Hello lovers.

I've been using LOVE off-and-on for a year or so, and one issue I keep running into is physics implementations.

I've been prototyping a couple of simple-ish platformers using my own physics implementations, but physics is not my strong suit so they can become unreliable in certain situations. They have also been very time-consuming to write/tweak. One such unreliability has been dealing with variable time-steps. The love.physics page notes that Box2D is heavyweight and not good for basic game collisions, so I've been avoiding it.

I have 3 questions:

• How sophisticated must the game collisions be to constitute using the love.physics library?
• Is love.physics really that inefficient, or does that warning at the top mostly serve as a detour for inexperienced users?
• Does anyone have suggestions as to what I should be using for general collision detection and movement if I don't use love.physics?

Thanks in advance!

[Foxcraft]

Hey Seltzer,

I think you need to figure out what you want to do and deal with. If it's just a matter of getting your math straight for something like jumping, you might not need a whole new system to handle what you want to do, you just need to understand what you need to deal with.

You can really use whatever you want, it's just finding what's good for you and your project.

I'm trying to work out what sort of collision system I want to use myself and recently picked some non-computer friends' brains on how to work out my own jumping. Talking with them a bit, them taking it from a more equation perspective and us just talking about how jumping works in general (push off ground more than gravity pulls down, hit 0, and come back down) really helped me.

I've been poking at bump.lua, though thinking on more advanced options instead for getting slopes and uneven terrain to work (Fizz X, etc.) if it'd be too much with bump. I personally would rather not use Box2D simply because I'd rather use less resources if I can help it. But if it comes to it, I'd use it

The other options besides Box2D, as I understand, basically just handle the collision detection and leave implementing the physics up to you.

So, what are you particularly trying to do and are having trouble with? Implementing jumping and delta time (dt)?

[Seltzer]

Thanks for the reply!

In one of my games, I'm trying to simulate what a plastic bag looks like when it's snagged on something in the breeze, which has me completely stumped.
In another game, I'm trying to do general movement calculations (i.e. jumping, bumping into things, etc.).

One of the particular issues I've had is making jumps look and feel right, and make sure that movement accelerates/decelerates properly. It works relatively well now, but it took a lot of time and tweaking to get right, so I was hoping there was a simple physics implementation available that did just that. I don't really need most of Box2D's features, but I would like a robust implementation of its basic functionality.

I think the delta time issue can be solved by choosing an arbitrary time step (say maybe 0.1) and iterating updates on that step until lagged time catches up to real time. Do you know of a better solution?

[Foxcraft]

I can definitely see how the plastic bag can be stumping. That's a tough one. I think you'd definitely need some custom stuff, even with Box2D (though I don't know much about that). I'd say the most of it is figuring out how to control the wind part, and once you figure that out, the rest might more easily fall into place. It'd take some thinking though.

For the simple jumping and bumping, you can probably use something as simple as bump.lua if you want to use a library for collision. Getting the jump to feel right is tricky, I know that. I think what has helped figuring out how to get something decent is how gravity messes with the acceleration. That is, you start with a jump force, which changes by gravity. Once that force runs out, you start to fall at gravity's rate. Gravity doesn't act the same as a regular push or pull. It's the rate of change.

These are some of the functions I made as part of playing with the Sockmunkee Dev platformer tutorial (which unfortunately stopped before implemented how to jump).

Code: Select all

function player.physics(dt)
   player.x = player.x + player.xvel * dt
   player.y = player.y + player.yvel * dt
   player.yvel = player.yvel + gravity * dt
   player.xvel = player.xvel * (1 - math.min(dt*player.friction,1))
end


function player.move(dt)
   if love.keyboard.isDown("right") and 
   player.xvel < player.speed then
      player.xvel = player.xvel + player.speed * dt
   end
   
   if love.keyboard.isDown("left") and 
   player.xvel > -player.speed then
      player.xvel = player.xvel - player.speed * dt
   end
end


function player.boundary()
   if player.x < 0 then
      player.x = 0
      player.xvel = 0
   end
   
   if player.y + player.height > groundlevel then
      player.y = groundlevel - player.height
      player.yvel = 0
   end
end


function player.jump()
   if love.keyboard.isDown(" ") and 
   player.yvel == 0 then
      player.yvel = -500
   end
end

function UPDATE_PLAYER(dt)
   player.physics(dt)
   player.move(dt)
   player.boundary()
   player.jump()
end

A little slow of a jump, but messing with the gravity in main.lua and the jump speed can affect those. Alternatively, you can go by the jump time or jump height, but it kind of makes more sense to me (personally) to play with the forces instead. It's not perfect in some other ways, as I should probably make a player.onGround value that lets me check if the player is on the ground (which I can figure out in player.boundary) instead of going by the y-velocity, which might hit 0 at the peak of the jump. But it makes for the right kind of jump arc, it just needs playing with the forces to get right. You'd have to do the same with Box2D, since by default, it uses realistic values which platformers don't really use.

Here's video 1 and video 2. It's a nice walkthrough that I learned some good stuff from, despite being unfinished.

The LÖVE libraries like bump have demos, which include jumping. I'm probably going to start picking through them soon myself.

The above also demonstrates the way I'm used to using dt. I've played with it in some other ways in the past, but it's been a while.

[Jeeper]

How sophisticated must the game collisions be to constitute using the love.physics library?

Well, if you intend to make a super simple game I suppose that box2d could be a bit overkill, but on the otherhand it could still be good to use it in order to learn it for when you need some of its awesome features.

Is love.physics really that inefficient, or does that warning at the top mostly serve as a detour for inexperienced users?

I have not had any efficiency issues using box2d and I would not call box2d too complicated for pretty much anyone. I find the warning silly.

Does anyone have suggestions as to what I should be using for general collision detection and movement if I don't use love.physics?

If I did not use box2d and would need collision that is a bit too sophisticated to be arsed to code myself, I would for sure use kikito's Bump library. It is super simple to use and a solid library.

[kikito]

I would not say that Box2d is "heavyweight" in the sense of that it is "slow". Lots of games use it with success, and I've yet to find someone who points at box2d as a performance bottleneck (assuming he/she was not doing something crazy with it).

The problem box2d has is that is is heavyweight cognitively and in behavior. You have to learn a lot of concepts and their relations in order to use it. This is in part because it models physics, not only collisions. I also should point out that the physics it models are more or less "standard newtonian".

This means that if your game requires a lot of realistic physical modeling, with solid objects, many kinds of joins, and physical properties like friction and restitution, box2d is a good match for it. On the other hand, if your game only needs a small set of rules (maybe collision detection, a bit of gravity and that's it), or if the concepts it requires don't match well with newtonian physics, then box2d might not be a good match for it.

The best scenario that I can think of for box2d is Asteroids, or a ship game with similar handling. The rules of physics required for that game are almost identical to the "default" ones given by box2d. So there will be "tweaking" (change the value of this force, increase the restitution of this other), but almost no "trickery" (i.e. replace this shape by a bunch of line shapes). You can even do fancy articulated ships with joins quite easily. You will still need to know physics, mind you. But you will not have to 'trick' box2d almost at all.

The next place I can think of where box2d is good is in a pinball game. You don't have lots of concepts in a pinball game, but the physics of the ball can be done with a bit of the default box2d gravity and collisions, and the rest of the elements of the game will mostly be static objects with certain special properties (like restitution). So they are a good match.

On the other side of the spectrum, there are most platformers. In general, a platformer doesn't need lots of concepts: "player", "platform", "gravity", "jump". Maybe some "ground" and "enemies".

Not only that, but the physics needed, while more or less "realistic", are not newtonian. For example: in a platformer, when there's a column of stacked boxes, you expect the player to be able to "run over the one on the top and jump forward" (maybe to reach some hard to reach treasure). In newtonian physics, with the right coefficients, the box at the top will "go backwards" as the player tries to runs over it; then probably the column will fall backwards, and the player downwards. This is realistic, but not expected in a typical platformer game.

If you want to get the "platformer feeling" with box2d you end up having to "fight" the realism to "simulate" what we expect from platformers. You end up doing things like giving boxes infinite mass (for example). But then this has unintended consequences: if you later decide to manually move one of those boxes with setVelocity (even with a slow velocity), and it hits the player, it can propel him into the stratosphere, because of the conservation of momentum. And so on.

This is fine if you are trying to do a "waky" platformer, or if you are willing to spend a lot of time "fighting" and "tricking" box2d so that it behaves like you want instead of how it wants to. Lots of people go this route. I personally think it is like killing a mosquito with a bazooka.

[Seltzer]

Thank you everyone for all the helpful replies. Plastic bag physics is going to be a challenge, but I think I understand what Box2D is good for now.

[s-ol]

-snip-

Well put kikito.
It seems a lot of people/newbies don't realise there are quite distinct meanings of the term physics in relation to games and box2d, when we talk about physics in the context of your "everyday platformer" we refer to the basic rules of movement, which do not at all line up with the scientific field of physics (and it's subset of mechanics).

In context of box2d we do also talk about "rules of movement", but about realistic physics that try to match real life and newtonion physics as close as possible (to some level of detail ofc). When using box2d you cannot change the actual physics code but instead have to "fight it" by applying forces and impulses, so it might be hard to get some specific behavior you want without a good understanding of macrophysics.