I would like to get input from the community regarding how best to represent simple objects in a Box2D based simulation.

Some background:
Without going into too much detail, think of a top down game with a character and some 'food'. You can picture PacMan™ even. Suppose I will simulate the character and the walls to be Box2D so the guy cannot leave the maze and I get collision feed back etc.

My question:
Should the 'food' be part of the Box2D simulation?

My thoughts:

The food doesn't need to be in the simulation because..
It doesn't move.
As soon as the character collides with the food it is removed from the game.
It should not apply any force to the guy, or anything, ever.
Nor should anything ever need to apply force to it.
It's extra computation that isn't necessary.

The food could be in the simulation because..
I am already using Box2D.
Box2D can handle the collision events for me.
Again, Box2D can handle the collision events for me; I don't really want to check for collisions myself.
Box2D should let the food 'sleep' so it won't be much extra computation, correct?

What do you guys think? Do the benefits outweigh the costs here? Are there other pros/cons I'm missing?

I look forward to getting feedback.


It all depends on the complexity of your simulation. The more objects you have the more time it will take to solve the collisions.

You can set your food filters to collide only with your player and your food bodies type to static.

Then when you collide simply disable the collision resolution and add your food objects to the "end of lived" list.

You might have many objects like that so this process will be simple to setup and repeat.

If your simulation starts slowing down or if you want to increase performance, all you have to do is to use a position and check the distance of all food objects with your players. This is a very small operation and will be faster than letting box2d handle it.

Your food objects can even be reduced to an array of recyclable vec2. They will take much less space in memory and in processing time.

It also depends on the structure of your game. If you can simply add an new system and components to your entities you might find it simpler to use your own system for the food. have a look at Component Based Entity Systems

Concerning javascript I would go with my own solution as the garbage collector and other mechanisms in js tend to create some inconsistent results with larger amounts of bodies.

  • \$\begingroup\$ Hey Coyote, thanks for the response. I think that's the real point, "it all depends on the complexity". I'll leverage Box2D until I actually see my "simulation start slowing down" and optimize then. Great link BTW! \$\endgroup\$ – Sean Connolly Feb 17 '13 at 14:55
  • \$\begingroup\$ I don't see how you would make a much faster simulation yourself than the one in box2d? I mean with space partitioning it doesn't really add much complexity does it?? Or am I missing something? Seems to me like checking the distance from all food object to the player should be much slower... \$\endgroup\$ – Mikael Högström Mar 5 '13 at 19:23
  • \$\begingroup\$ It depends on the size of the levels, on the number of food object, on the existence of the objects when they exit the view (I have a game where certain objects stop existing when they leave the view, i.e. particles, bullet holes...). It also depends on the structure of the level. If the level is build around a tree structure you can only test each player against the food objects in their branches. In a tile based game you can test only against food object within the tiles adjacent to each player... If you already have a structure used for level partitioning you can use it efficiently. \$\endgroup\$ – Coyote Mar 6 '13 at 0:21

I think you should include food in the simulation.

If you do you will already have efficient checks for collisions with player body which you will need to make yourself otherwise. If you do not iclude it in the simulation you might need to implement a sweep and prune algorithm yourself (or maybe some space partition or similar) that box2d will already be doing for you.

What you need is to use sensors which detect collisions without having a "response".

Who knows, one day you might want to let different types of physics apply to the food as well? Magnets, explosions etc might need to apply forces/impulses and then you already have a lot of the structure in place.

  • 1
    \$\begingroup\$ +1 for mentioning sensors which is the best choice for triggers like a powerup etc. \$\endgroup\$ – bummzack Feb 14 '13 at 19:29
  • \$\begingroup\$ Agreed. Thanks for the response Mikael. I'll include the food in the simulation and only optimize when I identify a performance issue. Cheers! \$\endgroup\$ – Sean Connolly Feb 17 '13 at 14:56

My thought is that you could use it - Say as a static body and assign it to an impact group that has no effect on other bodies. But like you say, box2d will do collision for you so it would make it a lot easier to implement pacman eating the food. And also like you say, it would be asleep so it wouldn't cost too much more in computation.

Why make it more difficult - you should probably use the engine as it does a lot of the heavy lifting and doing so shouldn't add too much (if anything) to the processor use.

  • \$\begingroup\$ I think this is the right answer until too many food objects start slowing down the simulation. If there is no such issue keep the food in the box2d simulation and collide without resolving the collision. \$\endgroup\$ – Coyote Feb 14 '13 at 15:59
  • \$\begingroup\$ @Coyote Simply make it so that the food objects are destructed after a amount certain time. \$\endgroup\$ – Kenneth Worden Feb 14 '13 at 21:22

Your Answer

