[The Accountant] Movement miscalculation: bug or feature?

Since the other topic got fluctuated with different ideas I wanted to separete an actual issue so it can become more visible. In test case 11 the following can be observed:

As you can see the Y position of the enemy becomes incorrect after the first step and only gets corrected when he reaches the data point.

Is this a bug? If so, ping me, I can send you an 8 lines snippet which will calculate the positions perfectly.

Is this a feature? In this case, it prevents half of the strategies, which try to plan ahead for multiple turns, because their planning becomes invalid after the turn passes, and will need to start everything from scratch again. What’s the reasoning behind this?

Thank you for your time, we look forward getting some clarity on this.

13 Likes

Hello,
Yes there is a rounding error which causes a miscalculates when moving at a very specific angle.
Thanks for pointing that out, I’ll fix it immediately.

I appreciate the intention to fix it, I’ve noticed the change, but unfortunately it’s now happening on every level. After taking 4 steps correctly the 5th step is being miscalculated on the first level for example.

Hello,
I’ve fixed that issue too.
However this means that agents now move very very slightly differently now.

Here is the code we use to compute movement (in Java):

public void moveTo(int targetX, int targetY, int speed) {
    double dist = distanceTo(targetX, targetY);
    if (dist <= speed) {
        x = targetX;
        y = targetY;
    } else {
        x = (int) (x + ((targetX - x) * speed / dist));
        y = (int) (y + ((targetY - y) * speed / dist));
    }
}

EDITED

3 Likes

Thanks a lot for fixing this Julien!

1 Like

Just to mention that with this formula, agents move “faster” when directing to 0,0…

Will use an exemple: from 1000,1000 to 2000,2000=> we go to (int)(1353,55) => 1353,1353 and after, (int)(1706,55)=>1706,1706 => total distance: 998,4…

from 1000,1000 to 0,0=> we go to (int)(646,45)=> 646,646 and after, (int)(292,45)=> 292,292 => total distance: 1001,2

To have same distance in both case, you need to (x + (int)((targetX - x) * speed / dist));

(of course, if (int)(-353,55)=-353 in Java, not sure of this ;p)

It is expected that agents move faster torwards 0,0 (“The coordinate system of the game uses whole numbers only. If Wolff or an enemy should land on non-whole coordinates, those coordinates are rounded down.”). Therefore, for this specific contest, Julien’s corrected formula is the right one.

True… but what append if there is a data on this point: Distance is >500 (500,65 in this case) but the guy lands on it… does it take it this turn? or the next?

An other fun things, is that it can be faster to take a data point that is farer than an other…

Ex: Enemy on 2000,2000 data on 3413,3413 => distance 1998,28 => will take 5 turns
Data on 586,586 => Distance 1999,70 => will take 4 turns…

Was just to say… game work like description said, i know… But need to accept that we and enemy can move faster in a direction than an other ;p

On this specific topic, the rules are slightly misleading. They state that :

If the enemy is less than 500 units away, the data point is lost and the enemy moves onto its coordinates.

The behavior of the game engine would be better described this way :

If the enemy can move on the data point, it is lost and the enemy moves onto its coordinates.

Indeed, it is possible for an enemy further than 500 units away to take a data point.

1 Like

I wasn’t sure ^^ Thx a lot :slight_smile:

Good point. I hadn’t spotted that

If the enemy can move on the data point, it is lost and the enemy moves onto its coordinates.

The problem with this sentence is the same as the original, the order of operations in the sentence make it seem like the data is take, then the position settled. Were as in the section with the operations has the retrieval as the last operation.

So it should say:

If the enemy can move on the data point the enemy moves onto its coordinates and the data is lost.