Mortimer the Lepidopterist: postmortem

Cosmologicon on 2010/08/30 04:20 of Universe Factory 11

This was the closest I've come to completing my game idea for Pyweek, so I feel pretty good about that. In retrospect, it's easy to see why I was able to finish: by underestimating the amount of time I would have.

I was busy this week: packing Tuesday, moving Wednesday, then staying at a friend's house with just my netbook. Also I flew across the country Friday to attend a wedding on Saturday. I knew all this would happen at the beginning of the week, so naturally I had low expectations for getting anything done. That, combined with the fact that "caught" was the only theme I didn't have a good idea for, meant I picked something unambitious. I was able to get 95% of the game mechanics done by Tuesday.

It turns out that I was able to work on the game despite being on the road, and this let me add polish to the game for the last two-thirds of the competition. I think this ratio of one-third core mechanics to two-thirds polish was about right for me.

What did I learn this time around? Not a lot. However, I did stumble upon a solution to a problem I've had before. This game has a lot of text popping up on the screen, way more than any game I've done before (Sorry I don't have a scanner right now, but here's a photograph of my notes):



So, how do I write my label class so that I can ask for a label appearing 20 pixels from the bottom right of the screen that stays for the entire game, and also ask for a label appearing 100 pixels below the center that appears for 1.2 seconds, rises 10 pixels, and then disappears, playing a sound? And of course they have different fonts, font sizes, and colors. Usually when confronted with this problem I try to create a good, extensible constructor with tons of optional arguments that cover every possible need. This time around, I said "screw it" and did something quick and dirty.

Every type of label in that picture is a different class that inherits from the base class and overrides one or more of several static variables and methods: the variable "expiring" determines whether it disappears, the method "duration" determines how long it lasts, and the method "position(self, surf)" sets its position in terms of the surface. So I don't ask for a Label that appears in a certain place for a certain time; instead I ask for a ComboBonusIndicator, and all the specifics are contained in that class. It worked really well. I plan to do it like this from now on.

So, I feel like I figured something out. Whenever I do this, more experienced game makers explain either that this is obvious and everyone does it like this, or it's flawed and there's a good reason nobody does it like this. We'll see, but I know it worked for me. :)

Thanks richard, for another great competition! Good luck to everyone in judging!

(log in to comment)

Comments

gcewing on 2010/08/30 08:37:

I don't think there's anything "quick and dirty" about what you describe -- it sounds like a perfectly good approach. It's probably better than trying to stuff too much functionality into one class and ending up with a swiss army knife that's equally clumsy at everything.

tartley on 2010/08/30 15:01:

One think I like about pyweek is that the 'disposable' nature of doing a quick'n'dirty game project lets one experiment (both with game styles, and with programming ideas) to try things out and see what works and what doesn't.

So it's really great to also read about other people's conclusions after trying things out like this. Thanks for the post!