Discussions

There are not that many to choose from. Take a look at your options here.

Things to make things easier: (1) add a constructor to set the initial image (or set the initial image as the default image for objects of the class); (2) set the appropriate image immediately after changing the 'live' value instead of every act cycle; the check for game over can be done there also; (3) there is no need for an 'act' method in the class; everything is done when the counter is created or when a field changes its value due to other classes calling for it. In other words, you only need the constructor to set the initial values and image and a method that is called from outs

First, I am only one guy. But, as far as tutorials go, you can check out the trails at the java website. Start with the 'Trails Covering the Basics' links on this page.

As far as actors spawning atop one another, the code given above looks awfully bulky; although, it would appear to do the trick as far as keeping them from spawning atop one another. Where exactly are you declaring the variables given ('spriteOnLeft', 'spriteInMid' and 'spriteOnRight')? With a little organization, the bulkiness can be practically eliminated. Using a 'switch' structure (or one-line 'if' statements) to create the appropriate actor to spawn would eliminate the need for multiple 'if' structures for placing the actor properly. Using an int array to hold the x-coordinates that a

You could have the class extend my QActor class which allows a factor of 100x fine tuning to the movement and rotation of actors. Check my support classes collection for it (it is in the Asteroids w/Improved QActor class scenario). Then, your original code would have 1/100th the original speed. You can now increase 'move(1)' to 'move(50)' to produce half the original speed or adjust it to your liking from there.

Thank you for all your replies, I have made one of the stupidest mistake of my life, it was just a problem with a name, GreenFoot didn't recognize "Explosion.png" because the file's name was " Explode.png" hahaha !

I think that is because you have information tags in your sound file. Try resaving the files without them.

This looks like a partial stack trace. The first part (including the exception type) has been cut off. Are you able to get the full stack trace? (Try turning on the "unlimited buffering" optional from the terminal menu). Also, what version of Greenfoot are you using?

All your methods called from the act method, except for the 'move' method, could potentially remove the actor from the world. If any but the last one does, you will get that error. You could either place the following line between each method: <Code Omitted>or you can preceed each method call like this example <Code Omitted>

In Level1 act method, add this line: <Code Omitted>

I suggest you create a new simple scenario that reproduces this error, then comment out the adding of the object into the world and upload the scenario, publishing source, here so we can look at the issue first-hand.

@valdes, I am so sorry. I stated that the change in line five was to prevent flicker -- and that is not what I meant to say (that is why the changes was not perceptible to your eye). That change was introduced so that the image of the actor was not continuously being set when it was not changing.

To be specific, the Actor class API says this: 'protected' means you can only call the method from an Actor subclass (or the Actor class which you cannot edit); 'java.util.List' means it returns a List object (btw, the method never returns 'null'); 'getObjectsInRange' is the name of the method; 'int radius' is the first parameter which should be a positive integer indicating how far the search extends; 'java.lang.Class cls' is the seco