Hey there,

I belatedly realise that it's only fair for to me to point out to all of you who are presumably *still playing* Sinister Ducks that it's very very hard to actually die. (ie. let enough enemy ducks bash you on the head so that you run out of feathers and plummet from the sky.) Even if you did - you have infinite lives! So you can just stop playing once you've had enough.

Thank-you.

ignore what this used to say. I am delerious.

I'm posting this fix in case others have run into the same (or similar) problem.
I don't know if my own game has this issue or not but I ran into it quite a bit in other games.

The problem:
At some (early) point, the game exits with
Fatal Python error: (pygame parachute)
Segmentation Fault

Quick fix
Find a copy of freesansbold.ttf and copy it to the pygame directory. Mine was in /path-to-pygame-source/lib

My system:
Ubuntu 8.04, originally with pygame 1.7.1release
But this problem arise when I built pygame 1.9.1release from source.

How I built pygame 1.9.1 (because I might have done it wrong and maybe that is why I have this problem.)
Downloaded pygame-1.9.1release.tar.gz
Got all the SDL dependencies through "apt-get install".
tar xzvf pygame-1.9.1release.tar.gz
cd pygame-1.9.1release
python setup.py build (because I wanted to keep v1.7.1)
cd /path-to-game/
ln -s /somepath/pygame-1.9.1release/build/lib.linux-i686-2.5/pygame pygame
python run_game.py

How the bug was found:
Using pdb and "step", a lot.

What the source of the problem seems to be:
First, it seems that freesansbold.ttf is not copied from pygame-1.9.1release/lib to pygame-1.9.1release/build/lib.linux-i686-2.5

Second, it seems that the file is actually found (without copying) but then the wrong directory is appended to its path before loading so that the "File not found" error is not triggered but an error occurs when pygame/freesansbold.ttf is loaded.

Dear Everyone.

Please download it for here . this is bug fixed version.
and add a  s:  cmd for debug. you can use it to show every blocks's weight in the game.

Milker
P.S. Dear @Cosmologicon
If you still find a bug in my game, please let me known.
Thank you.

I'm probably still a little delirious, but here are my post-mortem thoughts about our game, and PyWeek.

Sinister Ducks is our first PyWeek submission. We had a great time putting it together. Many thanks to Richard and everyone else who contributes to making PyWeek happen, and to all the other entrants for their work and passion and joy and tears and advice.

It is about the simplest game we could think up. We didn't set out with the following goal in mind, but after a day or so it became clear we were pretty much converging on the gameplay of the arcade classic 'Joust'. After realising that, we didn't go out of our way to avoid it - after all, Joust was really fun!

We don't have wild innovation, terrific production values, nor any variation or depth. But it *is* a game, more or less, that provides an amount of fun within its small remit, flapping around bouncing off other birds heads, and we got it uploaded within the deadline, and can point at it and say 'I made this'. That makes me happy.


My lessons from PyWeek:

FOR FUN: PREFER ITERATION OVER PREDICTION
Even with such a simple game, it was surprising to me how difficult the core mechanics were to nail down. For several days we imagined that collecting feathers would give birds a more powerful flap, but then we discovered that this wasn't actually a very desireable thing for the player, so we had to scrap that. So, plan to iterate on game mechanics is one lesson that obviously I've heard others say many times, but I'm learning all over again for myself now.

GET FAMILIAR WITH YOUR TOOLS
We could have worked two or three times faster if we had any experience with the (parts of) the libraries we were using. In particular, for us, we should have seen ahead of time that we would end up doing a 2D sprite game, because that just seems easiest and simplest, and hence I should have invested a little time up front understanding a few of the libraries for doing sprites, by hacking out a spritey demo or game, long before PyWeek.

VALUE GOALS & HANDS-ON EXPERIENCE
I dabble in games and graphics programming in my spare time, although the majority of that time goes into undirected exporation of whatever I'm finding most interesting at the time. Having a tangible goal with a short timeframe like this was a good change of pace for me, because it forced me to grapple with the mundane nitty gritty (like digging out that microphone headset and actually recording some dying-duck noises), rather than just imagining the process and thinking 'yeah yeah, I could do that'.

DON'T OVER-ENGINEER
All four of us on the team are professional software engineers. We like to think of ourselves as being relatively agile and enlightened, as corporate programming drones go. It's clear though that the different environment and parameters of PyWeek caused us to struggle against some of our ingrained mindsets. One of us, when creating a three-line .ini file to store some settings for the game, found himself thinking about how best to acquire / implement a general-purpose config parser - luckily he caught himself in time. I, however, actually spent (wasted?) a few hours refactoring our sprite/image handling code. Although the code is now better looking for it, I didn't then have any time left over to build anything on top of the refactored code, so the user-visible difference is naught. With such a tight timeline, at least for a team like ours that is inexperienced in this domain, and has limited free time at our disposal, everything has to be focused on immediate and visible payoff. What can I do that will improve the game this hour? Within ten minutes?


