This is very strange. What is the reason for not including it?
I see other threads with requests for other game modes, and including unnecessary constants in the JSON file, all being listened to positively. But this one is not?
Maybe it’s my fault for not explaining the reasons why it is needed. I just assumed that not including it was an oversight that could easily be corrected, so explanation wasn’t really needed.
I agree that it is a trivial calculation when the bot is running a whole game at a time - all it does is add a bit of inconvenience to every bot writer. I think it would be worth putting it in just to avoid this inconvenience for everyone, but that isn’t the important reason! It is too trivial a calculation for the reason to be that you want people to have the challenge of figuring it out.
The more important reasons, though, are that bots aren’t only run for a whole game at a time.
There are all kinds of reasons that, while developing a bot, one would want to run just a single round. The two main ones I can think of, are:
-
Benchmarking (testing the performance of a bot in a single round) - this can’t be done neatly with the bot running for a whole game, first because it is much slower, and second because we no longer have our bots’ debug output included in the Round directories, like previous years, so instead we will have to run our bots in a special mode which outputs the relevant data.
-
Simulation testing. Here the input is the game state plus two moves, and the output is the next game state. The next game state can then be verified against the next round’s game state from the game engine, to ensure our own simulations are correct.
Except, because this critical piece of information is missing from the game state files, the state file plus the two moves are no longer enough to simulate a single round!
There is a single piece of state that is left out - the opponent’s current worm!
So, to run a simulation test, for example, you need to feed in an extra piece of information - the opponent’s active worm. But where do you get it from to feed it in - it isn’t in the JSON file! Do you then have to simulate the entire game up to that point? But the point is testing the simulation - you don’t know it’s correct yet. Other approaches, like trying to detect which worm actually moved the next round, are a pain and subject to a huge number of corner cases.
There is every reason to include the opponent’s active worm: it makes everyone’s lives easier, and enables people to benchmark and test their simulations. It is the only relevant information that is not included. There is no reason that I can see not to include it. So please could you reconsider this and include it!
