Discussions

You have yet to initialize the second set of images.

You cannot slow the animation by delaying the initializing of the animation images. You will need an extra counter to count act steps between image changes. You will also need to keep track of the last direction moved so this new counter can be set properly to change the image immediately when the direction does change. First, however, you should note that with your current code, some unwanted behavior will occur. Imagine, if both "a" and "left" are down, the speed double

Thanks!

Inverting should not change the speed -- it should change the direction:

Since the ForceField objects created belong to the Rocket objects that create them, maybe the ForceField class should be inside the Rocket class. Either way, the ForceField object created by a Rocket object should be referenced in the Rocket class and controlled by the Rocket object it belongs to.

@danpost I took the setPaintOrder method and ended up putting everything in order. The speed on everything is super choppy. This trying to figure out how that out.

You're right, danpost, I hadn't spotted that colision can also remove the object.

Ja, Ausrufezeichen werden zur Verneinung eingesetzt.

Where does the 30-second delay come in? When does it start? What, if anything, happens during the delay? And what happens when the 30 seconds is up? There are two things about the code provided that should be noted. One is your loose use of the getWorld method throughout the class. Once: the line <Code Omitted>

Thank you, it works. I guess I was thinking wrong.

In a World subclass, you would use: <Code Omitted>

For general info, as of the recent Greenfoot 3.8.0+, you can use the new Java feature for this kind of code, so that: <Code Omitted> Can be replaced with: <Code Omitted> Essentially, you can put a variable name after the type in "instanceof" and it declares that variable for use within the if. It will have the type that you just checked with the instanceof.

Easiest reply would be to put the int in your World subclass where it will be accessible to all Actor objects in the active world. You could go as far as adding a getter and a setter method (for that int) in that World subclass as well.

Since the size of a hand is variable, it might (will be) better to use List objects instead of Array objects for the hands (plus draw and discard piles). You can use an array for the players themselves (a game will have a set number of players, regardless of what that values might be. The if block might be best placed in your MyWorld act method. Or, at least the