The problem is here: public void kill() { enemy = new Enemy(); getWorld().getObjects(Enemy.class); getWorld().removeObject(enemy); } In this method you're doing 3 things: 1) Creating a new enemy 2) Getting all the enemy objects in the world but not storing them anywhere 3) Removing the new enemy you created (but never added to the world.) What you actually need to do is store the result of the getObjects() method in a variable, and then loop through that list and tell the world to remove each item in it :-)

Are you joking with the above method or do you really want me to comment on it? :P The method will always return false at the moment because it's only used to walk into blocks. If you download it and shift one of the other blocks up a bit (so she walks into the side) then it'll return true and she won't progress any further. Ish. As pointed out earlier it's still a bit buggy when walking to the left! In terms of indentation - well, yes code should be indented properly but if not, treat it as a challenge ;) Write a little utility that takes the Greenfoot project and rewrites all the source files with indentation of your choosing :) It shouldn't take long, I first wrote mine a few years back (for general source files though not Greenfoot projects) when various people kept throwing source files my way with hideous indentation and asking me what was wrong with them. It's probably been the quickest program to write that's saved me the most time! Yeah it doesn't manage things absolutely perfectly, if lines are split then it doesn't indent them any more than initially (and I'm sure there's other bugs in there somewhere) but it makes things more than readable. You're welcome to mine if you want it, but it does make a nice little programming task.

Without meaning to put you off or sound condescending at all, it might help you to do some seperate reading up on various Java basics - primitive types, objects, types of methods, returning values, parameters etc. and what they do. I'm happy to keep throwing pointers at you but it's not really going to do much if you don't understand what the code does! In terms of the above code, you'd need to put that in a seperate method in a way that would function to determine whether you were about to sink into the ground. It's much like the approachWall() method, but this time the amount you "look ahead" and therefore feed to the getOneObjectAtOffset() method will depend on how fast you're travelling :-)

Not exactly, because logically speaking the above doesn't really make sense. getOneObjectAtOffset returns an actor, and you need to store that somewhere to use it. What are you trying to do by returning != null? You can say: return getOneObjectAtOffset(x, y, Ground.class) != null; which is equivalent to: Actor a = getOneObjectAtOffset(x, y, Ground.class); if(a!=null) { return true; } else { return false; } ...or you could do: Actor a = getOneObjectAtOffset(x, y, Ground.class); return a != null; != means not equals, just like == means equals - you have to have two things to compare either side, otherwise it doesn't make sense and the compiler won't let it through.

Have a look at http://www.greenfoot.org/doc/javadoc/, in the Actor class: "Return one object that is located at the specified cell (relative to this objects location). Objects found can be restricted to a specific class (and its subclasses) by supplying the 'cls' parameter. If more than one object of the specified class resides at that location, one of them will be chosen and returned." So it tries to find an object at an offset from the actor you're calling it on (x and y are used to specify the offset) and returns null if it can't find any.

Hmm, I don't actually remember it being quite this slow when I last played it at all - perhaps the "other system" of loading enemy images has made things worse instead of better?

Hmm. I think I need to work on my gender at sight skills... Well, an easy way to "solve" it would be: if(getOneIntersectingObject(Ground.class)!=null) { setLocation(getX(), getY()-1); } That'll also "cure" the problem of him falling through the ground. I use "" because when I say "solve" and "cure", instead of falling off or sinking into the ground then he'll rise up gradually instead. You could actually solve it (without inverted commas) by using the getOneObjectAtOffset() method to look ahead at the number of pixels that he'd move in the next act method, and then adjust it accordingly (i.e. if he's travelling at a rate of 10 pixels per iteration, but he's only 5 pixels away from the ground, change the speed to 5 pixels instead of 10. I'm going to be mean though and leave you to work out how to put that into code ;)