Running without GUI, reloading the bot and running speed

[SirStone]

Hi
I'm trying to start developing a bot for this version of Robocode but I'm meeting a couple of big walls that I don't know if I'm missing to see the way around them or if these are features that still requires development.

First of all, is there a way to hot-reload the bot during the battle? In the classic version of Robocode I just need to restart the battle that my bot is reloaded with the new code. This helps a lot with the speed in the development of a bot. Here I see the with a restart the bot can't be reloaded because the bot is a different process itself, and if I reboot the bot for the battle is a bot leaving the game.
Is there a way to "update" the bot code without the need to recreate a battle from start?

This leads me to the next question: is there a way to launch a server+bot+observer+any other requirement prgrammatically and without the gui? This would be required to create some automatic process useful to train bots with, for example, machine learning algorithms. I can't figure iut right a way how to achieve it but I see that should be possiible, I just don't know If it's only still missing documentation or is not possible at all.

I have an old 10+ yers old macbook pro, it can start battles but I noticed a couple of issues that I fear is related to the slowness of my machine and I would like to ask confirmation to this.
I noticed that if I raise the TPS the server registers my request but the game doesn't look like is affect, maybe a little if not at all; is this because is already running at the maximum speed my computer is capable of handling the game?
I've found out the little tooltip that raises up if you keep the mouse over the TPS cursor. Is now clear why I could not go over e certain amount of speed, the turn can't go faster the allowed timeoud for a turn, still would be nice to see the actual TPS is the game running at, at this point.
Using "Walls" sample bot I've noticed that it sometimes is like not turning 90 degrees on hitting the corner but a little more so the bot start taking a diagonal path towards a wall, turning 90 degrees and keeping that new diagonal path angle until a new change occurs.
Is this known? Maybe a bug in the bot? Or is my computer so slow that the bot receives/gives out a wrong informations due some latency answering to the server?

Sorry If put down a loto questions, but I preferred to take my time to try and undertand all this by myself and in my little free time I couldn't give answers to these.

Cheers!

[flemming-n-larsen]

Hi Davide,
That is a lot of questions, and I will try to answer them one by one in the following.

Hot-reload?
TankRoyale is not like the Original Robocode running within the JVM with all the pros and cons.
With TankRoyale, your bot, controller, observer connects to a real server running the game, and the GUI is just a controller/observer displaying information provided by the server. Your bot is controlled by the server, and it needs to react on the events sent from the server, or it will be kicked.
You can do whatever you want for your bot. But the connection needs to stay open (for hot reload?), and your need to make sure your bot continues to react on game updates/events sent from the server while hot reloading.

"hot reload" is not something I will look into for Robocode Tank Royale. That is up to the bot developers to do or provide.
I provided a bot api for Java and .Net, and will provide an api for web later. If you want more control over the bot, you can make your own version of the api or make an API or your own as you wish, as long as it stick to the protocol and schemas.

You can read about the schemas and protocol used in Tank Royale here:
https://github.com/robocode-dev/tank-royale/tree/master/schema
https://github.com/robocode-dev/tank-royale/tree/master/schema/schemas#schemas

[flemming-n-larsen]

@SirStone
Thank you for following up and this and your detication to this game! And also your nice thoughts and suggestions.😊

If you found an issue/flaw in the game, more people will eventually run into the same stuggle. So let's fix it. 🙂

Btw. I also tend to use may hours on creating this game and get rid of annoying bugs etc. to stabilize the game. 😉

Generated ID at server-side

I really like your idea of letting the server generate an unique id it sends to the bot (actually any client).
It could be a plain UUID (looong!), but it could also be some generated ID that is somewhat shorter and easier to display on the UI, if the user wants to see it? In a battle, all bots are represented by and id like 1, 2, 3.. etc. But this is only for the battle, and would not work as an identifier.
Anyways, this ID need to be added to the bot-handshake, and at least cover this sequence/flow.
So I will start looking into that.

Communication with server (commands)

I agree that this should be possible in the future. Especially, when the game gets more advanced. So I get your point, and you are right.
Regarding the version of the game, this is sent through the bot-handshake already, and I guess you need to know the port as well in order to communicate with it in the first place. 😉
But I guess other commands might be relevant? If so, I propose you create independent feature request here to make sure we keep track and progress and let other people give suggestions/ideas to those requests as well. 🙂 So if you have some nice commands we should add, then don't hesitate with creating a feature request for it.

[flemming-n-larsen]

