Why Your Physics Glitch Exists and How to Fix It
I spent three weeks debugging a collision issue on a platformer where characters would phase through walls at high velocity. The problem wasn't in my collision detection code itself. It was floating point precision. When I switched from single-precision floats to doubles for position tracking, the wall-phasing disappeared entirely. This is the kind of thing that eats weekends when you're not expecting it. Games run on math whether you like it or common. Not all of it is calculus or linear algebra the way you learned it in school, though. A lot of it is applied numerics and approximation tricks. Ray-sphere intersections use dot products. Pathfinding runs Dijkstra or A-star on a graph. Shaders are just vector math evaluated per-pixel on the GPU. Quaternions come up constantly for rotation, and most beginners skip them because they look weird. Don't skip them. Euler angles gimbal-lock. Quaternions don't. I wrote a whole camera system using Euler angles once. It took me two days to rewrite it with quaternions. The quaternion version was shorter and didn't break when the player looked straight up.
Normal distribution random numbers. Box-Muller transform. If you need Gaussian-distributed values for things like enemy spread or procedural terrain variation, there are standard implementations. In Unity I usually just use a simple sum of six uniform random values. It approximates normal pretty well for gameplay purposes and costs almost nothing.
The Math You Actually Need Day to Day
Vector math is the base layer. Dot product tells you angle between directions. Cross product gives you normals for lighting and steering. Both show up in every rendering pipeline and most gameplay systems. Matrices handle transformations. Translation, rotation, scaling all compose into a single 4x4 matrix in homogeneous coordinates. Most engines abstract this away, but understanding how matrix multiplication works saves you from head-scratching bugs when transforms don't behave the way you expect. I had a scene where children objects inherited wrong scales because I was applying scale after position in my own matrix multiplication. The order matters. Row-major versus column-major matters too, and engines disagree on which they use. Spline interpolation shows up everywhere for camera paths, animation blending, and procedural generation. Catmull-Rom splines are the workhorse. Cubic Bezier is more common in art tools. Both give you smooth curves through points, but they handle control differently. Catmull-Rom passes through every control point. Bezier curves pull toward control points without necessarily reaching them.
Get the Full Details
What People Get Wrong About Game Math
The biggest misconception is that you need to implement everything from scratch. Most of what you need already exists in math libraries. GLM for C++. UnityEngine.Mathf for Unity. Apache Commons Math for Java projects. The value is in knowing what function to call, not in writing the function yourself. Another trap is precision assumptions. Single-precision float gives you about seven decimal digits. That works fine for most gameplay distance. When you're dealing with planetary-scale worlds or very small coordinate differences, single precision falls apart. Minecraft handled this with chunk-based coordinate remapping. Some games use double-precision floating point for world coordinates and still snap to float for rendering. Both approaches have tradeoffs. Performance optimization with math usually means reducing operations, not increasing precision. A squared length comparison avoids a square root. Dot product normalization avoids division. These are tiny savings that compound across thousands of entities. But premature optimization based on mathematical purity instead of profiling data is waste. Profile first. Optimize the hot path. The rest doesn't matter.
I encountered a specific edge case in a networked multiplayer game where state reconciliation failed because two clients calculated the same trajectory slightly differently due to floating point non-associativity. (a + b) + c doesn't always equal a + (b + c) in floating point arithmetic. The fix was deterministically ordering all arithmetic operations the same way on every client and using fixed-point integers for network-synced physics. This added about 15 percent overhead to the physics loop but eliminated the desync entirely. Worth it.
Resources That Actually Help
Game Math by Nat Musgrave covers the practical side. Red Blob Games has excellent visual explanations of pathfinding and spatial partitioning. The GPU Gems series is free and still relevant for shader math. For reference implementations, check out the glm library source code. Reading well-written math library code teaches you more than any tutorial. Mathematics In Games doesn't require a math degree. It requires knowing which tool solves which problem and having enough intuition to catch when the math says one thing but the game says another. The code will compile. The simulation will still be wrong. That mismatch is where the actual work happens. Some approaches fail in scenarios you won't anticipate until production. SDF raymarching looks elegant until your scene has thin geometry. A-star guarantees shortest path on static graphs but becomes expensive at scale without hierarchical optimization. Fixed-step physics is stable but can cause stuttering if your frame time exceeds the timestep. There is no universal solution. Every technique has a failure mode.
The practical advice is to learn the fundamentals well enough to recognize when something is wrong, then reach for existing libraries rather than building custom solutions. Custom math code is where bugs hide. Library code has been stressed by other people's projects. Use the library. Understand what it does. Move on to the next problem.
