41–50 of 69 posts
I know this post is focused on collision resolution, but I was still a little disappointed to see collision detection handwaved away. In my experience that's where the real headscratchers are.
Hey everyone, author here! 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…
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
Hey everyone, author here! 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…
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.…
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.
Earlier quoted context omitted.
It's still the same principle even in games. If you are trying to explain where forces come from and how resolution works, you need to ground it in something. Otherwise you are just adding extra assumptions onto assumptions.
In proper physics simulations, everything's about forces, most things are springs, and you never teleport stuff. In games, modelling the ground as a spring really doesn't work and teleporting entities when they collide with parts of the world often makes a lot of sense. It's just not the same. EDIT: If I'm incorrect, please explain how. I've written some game physics systems and seen some proper physics sim systems a…
It's true that some commercial solvers like Ansys use spring/penalty methods, but this is due to the spring forces being easier to couple to other solvers. It's harder in the Ansys force/velocity formulation to combine things like elasticity and fluids to their rigid body solver. To deal with the instability of systems of many stiff springs they have to take many small timesteps to avoid convergence issues.
More recently techniques like XPBD have been gaining popularity, particularly in film, which use purely positional constraints and variational methods to combine many different types of physics simulations. There's a really great and approachable series of videos by Matthias Muller on youtube which goes through how to implement all this in JS https://matthias-research.github.io/pages/
Finally it's funny you should mention games, since many older games used spring methods for physics. It was only when constraint based solvers became popular after Havok/Half-Life 2 did we start to see games with real rigid body dynamics and stable stacking of boxes. Older physics games like Trespasser ( https://en.wikipedia.org/wiki/Trespasser_(video_game) ) had many bugs due to the use of hacky spring physics. For a good explanation of how games do it today look at Erin Catto's work on Box2D https://box2d.org/publications/
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.
Neat! do you have a resource that explains this perspective further?
This is a specific reference on how constraints model contact between rigid bodies https://box2d.org/files/ErinCatto_UnderstandingConstraints_G...
Most games since Half Life 2 use constraint forces like this to solve collisions. Springs/penalty forces are still used sometimes in commercial physics solvers since they're easier to couple with other simulations, but they require many small timesteps to ensure convergence.
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/
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 :)
___________________