So a match-3 type of game where matching rows and columns get removed? My implementation tracked the positions on a 2d array (ds grid would work just as well). The matcher was a simple brute-force loop. Pick the color of item in first position (if the position is not empty). Do any of the neighbours have same color and they are currently not falling? If so, keep exploring in those directions. Is there a third? If so, create a temporary array and store those positions in it. Keep exploring until different color or field edge is found. Store the temporary arrays in found matches array. Then pick the color in second position and repeat. Once the entire field has been explored, go through the found matches array, destroy every instance listed in there, and empty the array.
The grid also has a routine that looks for empty cells beneath filled ones. Is the cell beneath this occupied cell empty? If so, how far down does the empty region go? Switch the instance's position to the deepest empty cell and mark it as falling. This check needs to run from bottom up or the items won't fall right. The routine does not have them do positioning in intervening empty cells because there's no point in that. The items will not stop in them, and while falling they cannot be part of matches. So it makes sense to immediately set them to their destination.
Relating to these actions the instances mostly had just a fall routine. Am I set to falling state? If so, animate from my sprite from its current position towards my position marked in the grid, and have gravity global accelerate my speed. Did my sprite reach or go past my grid position? If so, center sprite to my position, set speed to zero and switch from falling state to stationary state.
In other words, an item has two positions: their actual position on the grid and a position for their sprite. When they fall, their physical position changes immediately to destination to reserve it, and then the item animates their sprite falling to that position. While fall is animated, the item will not match with other items, because visually it is not yet in correct position. If you don't switch the physical position immediately when the fall starts, the item may need to compete with other falling items for that position and try to figure out which one reaches it first (which could be difficult because items falling from higher up have accelerated to faster speeds). Best to skip all that nonsense and reserve positions immediately - again, checking from bottom up so they pile in correct order.
If you were making the kind of game I described above, then collision_line probably wouldn't fit.
