1. The list of game libraries has been moved to the python.org wiki as PythonGameLibraries.
2. The pygame.org cookbook is allowed as a resource.

This poll runs from now until the start of the challenge, 00:00 UTC on Sunday the 3rd of September. See the rules page for details about how the voting works.

The "system capabilities" poll will be closed in a few days.

Basically, you're a hungry rabbit and you're trying to eat food from a farm. The farmer is (understandably) trying to stop you from doing so.

Your only defense against the farmer is to dig and hide. You can't hide too long though, or your hunger will take over!

In the end, I retired at 11:00pm and read a book in bed. I'd resolved to try PyODE, but I knew that would probably cause more pain that it was worth.

This morning when I woke up after a good night's sleep, I had the solution. It was simple and after sitting down for about half an hour it was coded. Half an hour later it was debugged ("if you write code as cleverly as you can, then by definition you can't debug it"). Now my rabbit is bounded by fences. It can dig holes. If it digs for long enough, it goes into the hole and moves around under the ground, only to pop up elsewhere (leaving another hole).

I intend "easy" mode to be for people who just want to muck around, so the time limits will be much lower (or non-existant) and the farmer will move slower, etc. For example, on "hard" mode you'll also get hungry if you just sit around.

I still don't know why. My level editor now has the map portion drawn using a perspective view. It just means the picking is a little harder, but thanks to gluUnProject (and a little tweaking) I can get pretty accurate coords - enough to place map objects anyway.

Next up will be saving maps and enforcing a grid. Then I'll go back to working on more game code. Still plenty to do there...

I'm using Alex's text-rendering library PyGlyph to do the text in the buttons, if anyone's interested. It apparently has better layout than pygame.font.

The latest version of the game is bouncy-r3.

1. You're a rabbit who's hungry and can eat food from a garden,
2. The farmer will notice and try to catch you, and
3. You can hide from the farmer by digging underground.

I also got the level editor mostly working today -- I couldn't get picking working while drawing the map in perspective so I switched back to ortho, and the lighting worked. No idea why it works now and didn't before. My next step is to bring up a little menu with actions (rotate, delete, move) when you click on an object in the map.

I have some additional ideas for gameplay, but I'd welcome suggestions. First up will be the introduction of a "hard" mode which has a timer, and you must eat up before the timer runs out.

Also the collision detection / response is a little dodgy in places and I'd like to clean it up...

I modelled up some new props too, since those don't take very long to do.

I added the higher-level game structure (menu, level progression) and some transitioning to and from the actual game itself. I've also implemented a couple of aspects of the difficulty system. Easy is easy (but probably not easy enough) and hard is quite a challenge.

I also cleaned up the A* routine a bit - the code in there wasn't very optimised and thanks to RB[0] the farmer can now walk angles. There's still a slowdown sometimes from the A* firing so I need to figure how to split that over multiple frames.

There's an upload script to make uploading of large files easier. See the help page for a link.

If you're uploading gzipped tar files, please name them .tar.gz until further notice. The webserver (which I don't control) will run an additional gzip pass over .tgz files when it serves them (no, I don't know why) and thus the files will appear to be corrupted when downloaded. Naming them .tar.gz will work because I've previously asked my webhost to fix them. I've now asked them to also fix .tgz

I've been debugging collision response code again today. I've resorted to using a very simple case: Axis-Aligned Boxes (AABoxes) for everything. I was using a sphere for the rabbit and a cylinder for the farmer, but that level of detail was unnecessary and it confused the hell outta the code to boot.

I think I've finally got it working reasonably well. Remind me to write up a CookBook entry on this once PyWeek is over.

I also got the farmer to face the correct direction (ie. the direction of movement) which took much longer than it should have.

I also optimised the farmer's A* routine. It's now highly specific to my game, and takes less than half the time it used to take for my more convoluted map. One problem that came up today was that the farmer's hitbox was larger than the A* grid size. This meant that the A* routine would happily plot a course that the farmer couldn't follow due to running into things :) It was a bit silly, really, since the farmer doesn't need to run collision-detection routines, really.

