- It provides fundamental information about an object's collision polygon that can aid in writing advanced custom collision detection code. Consider objects that climb slopes along their bottom-center image point but retain the information needed to use their bounding polygon when testing for collisions near edges, where their extremities must be off the edge if they are to fall. Or perhaps consider a scenario where you want to test if one object is fully contained within another.
- It provides a neat, reusable method for fetching information of this nature. Without this condition in C2, I would have to use a single pixel sprite. If I were to use this sprite and position it to the point in question each time I were checking for overlap, I would have to repeat this series of events for every object in question. It would be difficult to see at a glance what point I'm comparing against because those values would be overshadowed by the logic of the algorithm that involves positioning the sprite, etc. Functions won't work because then I would have to pass a parameter that refers to the object whose collision polygon I'm testing against. Let's say I pass it's IID. I don't see a way to Pick an object with an IID and test for overlap with it. I could use Families and UIDs, but that still makes it far more complex than it needs to be.
- Something as intricate and precise as a collision polygon could be used in countless ways, but we are presently only given one limited usage of it: to check if two objects overlap. The power and flexibility of defining a collision polygon to sub-pixel precision seems wasteful when only one essential use is allowed. More open access to the collision polygon (by way of checking if a point lies within it) would significantly increase the programming possibilities available to the game developer with very little increase in software complexity.
Thanks for considering my request!