LIGHT and PLAN are bugged. Because of how TimerEffect is coded, the last “tick” can’t happen.
For example, a PlanEffect is created with a tick of 5. On the last turn, of the PlanEffect, the turn begin with a tick of 1. But look at this code. The tick-- is done before application of the effect. Because of this, when we are here, the effect is not applied.
Because of this, a PLAN only heal 4 times. Not 5.
I don’t know if fixing the bug is worth it, just update the statement will be enougth.
Also, the game description says the slashers only go rushing after spawning if they have an explorer in LOS. This is not true: after spawning, they always rush.
Hello, is it plan to patch the referee?
Is it plan to remove the randomness of the referee or is it part of the game? For example, https://github.com/JohnnyGuye/code-of-kutulu/blob/master/codeOfKutulu/src/main/java/codeofkutulu/models/Minion.java#L80
Since the randomness is here to assure the symetric aspect of the game, i don’t think they’ll touch it.
And well, we spotted many bugs since the beginning of the contest and it seems like they won’t touch the referee at all 
There has always been bugs in a contest and I’m afraid there will always be. Some really problematic that needs to be fixed, some others that don’t matter that much.
You know that for most of the bugs, it’s not worth fixing them, especially when the contest is too close to its end.
As a unofficial rule, don’t expect a fix to a bug other than a Double-Hulk issue after Tuesday.
I don’t think there’s game breaker bug in CoK. But none of them are fixed/mentioned in the statement … it’s pretty weird. The statement tells wrong things.
In this match, I die while waiting for input. I receive entity_count = 16, but I only get 15 entities, and then I timeout while waiting for the 16th (the EFFECT_PLAN). Please help 
Error in description:
Shelters start with 10 energy
Would you consider, for future contests, to always include a sentence in the game statement, such as “Please refer to httpxxxxxxxx (link to github) for a list of bug and statement corrections which are found after the game has started and not reflected in this game statement.”, if that will be how the bug and statement corrections will be handled? At least the players will be alerted of the fact instead of having to discover by themselves.
Github issues are probably a much better way to handle this than a forum thread indeed.
I think there’s another error in the statement:
In the description of param2, it’s written:
“Minion: id of the explorer targeted by this minion. -1 if no target (occurs only on spawn)”
But -1 occurs not only on spawn, for instance a rushing slasher can target none of the players (so param2 == -1).
13
EXPLORER 0 9 1 174 2 3
EXPLORER 1 10 1 210 0 3
EXPLORER 2 10 1 105 1 3
EXPLORER 3 10 1 205 1 1
WANDERER 8 11 1 12 1 2
SLASHER 12 10 6 34 1 2
SLASHER 14 11 4 34 3 -1
SLASHER 15 11 3 34 3 -1
WANDERER 16 11 5 22 1 2
WANDERER 17 11 6 27 1 2
SLASHER 18 11 2 3 4 -1
WANDERER 19 5 5 32 1 0
WANDERER 20 5 7 3 0 -1
I see that sometimes the Slasher state is “Serving my master” which is not described in the image of its behaviour …
What is this state supposed to mean ?
According to the referee (https://github.com/JohnnyGuye/code-of-kutulu/blob/08c9be210c6b9362a1cb933f41da708282b083dc/codeOfKutulu/src/main/java/codeofkutulu/models/MinionSlasher.java#L85) it seems to be a transitory state between Stunned and Preparing Rush, but I wonder if we can get hit when crossing this state.
I think I can answer myself …
WANDERING === SERVING_MY_MASTER
PREPARING_RUSH === STALKING
OK, I finally captured a state where the same exact game input (same code, same bots, same seed) produces at least 4 different game results:
The last one I just achieved by clicking “replay in same conditions” after one of the other ones.
This makes it very hard to debug a bot; to start with, even if I don’t touch my code at all, I can’t “send to IDE” from a match I saw and debug why something weird is happening, because more than half the time, it’s not happening anymore, and I can’t reproduce a problem.
Also, as you can see from the spread of the results, it makes ranking even more volatile than you’d normally expect from a 4-player game where bot strategy success depends on what other bots are doing.
I only compared the first 2 games: it breaks around frame 77. But this is not a bug in the game, as the wanderers are all at the same positions in both matches.
It is players doing random moves, resulting in different board positions for future turns.
This question seems to get asked a lot. Think of it this way. There are two potential sources of randomness each match. Randomness from game itself (e.g. map, starting position, etc.) and randomness from the players themselves (for instance, having some of their decisions be based on a random number). Using the same seed only stops the randomness from the game, it doesn’t stop the randomness from the players.
I understand that. It wasn’t really a question, so much as an illustration of my suspicion that this game is a little bit too chaotic - tiny non-deterministic fluctuations make for a whole lot of really divergent outcomes.
The CodinGame interface, debugging workflow - mostly the “send to IDE” option that I use heavily - and really most games I’ve tried on here so far seem to assume a much more deterministic rule set.
mind you, technically, ‘a little bit chaotic’ and ‘too deterministic’ are a bit like ‘a little bit pregnant’ or ‘a little bit dead’, but hopefully they get the general gist across. It’s the volatility, not literally the technical possibility of randomness, that I found distressing.
I guess the non-determinism from player randomness specifically is more of a general CodinGame issue than CoK - if you’re letting people call wallclock time functions you can’t really ever clamp down on it, though you could probably mitigate it quite a bit by running all code each time inside identical VMs which think it’s Jan 1st 1970 and even maybe overriding any wallclock calls to return something fake but deterministic…
But the calls to rand in the referee code seem really superfluous, especially when the same referee/rule set goes to such great pains to explain the very deterministic way that the wanderers choose where to go next.
You will not find many friends with your suggestion to ban any randomness from bots. There are a lot of search algorithms that work that way (random choices, repeat as long as you have time or a combination of both). When you open the replay in a new tab and click the … below, you can see your stderr output, so just print the board state to stderr and copy it to get just that one turn.
I guess I’m the one responsible for the random target selection. Before it started at the previous target and then iterated over the remaining ones by incrementing the index. But this makes it a little unfair for the player coming after the current target.
Moreover a little randomness is good not to always get the same outcome vs the same opponent (see here) - though it’s less on an issue for 4 player games.
You can have deterministic randomness, though! (re: allowing for player strategies with random search) Just need to have/use random functions that always return the same results in the same order with the same game seed (and other parameters, if any). It’s only things like seeding on time that would make it actually change from one ‘identical’ run to the other.
Maybe that’s what ultimately happens with the referee anyway, not sure; but there’s always more convoluted but more predictable uniform-distribution tricks like “on even turns, start looking from bottom of the player list; on odd turns, start from top”
re: debugging - Most of the time, I found I needed to change the stderr output to debug properly (too much data to output all of it all the time), so that’s why I needed the IDE.
Not sure whether getting the same outcome vs. the same opponent is really a bad thing, in the context of trying to rank the bots against each other? Am I missing something? I suppose it can be frustrating from a player’s point of view. but hey, at least then you know for sure which bots are better than yours.
Anyway, most of that is more about the platform in general at this point, I guess I’ll get used to it as I figure it out.
Even with a deterministic algorithm, you can have “randomness”.
For example my algorithm was a minmax with iterative deepening. I can give you my full code, you won’t find any random function in it. But since my stop condition is while (time < 50ms), i can’t control the number of iteration i will do. So sometimes my search will be depth 8, sometimes it will be 14. And because of that, the chosen move will be different.
Your fight is already lost. Sorry.