The day's not over yet so I'm hoping to resist the lure of the telly-vision (did you know Australians download more TV than any other country?).

I'm not going to put up any more snapshots or screenies as that would ruin a couple of surprises :)

I spent most of today cleaning up the code, fixing bugs in the AI pathing.

Most of my problems today came from that old bugbear, multiple coordinate systems. My game world is predominantly a single coordinate system, the object space. A lettuce is about 2 units high. Movement, collision detection, etc. all work off the same coordinate system.

Unfortunately the farmer's pathing uses an A* grid, so I have to chop up the world into discrete pieces. The farmer is about 4 units (2 lettuces) across, so that defines my A* grid cell size (otherwise the farmer could be seen to walk partially through obstacles that should be walked around).

I generate the A* grid using the bounding boxes defined for all the objects that the farmer is going to try not to walk into (or over, in the case of lettuce). This was bug area number one. I spent a couple of hours tweaking the code that generated the A* grid "impassable" cells from the bounding boxes, and also the code that analysed the grid based on the current farmer and rabbit positions. There was a bit of refactoring in there too.

Next I realised that it'd be much nicer if the static objects in the game were better-aligned to the A* grid, so I spent an hour or so bending my brain over the forwards and backwards transformations required to get a 4-unit grid into the level editor.

So after all that I've got a much neater A* grid.

During all that I distracted myself by modelling up a new prop.

Oh, I also fill the grid now so that the farmer knows which cells of the grid are "inside" the farm (bounded by impassable objects, usually fences). This could be used in the future to have multiple farmers in their own farms.

I've got a lot of things I'd like to do to the game but I'm not sure I'm going to have time - my Saturday is pretty fully booked. Hence I've uploaded what I've got so far. No music, no sound effects, not particularly amazing level design, no flashy intro screen or "you win" screen. I'm not even sure whether "hard" is actually hard :)

Special bonus, if you're curious, try uncommenting the toon_program code at the top of map.py. You will need a shader-capable graphics card.

I'll re-evaluate the duration at the end of this challenge, but at the moment only 35% of eligible users have actually rated any games. Eligible users being those in a team that put in a final entry.

Of that 35% of users, no-one has rated all the games. Several have only rated one. A couple of games have been rated by 24% of users, but the average is more like about 15% of users.

If it turns out these numbers don't move much at the end of the second week, I'll reduce judging to one week.

There's a chance, of course that my posting this message will encourage some users to rate some more games. Miaow ;)

If you can't get a game to work, then consider a couple of guidelines:

1. Does the author of the game indicate that it should run on your platform (either implicitly or explicitly)? If they do, and the game does not work because it is broken, then you may penalise them for it if you wish (that is, rate them very low and check disqualification).
2. If you cannot get a game working because you can't make the dependencies work, then it's not really fair to penalise the authors of that game. Hassle the authors of the dependencies that are so hard to get to work.

I will revisit this area of the judging for the next challenge, most likely by including an explicit "did not work" indicator in the ratings. I will need to consider how that will affect ratings though.

Again, congratulations to everyone who participated. You wrote a game, that's pretty darned cool :)

Uploads are open again if you'd like to upload an improved version of your game, or a new screenshot. Also list your game on pygame.org - I'm happy for you to use pyweek.org to host your game downloads.

Again, thanks for participating, and I hope to see you back for Pyweek #4 in March '07 (and possibly in January for an off-season challenge :)

ps. please feel free to advertise the challenge in any news services, forums or mailing lists you know about to help get the word out.

• In-game instructions screen
• Fixes to collision detection
• "Normal" game difficulty which lies between easy and hard.

I've just released a new version of my PyWeek entry Bouncy the Hungry Rabbit which has some bug fixes for the latest PyOpenGL.

Thanks, Paul Holt, for the patches! Enjoy!