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.

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!

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.

Odd that it's not lagging for any of you... maybe that's one of the blessings of working with an underpowered computer! What I meant by lagging is that every six isometric redraws it would pause for a half-sec, even with the scenario speed up at max. I believe it has something to do with the fact that I was using a try-catch system every redraw, which Java is not good at doing quickly. This happened at as few as 10 people. Fixed it now, so hopefully that means I can add some extra logic to the little people.

True 3D is not practical to do for a project like this. However, since I am incapable of good 2D drawings, isometrics are the only course left.