0
\$\begingroup\$

The game is 2d, and the genre of this game is tower defense.

I managed to get it moving to the cell and arrived in the cell. But it never arrives at the middle of a cell.

Here's what I did...

public Enemy plotPath(Cell start, Enemy enemy, float deltaTime) {

    //Direction 
    int directionx = 0;
    int directiony = 0;
    if(enemy.position.x < start.position.x) {
        directionx = GraphConstants.X_DIRECTION_RIGHT;
    }
    else if(enemy.position.x > position.x){
        directionx = GraphConstants.X_DIRECTION_LEFT;
    }
    else {
        directionx = GraphConstants.X_DIRECTION_NA;
    }

    if(enemy.position.y < start.position.y) {
        directiony = GraphConstants.Y_DIRECTION_DOWN;
    }
    else if(enemy.position.y > start.position.y){
        directiony = GraphConstants.Y_DIRECTION_UP;
    }
    else {
        directiony = GraphConstants.Y_DIRECTION_NA;
    }
    enemy.position.add(velocity.x * deltaTime * directionx, velocity.y * deltaTime * directiony);

    return enemy;
}

Then, the game would calculate the distance between the enemy and a point. If it is zero, then remove the cell from the enemy's list of cells (A*star algorithm). The enemy position would be calculated by vector addition. It looks like the enemy's position wouldn't never arrive at the point.

Vector addition

public Vector2 add(float x, float y) {
        this.x += x;
        this.y += y;
        return this;
    }

I have the enemy positioned in (-0.1f, 3.5f). The velocity of the enemy is 2f. The cell is based 1f x 1f. The middle of a cell is (0.5f, 3.5f);

I logged the calculations, here's the calculations -

-0.1    3.5
0.03482666  3.5
0.04385986  3.5
0.054541014 3.5
0.072546385 3.5
0.106665045 3.5
0.14072266  3.5
0.17520753  3.5
0.21030274  3.5
0.24313965  3.5
0.27927247  3.5
0.31210938  3.5
0.3467163   3.5
0.3805298   3.5
0.41867676  3.5
0.44882813  3.5
0.486792    3.5
0.5188354   3.5

I used distance between the enemy and the middle of a cell -

if(position.dist(start.position) == 0) {
                path.remove(0);
 }

I'm thinking the velocity * deltaTime * direction isn't correct. I tried to google around but couldn't find the solution. Any ideas?

\$\endgroup\$
2
  • \$\begingroup\$ But it did arrive, it actually went a little further 0.51 or did I miss something? \$\endgroup\$ Commented Jun 4, 2011 at 22:07
  • \$\begingroup\$ You are right. I overlooked that part. \$\endgroup\$
    – Tashu
    Commented Jun 4, 2011 at 23:18

2 Answers 2

2
\$\begingroup\$

Can you show the code where you check if it has arrived? Do you make a floating point comparison using == ? That would not work, check for >= or <=

Edit: You are right, velocity * deltaTime * direction isn't correct, because the velocity should already be the direction, assuming that the velocity has been set properly. It should only be velocity * deltaTime, but I dont think thats the problem, since it actually arrived as your logging shows.

Edit: Instead of:

if(position.dist(start.position) == 0)

use something like:

if(position.dist(start.position) < 0.3)
\$\endgroup\$
9
  • \$\begingroup\$ I added the code as you requested. I calculated the distance between the enemy and the middle of a cell and see if it equals 0. Mark mentioned that it actually passed the middle of a cell. I'm not sure why it did that. The directions is based on 1's like -1, 1, or 0 (no movement on x or y). \$\endgroup\$
    – Tashu
    Commented Jun 4, 2011 at 23:23
  • \$\begingroup\$ It was me who mentioned that ;) The point is not the wrong direction calculation, since as I said, it arrives. The point is how you check that it arrives. You check for a zero distance. But it is never exactly zero, because your calculation goes in steps like this 0.44, 0.48, 0.51 . You see it was never exactly 0.5 hence no zero distance. That is why I said you have to ckech using > or < but not using == 0 \$\endgroup\$ Commented Jun 4, 2011 at 23:29
  • \$\begingroup\$ See my edit for the exact implementation \$\endgroup\$ Commented Jun 4, 2011 at 23:35
  • 1
    \$\begingroup\$ Depending on the speed you must adjust the 0.3 \$\endgroup\$ Commented Jun 4, 2011 at 23:36
  • \$\begingroup\$ Got it. I think I understand your point. I thought it'll be better to get it to zero but that works better. Thanks, Maik. \$\endgroup\$
    – Tashu
    Commented Jun 4, 2011 at 23:42
0
\$\begingroup\$

if you are going with a* algorithm there is no need for enemy to reach to exactly center of the cell, just check if it is near the center remove that cell from it's list. you can easily check that : sqrt(sqr(enemy.x - cell.center.x) + sqr(enemy.y - cell.center.y)) < closevalue. you can also change velocity at every frame to move directly toward the center and if you are realy close, just set velocity to distance / dt or jump your character directly to the center. and as maik said having another variable as direction is wrong, since velocity already contains direction (it can be negetive or positive).

\$\endgroup\$
1
  • \$\begingroup\$ I see, thanks for solutions. I'll go ahead and work on. Thanks. \$\endgroup\$
    – Tashu
    Commented Jun 4, 2011 at 23:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .