You can try using getOneIntersectingObject(Crate.class); and then you have to check if the crate's getX() is > than figure's getX() (meaning the crate is to the right).

Hm. You can tell the character if it is not clear in front (you can call a separate boolean method that does the check here), and if it is not clear, do not move.

But if I say 'do not move' then I can't move AWAY from the box either. Zerg, I will add some eventually. First I want to work out all the glitches and get up to about level 3 at it's previous stage. :)

To be able to move away, the boolean should only return true when going right, and there is a box. If there is a box to the right, but left is pressed, moving is possible. (Something along the line like that>).

Ha, I like this one! my favourite one! Left an "I like it"

Where do you get yout images from?? do you use a proggramm to create them by yourself? If so, which programm??

@ kensh, really? I haven't noticed that happen to me. I'll look into it though. :) @ Tigrex, Thanks!! :D I am drawing all the pictures myself in Photoshop. @ MTK, what do you mean?

I mean the GNU Image Manipulation Program (and Inkscape). It's Free/Open Source and served me much better than Paint Shop Pro or Photoshop.

I found two bugs: When you fire when you reached the highest position you can jump at from your location, you fall down, but stop a little bit above the ground. And you can jump into these boxes from the side.

I don't get the stopping just above the ground thing. I'm not sure how to fix that, but it's not that big a deal. Also, I don't know how to fix the other either. Thanks though. :)

To keep the character from sinking into the ground, I would run a while loop on every act that checks if the character is sunken and if so, raises the character 1 pixel. You can do similarly in all 4 directions. Be sure to use a while loop, not an if statement: with the while loop, the character will just fall and land perfectly right away, with the if he will slowly rise out of the floor frame by frame instead. I haven't tried this, but I guess you can loop-increment the position 1 by 1 too, this might keep the character from flying right through the floor when falling fast: while((int) y > getY() && !hitFloor) { setLocation(getX(), getY()+1); } while((int) y < getY() && !hitHead) { setLocation(getX(), getY()-1); } Instead of setLocation(getX(), (int) y);

Yeah, MTK. I can't think of a way to fix this. The arrow is a class called Arrowleft and the archer is a class called Archer1. Can you think of anything?

I tried that just now using the same counter method I used for the Figure firing, but for some reason the Archer shot, then shot again, then shot again a bit sooner until it eventually became a constant stream. :\

What you should do is instead of having the arrow reset when it reaches the end, have it remove itself. Then you can have the Archer1 create a new Arrowleft.

The code for having the arrow remove itself would be something like getWorld().removeObject(this); The benefit to doing it this way is you don't have to add both an arrow and an archer in the level constructor. You just add the archer, and have the archer add the arrows! Then you can do things like having archers move, or having archers spawn at different locations!

But can you help me with coding the Archer to add the arrows himself please? :) Right now the arrows have lot's of variables: public Arrowleft(int b, int l, int s, int t, int y){ left=l; speed=s; beginning=b; turn=t; starty=y; } So I have to do all this to add one: addObject(new Arrowleft(580,150,6,0,185),580,185); How can I make the archer control all that?

This would probably be better: public Arrow(double angle) { } public void addedToWorld(World world) { x = getX(); y = getY(); } public void move() { //call on every act x += Math.sin(Math.toRadians(angle)); y += Math.cos(Math.toRadians(angle)); } To create a left-pointing arrow: getWorld().addObject(new Arrow(270), 580, 185);

I meant: public Arrow(double angle) { this.angle = angle; }

Also, it it very confusing for me that one hand controls half the motion, and the other hand controls half the motion and firing. It seems that one hand should move and the other should fire (perhaps up tu jump, space to fire)?

so long as the arrow is removing itself at the end instead of resetting, you only need the direction and and a life time for the arrow. You can use MTK's code for the direction, and then add to the constructor public Arrow(double angle, int life){ this.life = life; this.angle = angle; } Then in the act method, have a timer variable increment each act and when it is the same as life, then remove the arrow.

You need a lifetime if you want the arrow to stop eventually! Otherwise you can just wait until it hits the edge of the world and remove it then. If there is no time at which it is removed, then you wind up with too many arrows :P