@roamming gamer
Yes! That’s why I slightly shrunk the radius of the physics circle.
precollison and postcollision are great ideas too.
Animation would be the best solution (combined with pre and postcollision).
@roamming gamer
Yes! That’s why I slightly shrunk the radius of the physics circle.
precollison and postcollision are great ideas too.
Animation would be the best solution (combined with pre and postcollision).
Does anyone know of someone else who has tried this sort of thing?
Animation would always look best, but its not practical for a game with numerous balls that can bounce in various positions, against other objects, and more than one sometimes.
A “squish”-able body might be able to be constructed using a LiquidFun.
https://docs.coronalabs.com/api/type/ParticleSystem/createGroup.html
Best regards,
Brent
I think the best solution would be for Corona to offer a secondary physics engine that handles non-rigid bodies, too - which could handle squishing many balls into themselves. When Corona was originally developed, phone and tablet CPU speeds could not handle it - but now, they can.
For Corona to remain the best 2D engine for games, supporting non-rigid bodies is a must, IMHO.
@sporkfin, it seems someone else has already asked this question at: https://stackoverflow.com/questions/3269212/non-rigid-body-2d-physics-engines-in-c
There are several packages/engines out there that support deformable/soft bodies. If you want something free you can for example check out Phyz, SOFA or Bullet.
There is a detailed listing on wikipedia. Most of these are 3D-based but you can adapt them to a 2D model by setting up the scene as a plane.
@troylyndon - Have you see this article ? It’s a process to unify your liquid fun bodies into a single element visually using snapshots and filters. It’s super cool and could be a good solution for distorting your physics objects due to collisions. However, I have found it to be processor-intensive so if you have a lot of other things going on, it might be a lot to ask of the CPU.
Pre-rendering is the way forward here I think… just have an image sheet containing the ball in various stages of squish and switch the animation on when it collides. You could say have 10 frames (for the squish) and then just reverse the animation to make 20 frames. If you make the image sheet grey scale you can tint it whatever colour you want.
It is then just a question of timing the switch from static animation (i.e. only showing the first frame) to dynamic animation (for the squish) and back to static again.
That’s a good solution but it doesn’t cover multiple object collisions ; say one ball getting hit on 2 or 3 sides simultaneously which I think was @troylyndon’s reason for not liking animations for the task.
I think the best solution would be for Corona to offer a secondary physics engine that handles non-rigid bodies, too - which could handle squishing many balls into themselves. When Corona was originally developed, phone and tablet CPU speeds could not handle it - but now, they can.
For Corona to remain the best 2D engine for games, supporting non-rigid bodies is a must, IMHO.
@sporkfin, it seems someone else has already asked this question at: https://stackoverflow.com/questions/3269212/non-rigid-body-2d-physics-engines-in-c
There are several packages/engines out there that support deformable/soft bodies. If you want something free you can for example check out Phyz, SOFA or Bullet.
There is a detailed listing on wikipedia. Most of these are 3D-based but you can adapt them to a 2D model by setting up the scene as a plane.