I: First off, I want to thank you for taking the time to be here. I know you have a busy schedule and a lot to do to prepare for the competition. To get us started, why don't you tell us a little bit about your past and what your programming experience has been so far?

Me: Sure thing I. And let me start off by saying this is a pleasant break from the non-stop coding and debugging I've done the past week. A little bit of nice dialogue will be good for my sanity.

I: Hahaha. Yes, well... We can only hope...

Me: So anyways, I dabbled in PHP/MySQL a couple years ago for some Wordpress sites I was trying to customize. My programming knowledge didn't go very far. I didn't even really get to the Object Oriented stage. I knew what they were and how to use them, but that was about the extent.
I don't know what got me interested in programming again. I think a couple weeks ago I wanted to write something that would simulate a poker table and tell me how often four of a kind gets beat at a 10 handed Hold'em game. It was a lot more difficult than I thought to write and while I was learning to code it, I drifted off to PyGame and other Python stuffs. And now I'm here. I'm a little worried that maybe I'm biting off more than I can chew by entering the PyWeek competition, but I have decided to measure my success by how much I learn more than what my entry ends up looking like.

I: Wow. Sounds like you're really new to this but that it hasn't stopped you from jumping in head first. What have you learned so far and what do you plan on incorporating into your game?

Me: Right now I'm most comfortable with discrete map type games like the classic worm eats apple game. I'm debating whether or not I should use PyWeek as an opportunity to step outside that comfort zone and learn tiling and try a side-scrolling shooter, or if I should stick with what I know and focus on putting together something that is polished and bug-free regardless of its simplicity.

I: Well, if you want my opinio...

Me: I already have it.

I: Of course. Can you share with us some of the resources you plan on using during the competition?

Me: I'm sure I'll wear out my bookmark for the pygame docs:  http://www.pygame.org/docs/ 
I'll also probably force pyweek.org to up their bandwidth cap due to my excessive downloading of previous entries to use for example code and ideas. One specific article that I am still digesting currently is http://ezide.com/games/writing-games.html . I hope it will help me to better structure my code.
I'll keep you updated throughout the week with new resources that I find useful.

I: Cool, I look forward to the updates. I know you're busy so I'll let you get back to monkeying around with the code. Keep in touch.

Myself: Don't do drugs, kids.

I started off sketching ideas for about 30 minutes and tried to organize what objects I'd have and how everything would map out on screen.
 



The storyline is you are a mad scientist who's Frankenstein experiments have backfired. Now you have to combine ingredients to throw at your creations to defend yourself and your lab.

Random ingredients will pop up on the lab table above (in front of) your character. The effect of the ingredients depends on what you pick up. You can adjust the range that you throw them.

I spent about an hour playing around with py2exe, pygame2exe, and the skellington-2.3 package. I probably should have spent more time messing with those things before the competition started. Had other more interesting projects on my plate though.

I am using a lot of the code from the example games that shipped with pygame as a base for building from. I wouldn't have been able to get as far with the sprites as I've gotten if I had just been reading the pygame docs.

I copied the sprite layout from the aliens game from the pygame examples.

Spent a couple hours trying to figure out why my background sprites were getting drawn over my foreground sprites on occasion.

What you see below is a 7x7 grid of sprites. The ingredient affects will apply to those sprites and affect any zombies that are colliding with that grid sprite.
 

 

Ok that's enough back to coding.

I have come to the realization that I'm going about this the wrong way. In my rush to get a working game, I've neglected good code practice. I have no comments and a lot of leftover code that is un-used and un-labeled. My understanding of how the game should turn out has changed a lot since I started but I have been pushing forward trying to make what I have work rather than scratching the majority and starting over.

Since this is more about learning than anything, and since I don't want to start building bad habits early, I'm going to slow down and pretty things up a bit. At least then if I don't finish, maybe I'll have some well-written re-usable patterns/modules for the future.

Yesterday, I finally finished the core mechanics of the game. A simple enough accomplishment, but it sure feels good. I was getting very frustrated for a while. I feel like my big breakthrough came when I stepped back from the grind, cleaned up/refactord the code, and started commenting what I had done. It seems to have made it so much easier to debug and add/change features without breaking something.

From now on I'll just be adding things like the start screen, adjusting the difficulty, cleaning up images that up till now had just been placeholders, etc...