I've got a bunch of code that I don't care to write again, so I've documented it and called it a library:
http://www.meatengine.com


In part to test out the library, in part because it's been an idea I've wanted to experiment with, I wrote a silly little flight sim today.


Collide with the boxes in the shortest amount of time. The flight dynamics are pretty cheesy, but they kind of feel like a glider - the higher you go, the slower you get. There's no collision with the ground or with the hilariously festive sombreros.


There's quite a lot that's not in here, like a graceful entrance/exit, and OpenGL display lists. By my reading of the PyWeek rules, this amounts to published code over a month ahead of the contest, so I think you're free to reuse (and improve on) anything you find interesting.

Woody Tygerbaum is back, and he's got a twisted ball factory!
What you see in this picture is really just a single textured quad of a sketch I made of the game, but it's running inside Skellington 11, using OpenGL.

Early this afternoon, I added the ability to twist the tubes. Then, I added crates (with lots of guidance on what a crate should look like from the IRC folks).

And now, if you drop enough balls of the right kind into each crate, it goes away. If you get rid of all crates, you win!

Has this song been stuck in anybody else's head?

Her mind is tiffany-twisted, she got the mercedes benz
She got a lot of pretty, pretty boys, that she calls friends
How they dance in the courtyard, sweet summer sweat.
Some dance to remember, some dance to forget

Based on feedback, I tried adding brass rings to the pipes where you could twist them:

I kinda like the way it looks - I'm going to see how it feels over time, though.

I didn't get a whole lot done today, I'm sad to say. I did some minor polishing on the game, including:

