This, combined with momentum, will allow the player to constantly keep the ball moving, perhaps even jump the ball to collect certain kinds of items. Plus, I just thought the idea was neat. (Before anyone asks, yes, this was partly inspired by Mechanic #001: Negative Space over at the Three Hundred blog.)
I felt that creating a simple 2d physics engine that could do the kinds of calculations this game requires would be both complex enough to satisfy my professor's desire that this be a non-trivial piece of programming and easy enough to get done with whatever time I can muster up in the next 6 months. (Although, there is a bit of concern on the part of some of my coworkers that even this is too ambitious.) A physics engine would also give me about a billion things to write Code Contracts for; my Vector2 implementation already has 81 pre and post conditions that are verified on build and so far that class has only very minor functionality (overloaded ==, !=, *, length (magnitude) and some convenience methods for getting the vector as a 2 element array).
The other reason why this appeals to me is that I will have the opportunity to write the first and (as far as I can tell) only Code Contract verified physics engine for C#, talk about a resume enhancer!
I've gotten the first bits on CodePlex, check out the project here. I would say feel free to contribute, but I probably won't be accepting pull requests until after I've been graded (for reasons that should be fairly obvious).
Side note: setting up VS2012 with Git and hooking this all up to CodePlex was a dream. I don't know if it was simply that I've learned much about source control tools in my experience with Google Code and Mercurial, or if it's just really easy with VS2012, but I had none of the problems I was expecting. I can see why people use CodePlex with Visual Studio projects.
