Discussions

Believe me. As you continue programming, you will find how useful those other collision can be. They all have there benefits (and drawbacks).

Provided the parts of the snake each retain which part it follows, you only need to keep the head and the tail parts in fields. Never move the "body" of the snake. When moving, replace head with a body part and move head. Then, only if not eating, remove tail piece (the tail field needs updated first to the piece the tail follows).

The Greenfoot.delay() method will suspend all actions for the number of act cycles given as its parameter. If the touching of another actor causes the healthbar to decrease, then it is probably true that for each act the touching occurs or continues, the healthbar will decrease. My suggestion is to list objects it touches and only decrease the healthbar when an object is added to the list (and not when the object

My suggestion is to use static fields for the upgrades. They must be initialized during your initial world constructor only. Static fields are "class fields" which do not reset when a new world is created, nor when the scenario is reset. This is why they need initialized in the initial world constructor. The keyword "static" is added to the field declaration line. For example:

Try deleting all of your import statements to awt and swing in your classes. Also try deleting lines of code like "frc = ((Graphics2D)getImage().getAwtImage().getGraphics()).getFontRenderContext();" in your Score class. I think many/all awt/swing methods and/or directly accessing AWT images have no TeaVM/HTML5 translation available which causes it to fail when uploaded to Greenfoot's website. Good luck!

You share from the greenfoot editor. Use either Ctrl-E or Scenario >> Share.

Sorry for the delay in addressing this - due to travel and annual leave over the summer. I believe this is now fixed and all the scenarios which can be fixed are currently being processed to work again. (Your linked scenario has been done just as I write this.) Let us know if you spot any other problems.

Hey no_name, this is a pretty complicated problem but the answer is pretty straightforward. When Greenfoot resets your world instance, it recycles the JVM (Java Virtual Machine) which can annoyingly have some leftover data from previous runs. The most common way you will run out of heap space is by loading too many images. Even after an image is not attached to a Greenfoot Actor anymore (i.e. usually when the actor is removed from the world) its image is Cached by greenfoot so long as you used the method: <Code Omitted> Now, there are ways to load ima

Instead of three different Life# actors, try just one displaying the correct number of lives. You could start with the following:

I was able to fix the bug with my own project by uploading the game using version 3.8.2 which I archived here: https://archive.org/details/greenfoot-windows-382