Ocean of Code - Bugs


Thank you, you were right!
The problem is always between the keyboard and the chair. The true question is which keyboard and which chair :smiley:


Hello ! First, bravo for this contest !
I loose a game and I don’t understand :
I’m on (0,5) with 3 lives.
I move to E so I should move to (1,5)
I throw a torpedo on (0,3) where is my opponent. It should not damage me !
My message is “MOVE E | TORPEDO 0 3 | TRIGGER 4 6 | TRIGGER 3 6” and I loose with score -1 :sob:
(There are mines on these places)
Thank you for your help !


Please always add a replay link for that kind of bug report.
I’m not sure if that message is supposed to make you lose instantly, but it’s incorrect for sure.
“But you can use each type of action only once per turn”
“You can’t trigger multiple mines in the same turn.”


Ok, didn’t read all the green lines, sorry !!
I trigged only one mine and I win the game !
“The problem is always between the keyboard and the chair” is true !


Hello! A minor inconsistency in the rules (at least for Wood league).

“If you fail to output a valid action, you will SURFACE in that turn”

Later, under Lose conditions:

“Intersect your own path, move into an island or out of the map”

It’s a minor point because it’s bad coding to output illegal actions, anyway, but if I move to an invalid location (this would fall under “failing to output a valid action”) will I surface or will I lose immediately? A quick test reveals it’s of course the later, but this should be clear in the rules.


I’m getting a timeout issue using Swift. I put a timer around the first readLine() and it is taking 40+ ms (with a 50ms game timeout). It jumps around, and I get through 6-8 turns before getting timed out.


Hello! A minor incontinence in the rules (at least for Wood league).

What is incontinence?

Incontinence is a term that describes any accidental or involuntary loss of urine from the bladder (urinary incontinence) or bowel motion, faeces or wind from the bowel (faecal or bowel incontinence).

Maybe you meant inconsistence… Please, do not piss in the Ocean (of Code) :slight_smile:




We did an update of the game. The input scheme for MSG got a little stricter.
Double MSG and an empty MSG is no longer allowed. Sorry for the inconvenience :slight_smile:
Hope the new tooltips (as voted), extra frames, life lost on correct frame and path marked on correct frames feels better :rocket:


Maybe you meant inconsistence… Please, do not piss in the Ocean (of Code)

Touché :rofl:. I really don’t see how I could’ve missed that! I don’t even have the excuse of auto-correct. While we are at it, it’s actually inconsistency. (fixed my previous post to reflect that). My initial point stands, though.


This post got longer than I anticipated, so it now needs a big huge

“this is a great idea and implementation! Thanks to the creators!”


Now, who am I to miss an opportunity to mess with native English readers’ minds?

Now that I’ve got the full statement, here’s a list of incontinencies (or ambiguousnesses that would need statement clarifying because they can result in at least a local incontinency):

  • “By using surface you will reset your path of visited cells so that you can freely move to a cell that you have previously visited.”
    This is massively ambiguous as to how the current cell is treated. It appears from the viewer the current cell is still not visitable, but that’s at odds with the phrasing: that cell is previously visited from a previous turn, so it would be reset and visitable again, and for most common interpretations of “visiting” staying in place is not a part of it. All the less that the sentence literally says previously visited cells can now be “moved to”.

  • The entire statement is quite incontinent with regard to invalid actions.
    It always mentions “You can’t” such and such, but never really says what happens if you still do. The most obvious example is movement looping, which happens to be explicitly incontinent: on one side “If you fail to output a valid action, you will SURFACE in that turn”, and on the other “Intersect your own path” is listed as a losing condition. The same could be said about:

    • firing torpedoes out of range
    • firing torpedoes at an island (common sense says it’s pĥysically possible, resulting in an explosion either on first land or last sea cell)
    • triggering a non-existent or non-own mine
    • placing a duplicate mine

