After the rain...

So, PyWeek is over and so am I... really I'm dead after soo much. But it was quite fun participating so I'll be looking forward to the next compo, and this time I'll make sure to have my libs and planning done so my code won't look like a complete mess of locals and globals flying everywhere and almost no classes whatsoever.

Anyways, things went quite the other way around in this week. At first I had no idea at all for the feather theme, but then I just thought of merging all themes into one big game, so it should be easier. Well, somehow I guess it was. Doing a platform was quite fun, but I completly skipped the planning part and midway through the game I had was completly different from what I had in mind.

The original plan was really a math-ish puzzle game, where you would have to toggle switches to activate paths and portals, but I planned maps a lot larger than the ones I ended up making. Then I remembered pygame alone is not the best to make update-the-entire-screen-every-frame games and dropped the idea. Then I just focused on getting some functional stuff done and started writing a lot of codes at random.

The results, although I did made it to the deadline, weren't that great. As you can see by looking at the code (please don't do that, most of things there are sorta shameful .-. although there are something useful I wrote on the last days of the compo, like the novel manager thingy) everything is a mess and most of things I wanted to do I couldn't just because I spent a lot of time doing things that I needn't either because I could just pick up some lib or go without it. The complex map module I wrote at first was one of those all-not-needed things. I really didn't need something with lots of frames where player would have the ability to jump and such.

After all I had a lot of trouble editing code and some bugs resulted from this. Like sometimes if you press escape and select don't exit the game, the game will keep asking if you want to exit what is sorta annoying. There's also a bug in collision system where feathers will just pass right through bugs but won't kill them, but this should be something with the mask module, I didn't had really much time to work around this, but some bounding box collision should work perfectly here.

In short, there's a list of things that didn't work to me in this compo:
  • Did no planning whatsoever (my todo lists couldn't be taken as a planning)
  • Spent precious time working on the wrong things.
  • Made a mess of locals and globals on the code, which leds to bugs and difficult to edit the code.
  • Spent precious time doing nothing but looking at the console screen waiting for some brilliant idea to pop up out of nothing.

Things that I learned during this compo:
  • How to use bitmasks and pixel-perfect collisions in pygame
  • I should make plannings before go writing things at random
  • I should use OOP to get things more organizated

So, I'm ready for next PyWeek, with a bit more of knowledge on how to make a game. And hopefully next time I'll have a fun game that won't have a completly messed source code.
Btw, I guess I'll keep working on this game, maybe I can get something interesting out =D

(log in to comment)


Why on Earth did you want to make pixel-perfect collisions? I agree that you have spent the time on the wrong things! I am sure you will do much better next time, but you could also consider joining a team (you can draw, so I bet anyone will be happy to have you!), so you could get some experience with a possibly more goal-oriented workflow. Or just dissect some PyWeek games you like and look at how they are organized. That's what they are open-source for!
I agree that pixel-perfect collisions are overused. I've made a variety of games involving collisions and never once have I used it. I usually use a bounding circle, sometimes a bounding box.

Re: horrible code. One article said that reusable code should be the last thing on your mind; nobody is ever going to use a single line of your code again. Well, they were talking about Ludum Dare, and it's less true with PyWeek. If nothing else, you will be using your code over the rest of the week. This time, I tried to write reasonably well during the first half of the week, and that payed off, but at some point I completely gave up. I have a base class with seven derived classes, each of which has an exact copy of the same few member functions. Every time I copy-and-pasted a new derived class I felt a little twinge of guilt for not moving the code into the base class where it belonged and fixing things up, but I remembered the article's attitude and I suppressed it. I regret nothing!
This time, I tried to write reasonably well during the first half of the week, and that payed off, but at some point I completely gave up.

That's normal, I think. There comes a point where meeting the deadline becomes more important than keeping the code clean. It makes the code more brittle and hard to modify, but that doesn't matter because you're not going to have time for any major reorganisations in the day or two left anyway!

After the dust has settled, I often go back over it, pick out any generally useful parts and put them in a library, tidying them up in the process.