@SirStone
With release 0.17.0 I rolled back the boot-id concept, and replaced it with the session id concept, where the session id is generated by the server, which the client must sent back with it's handshake.

This should help you solving your challenge. 🙂

[SirStone]

Very nice, the sessionID makes more sense than the boot id. But still this can't solve my challenge. I've wrote as you suggested a detailed "independent feature request". Hope it helps you to help me and possibly others.
Here the the link for the readers Possibility to identify bot from Process to Tick

[stobias123]

@SirStone - would love to see your code if you're willing to share! I've been working on a openai gym project around tank-royale, and a whipped together this little react ui - https://github.com/stobias123/tank-royale-web-ui - but your UI seems much more fully featured!

Would love to check it out

[SirStone]

@stobias123 I'm continuosly planning to put the code on a github repo, I really believe that this piece (part of a bigger project of mine) can be useful to others too, but I am always postponing the job because in order to do this I have some steps to do before to make the repo really usable, for example: stripping the project out of the main project, making a useful README that explains how to use it, move some parts of the code to .env files for secrets and other environmenal variables in order to avoid to need to edit code for these things.
Now that I have proof that someone could really benefit from it I'll defenitely try my best to provide the community with the project of my WebUI. Maybe I was just waiting for someone to ask for it :)

[flemming-n-larsen]

Running Tank Royale without a GUI

This is definitely possible. Again, you can have a look at the schemas and the sequence diagrams that gives an idea of the protocol being used.

You need to:

• Start up a server (could be by a controller)
• Let the controller/observer join the server
• Let the controller instruct the server what to do, e.g. to start a battle with some specific bots.

Robocode Tank Royale was designed with the server, controller, observer mindset so it would be possible to control the server and the game.

But I have not provided any API similar to the robocode.control package from the original game. I might do it sometime in the future, but this is not a priority yet (see roadmap)

[flemming-n-larsen]

TPS (Turns Per Second)
I don't think running on an old machine should be a big problem for the game. The true limitation is how fast the packages can be send over the Internet or at the localhost via a WebSocket. And running most CPU heavy stuff in its own process should make your code incredible fast. The "warmup" time for the websocket might give some latency with the first turns for the very first round.

What you really need to look for is the turn timeout measured in microseconds. All bots can use up to X amount of time limited by the turn timeout. You set this value from the Setup Rules in the GUI for a specific type of game. Normally it is set to 30000 microsecond, which is 30 milliseconds giving a TPS of 1000 / 30 = 33 TPS.
When robots is using too much time and passes the turn timeout, they will skip the turn and the server/game continues to the next turn. But 30.000 microseconds is a very long time on a modern computer.

If you want to have a higher TPS, you could set the turn timeout to e.g. 1000, meaning that the bots will have 1000 microsecond to make their move (send their intent, which is the same as calling go() from the bot API). Then you can set your TPS slider to 1000 / 1 = 1 TPS, which is pretty fast, when you have set the turn timeout to 1000.

Notice, if bots do little computing and almost send their intent to the server right away, and all bots do that, the TPS will increase as all bots sent their intent before the turn timeout. But bots could in worse case use more processing power and make heavy computations in order to make best use of the time available before sending their move.

You could try out a low turn timeout with the sample bots, and raise the TPS to a big value. The sample bots is almost doing nothing, so they can have a very low turn timeout.

[flemming-n-larsen]

Movement of the Wall sample bot
Most bots seems to skip some turns with the first round in the start of the game. When this happens for the Wall sample bot, it might not complete its 90 degree turn.
This happens inside the turnLeft() and turnRight() methods of the API, which is "just" looking on the remaining turn degrees. Currently, the bot API does not take SkippedTurn into account and adjust accordingly.

This can be seen as a bug, with it depends on how "exact" the bot API should behave. A real dominating killer bot will probably not be using turnLeft() and turnRight(), but call the setTurnRight() and setTurnLeft() each turn to adjust its current turn depending on what is going on here and now. So the turnRight and turnLeft should be seen as methods you use for simple bot or newcomers of the game to get started, as the bot will not be able to change it movements for several turns and adjust its movement to the current situation, which can be pretty fatal.

My advice for bot developers is to take SkippedTurns into account and make sure the bot can handle when it is skipped one to several turns now and then. It makes the bot more stable... and dangerous.

I might have a look into making the blocking calls like turnRight(), forward() etc. more reliable for the bot apis taking skipped turns into account. But it is not a high priority right now.