Input connections and test-driven devvin'

Hm, a while later, I'm not sure that putting the input adapters in the BaseLevel class is the best way to go. I'd really like to piggyback my mechanism where I can register an input consumer, and don't have to manually propagate the input frames from the main class to level to puck. Instead, it should be possible to have the pucks hook themselves up, by tagging them with, say, Keyboard 1/2, Network 1/2...

Then again, perhaps this is overdesigning. Shouldn't be a problem to have the BaseLevel hold two keyboard input controllers and hooking at least one puck to them, and in the case of network input explicitly asking the netplay delegate to control "this little puck over here".

I'm trying to get disciplined about letting test-writing drive development. For the keyboard input thingamajig, I wrote a test that connects a puck to an adapter, sending a frame to it, and dispatching it. The puck is a mocked subclass that sets a flag to true when an input frame arrives. From the start, the test naturally didn't compile, so I had to add the puck's dispatch routine. Then, the adapter doesn't dispatch, and then the puck doesn't answer. But, after a couple of iterations, the test passes and I can move on to sending all the different input commands and flagging them in turn. It's a fun way to work, albeit a bit strange to wrap a moist brain around.

Allright! I have the tests set up (and their respective sources) to do all manners of nice checks: making sure input reaches the pucks, that all frames do get dispatched, that directional input comes through as well as "hit" events, that the Player 1's puck does not even read Player 2's input, even if they have the same names, and that each player's input get directed to their pucks even if there are two pucks connected. Not bad at all. Sleep time and a major SVN commit.