Box2D - Do these simple objects need to be in the simulation?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.