• focus exception - when you switch to another window, I have code to trigger a pause menu. No actual pause menu exists, though (indeed, my hFSM code isn't in, yet), so it used to throw an exception that didn't make people happy. They should be relieved to know it's fixed.
• music - I'm no musician, but if you're going to turn the music off, there'd better be music there to turn off, right? So I made two short MP3 files, which I'll in turn process into OGG, and get playing ingame soon. There's a robot saying "tubes", which sounds a little like "noobs". Sorry about that. I'll get a better robot next time.
• transparent tubes - I think the balls are easier to see now.
• color distribution - balls are emitted based on a color distribution table. Eventually, each level will control its distribution.
• ball distribution - I take measures to keep balls from stacking up on each other at the top of the screen. You may still be able to glom them together through clever twisting. You're very smart.
• greener greens - The green ball should be more easily distinguished from the black ball. No progress on making color-blind-friendly assets. I have an idea of how to proceed; an alternate set of assets for the balls and the 'shipping labels' with colors+patterns to help disambiguate. I'll allow the player to toggle between these using a button (maybe 'C'), and mention this in the tutorial.
• brass rings - I probably mentioned this before, but it should be clearer where the player can click now, through the display of brass rings around the tubes.
• cheat button - press '1' to fake dropping a while ball into the leftmost crate. If you want to do such a thing.
• Py2EXE - I made a skellington-free copy of my game, which seemed to be the easiest way to get Py2EXE to work for me. I now have non-programmers testing out my game.

I simultaneously think I've got a lot done, and not very much. And there's a lot remaining, and not very much.

Today, I made a BUNCH of marble art - mostly making stuff, throwing it away, making different stuff, starting over. I now have an icon that I like (no more using the PyWeek4 WTIPD icon!), and I researched actual marbles. Wikipedia's page on marbles isn't as good as I hoped to tell me what an aggie vs a immie vs an alley would look like.

I got most of my intro working - I need to redo my picture of Woody, as he doesn't really fit in with my look. Also, I'm going to have more playable characters, so I want a consistent look through all of them.

The stuff I got done today probably goes a long way towards the game feeling complete, but I still need to hook up the level designs I've written (# balls at a time, the requirements of the crates, etc) to the board constructor. Shouldn't be hard, just have to get around to doing it. There's also some light parsing I need to do to convert level design structs into useful data.

Still haven't put in the color-blind assistance. I feel optimistic that I can do it quickly, though.

Hopefully, by this time tomorrow, I'll have tutorials in.

For some reason, I had been delaying the last piece of the game - the bit where I track the time and/or the number of mistakes the player makes. These are the way the player can lose, so it's an important feature of the game.

I finally got them in, and I will have to start tuning the game really soon - some of the levels can't be completed - the combination of the time limit and the ball launching speed and the crate requirements just don't add up, even with perfect play.

I added in a bunch of sound effects, and that makes the game feel a lot more "solid" - even a clicking sound when the tubes twist feels more responsive.

I stayed up late last night doing my programmer-art best at creating one character portrait. Only three more to go.

Well, I got a lot done, but could have done more. I did some last minute testing on my Linux box, which wasn't able to keep up with the 60fps I was asking for, so I inserted some adaptive frame limiting to try to get it to play smoothly on a wider range of machines. Here's hoping I didn't shoot myself in the foot by adding that so late in development

I also added the pause menu on the last day, but I had a better feeling about that - although there are probably other bugs related to it. For example, if the window loses focus, the music ought to stop. That's one bug I know about.

The credits in the readme have at least one error, too. Had I been keeping my readme up to date, rather than dash it off between release candidate 1 and release candidate 2, it might have helped.

I had considered having my levels have an enforced progression - do all the tutorial levels, which would unlock Tess and Blake, and then when you finished all of them, that would unlock Woody. Didn't get around to it, and gave myself the excuse that it'd just get in the way of judging (thought about having a cheat code to disable the feature, but figured it wasn't worth it).

I did manage to get the colorblind contrast art to work. When you hit 'C', the ball art is replaced by this:

which, I'm led to believe, looks like this to someone with no color perception at all (which is the worst case):

The green ball is problematic again, but it's playable, I think.

I spent most of Friday night editing voiceovers. I think they add a lot to make the various characters more personal and alive. I also think it's within the spirit of the rules to tap my friends for this sort of asset, and still call myself a "solo" entry. If you disagree, and want to play the game without voices, you can turn the sounds off by hitting 'S'. That also strips out the non-verbal "plonk", "clonk", and "click" stuff, which I'm also pretty proud of. I thought about doing all the voices myself (which actually would have saved me a fair bit of work, as my friends gave me a lot more voice clips than I was expecting or hoping for, so the editing job was a lot more than I had scheduled for), but my ability to pull off a female voice would have been jarringly bad.

I only uploaded a "final" version of the source version. I have a PY2EXE version on my website HERE, which I didn't think to go through the MD5 process for. So you shouldn't use it for judging the game, but if you wanted to show it to a non-Python friend, you could.

Thanks to everybody who gave me suggestions on what to improve. I intend to continue polishing and improving the game after the challenge is over (and my machine cools down). I can take some easy steps to improve the filesize and performance. There are several game design suggestions that I was given along the way that I want to try out - I suspect that many of them would have drastic repercussions if I did incorporate them.

I want to say thanks to the folks who said kind things in the comments, and the folks who rated the game well.

I also want to thank Richard for all his hard work on PyWeek - round of applause for Richard.

And another specific thanks to Richard, a couple people mentioned in their comments that the color-blindness assistance was a nice idea. Richard gets the credit for that one - he suggested that the original design might be problematic. I'm not sure if the "high contrast" patterns actually are playable with moving marbles, but I'm glad that people appreciated the feature.

I already know of several errors in the game, including getting names wrong in the readme, grammatical and spelling errors in the intro text, and at least a few logic errors having to do with the pause menu. Also, I crammed a lot of content into the game at the last minute, without attempting to make it bandwidth-friendly, so there's improvements to be made there. Also, there are a few features I wanted to get into the game that might have made it a little less annoying at times.

I've already put up a page for the game on http://www.pygame.org (as should you all for your games, go go go). I'll also be collecting my thoughts and providing downloads of newer versions at http://www.bigdicegames.com/PyWeek5/

Thanks again to all - is it too early to start designing "Woody Tigerbaum 3"? :)