This simulation was made by a ten-year-old after watching the explosion Greenfoot video tutorial! The only help he got was finding the syntax error in the line that places the original Rock.

This is a great example of what a 10-year-old can do in Greenfoot. A ten-year-old made this by himself after watching the Greenfoot video tutorial on explosions. (He has watched almost all of the other tutorials, and he already knows how to program in Scratch) http://www.greenfoot.org/doc/videos.html The Greenfoot tutorial shows a gray rock exploding into 40 pieces. Here are the modifications made by the ten-year-old. (The only help he got was finding the syntax error in the statement to place a rock in the original. 1) change number of fragments to 4000 2) change gravity to 0 3) change force to 0 4) set background image to space 5) made the world start with a rock in place The code for this is posted on kidslike.info http://www.kidslike.info/making_a_supernova_movie_greenfoot_programming_lesson

This interesting.. In My computer, if i created many objects my Greenfoot(1.4.5) become lagg Why in this scenario didnt ?(this scenario created 4000 objects !) I think every Greenfoot version if created (and added to world) many object it will become slower?

How fast it runs also depends a lot on what the objects are doing. If they are just moving without interacting with the other objects it will run faster than if you for instance check for collisions with other objects.

I'm not sure that that's exactly how it works...In my Realm of Battle, the original Fog Of War was ~2200 objects, none of which did anything. It slowed the game down immensely, even when no objects were interacting with them! I believe that at about 3000 objects, the game will perform at the middle speed setting even if it is set higher, regardless of the code content of the objects.

It is true that many objects will slow it down too. I wasn't quite clear enough about that. But, I was trying to explain why some scenarios seem to run smoothly with many objects where other scenarios don't. You can't directly use the number of objects as a measure of how fast a scenario will run. There are many other factors influencing the performance that might not be obvious. Some examples of this are: objects rotating, objects moving, objects added, objects removed, the distribution of objects, the use of intersection tests. For realm of battle, adding fog of war will make it much more expensive to do collision checks between the other objects, because the fog objects will also be part of the structure that will have to be examined. Greenfoot's collision detecting mechanism could be improved in many ways, but currently it is not high on our priority list, even though it is a very interesting problem.

Michael Kolling has every actor loads its own image. http://www.bluej.org/mrt/?p=101 In this game, all the debris all created with a single addobject statement, and they all have the same code.

...but the Debris objects don't have setImage("images/beeper.png"); in their constructor, they rely on the image having been set in the Greenfoot IDE. This is static - it's the same for all Debris objects, so it's only loaded once. If the setImage method were being used, then it would be loaded for EACH AND EVERY Debris object that was created. If you had that line at the beginning of the constructor (as in mik's example that you point to) then yes, there would be a huge pause while all the images were loaded. If you don't believe me, download the source and give it a try ;)