How does a custom physics engine connect to a tile graphics engine?

Question

I’ve been looking into adding physics to my tile based side scroller game, and it seems like the best option might be to write my own engine to handle things like collisions and gravity due to the simplicity of what it is I need.

I mostly understand the math that I need and some of the techniques to get the functionality I want (such as slopes), but the part I'm still missing is how the physics relates to the graphics, as well as how to actually implement that connection.

All that I've seen is that physics and graphics are separate, but are updated together (the textures/animations change according to the interactions from the physics engine). Aside from that, however, I have very little idea what I'm doing.

My question is: When it comes to a tile-based game, how do you handle physics bodies and their creation? And on top of that, what would be an efficient way to connect the two engines to one another?

Answer 1

The physics engine can be thought of as a data processing job.

It takes in a collection of physics objects including...

• collision shapes
• physical attributes (masses, material friction/elasticity coefficients)
• last step's transformations (positions & orientations in the world)
• last step's motion states (velocities & angular velocities)

It does some math on them, and spits out updated versions of the last two:

• this step's transformations (how has the object's position & rotation changed)
• this step's motion states (how will it continue to change in the next step)

Your graphics engine is another data processing job, that takes in drawing objects including...

• primitives (meshes / sprites)
• surface descriptions (materials / textures)
• transformations (where & in what orientation to draw the primitives)

You'll notice an overlap: the graphics engine consumes the updated transformation data that the physics engine outputs.

So the two engines don't really need to connect or know about one another at all. They just both know about a common data type that describes the position and orientation of a thing.

Not every physics object needs to be drawn (physics sims will often include invisible collider objects), and not every drawn object needs a physics representation (eg. backgrounds or VFX), so you probably don't want to couple the two concepts any tighter than the fact that they both care about positions & orientations.

You run the physics engine's step or integration method to update this data, then the graphics engine's draw step to display the results. Then you loop back and update it again..