Right. Time for chicken soup, then some judging...

With hindsight, I realise that I failed to include any binary versions with our upload of Sinister Ducks - I really was feverishly sick the last few days, and didn't get anything productive done after Wednesday night, except taking a coloring brush to our all-black place-holder art, and then hitting the 'upload' button during one of my lucid moments. So I must respectfully request that people run our game from the source, if that is possible. Thanks for the indulgence.

Dear All:

In the first question in my game, please answer int 1 to 6.
I am sorry has not info about this in my game doc.

If you don't like plain text game. please me know.

Frankie
P.S. Please give me some comment.

Cheats are very important in PyWeek games! Here are some for Wizburg, and I'm happy to give more if you want:

1. For more health, change the value in src/woldmap.py line 54:
   hp = 3
2. To slow the game down, change the 1000 to a 2000 or whatever in src/main.py line 65 (make sure you leave the decimal point on):
   dt = clock.get_time() / 1000.
3. Save this for last. To unlock all castles and spells, uncomment the three commented-out lines in src/worldmap.py (80, 81, and 94), and delete data/savegame.dat. But be warned, some of the game logic relies the ordering of events, so if the game crashes when you do this, it's not my fault!

Here are my postmortem thoughts:

• I'm big on not just tacking on the theme, and I'm not sure how I did. Although there was a direct train of thought that led me from the theme to the final game mechanic, objectively speaking, it seems tenuous.
• My last entry's weakest category was Fun. That's what I hope to improve on this time. I think I did, but we'll see how the judging goes.
• A common PyWeek suggestion is to have your tools ready before the competition, but I learn best when i have a project, so I find PyWeek an excellent time to learn some new tricks. This time it was Inkscape, and it's great! I'll definitely continue to use SVG when I think it's the right tool for the job. I especially liked drawing the castles on the level select screen.
• Surprisingly, I really enjoyed programming the bosses. I usually avoid anything more complex than moving in a straight line for enemies, but now that I've tried my hand at more complicated fights, I might try it again. It was time-consuming, but fun. I would have been satisfied with this game if there were no levels at all, just the bosses. Maybe with the time I saved I could have made a better overall game, who knows.
• You have to be smart about what to cut out and when. Implementing wordwrap in pygame is always a chore, and this time I decided to save the hour I would have spent making it work right by limiting dialogue to one line at a time. It might annoy some players, but that was an hour well saved in my opinion. (I'm sure that someone will name a library I should have used. Yeah, next time, but I didn't know about it this time, and that's the point.)
  
• I think I made the first two levels too difficult. This is always tricky. How hard you can make your game depends on the fun and production levels, because players are more patient with interesting games. Hopefully with the cheats above, frustrated players will make it easier and keep playing. In particular, you don't see any feathers until you've beaten the first level, so I hope it doesn't seem like I forgot the theme!
• I spent a lot of time on this entry, and I think it shows, even if certain parts are rough or unfinished. I worked straight through a couple days at the end. On the other hand, I didn't get started until Tuesday. It's hard to say if I spent more time on this one or the last one.

Looking forward to feedback. Just so you know, I'm more receptive to negative feedback/suggestions for improvement. Sorry, I'm told I don't take compliments well! Anyway, I had another great time this PyWeek! Thanks to Richard and to the community!

One of my experiments for this pyweek was to make use of Python's new(ish) coroutine support to implement the behavior of the player, baddies and some other scripted things in the game.

In short this looks something like this:

class Player
    def update(self):
        while 1:
            dt = yield
            self.x += self.dx * dt
            self.y += self.dy * dt

player = Player()
update = player.update()
update.send(None)
...
update.send(dt)

OK, so this is neat in theory. You could have multiple loops in there with multiple entry points (yield statements) depending on the current "state" of the player, and so on. I've seen some nice implementations of byte-chomper network servers using this sort of approach.

Only it didn't seem to work. Eventually I was back at square one with a single yield statement and a really, really long update() code body.

I've just refactored it to use separate update() methods depending on the current state of the player:

class Player
    def update(self, dt):
        self.current_action(dt)

    def do_jump(self, dt):
        # do jump stuff
        if landed:
           self.current_action = self.do_land

player = Player()
player.current_action = player.stand_still

I'll note that the simpler coroutines I implemented for the baddies and other things are still coroutines - but I'll probably re-implement them as regular functions as well.

So, was I just doing it wrong, or are coroutines just not that useful for a time-based player update?