talk on the Walls bot's 'wrong' behaviour (with blocking API calls)

[SirStone]

This is just a talk I would like to bring up about the wrong behavior that Walls is showing and how and if can be prevented. I think it's an interesting topic because what is affecting Wall is affecting all the current and future bots.

For the ones that doesn't know what Wall is, in brief, it's a Sample Bot that uses only blocking calls (you can do only one action at time) and apply the strategy to reach a wall of the battlefield and run following it's perimeter with the gun and radar pointing always perpendicular to the body towards the center of the battlefield. As soon a bot is scanned, the bot fires a bullet. simple as that.

The current program of the bot is correct on the paper but the actual behavior often is not. As proof I want to bring here the very same gif that is showed at the main page of this project:

Walls is the bot with black body and yellow gun/radar. As you can see it is not following the walls of the battlefield, is instead bouncing 90 degrees every time it hits the wall. The gun also, is not pointing perpendicular to the body but a bit tilted.

I've observed the very same things on the Walls implemented with my API in Nim but I could never understand if the fault are skipped turns or other miscalculations. Now that I see that even the official API has the same issue, I would like to know if someone wants to share an opinion in the matter.

Cheers

[flemming-n-larsen]

@SirStone You are right.
This behaviour is caused by two reasons:

1. Bots sends their intents for each round: new turn rates, target movement speed etc.
2. Bots might miss sending their intents, if the round is skipped, or the package send over WebSocket is delayed.

I think the only thing we can do about it is to update the Bot Intent to support blocking intents. For example that a bot heading at 0 degrees want to turn 90 degrees, and hence must stop turning at 90 degrees. This will require some changes to the server as well, which must remember the state when the command was given (e.g. the start heading). This way the skipped turns will not impact the intention given by the blocking commands.
If the blocking command is sent later due to a skipped-turn, it will not do any harm, at least for bots like the Wall sample bot, as it will not have been able to send any bot-intent yet. Currently it is sending per turn, and might fail. But by sending new intent that it must turn 90 degrees compared to its current reading, it will only send a single intent when it is facing 0, 90, 180, or 270 degrees. If the command is not sent (or delayed), it will happen e.g. one or several turns later, where the heading has not changed (yet).

I think I will create a new branch (prototype) for it and see how this works out. But it will require additional work for people implementing their own Bot APIs, including the one for Nim and the official ones for Java and .Net.

[SirStone]

If I understand well, you would like to try an approach where the bot (the API) sends the intent once and not calculate on it's own the remaining of that action to be able to fill all the subsequent intents, instead the server will automatically consume the full action "internally" for all the required turns. Am I wrong?

While developing my own bot API I've convinced myself that part of the movement remains calculus I'm putting in could be saved and carried out by the server and I find it logical that if I can send in the intent to turn 90, the server should keep in the belly the request and consume it internally. All the other logic ca be left in the bot API, for example, understand when the turning is completed.

my NIM API would be easier to develop and would be more equal to yours.

The down point would be probably the other issue you mentioned, there will be need something that protects the request of the bot from WebSocket lost/delayed issues, handling a re-issue of the intent automatically maybe.

I think is worth to try with a prototype as you proponed.

[flemming-n-larsen]

@SirStone I am still looking into this issue and doing a lot of experimentation. I found out that trying to control it on the server side is not working as I hoped it would.
It needs more control on the Bot API based on the initial starting position and directions, and turning to an "absolute" direction to know the target direction for the body, gun, and radar. I did a prototype on the last part, which gives promising results, but I still need the initial position, when the bot skips starting turns. The reason being that the first turn might be tick #n, where the bot has already been rotated by the server. So a rotate 90 deg. would be based on a wrong angle.

[SirStone]

I think I've recently fixed this issue in my API. To me was caused by a queue of intents not cleaned correctly and was accumulating one or more extra intents. I've eliminated the queue and the bug disappeared (on my machine at least)

I've mirrored my private repo to github, it's called RTR_nim_botApi2 and I can tell that is much better than the first repo.

[flemming-n-larsen]

@SirStone Yeah, I noticed you created a new version 2 of your API due to the SkipperTester, which is using the new version. 🙂

[flemming-n-larsen]

@SirStone Just a heads up. I am updating/refactoring the Bot API for Java and .Net a bit to provide the initial/starting position of the bot with the GameStartedEvent. And I changed the InitialPosition.angle name into InitialPosition.direction, which is more correct and consistent with the rest of the API. You might want to update your NIM API as well?

Currently, all changes are on this branch:
https://github.com/robocode-dev/tank-royale/tree/start-position

[SirStone]

@flemming-n-larsen Thanks for the advise, I will update my code accordingly.

[flemming-n-larsen]

@SirStone
I forgot to mention that providing the start/initial position also works as a work-around and fallback if/when turns are being skipped in the start of a round. That is, if no tick event has been received yet, it the initial position will be used to determine the x and y coordinate of the bot (from the StartGameEvent along with the directions for the body, gun/turret, and radar.
This should fix the issue with the "Walls bot's 'wrong' behaviour" without the need to introduce complicated logic to fix this issue.

[flemming-n-larsen]

@SirStone I made a major bug fix causing a turn glitch to to "previous direction" not being set with a certain condition, causing wrong turn angles for the body, gun, and radar. 😊
This could be seen with the Walls bot's gun in the very first after reaching a wall.
This bug was really hard to nail!

Here is the commit with the fix:
6d0e934

[SirStone]

@flemming-n-larsen great! I'm going to wait for your next release to see this fix in action, and if I understood the code diff correctly...yes that was not an easy bug to find, nice catch!

PS: Sorry for the delay in answering, got busy days and low chances to wake up my pc.

PPS: I took time to switch to another OS too, Fedora Silverblue this time

[flemming-n-larsen]

@SirStone Cool. I look forward to see if this fixes your issue, when you test the coming 0.23.x release.

Regarding not answering fast. No worries. I know what you mean, I have times as well where I am slow at answering when I am busy. 😊

Fedora is a really good Linux distro in my mind. 👍

[flemming-n-larsen]

Fixed with release 0.23.0