A Code of Ice & Fire - Bugs


#1

Use this topic to report bugs or remarks about the A Code of Ice & Fire challenge.

:fire: https://www.codingame.com/contests/a-code-of-ice-and-fire :fire:

The referee code is publicly available on Github:

https://github.com/Azkellas/a-code-of-ice-and-fire

Code to help you started:

https://github.com/Azkellas/a-code-of-ice-and-fire/tree/develop/src/test/starterkit

Special thanks to the creators Azkellas and Tehelka

Notes

  • Go players: Don’t forget to comment unused import
  • Pascal players: Please rename duplicated variable (x, y, owner)

Current bugs:


#2

Hi !

It seems that i have a minor Income calculation problem :wink:
According to the linked screenshot, the red player has 43 actives cells, and 8 level 1 units.
My calculateIncome function returns 35 (seems ok to me), but the given value at loop beginning gave me 34.

Many thanks !


#3

There’s a bug with the pathfinding.

If you try to move with a level 1 unit to a far cell (so distance > 1), but the target is occupied by a unit, the referee will refuse the action. I think the good behavior should be to move the unit according to the pathfinding instead of just refusing the action.


#4

The income is updated only at the beginning of every turn. The screenshot is maybe taken in frames between two turns (i.e. after you moved a unit and expanded your territory).

Edit: false info, just ignore my comment, sorry :blush:


#5

Hi,
Thank you for reporting. The income shown is updated after each action, but might indeed be wrong (if there are territory cuts / re-gain). However the income at the beginning of each turn is correct, so it does not affect the gameplay. Please make sure they received the correct amount at the beginning of their turn.


#6

Of course, I verified 3 times.
The screenshot is made at round starting, before any of my moves, as my income calculation.


#7

Ok my bad I see the problem now. The opponent gold sent at the beginning of each turn might indeed be wrong, because only the current player’s income is recalculated to avoid such issues. This will be fixed on Monday.


#8

FYI I was testing my own calculateIncome function, to check if my result was equals to the incomes the server gave to me at the beginning of each turn.
So no unit/building/board updated before calculation

Edit : I saw just your answer, no problem good luck :wink:


#9

We’ll make an update to the game very soon:

  • 1 more tile for the blue player (2nd player) at the beginning of the game
  • fix of a bug regarding the prize of additional mines.
  • name trim
  • better pathfinding
  • fix of a bug where the opponent gold was wrong in some situations

I’ll let Azkellas add more details when the update is live.


#10

We buffed the blue player after realising red had a substancial edge. A game with two top10 players was won by the red side 66% of the time. One game out of four against lower AIs would end in a draw. I tried different patches offline (benchmarking my AI against itself). The red/blue winrate is now fixed but there remains many draws.

Note that you still play both sides on the same map when matched against an opponent and the results count as one (so you can draw).
There won’t be any more changes during the contest.

Good luck.

Here are some stats on the new patch:

top10 vs below
            |     before       |      after    
games       |     2*778        |     2*758
winrate R/B |    58% / 42%     |    50% / 50%
Wins/Draws  |    75% / 25%     |    84% / 16%
RD/BD       |    81% / 19%     |    48% / 52%
*RD means draws where red side won both games (BD for blue side)

top10 vs top10
            |     before       |      after    
games       |     2*1889       |     2*398
winrate R/B |    66% / 34%     |    54% / 46%
Wins/Draws  |    56% / 44%     |    60% / 40%
RD/BD       |    88% / 12%     |    59% / 41%

detailed top10 winrates
raw
          |    old     |   new
vs all    |  35/40/25  |   53/30/17
vs top11+ |  67/25/8   |   79/16/5
vs top10  |  28/44/28  |   30/40/30

with ponderation
          |    old     |   new
vs all    |  33/40/27  |   52/30/18
vs top11+ |  71/24/5   |   77/17/6
vs top10  |  24/44/33  |   23/45/32

#11

For stat lovers or people wanting to know wether they are favorite or not given a map and a position, I investigating the impact of map sparsity. It seems maps do not affect winrates.

The global red/blue winrate is now of 47%/53%.

Here are my stats (top10 vs top10 games only):

numbers between hooks = number of void cells, between 0 and 9, 10 and 19, etc. 
STATS Red draws / Blue draws (only considering draws):
[00-09]: 46%/54%, games: 28
[10-19]: 51%/49%, games: 123
[20-29]: 48%/52%, games: 224
[30-39]: 42%/58%, games: 212
[40-49]: 47%/53%, games: 214
[50-59]: 45%/55%, games: 117
[60-69]: 44%/56%, games: 55
[70-79]: 61%/39%, games: 33
[80-89]: 33%/67%, games: 12
[90-99]: 75%/25%, games: 4
[100-109]: 0%/100%, games: 1
Total: 47%/53%, games: 2*1023

STATS double wins / draws:
[00-09]: 60%/40%, games: 70
[10-19]: 55%/45%, games: 273
[20-29]: 55%/45%, games: 499
[30-39]: 59%/41%, games: 516
[40-49]: 55%/45%, games: 477
[50-59]: 60%/40%, games: 294
[60-69]: 65%/35%, games: 156
[70-79]: 57%/43%, games: 76
[80-89]: 62%/38%, games: 32
[90-99]: 67%/33%, games: 12
[100-109]: 75%/25%, games: 4
Total: 58%/42%, games: 2*2409

#12

Hi, is there any indication of why i lost a particular game?
For example this one: seed=-1238745318884575230


#13

Looking at your output, you print a statement terminated with a ; and no WAIT like you did the turn before.


#14

Found the problem, had infinite loop in there … (so timeout i guess)


#15

I ran into a problem when trying out against the boss here (seed=3816518794802970600): https://www.codingame.com/replay/389429127 . After 7 turns of functioning as it should, my code suddenly stops and i get a timeout lost game. I put some output in the error stream to see where exactly it stopped working and this appears to be when I’m reading in the info on the units on the board. Here is a piece of my code with the last line executed + the next few that should execute but didn’t. I’m coding in Python.

print(“debug15”,time.clock()-turn_start,file=sys.stderr)
self.units=[Unit(*[int(j) for j in input().split()]) for i in range(int(input()))]
print(“debug20”,file=sys.stderr)

The Unit class is the one from the starter solution on Github, so that’s not likely to be the problem.
The reason I’m putting this here is because the line for reading in the units actually works the first 7 turns (and there are actually units on the board in those turns), which leads me to think there might actually be something wrong with the input i’m getting at that point.
In the error stream, the floating point number is the time elapsed since the start of the turn in seconds, so it isn’t even near the limit of 50 ms yet.
I also noticed that when my last turn starts, my gold suddenly increases from 0 to 70, while my income is only +13.
Can someone look into this? Just tell me if I’m doing something wrong and it’s just my code that’s buggy.
Thanks in advance!

Edit: It’s in all of my games, so I probably did something wrong, but I can’t seem to figure out what it is just yet.
Edit 2: Not all my games, some of them just play out completely fine, like this one (seed=-1680175704966286080): https://www.codingame.com/replay/389481327


#16

I also had lots of timeouts when reading units. Today morning, I came here looking if someone reported something similar. Now, to me it feels like it is just bad reporting of timeout.

Don’t focus on checking timeout with position logs. They are not always at the same spot. Try to fix the timeout for the whole code as one.

I was able to move forward after fixing a long running loop. There definitely was a timeout - but not exactly at that spot.


#17

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)