I'm really curious if my game was fun and hard enough. I kinda got it out last minute missing a lot of features. So, I'm wondering if anyone actually beat the game.

Emanuel, a friend of mine, created this nice video. Enjoy! Juanjo

Wow, thanks for the strange awards, everybody. I hope you enjoyed the mental exercise. Part of the reason we wanted to do a regex learning game is that we are sort of amateurs at the subject. Well, I suck, at least. So, this was as much of a learning experience for me as for anyone else.

We wanted multiplayer, but alas, time did not allow. Hanclinto did a fantastic job with the curses interface. I really enjoyed working with him, so here's props to the Hanclinto!

If we learned anything, it's that a good division of labor, source control, and small enough scope is a good recipe for getting a game finished, even without much time to work on it.

Thanks for the great feedback you're all leaving.

Most of my effort was spent creating the game engine so unfortunately the user-facing code received less attention, and thus is ... somewhat ... utilitarian :)

Just so you're aware, my TODO for the next release of the game includes:

1. help-screen popup when starting first dungeon
2. context-sensitive LMB: click on character switches; LMB on footstep moves; LMB on enemy attacks (if only one attack) or brings up menu
3. indicator for visible off-screen NPCs
4. NPC turn notification
5. more actions for characters (PC and NPC) to perform in the game
6. NPCs need differing loadouts and skills
7. a lot of cleaning up of the player management screen

The code already implements a bunch of things like handling different NPC equipment and skill sets (and altered attributes), but the current levels don't use that.

Any further suggestions will be gratefully received. If anyone's interested in helping me with it that'd be cool too.

Update: To the user who requested keyboard movement - it's already there (arrow keys). And so's the shortcut for "next character" (spacebar - clearly my spacebar icon sucks :)

15:58 <@ZeroByte> yo gordnik, pyweek is coming soon
16:00 <@gord> wasn't that a few months ago?
16:06 <@gord> ahh its every 6 months, of course
16:09 <@gord> shall we do an entry then mr ZeroByte?
16:09 <@ZeroByte> why not

For any of you attempting to play Crazy Atropos with pygame 1.8.1, you're going to receive an error because pygame 1.8.1's reworked color module removed a lot of color functions in pygame 1.8.0 that we used in the game.

So here's a quick hack of a fix for those using pygame 1.8.1 (it's a text file, so right-click, save as etc).

It's main.py with a few lines added that turns the Color class (introduced in 1.8.1) into a tuple (used in 1.8.0), along with a few functions that 1.8.1 removed. Simply put this in /lib of the game directory, and you should be good to go!

Feel free to judge based on the uploaded version and mark 'does not work' if you want; we apologize for our myopia.

It might be a good idea to back up the "checkpoint" folder after each checkpoint in case you mess up a room and go save at a different checkpoint by accident. You can also edit the checkpoint folder (such as copying a map file from maps to checkpoint to reset the map), but it is possible to mess something up.

In the room with millions of portable bridges, if you go to the right screen there is a checkpoint at the start, so if you want to unlock the door don't go right until you manage to do so. Although the northern door may not even be necessary. I have not completed the right branch as of yet, my game partner designed that branch and it is quite difficult. The extra string found in the yellow door in that room will make the next section easier, but it is (theoretically) possible without it.

If you are unable to reattach to an object, tie/untie a string you should be able to tie, or pick up a piece of string; the problem may be solved by closing and running the game again (closing the game saves your position), or leaving the map and returning.

Avoid leaving the map when tied to a post.

I'll be posting a video walkthrough at some point in the next week. If I manage to beat the right path that is :)


I am very proud of this game. Although it falls short in many areas, it is fairly complete, and most (not all) of the bugs have been ironed out. Considering the difficulty of development, I am surprised we were able to finish. Still, there are a lot of things I'd like to do, so we will definitely be working on this game some more.

Besides the bugs and some design flaws, it is badly in need of a middle section. The difficulty goes from quite easy to quite difficult with no section to provide medium difficulty. Our decision to branch the level was good for the limited dev time, as it meant we could both freely develop maps without bumping into each other, but it left no room to balance the two sides. Both paths are difficult, but I am pretty sure the right path is harder.

