It's a known bug (although I was pretty sure it was fixed). I presume you were heading towards the world? It's because the snake is built up of points, so many points that it looks like a curved line. Two points make up a line or segment of the Snake, so for collision detection I just check if two segments are overlapping. However I was scared this could become very slow when you end up with thousands and thousands of points in the Snake so I only compare the first few (I think the exact number is 5) points at the head of the Snake against all the rest of the points in the Snake's body. Personally I think of it as more of a quirk in the game rather then a bug (like how in the original Pac Man there is a position on the first level where you cannot be killed by ghosts). It's also quite dangerous to recreate because you can only do it reliably if your both close to the world and heading towards it (the gravity of the world makes you fast enough to do it). Typically the closer you are to the world the more likely you are to crash into something and die.

Yes, it's to do with the security manager and the GreenfootImage class. I am using reflection to change the BufferedImage used internally by the GreenfootImage. As standard GreenfootImages have full alpha support and I was replacing the BufferedImages with one that only had partial or no alpha support, as these were far faster. I had originally presumed that the security exception wasn't being caught by my code. My original solution was to catch it and so not have the images changed. It would be a lot slower if your not logged in, but would work. However it appears my code is catching it, so I'm still unsure why it fully breaks. I do however have a new fix which I might try implementing today (and actually do it too). I still plan to finish Super Thundershot but after I have finished my current game, Sokoban Supreme (comming soon).

You could always implement different counters. Sometimes you want the realtime framerate which is calculated on a per frame basis (useful for when your getting spikes in the frame rate), other times you might just be interested in an average frame rate over time and I personally literally count how many frames (or more accurately acts) occured in a second and then update the value (so it only updates once every second rather then in realtime). You might even want to go further and record the FPS to disk so you can compare the change in a frame rate over time (I used to do this with a program I made that displayed given frame rates as a graph). Very useful for testing new optimisations and code that could potentially add more overhead. You could try implementing all of these and any other alternatives people might find useful when profiling their scenario. This scenario could then try to be more of a 'do-all FPS all-in-one' scenario.

Nice idea but it would be more useful if all of the FPS code was 100% contained in the Counter actor because then it would be easier to port and use in different scenarios.

There is already a place to ask general questions about Greenfoot: http://groups.google.com/group/greenfoot-discuss In the future it would be probably best to ask there, especially if you want a response as it's more likely to be read. Anywho, in order to upload you need to click on the File menu and then Export in the Greenfoot editor. You should also be using the latest version of Greenfoot. To make actors eat food, in the actor that's eating you check for an intersection with you food object with the getOneIntersectingObject method (i.e. getOneIntersectingObject(Food.class) if your food class is called Food). It returns null if a Food is not found, or a Food object if one is. If it did return a Food object then just remove it from the world (i.e. getWorld().removeObject(food)) and then do whatever happens when you've eaten food (like scoring some points). There are also resources on the www.Greenfoot.org site that should also be able to help.

A nice game, but I have a suggestion. Add weight to the balls that counteracts the mouses position, taking into account how far they are from the pivot in the middle. So as a ball rolls out to the edge you'd need to tilt the plane more and more to counteract it's effect and keep it flat.

An improvement, but it gets really laggy after a while (or at least on my 900mhz celeron). How are you representing the lines? I can imagine it's an array of points with you adding to it, then clearing and redrawing the entire screen (or something similar). If your not too concrned about undo then just draw any new lines directly to the background with no storing or clearing. It should then be at the same speed regardless of how many lines have been drawn since old ones are stored on the background. But you could still implement undo by copying the background over the last 5 times that a line was added (so undo is just going to a previous background). I'd aim to try and keep the speed consistent.