Just some thoughts on engine tweaks. I’m using a dotnetcore starter bot and would love if we could tweak the below:
Allow an option in the engine to effectively pause the game before it starts the first round. This would allow us to attach a debug process to code so that we can follow our decisions. Currently I have to leverage the timeout factor in the game config ( I could be missing something obvious here so if anyone knows a better way, please let me know )
When using the console player option, can we have the co-ords output on the screen for the current worm? I’m having to go into the state file to check where my current worm is. Just a simple x= , y= after the w=wormno, sample below
A await output option similar to the console but for a bot? When using console, the bot timeout doesn’t apply, could we be able set the same for our bots to a reference bot? So basically the reference bot will wait for a response regardless of timeout?
An interesting challenge, looking forward to it. Oh, and please add a note that node is required for the reference bot, I wouldn’t have known save for someone on the forum saying it was required for the js starter bot. There’s no readme in the reference bot in the starterpack I downloaded today.
Hi @KosmikZA, we can definitely do the console tweak, great idea btw
For the time being, unfortunately debugging can only be done 1 round at a time. You will need copy and paste the round you are interested in, into the bot’s directory. Then simply call the bot’s method to execute that specific round number. The problem is that the bot won’t have the memory it could have attained prom the previous rounds
So I let the game start and once it gets to the console stage, it pauses. I can then leverage my VS to attach to the bot that is busy in the game process
The state files are fine and easy enough to use or manipulate but I’d just like the option of a pause at the start of the game so that I can attach to the process. Also , is there the option to resume a match? by passing a round ID or some such to the arguments of the engine?
The believe the game engine also has a flag that turns off the per round time restriction. I am not certain about this however, and that might be an additional tweak that can be done on the game engine side so that it does not continue the game while waiting for you to attach the debugger to your bot.
Cool, I think just manipulating that then would work? Just make it a really big number. I believe the game engine waits that amount of time for a response, but will continue if it gets a response before then.
So Just thinking out loud, If the bots are always running what happens if we use the time the other bots has to move to hog resources (slowing the other bots performance) to improve on a tree search method for example, will this be allowed?
The bots are continuously running to be able to keep states between rounds as stated in one of the other threads, the C# starter bot has an infinit loop in. And as far as I can see the game engine does not terminate the bot after each round, it just continues if it does not get a response in the given time.
I agree with Kortgat’s concerns about bots stealing processing time from their opponents. Personally I was planning on spawning multiple threads and having background processing happening while I’m waiting for the next line from stdin.
I’m sure the Entelect team has a plan for this and I’d be interested to hear what the plans are.
I have some ideas on how they could do it:
Use docker pause on the containers when it isn’t your turn. From your bot’s perspective, it’s just running an infinite while loop, but it’s actually stopping and waiting for the opponent’s turn.
On Unix systems (Mac or Linux), send the bot process the SIGSTOP signal, which suspends it, when it isn’t its turn. This is sort of like hitting Ctrl-Z on the terminal to suspend the process. When it’s the bots turn again, send it the SIGCONT signal to have it continue running.
Run the bots on different machines so they don’t fight for system resources, and run their turns in parallel.
I know very little around docker but wouldn’t it make sense for the game engine to be in one container and each of the bots in their own respective ones? Intercommunication via some handler but as you said, the containers isolate the code from impacting the others, kind of how I understand micro services with containers to work.
Thanks for jumping into the conversation @NellStephanJ. Does that mean that you’re planning on using a mechanism like docker pause to stop the one bot from running while the other is taking its turn?
Keeping them in multiple docker containers helps to structure the isolation, but at the end of the day my understanding is that there’s one host machine that all the containers are running on, so you need to do something to make sure that a bot has exclusive access to the underlying hardware while it’s making its move.
The containers do not have to share a machine. See for example https://aws.amazon.com/fargate/ I believe Azure ACI is also similar, but I know less about Azure.
We are going to use Azure Container Instances. This means that each container will run on guaranteed resources separate from the other containers. For communication between the runner and the bots, the containers will be on virtually the same network.
With this said, both bots will be running simultaneously, so you might have extra time between your rounds to calculate things if your opponent takes longer to give their move. But that only holds true if your opponent is slower than you and it is only up until the total time of 1 sec has passed, then the next round will start.
To give an overview of how we plan to run matches we will schedule all the matches that need to be run in a tournament and put it in queue storage. The Logic App on Azure will then be used to implement the necessary setup and orchestration for a container group. Within a container group, we will have our game runner and two competing bots each within their own container. After a match has completed the necessary match details and results will be sent back to the logic app and the logic app will do some admin tasks such as logging the match details and results. Naturally, any errors and container failures will also be handled by the logic app and if the logic app and Azure container instances cannot resolve a problem we will intervene manually.
)
. The game runner and both bots will each run in their own separate container.