Well I'm not sure why your sounds aren't working, but have a look at freesound.org - you need to register, but when you do there's a pretty extensive collection of sound effects at your disposal.

Oh and just a comment on the gameplay - with or without sound it seems quite fast initially! Could you slow it down to start with and then perhaps speed it up gradually?

That's odd, does Audacity not handle it? It's coped with all the file formats I've used on it so far, including wavs that Greenfoot didn't like. Sounds like a stupid point, but you did select "export to wav" rather than saving it as an audacity project file? What error did you get? As for other ways, well you need to get it into a format that Greenfoot can play - I don't know of a program that'd do a better job than Audacity so I wouldn't know what to recommend if Audacity doesn't work. Unless you try making the sounds again (what did you make them in?) For now, you could just comment out the lines that play the sound and upload it - it won't have any sound but it shouldn't keep freezing like it does now.

Yup. In fact there's only one problem - the freezing is called by the problems with the sounds (when the scenario encounters an exception, it stops.) If you have a look at the java console, then chances are you'll see something like this: java.lang.IllegalArgumentException: Format of sound file not supported: URAN.wav at greenfoot.Greenfoot.playSound(Greenfoot.java:141) at Astroid.boom(Astroid.java:82) at Astroid.act(Astroid.java:29) at greenfoot.core.Simulation.runOneLoop(Simulation.java:200) at greenfoot.core.Simulation.run(Simulation.java:129) Greenfoot's sound support isn't great at the moment, and while improving the sound support is on trac, it's by no means a trivial task! The problem is while the API says it'll support WAV, it doesn't support all types of WAV, and that seems like it's the problem here. I can't remember the supported formats quickly, but try loading the sound into audacity, then exporting it as a wav file from there using the default settings - it's how I've saved many sounds in the past and I've never had a problem that way.

I found level 3 possible but a big step up from level 2, I'd suggest it needs to come down in difficulty a bit. However - I still find the jumping far too short and fast, which make the jumps necessary in level 3 very difficult (in fact I'd go as far as to say that's why it's so difficult!) so by making the jumping slower and more natural, this should go at least some way to making the third level easier.

Firstly, the scenario doesn't work at the moment because your Smiley0.png has an upper case S at the start - and it needs to be lower case since it's lower case in the prefixes you've specified! In versions of Greenfoot previous to 1.4.6 the API was case insensitive, so it'd usually work when you were running it on your home PC, but not the gallery (which is case sensitive.) However, the latest squeaky new version of Greenfoot does I believe have case sensitive filenames built in, so if you upgrade you shouldn't fall into that trap anymore - you'll get the errors when you compile on your home PC rather than just getting a dead scenario when you upload to the gallery :) Secondly, you probably want to get rid of or change: // Create a new world with 20x20 cells with a cell size of 10x10 pixels. ...since the following line clearly doesn't do that! Also, is one of those lines meant to read 700 instead of 800? As pointed out earlier, you're not actually adding seperate birds in the scenario with your code above, you're just repositioning an existing one (since you only ever create one bird.) So at the moment, the 4 last lines in that code could be deleted with no noticeable affect. And as for creating a loop, that's always the best way to avoid writing out the same code lots of times (even if it's only one line!) So if you wanted 5 seperate birds, you could do something like the following in place of the existing code: for(int i=0 ; i<5 ; i++) { addObject(new Bird(), Greenfoot.getRandomNumber(800), Greenfoot.getRandomNumber(400)); } If nothing else, this way makes it easier to avoid mistakes (such as the 700, if that was a mistake!), reduces clutter and generally just improves code quality.

In reply to http://groups.google.com/group/greenfoot-discuss/browse_thread/thread/c671eca737a6726d I see what you mean now - I think. Have a look at http://greenfootgallery.org/scenarios/524