It's becoming apparent that some people's experience of our game is inducing motion sickness, if you suffer from motion sickness please run the game in windowed mode (change it in options and then restart the game). If you still feel nauseous then you probably should stay clear of it, sorry :-(.

One of these days I will actually have something to show people. When? I'm not sure. I can comment on a few things I learned from this PyWeek, the last Ludum Dare, the Mini Ludum Dare two months ago, and a few other previous competitions.

The first observation I could make is that even though Ludum Dare is only two days long, both times I accomplished a lot more than I ever had during any of my PyWeek attempts. This may be due to the following reasons:

• With the Ludum Dares I quickly came up with a game idea and just went with it. I didn't worry about whether it was good or not because if they were bad it would have been only two days wasted. With PyWeek I struggled for a long time trying to come up with an idea I liked, and didn't really come up with anything I felt was good enough.
• Having more time seems to make me more lazy. It's easy to think, "I have a week, that's more than enough time." On the other hand, when I have only a short amount of time I'm thinking, "This has to get done NOW!"
• Going along with the above two points, having less time and a more definite idea kept me more focused. I spent most of my time this PyWeek rather idly tinkering with a graphics engine -- which I didn't really have to do.
• Although making 3D graphics and animation is fun, 2D can be quicker (depending on a lot of factors, of course.) I was more satisfied with the side scrolling platformer I tried making during the Mini Ludum Dare than with any of the other competition attempts -- it was fun, easy, and fairly quick to make. Oddly enough more was accomplished during the 3D Ludum Dare attempt than during this PyWeek (though they very similar designs.) I think it's easier to overlook an engine's design problems when there is too little time to worry about it (though there were really only a few problems, namely compiling OpenGL display lists seemed very slow and I didn't have any text capabilities.)
• Not being able to use PyODE the way I wanted to had taken a lot of wind out of my sails. Simpler game dynamics seems to allow for more rapid development.

Some things I will try to remember when the next PyWeek rolls around:

• Come up with a game idea immediately! It doesn't matter if it's a great idea, it just has to be clearly defined. I need to know what I'm working towards. I didn't come up with a real idea for PyWeek until Thursday.
• It might be good to stick with 2D. Though I enjoy making 3D models and animation, the programming aspect seems more difficult, time consuming, and error prone -- especially if collision detection is involved.
• I should not write a graphics or physics engine. Going along with the above point, a lot more could have been accomplished if I simply used pyglet -- especially when it comes to menus and text. Trying to write my own text engine in OpenGL feels like a waste of time.
• Get working gameplay up and running before anything else -- hopefully on the first day even. It's too easy to work on other little things (graphics, engine features, etc.) and keep pushing back actual gameplay development. If every day there's a working game then when the deadline finally arrives I would not be stuck with something unplayable.
• Remember to have fun. A couple of times over the past week programming just felt like too much of a chore. I think it was mainly because I did not have a clear goal to focus on, but, as a whole, the process of creating should be fun. I don't have to worry about whether or not anybody would enjoy my game -- I should just enjoy making it.

Our game, and many others here, require pymunk. In order to get pymunk working on OSX you'll need to obtain or build a libchipmunk binary.

Penguin has built the dylib for intel based mac's. You can find it on myke's site Here or Here. (You'll need to click "Save file to your PC" near the bottom of the box.)

If your mac isn't intel based, or if Penguin's build doesn't work for you, you can build your own copy with the following:

svn checkout http://pymunk.googlecode.com/svn/trunk/ pymunk-0.8
cd ./pymunk-0.8/chipmunk_src
gcc -O3 -std=gnu99 -ffast-math -c *.c
gcc -shared -o libchipmunk.dylib *.o

For our game you can drop the dylib into the pymunk folder among the .dll and the .so files. If you have pymunk installed on your system you can drop this dylib in the appropriate folder. (e.g. /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/pymunk-0.8-py2.5.egg/pymunk/)

Your feedback on how well these methods work would be greatly appreciated. If you have any trouble please feel free to ask.