Can you give me some comment ??

Thank you.

You can download the standalone windows versions from the following links:

http://mindless-labs.com/games/gcollector/garbage-collector-v1.0a-win.zip http://mindless-labs.com/games/gcollector/garbage-collector-v1.01-win.zip

The first one is identical with our final submission, the second one is improved with two arrows which appear as you leave the screen so you always know where you are.

Have fun!

If you have any comments or questions about Yo Yo Brawlah, please post them here. We'll try to answer them as best we can.

Managed to get py2exe not to barf so if your that way inclined:

http://gamecomp.googlecode.com/svn/trunk/gamecomp/NaN7.zip

Please note there is a fix for the level bug in this so please ignore it.

Cheers

I'm still not getting any sound from Pyglet on MacOSX. Previously I thought this was because my AVBin installation wasn't working, but it turns out it's because OpenAL isn't working.

>>> import pyglet.media.drivers.openal
...
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ctypes/__init__.py", line 330, in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
AttributeError: dlsym(0x10d4e0, alListener3i): symbol not found

Looking at /System/Library/Frameworks/OpenAL.framework/Headers/al.h, it appears that the following six variants of alListener are supposed to exist:

alListenerf( ALenum param, ALfloat value );
alListener3f( ALenum param, ALfloat value1, ALfloat value2, ALfloat value3 );
alListenerfv( ALenum param, const ALfloat* values ); 
alListeneri( ALenum param, ALint value );
alListener3i( ALenum param, ALint value1, ALint value2, ALint value3 );
alListeneriv( ALenum param, const ALint* values );

However, according to nm, only four of them actually exist in the dylib:

9b20d9cc T _alListener3f
9b20dcf0 T _alListenerf
9b20db54 T _alListenerfv
9b20f0e8 T _alListeneri

I'm not sure what to make of this. Maybe my MacOSX has an older version of OpenAL installed? But then why do these functions appear in the header, but not the library?

Has anyone else successfully got sound out of Pyglet on MacOSX? What version? Mine is 10.4.4.

The game Kiko runs too slow on Linux and Mac, due to a bad selection of time provider.
A workaround for this requires only a one line change:
in kiko/base.py, near the begining, change the line
time_service = time.clock
to
time_service = time.time

