Bug: instantiation order is used when evaluating previous action

[LuBeNo]

This has been keeping me busy some time...

Steps to reproduce:

• 1) SG moves to ally
• 2) SG changes to move to ressource
• 3) Now it depends on the instantiation order: In the very same tick, the bots with higher priority detect the SG to move to an ally. The bots with lower priority already detect the SG to move to a ressource. (what is a bug.)
• The bug does not appear when the SG flees from the ally in step 1.

Example in "set your priorities", shotgun is in second position. First bot idles one step longer than any other bot. All 3 screenshots were taken at the same tick. (pause)

Plan.jpg (67.49 KiB) Viewed 2542 times

AS Prio 1.jpg (120.68 KiB) Viewed 2542 times

AS Prio 2.jpg (122.31 KiB) Viewed 2542 times

[LuBeNo]

I can only add 3 images to one post:

SG.jpg (123.55 KiB) Viewed 2540 times

[pier4r]

Nice find

[LuBeNo]

I also reproduced the bug mentioned in: Timing issue with "moving to resource ally" (very similar)

Steps to reproduce:

• 1) SG moves to ressource
• 2) SG changes to attack an enemy
• 3) Now it depends on the instantiation order: In the very same tick, the bots with higher priority detect the SG to move to a ressource. The bots with lower priority detect the SG to move to an enemy. (what is a bug as SG never did move to an enemy)

Example in "starving", shotgun is in second position. First bot (SN) detects the SG to move to a ressource. The third bot (AS) detects the SG to move to an enemy. All 3 screenshots were taken at the same tick. (in pause)

Plan.jpg (87.98 KiB) Viewed 2521 times

SN.jpg (89.92 KiB) Viewed 2521 times

AS.jpg (87.1 KiB) Viewed 2521 times

[LuBeNo]

Here comes the SG state at the same tick:

SG.jpg (86.18 KiB) Viewed 2521 times

[LuBeNo]

I think the current implementation does not have a previousActionReference and uses only one actionReference for each bot:

Code: Select all

// can hold [Attack, Move, Flee, Idle]
Variable Bot[i].previousAction, Bot[i].currentAction

// can hold [enemyBot, Bot, enemyBase, Base, Ressource, Nullpointer]
Variable Bot[i].actionReference


// memorize previous action in the new tick
for(int i = 0; i < Bot.Count; i++) {
    Bot[i].previousAction = Bot[i].currentAction;
}


// evaluate bot plan
for(int i = 0; i < Bot.Count; i++) {
    Bot[i].currentAction = evaluatePlan();
    Bot[i].actionReference = evaluatePlanReference();
}

It should do the following:

Code: Select all

// can hold [Attack, Move, Flee, Idle]
Variable Bot[i].previousAction, Bot[i].currentAction

// can hold [enemyBot, Bot, enemyBase, Base, Ressource, Nullpointer]
Variable Bot[i].previousActionReference, Bot[i].currentActionReference


// memorize previous action and previous action reference in the new tick
for(int i = 0; i < Bot.Count; i++) {
    Bot[i].previousAction = Bot[i].currentAction;
    Bot[i].previousActionReference = Bot[i].currentActionReference;
}


// evaluate bot plan
for(int i = 0; i < Bot.Count; i++) {
    Bot[i].currentAction = evaluatePlan();
    Bot[i].currentActionReference = evaluatePlanReference();
}

[LuBeNo]

I also reproduced the bug mentioned in: Same teams, different sides, different results.

Steps to reproduce:
1) SG moves to ressource
2) When the SG detects an enemy moving towards a ressource in close range, it switches to attacking.
3) Now it depends on the instantiation order: In the very same tick, the SG with higher priority (from team white) detects the enemy SG to move to a ressource inside close range and starts to attack. The SG with lower priority (from team red) does not detect the SG to move anymore and continues to move to the ressource. (what is a bug)

