I'll pitch my interest into this.
While the library (IMHO) isn't intended to be as sophisticated as phys2d it should be possible for a developer to extend the systems provided to obtain that functionality if needed. In short it should be designed to make common/repeated tasks as simple as possible.
Can we define what this functionality is? Here are some thoughts:
* Let's start with just detecting intersection, we likely need position and dimensions to handle this
* But how do you resolve an intersection? Well, now we might need velocity
* And what if we have a big entity and a small one? Likely you want mass to distinguish heavy things from light things
* What about acceleration or friction? How are these managed? By the user, are they important for collision resolution?
So, now we have position, dimensions, velocity, mass. Assuming two dimensions for each vector that's seven properties or fourteen get/set methods! Now, I don't think a good library makes you implement fourteen throw away methods; on the other hand I'm not happy with a library that makes you use your one shot at inheritance on some base class...
Not to mention that at this point we've nearly duplicated all of the state on an object in Phys2d, so we're back to square one and in that case we already have libraries that do what we want and more. (Will you want support for bouncing balls? Joints? Sprints?)
Let's try again. How about we think about some scenarios:
* The library handles intersection, we're making asteroids and only need boolean collision detection
* The library handles intersection and client handles resolution but needs more than a boolean result from the intersection, we're making a simple platformer and need the side of the collision for example
* The library handles intersection and resolution, the physics are too involved for the client, such as resolving intersection between irregular shapes, we're making a platformer with simple physics and complex shapes
In my mind a "simple" library is one that scales to address these different scenarios without forcing the client who needs boolean hit detection to follow the same patterns as the client who needs the full blown collision resolution system.
Now, in my mind this might be accomplished by allowing the user to define what physical properties his POJO has and then configure the collision detection/resolution object to operate on the definition. At the same time performance is important so we don't want to rely on reflection for all of this. And we still haven't solved the problem of having to implement a dozen properties...
Anyone care to respond?
My website about game development http://anotherearlymorning.com