And a few non-fatal infelicities:

  • “You cannot move or fire through islands.” Triggering mines can easily be thought of as some form of firing. Better be specific: “fire torpedoes”.

  • The torpedo paragraph could use a more specificative style. Something in the lines of: “torpedo explosions damage submarines (yours or enemy’s indiscriminately), and have no effect on mines, islands or empty water.”

  • “MOVE direction POWER” makes it read like we have to output the string “POWER”. Moreover, the strings to use as a power name aren’t explicitly listed anywhere.

  • “Each player has 300 turns including the initial placement.” This is CG-API mumbo-jumbo. For all intents and purposes, the player has 299 turns. Also, this has nothing to do with a Victory Condition.

I’m normally not that strict about statement details; but this contest happens to be all about interpretation of the opponents’ decisions, and an incorrect interpretation has very drastic yet hard-to-pinpoint consequences. It’s poor form to have to peek at the referee that much.

Possibly-breaking suggestions if/when this makes it to undeadlined multi:

  • “cooldown” is poorly chosen given the player starts with it full. “charges[Still]Needed” or “powerLevel” (counting up) could be better.

  • Adding an input line where the referee echoes what he will tell the opponent were our orders would be extremely helpful in clearing out most of the incontinencies and infelicities detailed above.
    It’s particularly beginner-unfriendly to deny a user a move for unclear reasons, force-surface him as a result without notifying him, and then let him desperately choke to death while he’s out of sync with the real open space.

  • You may want to factor the explosion properties to their own paragraph (and add a picture.)

  • an unwarranted left-handed coordinate system :cry:

(I’ve got a few other totally trivial spelling/grammar/style corrections as well, if there’s any interest for that. Are PRs still in order?)


Getting timeout on first readLine >2500 ms :tired_face::exploding_head::grimacing:
Loop also timeouts reading input >50 ms

see Standard Error stream for timings


Pull request!

Contains 4 patches:

  • Formatting, style and language.
  • Give the visibility section a more “diff” feeling
  • My rewording epiphany: separate charge/energy/power
  • Split out a Powers paragraph

To be applied using standard git tooling: download the patchset as something descriptive such as JBM-patchset.mbox and then:

$ git checkout -b jbm-patches master
Switched to a new branch 'jbm-patches'

$ git am JBM-patchset.mbox 
Applying: Formatting, style and language.
Applying: Give the visibility section a more “diff” feeling
Applying: My rewording epiphany: separate charge/energy/power
Applying: Split out a Powers paragraph

Resulting html.tpl

cc @eulerscheZahl @Illedan @G-Rom



If I am not mistaken there is an issue in the input format in C, in the map, to check this I did reset my code to the basic one, then used fprintf stderr the lines of the map, and it only read every other line. I put two screenshots there : https://imgur.com/a/D2xNTWr https://imgur.com/a/m1Nyity

Thanks :slight_smile:


You have to start your timer after reading your first line of input and stop it before printing your action. Otherwise you stop all kind of other things (referee, opponent bot).

Thank you very much for your efforts.
It would be much easier if you do a real pull request on github or at least share your final statement instead of the diffs. There’s a probably a tool or a feature of a tool that I don’t know but to me it looks like a lot copy-pasting of single lines.
I can’t promise how fast we will update the statement, as only CodinGame can update the contest.

You are right, the lines aren’t fully parsed in the first run, so the second run gets the linebreak. Try to read one more character with char line[width + 2] and fgets(line, width + 2, stdin).
I’m not sure if I should see this as a bug in the game or the code generator.


They’re git format-patch diffs. You just git am them. :slight_smile:
Sharing the final state is easy enough, but it wastes the rest of the commit history information :angry:

Out of the git world, the standard tools for this kind of work are simply diff and patch.

(and you’re making me notice I deleted the first character in the first one. sigh updating patches now.)


There is one performance issue. It may be connected to the framework/site itself, not this particular contest.
Here is a replay (open with caution): https://www.codingame.com/replay/443561978
It puts heavy load on a cpu. It plays at 6 fps on x10. But even on x1 it lags significantly every turn, though it tells me about 40 fps. Other replays don’t behave like that, I have 60 fps on x10 in every other.

My guess is that it struggles to render the result of “MSG …” command of another player.


And here’s the second patchset and resulting template.

  • Factor an Explosions paragraph
  • Clarify win/loss/SURFACE conditions
  • Fix some invalid HTML

/cc @eulerscheZahl @Illedan @G-Rom


Sorry, what games are we saying?



Commands like:
are valid?