title: The Physics of Motion in Game Development date: May 2026

The Physics of Motion in Game Development

Building a 2D engine from scratch is an exercise in pain and profound clarity. When you use Unity or Unreal, the physics of motion are abstracted away behind simple method calls like Rigidbody.AddForce(). But what is actually happening?

To understand this, I decided to build Siege of the Hearth in pure Python. No external game frameworks, just raw math, vectors, and rendering pipelines.

The Problem with Black Boxes

When we rely heavily on powerful abstractions, we often experience what I call conceptual erosion. We know how to use the tool, but we lose the understanding of the fundamental mechanics underneath. This was the same hypothesis driving my research with MindTrace AI and LLMs, but applied to software architecture.

"Building the wheel isn't merely about the wheel itself; it's about mastering the physics of motion."

Vector Math and Collision Detection

In a raw engine, every entity is just a mathematical vector moving through a coordinate space. To make two objects collide, you can't just check a box in an inspector panel. You have to implement AABB (Axis-Aligned Bounding Box) collision detection or SAT (Separating Axis Theorem).

def check_collision(rect1, rect2):
    return (rect1.x < rect2.x + rect2.width and
            rect1.x + rect1.width > rect2.x and
            rect1.y < rect2.y + rect2.height and
            rect1.height + rect1.y > rect2.y)

This fundamental truth, that a game is essentially an infinite loop of reading inputs, updating mathematical states, and drawing pixels, completely transformed my perspective on software engineering. It shifted me from thinking in terms of static scripts to dynamic, continuously evaluating systems.

Conclusion

We build abstractions because they save time and allow us to scale. But every engineer should occasionally strip away the layers and work at the foundation. It forces intellectual humility. It demands that you respect the craft.