Discussions

Looks to me like lines 8 thru 11 (presuming "actor1", which looks undefined, should be "snake") are specific to the turtle and lines 4 thru 7 are specific to the snake and, therefore should be done in their specific classes (however, cross-collision checking should be avoided).

Maybe more of a spammer than a hacker. Possibly all 6 users who voted were disabled. ?? (just a guess) Not something I would suggest doing, even if possible.

There is not -- at least, not among the methods given in the greenfoot package. However, that does not preclude you from making one yourself; or from importing a class that does have one. The SmoothMover class has a setLocation(double, double) method. Use the menu bar commands "Edit >> Import class ..." and select it. Then have your Actor subclass extend it. You will then have to modify your code to make use of it.

You will need a static field. However, because of the scope applied to static fields (they do not reset upon resetting the scenario), you will need to be able to distinguish between worlds instances that start a game (initial ones) from those that do not (subsequent ones). The best way to accomplish that is by giving your worlds multiple constuctors -- a non-parameterized one for initial worlds and a parameterized one for subsequent worlds:

You cannot "steal" the standard input stream (FileDescriptor.in) from greenfoot, which uses it for the Greenfoot class methods getKey, ask and isKeyDown. The same may be true for stdout. Use Greenfoot.ask for user keyboard input of character strings and System.out.print or println for output.

Try this.

Oops.. must have missed that method. Thanks anyways!

hey danpost, thanks a lot for the helping and suggesting me now it's not lagging anymore i think the problem was with the draw Oval, fill oval, setColor(rand color) when i changed it to a static image of the shield then it was not lagging anymore

Please refer to this page of the Java tutorials.

Oftentimes, the inclusion of static fields (class variables) in your MyWorld class is sufficient to allow the game to become more difficult from one world instance to the next. Some static final fields (class constants) can be used to describe the initial set-up of a "level". One static field (variable) would be used to track which level is current.

To actually implement the moving system, you need to save your speed from frame to frame:

An example is given in the first section of this page of the java tutorials.

The problem is that you have two (2) methods that could potentially remove the actor from the world, you call them unconditionally and they both require that the actor be in the world when called. You could use an if statement to place the condition of the second calling that the actor be in the world, as such: <Code Omitted>However, if you decide to rearrange things, it may cause issues again. Better, would be to start both methods, removeEnemy and hitByProjectile, with the following line:

That seems to have fixed the issue! Thank you so much danpost, you're an absolute lifesaver!

thank you so much, I am pretty new to this, so thanks