The recent entry on PerlMonks about that camel game reminded me of the first game I wrote back when I was a kid; Worm. You know, the game where you steer a worm left or right, hunting for $-signs (for some reason, what would a worm want with cash? totally unrealistic!)
So I decided to give it a shot in Perl, test-first, simplest-thing, while also trying out Subversion.
Given I pretty much know how to solve everything, it was a bit difficult to do the simplest thing at all stages. I ended up writing a Game::Location class prematurely that I forced myself to throw away. But later on I ended up needing it as the endpoint of a refactoring, so I moved it back into the source tree.
The basic design is very similar to what I would have designed up-front, but I have a feeling the code structure is a lot more sound than it would have been, with behaviour in the right class etc. This is the current contents of the lib/Game directory:
App.pm
Direction.pm
Event/Timed.pm
Lawn.pm
Location.pm
UI.pm
UI/None.pm
Worm.pm
The story card format of moving the development forward is nice. It gives focus to the moment, while providing a place to brain storm new ideas. And since I'm the customer, it's up to me to shuffle them around to make it as interesting as possible.
As usual, unit testing the UI is the most difficult part. But not that much, since I had everything up and running from tests before I came to the UI interaction. So everything was by definition scriptable. But how meaningful and stable is it to push characthers up the keyboard buffer to see that they come out right? Not a lot IMHO. Mapping between key presses and game actions, yes. Basic I/O, no.
Surprisingly, development is slower than anticipated. I thought I could whip something together in an afternoon. And maybe I could, but maybe that's the difference between hacking and developing solid software. Even if it's just a Worm game.
