Boss for own contribution not working

Feedback & Bugs
1

I’m currently working on a multiplayer game (bot programming). My Boss (or multiple instances of the boss) work fine when used inside the SDK, but not if I try to upload and test the game on CG. I have made the boss available as “config/Boss.java”, which is the exact same bot as during SDK testing. But the Boss always produces a timeout (it is very simple and shouldn’t time out). What could be the reason?

2

In case you don’t receive any replies to this post or your other recent post soon, please consider posting on CodinGame’s Discord server (#community-games-creation or #bug-report as appropriate), where you may get a quicker response. (And of course it’s better not to double-post in both the forum and on Discord in the future - I’d suggest to always try Discord first for topics on bot game creation.)

3

I would if I could. Clicking on “Discord” in the menu shows me an error that the invitation is not valid.

Is it possible to get a new invitation?

4

Try this: https://discord.gg/RVj6fqmT (link will expire in 7 days).

5

Also doesn’t work. Tells me that the invitation is expired or I don’t have the rights to join.

6

I’m not sure why it doesn’t work for you, but the link seems to work for me:

a
a974×1118 107 KB

The official link seems to work for me too. But for obvious reasons I haven’t followed the screen to be “invited” again.

7

I got the invitation working. Apparently I already had a Discord account I created a longer time ago, but Discord’s error message wasn’t helpful at all.

1 Like
8

This is a common issue when developing multiplayer games for Codingame (CG), especially when transitioning from local SDK testing to the actual platform. Even if your Boss.java works perfectly in the SDK, timeouts on the CG platform can occur due to several subtle differences. Here are the most likely causes and how to fix them:

:mag: 1. Input/Output Handling Differences

The most common cause of timeouts on CG (vs. SDK) is incorrect or inefficient I/O handling.

:white_check_mark: Problem:

  • Your bot might be waiting for input that never arrives, or reading input incorrectly.
  • The CG platform sends input via stdin, and expects output via stdout. If you’re not reading input properly (e.g., using Scanner.nextLine() without checking if input exists), it can block indefinitely, causing a timeout.

:white_check_mark: Solution:

Ensure you’re reading input in a loop that matches the game’s turn structure.

Scanner in = new Scanner(System.in);
while (true) {
    // Read turn-based input
    int n = in.nextInt(); in.nextLine(); // Be careful with nextInt() + nextLine()

    for (int i = 0; i < n; i++) {
        String line = in.nextLine();
        // Process input
    }

    // Compute and output your move
    System.out.println("MOVE 0 0"); // Example move
    System.out.flush(); // Critical!
}

:rotating_light: Always flush stdout after each move: System.out.flush();
Some environments buffer output, and CG waits for a newline + flush.

:mag: 2. Infinite Loop or Hang in Initialization

Even if the boss is simple, if there’s a loop that waits for input before the first turn, it will hang.

:white_check_mark: Example of a bug:

while (!in.hasNextLine()) {
    // Waiting forever...
}

This works locally (maybe SDK sends data faster), but on CG, timing and buffering differ.

:white_check_mark: Fix:

Never wait for input — just read it when expected.

:mag: 3. Threading or Static State Issues

If you’re using static variables or multithreading, they may behave differently across SDK vs. CG.

  • The CG environment may run multiple games or instances in the same JVM.
  • Static state persists between games unless reset.

:white_check_mark: Fix:

Avoid static state, or reset it at the start of each game.

:mag: 4. File Paths and Resource Loading

You mentioned config/Boss.java. But note:

:x: You don’t upload .java files directly.
You upload a compiled Player.java (or your main bot class), and the platform compiles it.

If you’re trying to load Boss.java as a resource or include it via file path, that will fail on CG.

:white_check_mark: Correct approach:

  • Your main class should be Player.java (or as specified).
  • The “boss” logic should be compiled into the same codebase, not loaded dynamically from a file.
  • CG does not allow file I/O or dynamic class loading.

So if your code does:

new FileInputStream("config/Boss.java")

→ This will fail or be ignored.

:mag: 5. Time Limits and Performance

Even “simple” bots can timeout if:

  • They do heavy computation in a loop.
  • They use inefficient algorithms (e.g., deep recursion, unbounded loops).
  • They process large inputs slowly.

:white_check_mark: Check:

  • Are you processing all inputs?
  • Are you using O(n²) loops on large n?
  • Are you using recursion that might stack overflow?

CG typically gives 50–100ms per turn after the first few.

:mag: 6. SDK vs. CG Input Format Mismatch

The SDK might simulate input differently than the real platform.

:white_check_mark: Action:

  • Compare the exact input your bot receives in SDK vs. what CG sends (you can log to stderr).
  • Use System.err.println() to debug input:
System.err.println("DEBUG: n = " + n);

This appears in the CG error logs.

:white_check_mark: Recommended Debugging Steps

  1. Add stderr logging to see where your bot hangs:

    System.err.println("STARTING");
while (true) {
    System.err.println("WAITING FOR INPUT");
    int n = in.nextInt();
    System.err.println("READ n = " + n);
    // ...
}

    → Check CG logs to see how far it gets.

  2. Remove all file/resource loading — only use stdin/stdout.

  3. Ensure Player.java is your main class, and Boss.java is just a helper class in the same package.

  4. Flush output after every println.

  5. Test with minimal logic — e.g., always output "PASS" to confirm I/O works.

:white_check_mark: Final Checklist

Issue Fixed?
Using System.out.flush()? :white_check_mark:
Reading input without blocking? :white_check_mark:
No file I/O or dynamic loading? :white_check_mark:
No infinite loops or hangs? :white_check_mark:
No reliance on static state? :white_check_mark:
Input format matches CG spec? :white_check_mark:
Minimal debug logs added? :white_check_mark:

If after all this it still times out, share:

  • A snippet of your main loop,
  • How you read input,
  • How you output moves,
  • And the stderr logs from CG.

I can help pinpoint the exact issue.