I am writing a collision detection system which uses the logic mentioned by Trevor here
But I have anticipated a problem which I have shown as a diagram
How do we handle this problem?
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.Sign up to join this community
Solution: You only detect and react to a collision on an object once per frame. This would move the second collision detection in step 3 to the next frame so that it will not enter an infinite loop and freeze.
Problems with the solution: If the two objects are not springs, but are instead solid objects you will see an age-old problem where it will look like the object shoots out at very high velocities from where it was. This may or may not be an issue either by the design of the game in question or simply because it would not matter if it does happen. Two common solutions when this happen, both of which require detection of the situation, is to remove the object either outright, or apply damage to it or the like or to alternately scan for the nearest 'open' area and move the object to that location.
Hope this helps
As James says, in many types of games, this sort of issue doesn't really matter much. But in others; particularly in games with fast-moving objects, it's critically important to get this right to handle complicated bounces in corners. So probably the smart thing to do is to ignore the problem unless it's actively causing problems for you. If it's causing problems, then here's how you handle it:
When your collision system is checking for collisions, instead of simply resolving collisions as you find them, you instead make a big list of all the collisions you find during the frame, and sort them according to the time-within-the-frame at which the collisions occurred. (your collision system will need to know about object velocities in order to calculate the time within the frame at which the collision occurred)
Once you have this sorted list, you resolve those collisions in order, from first to last. When performing the collision resolution, you need to use the "remaining frame time" as a parameter to the collision resolution function.
So here's a step-by-step version of this process, in the case of the situation shown in your diagram:
Note that if implemented correctly, Obj should be moving a smaller and smaller distance with each bounce, because the collision resolution is covering a shorter period of time within the frame at each iteration, and so eventually, Obj will be bouncing a small enough distance to no longer collide with the opposite spring within the frame duration.
Also note that it's still possible to get into an infinite loop if Spring1 and Spring2 are immobile objects and are placed so closely together that Obj doesn't actually fit between them, so it's important to have some maximum number of times that your collision system will iterate per frame. The faster your objects can move, the more iterations you need to support, to handle common "complicated bounce" situations. But in general, four or five iterations is a reasonable maximum for most games.
The reason that this situation happens is because you didn't take away any kinetic energy from the object, which is unrealistic- you even added it and made it go further. When an object impacts a spring, it doesn't rebound further or even as far as it came from- it rebounds less. By simply returning the object with less velocity/force/energy than it came in with, you should be able to ensure that this case never happens.
If I were to solve this problem, I'd take these two steps.
Step1: Infinite collision detection: This scenario occurs when the Object repeats its collision with the same set of springs for unreasonable amount of time. So for every collision with a spring, I would check whether the last X no. of collisions(say 50 times), has occurred between the same set of springs. I'd just check between the current 2 collided springs with the last 2 collided springs and maintain a counter and when the counter reaches X, I'd call it as infinite loop.
Step2: Preventing the infinite loop: Once we identify the infinite loop, we can handle it however we want. Eg. Restarting the game or Stop the object from moving further or bringing the object to the starting position.
I'm new to game development. Feel free to correct me.