Show opponent's current worm

In the JSON file, it looks like the currentWormId is given as a property of the game, not of an individual player.

It does look like the two players can have different currentWormIds in the same round, and this makes sense because the players can have different numbers of living worms.

But, this does mean that a bot can’t see its opponent’s current worm - which would be useful for knowing which of the opponent’s worms can move/shoot in the coming round!

Would it be possible to make currentWormId available for both players in the JSON file?

1 Like

Hi @Malman

I will discuss this with the rest of the team and get back to you. Right now I don’t think this is something we will be adding.

Since your bot is always running, you should be able to see which worm moved in the previous round, so the next one living will move this round.

Yes, it’s possible to get the information in another way, so it’s not like excluding it from the JSON file is keeping a secret or anything.

But it makes programming a lot easier to just have that information available in the JSON file, along with lots of other useful information that is already there. Especially when trying to debug while running a single round at a time, and other things like that.

I can’t see any reason why it shouldn’t be included.

Hi Renette & Team. Please add the OpponentCurrentActiveWormID to the gameState JSON. This will save some precious computational resources each round :slight_smile:

Have a happy day!

1 Like

Hi

I chatted to the team and unfortunately we are not adding this to the state.json

As gustav pointed out - since you have a continuously running bot it should be fairly simple to calculate yourself: Every player will start with worm 1 as active and the engine will select the next living worm for next active worm.

For example:
If all worms are alive the active worms will be 1,2,3,1,2,3…
Once worm 2 dies: 1,3,1,3
When only one worm is left it will always be the active worm.

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:

  1. 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.

  2. 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!

2 Likes

I also think it should be included.

It’s easy to track, during a game., but if that’s the reason then it also makes sense that the start state is an input at the start and form then on only the move the opponent made in the last round is given to the bot.

It’s not possible to calculate it during the game, since it’s legal to do nothing.

it doesn’t make a difference if the player does nothing, the active worm for each player gets incremented regardless of what actions they took. see the engine source for yourself.
it’s entirely deterministic and trivial to calculate yourself

1 Like

Running your bot only for a specific round is a very valid scenario that we did not consider. We have created a github issue to track it https://github.com/EntelectChallenge/2019-Worms/issues/23

The reason why we originally did want to add it was because it is so trivial to calculate during a bot running. The other state changes was information that was not available at runtime at all as far as I know.

2 Likes

Hi all

This feature is in code review. We will look at releasing a new starter pack when it has been reviewed :slight_smile:

3 Likes

Thanks for the update @Renette

Thank you for the update, and for changing your mind - looking forward to the new version!