Bug reports and comments wellcomed.
(thanks Zero|Byte from #pyweek for testing)

If you have comments or questions about Snake RPG, add them here. I'll try to answer any questions about the game.

If you want to comment the game without rating it, you can do so here.

...and... well we forgot to mention that pymunk and pygame is required to run the game. They can fortunately both be installed using easy_install.

Oh! and good luck, the current highscore is 88 string used in total for all 10 levels.

This a long post, but maybe you'll find it interesting to read it if you have some spare time. (Lessons are bolded in case you just want to skim through.)

My performance in this particular Pyweek was probably one of the worst. I had no problems with the theme, but I slammed my face into several walls. It turned out ok in the end, but I still wish I had made a decent game. The neat thing about Pyweek is that every Pyweek there's always something new to learn. This time, time wasn't much of a constraint, I blame my mistakes more. So I'd like to talk a bit about my week of Pyweek; despite the failure, it was actually quite unusual.

In the beginning, I had no idea what I was going to do. So I planned a simple platformer with string swinging and climbing and more stringy actions and decided to do it. I needed some rope/string physics, so, knowing that it would take too long for me to do that by hand, I picked Box2D. It was fairly smooth to use it and in the beginning things were well. Eventually, I was able to make a reasonably decent string that got longer or shorter. But then I realized I wasted too much time just tweaking the string, and decided to go with a different idea I had while playing with the string.

So far, things were okay. I had an interesting theme planned out to cover the mechanic. The basic mechanic was that you controlled an invisible ball with eyes that was attached below the string, and the physics made it feel like you were a string ghost, which felt really nice and cool. But I wasted a few days on it before realizing two lessons.

1. Be precise on your design, especially if your game isn't tried-and-true. My game involved shoving things away with white string and destroying things with black string, but I didn't realize how badly they could interfere with each other, considering they were parts of the same string. The problem in my design was that I didn't realize that it would be hard for the player to do what he wants, which brings me to lesson 2.

2. If you are unsure about how an element behaves with another element, be sure about it before putting those two elements together in the game. So after I realized my string was so hard to control, I decided to tweak it. And tweak it more. And so I spent a lot of time tweaking it to see if I could make the string easier to control. Putting joints there, removing joints here, adjusting parameters, etc. Eventually I had something I was somewhat satisfied with, but I had wasted a lot of time.

Also, having an interesting theme somewhat blinded my view of the mechanics. I had this really interesting, artsy idea where the string would represent life and white string and black string would represent good and evil respectively, there were several cool features about it, and I kept insisting on it, even with the mechanics not working out well. A possible third lesson here is to make clear view of your mechanics, try to see if they work well without what's on top of it (theme, rules independent of the mechanics, graphics, etc).

At that point, it was already Friday. I realized things just wouldn't work when I stumbled into more incompatibilities between design and physics. So at that point I decided to scrap my theme, but I liked the idea of that ghost-like string, it looked even nicer when it was glowing, and I didn't want to waste it, so I kept it. That was another mistake, sometimes you just have to scrap everything and start over (that's a hard one to learn and even harder to identify when you have to do that).

The third idea was very simple: there would be several enemies with black and white "weak points", and if you touched them with the same color, they would get stuck to your string. Also, if you made a weak point touch another weak point of the same color, they would stick together. The goal was to destroy enemies by "sticking" all the weak points to something. That sounded pretty cool, but there was a technical problem. It's a technical lesson, but, anyway, joints might not be as tight as you want. The thing was that, to make things easier, the weak points were different bodies from the enemies themselves, with joints attached. The problem was that they either kept distancing themselves from the enemies, or when one enemy was attached to another, they kept distancing from each other (this depended on how I tweaked the masses). I managed to have something reasonable except for fast or wacky movements, but there were two more problems.

First, the game felt like a Frankenstein. Nothing connected. There was the ghost string, there were the enemies, but there was no reason for them to be together. It just didn't feel good, next time I should keep in mind that every element of a game should be well connected. Second, the tipping point that made me give up was that my game not only crashed, but also crashed the computer, for the second time. Sure, it was only twice, and there were other programs running which could also be the culprit, but I just didn't want to risk handing out a game that might crash someone's computer.

Anyway, at that point I had only eight hours left, and I felt like I should give up. But I really wanted to submit a game, and those eight hours were mostly clear, so I picked an idea I had before, scrapped everything and decided to do it. I made a really simple and rough approximation to a string, drew some planes, drew some people, added the code, and finished a simple game. I never managed to finish a Ludum Dare, but, ironically, I managed to finish an eight hour game in Pyweek. I felt kinda glad, but I still feel bad for wasting an entire week. The good thing about it is that it actually made me feel a bit more confident for a LD, and there were a lot of lessons learned. A last interesting lesson is that sometimes you do better with a totally different idea in just a few hours rather than sticking with another idea for a week, although I think it's very hard to identify these situations, but it's good to know that situations like those exist.

It was fun, though. I've never tried to implement four different ideas in one Pyweek. I haven't gotten around to play the games yet, I still have to catch up with my usual postponing of things first, but I will when I find the time, there seem to be a lot of fun games. Sorry for the long post, but if you're still reading, thanks for reading. :)

Ok, well it's been over for a few days now. I had fun, although illness caused the week to be very draining. I started off with a few ideas with none of them well formed and not really any idea of how i'd go about implementing them. So I decided I'd start with a rope simulation. This used up two days (1st day using euler method, 2nd day rewriting using verlet integration which worked a lot better). Now I had a wobbly springy string with nothing to do with it.

Fleshing up a simple game around picking objects up and moving them about using your awkward springy rope, I came up with the idea for lunar delivery and came up with lots of ideas for the game that never got implemented at all. No matter... here's a few things I have learned:

Do physics after the concept. Perhaps this isn't always the right idea, but my game suffered because I was so focussed on the rope physics that I couldn't come up with any idea that didn't use it. I personally think the most fun entrys this pyweek were really the ones that didn't use rope physics. This is perhaps because not having to deal with physics frees up a lot of time to work on a better idea and more gameplay elements. Or perhaps because rope is kind of boring.

Fun - I don't think my game was all that fun, and related to the above.. I really should have come up with a fun idea first, rather than trying to come up with an idea around a rather boring toy physics thing.

I need to learn python - Similar to another post I saw on here, I realised that I wasn't really coding in python at all, I was merely coding in any other language and translating it over, so my code didn't use any nifty python features and tricks, because I didn't know them. At least this pyweek has got me more into python so that I can work on this for the future.

I will definitely be joining in more programming competitions, pyweek and others hopefully, and will hopefully be able to build up a catalog of things I have made

Any comments on my game would be appreciated, I know the concept wasn't that fun, but if you can think of ways that it could have been better, I'd love to know :) If you don't understand anything as well, just ask here and i'll try and help you.