Example in "starving", both shotguns have the same plan. Both screenshots were taken at the same tick. (in pause)

Plan.jpg (60.65 KiB) Viewed 2509 times

SG1.jpg (125.82 KiB) Viewed 2509 times

SG2.jpg (122.32 KiB) Viewed 2509 times

[pier4r]

Really nice work. Hopefully GFX will see it

[GFX47]

Thanks for your time reproducing and studying it. It helps me a lot.
I think you're pretty close to the issue.

[Captain Spock (Castlevania)]

Seeing that it will be fixed in alpha 8. I'm quite interested in whether "symmetry breaking" can be ultimately solved.

Now I have agreement with LuBeNo's point, asynchronous evaluation at same tick is a source of asymmetry. It must happen in the detection of moving/fleeing. I made another even simpler experiment to prove it:
[AI with 2 nodes]
Node1: Attack Closest MovingToSelf MovingToAlly Enemy
Node2: MovingToward Closest Enemy
In Interference, assign the above AI to one bot per team, and let the other bot do nothing.
When it begins, we will see that the bot from one team is moving, and the bot from the other team is attacking.

Aside from this, I'm wondering if there are other possibilities to break the symmetry. Unique tagging and multiple unit collision comes into my mind, but I guess they could be covered by using a symmetric initialization order. However, how about this:
Bots from both teams are trying to catch a ball and arrives at the same time. Who can get it? It is quite decisive problem, isn't it?

[GFX47]

Bots from both teams are trying to catch a ball and arrives at the same time. Who can get it? It is quite decisive problem, isn't it?

None of them catches the resource.

Actually, each game turn, 3 things are done:
1. All bots' AIs are checked
2. All bots are moved, collisions are computed
3. If only one team is in catching distance from a resource, the team gets it, or nobody does.

[Captain Spock (Castlevania)]

Bots from both teams are trying to catch a ball and arrives at the same time. Who can get it? It is quite decisive problem, isn't it?

None of them catches the resource.

Actually, each game turn, 3 things are done:
1. All bots' AIs are checked
2. All bots are moved, collisions are computed
3. If only one team is in catching distance from a resource, the team gets it, or nobody does.

That is good. But I guess that previous action stack is needed to avoid asynchronous evaluation?

[GFX47]

Stack?

[pier4r]

Bots from both teams are trying to catch a ball and arrives at the same time. Who can get it? It is quite decisive problem, isn't it?

None of them catches the resource.

Actually, each game turn, 3 things are done:
1. All bots' AIs are checked
2. All bots are moved, collisions are computed
3. If only one team is in catching distance from a resource, the team gets it, or nobody does.

added to the FAQ

[Captain Spock (Castlevania)]

Stack?

Sorry. Not a stack, just a variable for each bot.

[GFX47]

If you mean code has to check the previous tick action instead of the current one, yes.
It already does actually. I mean it should ^^

[Kanishka]

I mean it should ^^

This.

[Kanishka]

Okay... I'm free. Dr D, or anyone else, please inform me if something needs to be reproduced or tested.

[LuBeNo]

I can confirm that I cannot reproduce the behavior with Alpha 8. (Only tried to reproduce the setting from post #7) Looks good now.

[masterplayer]

Instant team tags can be used to trick the "previous action reference", allowing your bots to send information downwards their instantiation order without any delay.

First problem: Information sent upwards is recognized one tick later, breaking the symmetry of your team and eventually causing a butterfly effect.

Second problem: Bot A could tell bot B what he will do in the current tick, giving bot B his information one tick earlier as usual. Ignoring this problem would force all players to use a huge amount of tags, if they don't want to waste a tick of "reaction time" caused by the "previous action reference".

If you have no clue what I am talking about, create a team setup with one sniper and make all bots use the AI down below. Watch the replay in slow motion and you will see one bot being team tagged A first and team tagged B afterwards and another bot being team tagged B instantly.