Here are a couple of things I've learned about using pygame.mixer in the last couple of days. I'm posting them here in case they're of benefit to anyone.

• If you get something that sounds like an elephant has trodden on the keyboard of your pipe organ, you've probably got a "play this sound now" condition that's triggering on every frame instead of just once.
  
  
• If you need accurate timing of sounds, you may need to reduce the buffer size that pygame.mixer is initialised with. In a post-comp effort to add more sounds to 5B, I found I needed to use a buffer of around 64 bytes to be able to play short sounds at regular intervals of 100ms without the result sounding ragged. (This is on MacOSX, not sure if other platforms behave the same way.)

Got it there at last.

This version has 9 regular levels, a new random element, and a new part.

Note that 0.5 is the most recent version to be used for judging, even though it's not listed at the top, because I made the pending uploads in a different order.

Well, after a lot of questioning and second-guessing, I ended up participating in Pyweek 5, and I'm happy I did! I ended up switching ideas for a game about a hundred times and didn't start working on the finished idea (Melty Twist) until almost Wednesday, coupled with a full-time job and not knowing the language all too well, all led to a game which I think could definitely have been better, but honestly, simply finishing my first Pyweek and submitting something is a nice first step for me, and I look forward to being much more ready for Pyweek 6!

Wow, pyweek has come to a close. All I can say for us is that we had a blast!

It was a week of pizza, bawls, indian food, and chaos as we raced against time to get our (admittedly) overambitious project out the door. We both do python programming fulltime, but both came into this contest with very limited pygame knowledge.

The pinnacle of pyweek had to be those last three hours. We were running out of time and our game was very unpolished to say the least. Movement was very skippy, we had no music or sound, couldn't detatch from monsters, couldn't take damage, and so on and so on. There was a lot left to do!

Somehow, we managed to wrap things up quite nicely and then ... it happened. The last 30 minutes of pygame everything that could of went wrong, did go wrong. Still, we ended up submitting our md5 at 0:00UTC on the dot. Sadly, we didn't have time to fix a few bugs that cropped up at the last minute. One bug is that the level stops scrolling after a certain point, which sort of puts the kaibosh on our first level.

All in all we consider our project to be successful. We don't have a full level and the code can still be buggy at times, but we pulled things together into what we consider a pretty polished game for never having worked in pygame before. We're both really proud of what we did manage to accomplish, and frankly, neither of us thought we would make it nearly as far as we did. We both learned a lot during this competition and plan on continuing development on this game post pyweek.

Anyway, hope you all enjoy what's up there. We anxiously await the next pyweek!

Note about the final submission:
Blobbit is a puzzle platform game in which your only ability is to take control of monsters in your environment.  Currently the only monster in the game is Drakko, a fire monster which can damage other creatures and melt ice.

Fight your way through an exciting half a level and obtain vials to increase your mass.  Get too small and you won't be able to take control of Drakko anymore, but you will be able to sneak past him.  Make Drakko jump and jump off of him midair to get to some high places, but watch out!  The Evil Count Bugincode will stop you in your tracks if you bash your head into a cieling tile, mua ha ha.

Attach to a monster:  Jump on it
Detatch: Left Alt
Monster Ability: Left Ctrl
Jump: Space

As my friend tried to start it under windows freezed. :) It turned out to be a strange pygame.font bug. When you try to render a character with ASCII code 197 it hangs. Under linux everything works fine.

Here is the patch.

If you encounter a bug please drop me a comment here. Thanks in advance.

Some players complained about a KeyError exception, at "del self.shape_to_actor_map[s.contents.id]" in the destroyActor fuction. If you get this error (I havent been able to reproduce it myself) you can fix it with a small try-except-block. Replace line 248 in ActorManager.py in the following way:

before:

            del self.shape_to_actor_map[s.contents.id]

after:

            try: del self.shape_to_actor_map[s.contents.id]
            except: pass

The instructions in the readme seems to be a bit unclear on what you need to do to run Bouncy under Linux, so if you have trouble in running Bouncy under linux and it complains about a .dylib file not found, read on!

You will need to compile chipmunk. It is not very hard to do:

• Unzip the pymunk-0.1.1.zip file included in the Bouncy zip. It contains Chipmunk (and pymunk, the python binding, but we only need to compile chipmunk for Bouncy to run).
• Go to the folder named Chipmunk_src
• Compile!

  > gcc -O3 -std=gnu99 -fPIC -ffast-math -c *.c
  > gcc -shared -o libChipmunkPyEd.so *.o

• Move libChipmunkPyEd.so to /usr/lib
• The game should work now.

If I were to upload my game after judging, would my game appear on entry listing again or not?

Well, the final submission has been uploaded, and we've successfully managed to not use this diary for anything other than pictures of food and costumes.

Anyone who wants to see some evidence that we've been doing something other than eating and drinking all week is welcome to try out our game: Wound Up! version 1.0.2 is available from the entry listing page. We'd especially like to hear from people playing using Python 2.4, or on systems with slower graphics cards, as these were two of the situations in which it had the least testing. Also, let us know your high scores!

Finally, just in case you thought we'd forgotten, some photos of pie.

PyWeek is over. It was absolutely fun!. My final entry is not what I would call a finished product, but it's not bad.

I have a video of my game

I would like to have some features in my final entry but I couldn't make it:

• Sound Effects and Music, this is what gives life to a game, too bad that is not there.
• Map Editor, It's necesary for easily create new worlds
• More Worlds, There are only four of them.
• Two Player Mode: The engine was thinked for this. It's a shame not to have it
• MiniMap.

My final code is kind of ugly. Actually it has some nice parts, but at the end of the challenge I was trying to add new functionality as fast as I can and the result was some ugly code here and there. Nothing that can't be easily refactored.

At the end I didn't use Blender for the graphics, I made some pixel art with The Gimp. Now I'm less afraid of pixel art than before, but I must admit that I still suck as a graphic artist.

Some thing I've learn for my next PyWeek:

• Learn the API that you're going to use before the challenge. I was reading PyGame documentation at the begining of the competition and that made me lose time.
• Leave more time for desing improvement. I was fighting with technical problems until the end of the challenge and I didn't have enought time for tunning the fun factor.
• Don't try new crazy technical ideas. I was trying to implement a weird scroll system, at the end I decided to change it for a traditional tile approach. That made me lose time.

The fun isn't over. No we have to play all the games we've made. Have fun! and be nice judging my game ;)