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.
Feedback: Your introduction "From Mario bouncing off a Goomba..." might be a bit misleading IMO because most games like the classic Super Mario titles on NES and SNES do not require and did not use most of these calculations.
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.
Very nice. The section "A word about math" really is important. I am admittedly not good at math, but I was able to build a VERY (extremely, even) rudimentary physics simulation many years ago by really really simplifying the math concepts. I was essentially iterating on the building blocks, points, lines, etc. With a lot of small steps and a lot of visual debugging lines, it ended up extremely janky and slow, but it did kinda work!
Great article and very fun to read, as someone who also doesn't have a strong math background, so thank you for explaining these "trivial" concepts :)
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.
Sounds intriguing! I’m probably your ideal audience, given a large coding background, low math background, and current writing 2D focused games.
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!
I'm curious whether you've considered using Box2D[1] as a reference, since it is a pretty complete implementation of rigid body physics? Or is it more that you want to re-implement things from scratch as part of this tutorial?
Oh! Look, a well-researched, deeply-explained, and interactive post.
Honestly, when I initially read the domain name and noticed the TLD is ".ski" I was thinking it is from the author who wrote about Mecanical Watch [1] and other cool stuff.. it turned out to be a totally different one but of similar quality. What's the secret sauce behind this ".ski" TLD :)
There is very simple reason for this: "ski" it the most common suffix of Polish surnames, of which the most popular is Kowalski. There are a lot of people out there either Polish or with Polish origins.
Author of https://ciechanow.ski – the site we all love here – is Polish programmer working for Apple.
One side project I am working on right now is a 2d space shooter I am developing with my son. The idea is to have top down look, have each player control some kind of ship and fly in an enclosed area filled with space debris and shot opponents. An important aspect of this game is that the space debris can be moved around the arena and used creatively to capture opponents, prevent them from achieving their goals, etc.
As part of the project I was thinking we will skip game engine altogether because I wanted to teach my son a bit more about how to structure the application, etc. I thought in future we would use a ready game engine but at least once we would go through the exercise of implementing everything.
Everything was fine until we approached the problem of collision detection and handling. That's when things went downhill pretty quickly. Even with my theoretical math background I was soon consumed with just enormous amount of corner cases and finally decided to relent and use Box2d for this.
I am not a professional game developer, but I have over 20 years of development experience + math background and I still made the mistake of underestimating the problem. It really seems easy problem when you state it and just becomes exponentially more and more complex as you start digging into details.
Did your game require realistic physics collisions? If not, this might be unnecessary complexity. Almost no 2D shoot'em up game before 2000, and very few afterwards, go this route. Here's the common method to make a shmup with very simple rectangle comparisons:
But if your space debris objects are supposed to collide and agglomerate realistically, and if the player ships are supposed to have difficulty pushing a cluster of heavy objects out of the way, then using a physics library is sensible.
Did you come across Verlet Integration [1]? It is quite convincing and usable for a lot of use cases, and is actually quite simple. I surprised myself when I was able to create a basic physics systems in a couple of hours with this great tutorial [2].
Collisions are violations of the pairwise non-intersection constraint between bodies. Collision forces are Lagrange multipliers of these constraints. Collision normals are the (normalized) partial derivatives of the constraint function wrt one of the body's configurations.
That sounds like the kind of thing which works if you're doing physics at 1kHz+ with an integration algorithm with good numeric stability which honours conservation of energy, but in games, we're often running physics at down to 30Hz using some ad-hoc Euler-Chromer, which requires very different approaches
This is really cool! Love the explanations, the interactions, and especially the friendly tone of voice of the article. Looking forward to the ones following.
Making a 2d rigid-body physics engine is a really fun project. I made one myself in javascript before learning about linear algebra. And I dug deep into the maths to get it working. Despite months of work, I barely scratched the surface beyond the widely known basics.
Making a stable engine where objects don't compress into one another or jitter is a rabbit hole without a bottom that even the most math-heavy articles I could find rarely touched.
To learn JS I started with canvas, and without any game dev experience, made a couple of cute little browser games. One is a galaga clone that, for the most part, works OK. The hard part is the projectile collisions. Instead of taking the position of your bullet now, and where it would be in the next time step, and seeing if it would intersect with the enemy hitboxes taken in the same way, I _only_ checked on the current timestep, which means your bullets can magically go around the enemies! Silly stuff. Maybe some day I'll go back and fix it.
Wow, perfect timing. Some days ago I started to get interested in this, particularly in circle collisions. Keep it up, looking forward for the rest of the posts.
This is great. This reminds me of Chris Hecker's Rigid Body Dynamics series from GDMag/Gamasutra that I read (checks watch) almost 30 years ago! This is the classic/canonical set of articles.
Guess this is a Shameless plug but I wrote an interesting program over 12 years ago using even then very old three Js which is not quite the metal but much less abstract than today's tools. I'm always amazed when I check it and it's still running
My own attempts at 3d games failed to get good sweeping polygon polygon collision to work. IIRC I found one good demo video of a programmer demonstrating it on youtube but no code or articles or anything.
I do wish this kept going and went "and as a last step, we need to add in torque" because pretty much everyone stops at regular force vectors, but torque transfer is so ridiculously important.
[+] [-] ksassnowski|1 year ago|reply
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.
[+] [-] kibbi|1 year ago|reply
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
[+] [-] wingerlang|1 year ago|reply
[+] [-] CaptainOfCoit|1 year ago|reply
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.
[+] [-] Coolbeanstoo|1 year ago|reply
Would really appreciate the inclusion of an RSS feed so I can continue to follow along!
[+] [-] wiz21c|1 year ago|reply
Pardon my curiosity, but what tools did you use to build that page ?
[+] [-] unshavedyak|1 year ago|reply
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!
[+] [-] aa-jv|1 year ago|reply
[1] - https://box2d.org/documentation/
[+] [-] lern_too_spel|1 year ago|reply
[+] [-] nox101|1 year ago|reply
[+] [-] pmarreck|1 year ago|reply
[+] [-] redbell|1 year ago|reply
Honestly, when I initially read the domain name and noticed the TLD is ".ski" I was thinking it is from the author who wrote about Mecanical Watch [1] and other cool stuff.. it turned out to be a totally different one but of similar quality. What's the secret sauce behind this ".ski" TLD :)
___________________
1. https://news.ycombinator.com/item?id=31261533
[+] [-] kurrrrrak|1 year ago|reply
Author of https://ciechanow.ski – the site we all love here – is Polish programmer working for Apple.
[+] [-] onetimeuse92304|1 year ago|reply
As part of the project I was thinking we will skip game engine altogether because I wanted to teach my son a bit more about how to structure the application, etc. I thought in future we would use a ready game engine but at least once we would go through the exercise of implementing everything.
Everything was fine until we approached the problem of collision detection and handling. That's when things went downhill pretty quickly. Even with my theoretical math background I was soon consumed with just enormous amount of corner cases and finally decided to relent and use Box2d for this.
I am not a professional game developer, but I have over 20 years of development experience + math background and I still made the mistake of underestimating the problem. It really seems easy problem when you state it and just becomes exponentially more and more complex as you start digging into details.
[+] [-] kibbi|1 year ago|reply
https://kidscancode.org/blog/2016/08/pygame_shmup_part_3/
But if your space debris objects are supposed to collide and agglomerate realistically, and if the player ships are supposed to have difficulty pushing a cluster of heavy objects out of the way, then using a physics library is sensible.
[+] [-] JoeyJoJoJr|1 year ago|reply
[1]https://m.youtube.com/watch?v=lS_qeBy3aQI&pp=ygUSVmVybGV0IGl...
[2]https://m.youtube.com/watch?v=3HjO_RGIjCU&pp=ygUSdmVybGV0IGl...
[+] [-] alanbernstein|1 year ago|reply
[+] [-] iKlsR|1 year ago|reply
[+] [-] samlinnfer|1 year ago|reply
Back when flash was everywhere.
[+] [-] mike31fr|1 year ago|reply
Code: https://github.com/vandrieu/canvas-bouncing-ball (the collision logic is in src/collision.ts)
Result/Demo: https://vandrieu.github.io/canvas-bouncing-ball/
[+] [-] bfelbo|1 year ago|reply
If so, could you add a license?
[+] [-] ecaradec|1 year ago|reply
[+] [-] buzzcut_|1 year ago|reply
[+] [-] 33a|1 year ago|reply
[+] [-] mort96|1 year ago|reply
[+] [-] bollu|1 year ago|reply
[+] [-] gustavopezzi|1 year ago|reply
[+] [-] aDyslecticCrow|1 year ago|reply
Making a stable engine where objects don't compress into one another or jitter is a rabbit hole without a bottom that even the most math-heavy articles I could find rarely touched.
I used a series of old articles by Christ Hecker to understand the maths myself. http://www.chrishecker.com/Rigid_Body_Dynamics
[+] [-] ksassnowski|1 year ago|reply
[+] [-] mydriasis|1 year ago|reply
[+] [-] nj5rq|1 year ago|reply
[+] [-] CooCooCaCha|1 year ago|reply
[+] [-] filleduchaos|1 year ago|reply
[+] [-] pkaler|1 year ago|reply
https://chrishecker.com/Rigid_Body_Dynamics
[+] [-] swayvil|1 year ago|reply
Like those old atari games where everything was little square tiles / pixels.
But little squares aren't the most expressive geometry.
How about kisrhombille?
https://en.m.wikipedia.org/wiki/Kisrhombille
[+] [-] isoprophlex|1 year ago|reply
Besides that... Beautiful page, well done!
[+] [-] danbmil99|1 year ago|reply
http://busyboxes.org
[+] [-] Terr_|1 year ago|reply
https://gafferongames.com/categories/game-physics/
[+] [-] rrr_oh_man|1 year ago|reply
[+] [-] willvarfar|1 year ago|reply
[+] [-] TheRealPomax|1 year ago|reply