PyWeek - Bouncy the Hungry Rabbit

[ richard @ 03:19 ] A Bouncy bugfix and joystick release

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!

show //

[ richard @ 00:12 ] Post-compo release

I've just uploaded a new release with a few tweaks:

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

show //

[ richard @ 00:03 ] ADMIN: it's all over, once again

Thanks for joining in the fun. I had a blast, again, and I hope you did too.

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.

show //

[ richard @ 22:17 ] ADMIN: judging rules clarification

Sorry for my quietness on this subject - I've been busy elsewhere.

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.

show //

[ richard @ 07:14 ] ADMIN: Judging duration

I've had an enquiry about the length of the judging period (why two weeks and not just one).

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 ;)

show //

[ richard @ 22:10 ] ADMIN: torrent has 2 incorrect files

You will need to download the entries for "PyCor" and "Kiwi" from their entry page, ignoring any entry in the torrent for them. Sorry for any confusion.

show //

[ richard @ 00:24 ] Fixed submission uploaded

I left out the PNG files from the bouncy-r8 upload, so I've uploaded bouncy-r9 which should work now :)

show //

[ richard @ 12:20 ] A day of cleaning up, final submission time

My first task today was to finish off the user interface, which was done very quickly and I'm pretty happy with the result. I'm hoping that it's obvious what it's all about.

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.

show //

[ richard @ 07:59 ] Thought for today

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan

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 :)

show //

[ richard @ 02:56 ] ADMIN: notes about uploading files

Uploading large files and fixing .tgz suffixes

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

show //

[ richard @ 10:11 ] Some progress

I spent most of today playing with my daughter but I did get some time to code a little more of the game.

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.

show //

[ richard @ 05:04 ] Basic concept is complete!

I've completed the basic game I set out to make when I started:

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...

show //

[ richard @ 08:31 ] Level editor == the OpenGL pain

The level editor has taken up most of the afternoon today because of a couple of hitches. Mostly, I was stuck for about an hour trying to figure out why my objects weren't being lit correctly in the glOrtho view. I ended up with a piece of test code that rendered a glutSolidSphere and then called a display list that also rendered a glutSolidSphere (same params, nothing else in the display list) and the second sphere was rendered unlit.

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.

show //

[ richard @ 02:22 ] More gameplay added

Ignoring a couple of collision-detection bugs (you can get through the fence in the right place, and the collision response "bounces") I went to work on some of the other game features. Notably the bunny now gets hungry when you make it do things. You can eat the yummy lettuce to satisfy your hunger.

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.

show //

[ richard @ 23:28 ] I hate collision detection

I spent most of the first 12 hours of the challenge working through collision detection and response. This is something I always waste that sort of time on, unfortunately. I tried a few approaches, all of which were complicated and had me trying to figure out how the innards of the pyeuclid module worked.

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).

show //

[ richard @ 02:18 ] I have an idea!

It's now 2h 15m in to the challenge and I've actually got a solid idea for my game, which is a nice change :)

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!

show //

[ richard @ 00:00 ] ADMIN: theme voting has started

Access the poll in the sidebar or click on this link.

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.

show //

[ richard @ 10:06 ] ADMIN: pyweek.org hardware failure

The machine pyweek.org is hosted on had a disk failure about 12 hours ago. Unfortunately this resulted in the loss of about 48 hours' data. Sorry for any inconvenience.

show //

[ richard @ 04:03 ] ADMIN: rules update

I have recently edited the rules to clean them up and clarify a point:

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.

show //

[ richard @ 02:11 ] ADMIN: system capabilities poll

I've set up a poll to see what system capabilities are out there. Hardware, operating system, etc. The last poll's results may be seen here.

show //