Secret Lair: What better lair than R'lyeh? Obviously Cthulhu is an obvious person, and I have always wanted to build a game around Cthulhlu. Most likely this will be a game where you send units out to attack the enemy base while they attack yours.

 Mad Science: They tell you that Daedalus flew with wings strapped to his back, but did you know he also carried a primitive machine gun and a lighsaber, potions of invisibility and a time machine? I have always wanted to do a dogfighting game, but planes are too boring. But Daedalus vs dragons and flying monkeys sounds fun.

 Everything goes to hell: Well, I can do something where you try to survive against everything going completely wrong. This one needs refinement.

Delinquency: I don't know, you smash stuff or something.

Daffodils Or Tulips: No clue. Is this a reference or something that has deeper meaning?

First time with PyWeek, looks fun. If Daffodils Or Tulips isn't chosen, and maybe if it is, I think I can still manage a decent game.

Got a group of friends together, I said 'let's make a game' they said 'why not' and so it was.#

The team is:

Ali: Programmer
Charlie: Programmer
Luke: Design
Fred: Tester

Together we are Frank.

Since the last Pyweek I've become seriously disciplined at test-driven development in my day job. If it doesn't has tests, how can I know it works? Now I'm wondering whether it would be valuable for Pyweek.

Six months ago I would have thought it was a crazy idea to write tests for a Pyweek game. Pyweek is all about coding as fast as possible, right? And tests are just a waste of time I could be spending adding more features! But seriously, the amount of time I spend in a Pyweek manually testing my own game is massive, and it's always possible to leave some crasher in, something that worked once but got broken in the headlong rush to move features. I've read articles suggesting TDD is just always faster.

And anyway, how can you test that such and such a particle effect looks just so? Well, you're much more likely to break the code so that the particle effect just crashes with some exception, or is never started, or emits them off screen or something. How it looks is hard to test, but it's not the most important thing to test. I love having to not have to deal with that kind of crap any more.

So what do we think? Has anyone done a substantial amount of TDD in a Pyweek? Is it an approach that can work?

Hey there, folks! Well, I'm looking for teammates this time around. I figure that it'll help me get things done if I have others depending on my input. :)

Anyone want to join up?

- Akake

I am now learning the basics of Python along with Jappe.  Jack already knows Python, as well as many other languages.  This is gonna be awesome!
 

This is the first time I've been on a team, and the first time kid_imagine has competed in Pyweek.
We will probably only be able to touch base with each other once during the week, so I'm hoping FaceTime is up to the challenge!

The ideal distribution of work would be as follows:

hidas: code, music
kid_imagine: art, music
( music would be on a per-section basis, with each team member composing the music for his favorite level/area/time slot )
 
I suspect however it will end up more like the list below:

hidas: desperately tries to code while promising himself he'll still have time to compose music.
kid_imagine: happily draws and records music all week.

Another problem is Py2exe; I haven't been able to build ONE .exe with it. We may end up doing a pure Pygame project for the third pyweek in a row. You see, having to compile Chipmunk for Windows just to install Pymunk just to play one game is bound to be quite frustrating. If we used Py2exe it would be easy to bundle a precompiled chipmunk lib.

Hi everyone. Do to private matters, I disappeared for two years. However, now that they are resolved, I am looking forward to participating again this year.