To give some context, this is only part one in a series of blog posts I plan on writing about rigid body physics.
The post is aimed at people like myself, who aren't game devs and don't necessarily have a strong math background. Which is why I spend so much time explaining concepts that would appear almost trivial to someone who has experience in this area.
Happy to answer any questions you might have.
Game development beginners often have the wrong impression that they need rigid body collision calculations or a 2D physics engine like Box2D to handle collisions. That's true if you want to make a game like Pool or something with collapsing stacks of crates like Angry Birds.
But for a 2D platformer you only need to detect collisions by comparing (axis-aligned) rectangles and to handle collisions by changing the moving character's X and Y coordinates (to undo an overlap) or setting the character's Y velocity (after using the jump button, or after landing on a Goomba's head).
This also makes it easier for the developer to finetune exactly how moving the character should feel like. (This includes inertia, but this inertia is usually not physically realistic.) Trying to use realistic physics as a gamedev beginner can easily lead to floaty and unsatisfying movement.
An example tutorial to start with this simple physics-free approach: https://www.love2d.org/wiki/Tutorial:Baseline_2D_Platformer
Are you planning to read/explain through XPBD (Extended Position Based Dynamics - http://mmacklin.com/xpbd.pdf) as well in future posts? The concept seems to be gaining traction and I've used it with Bevy (via https://github.com/Jondolf/bevy_xpbd) with big success so far, seems more stable than the usual approach.
Would really appreciate the inclusion of an RSS feed so I can continue to follow along!
Pardon my curiosity, but what tools did you use to build that page ?
Most of the physics-based example are written in WebGL using three.js. Using three.js is a little bit overkill for this because all the examples are in 2D but it's what I was familiar with. For the actual physics simulations, I'm using matter.js.
The diagrams use a library I wrote while working on the post [1].
Everything runs inside a Vue app which serves as the glue between things like the sliders and the three.js scenes and diagrams.
If I may ask a question, in your mind what’s the benefit of more deeply understanding these implementations when physics frameworks handle a lot of the really mathy logic behind collisions and simulations.
Either way I’m putting this in my read queue. Thanks!