The number of frames per second in a Greenfoot scanerio is not constant, as the speed can be changed by the speed slider. Time consuming code will also make your scenario run at a slower frames/second than it would normally. For the default value of the speed slider, the scenario will attempt to run at a maximum of 60 act cycles per second.

Isn't this also linked to the speed of the machine its running on? I.E. No computer is the same as another, in terms of processor, graphics card, memory speed, etc, etc. Although the exception here is a fixed machine (say a specific Apple mac, iPad, etc).. Therefore, the frames per second (FPS) is very important for games to level the playing field. If a game is written to look at the frames per second and then chooses to work at 30 fps, it helps to ensure the frame rate on other faster machines will operate at the same intended speed.

I believe that Greenfoot will always try to make the scenario run at the speed dictated by the speed slider, and the only time it will run at any other speed would be when the code takes up too long of a time to execute.

You need to take a copy of the System time when the game starts. You then take the System time at the end and subtract one from the other (via a julian date format) and then translate the answer back to a Calendar object. Sorry, have to be brief. You need to look these class javadocs up.

I've got a ticket open suggesting we change the slider to be related to FPS, as it's a bit unwieldy at the moment. Builderboy2005 is right: Greenfoot takes the speed slider and turns it into a delay. So let's say the speed slider is currently set to 20 FPS, or 50ms per frame. We wake up at the start of the frame, and execute the act() code for your world and actors, and redraw the screen. This might take, say, 29ms. We then sleep for 21ms (so a total of 50ms for the frame), then do the next frame. If your code takes too long: say 58ms for processing the frame, we simply don't sleep at all, and start the next frame immediately. So the slider implies a maximum frame rate, which will obviously be missed if your scenario simply can't process frames fast enough. As for tylers: if you want to have some in-game notion of how long it took a player to complete a particular level, then counting the number of act() calls is the way to do it (and don't worry about converting that back into wall-clock time). Ultimately, Greenfoot scenarios are normally predicated on a fixed movement per act(), so really a player's skill is to do with how many act()s it takes, not how many minutes. Just the same as the important thing to how long a chess game takes is the number of moves, not the number of minutes. Or were you asking a different question?

MMm, understand your point nccb regarding the act count, but I'd always prefer to know the elapsed time. As for FPS< would be a good change. When you say the main thread sleeps, this is wasted time if the rest of the engine can't do prep work. I don't suppose we could have a secondary thread that can be used for worker threads? Probably not required, but would be useful.

Not sure what you mean by the 'engine', but if you're talking about the scenario itself, it can do any prep work it wants during the act cycle - either at the end or at the beginning. The thread sleeps only if all the actors have finished acting. Greenfoot is meant for beginners, and multi-threading is an advanced topic. There are many very competent programmers who still have a lot of trouble getting concurrency right! Besides, the Greenfoot API is not thread-safe. If you really want to mess around with threads, however, you can always use the standard Java API for doing so. My personal advice is: Don't do it :)