Loading [Contrib]/a11y/accessibility-menu.js
Back
Close

Coding games are turn-based games; they're always associated with a viewer. They're built with the CodinGame Game Engine (sdk)., see the technical details in the sdk documentation.

In an "infinite" loop, the player(s) must read the entries in the standard input stream and send a response in the Standard Output stream to play the game.

There are three types of coding games.

All coding games should

Solo Puzzle (with a viewer)

Like for In/Out puzzles, the player plays against the game and must pass all test cases to solve the puzzle.

Example: Power of Thor Each turn, the player must output a direction for Thor to take to finally reach the light.

Gameloop puzzles should also respect the test cases guidelines.

Learn how to create a Solo puzzle with the sdk

Multiplayer Game (bot programming)

Participants play against themselves in matches of 2 to 4 players in an arena. No more test cases. Once players submit their code (AI) in the arena, the system matches them against other players of the arena. Each match between players impacts their score, hence their ranking.

Learn how to create a Bot Programming game with the sdk

Games with Leagues

@TODO

Optimization Puzzle

Optimization puzzles are puzzles for which a player's score is computed. All players are then ranked against this score.

They must have a large number of test cases. Learn more about it in the test cases guidelines for optimization puzzles

Learn how to create an Optimization puzzle with the sdk

General Guidelines

When creating your coding game, we ask you to follow these guidelines in order to improve both its performance and players experience.

  • Viewer
    • The viewer must be self-explanatory. A player should understand most of the rules from a replay
    • The viewer must contain the avatars and nicknames of current players (if bot programming).
  • Referee
    • The referee must end a player's program when receiving an unrecognizable command.
    • The referee must send an error message in the console when receiving an invalid but recognized command.
    • The referee must stop the game early if the game is stale or already decided.
    • The referee must not crash. All exceptions must be caught (especially during the parsing of a Player’s actions, where most errors occur).
    • Indices must start at 0, not 1. The origin is always the top left pixel/tile.

Best Practices

When creating your coding game, we suggest you follow these best practices in order to improve both its performance and players experience.

  • Protocol/Stub
    • If options for a player are limited, they should be sent in input (ex: Wondev Woman)
    • The player's id should be 0.
    • The player's input should be sent first in loops.
    • Any non-explicit variable should be explained with a comment.
    • The stub should not change between leagues.
    • The generated stub should not contain more than 45 lines in Java.
    • The number of variables per loop should not exceed 10.
    • There should be maximum 2 loops.
  • Gameplay
    • The game should be turn-based. Only perform checks (collision, presence, etc.) at the end of a turn.
    • The total entities should not exceed 200.
    • The maximum number of rounds should not exceed 250.
    • The maximum alloted time per player should not exceed 25 seconds.
  • Graphics
    • Privilege the use of Sprites over Shapes (Rectangle, Circle, etc.)
    • Less than 2Mb in total should be used.
    • The minimum font size should be 36px.
    • The choice of colors should take into account color-blind people as much as possible.
    • .png and .jpg assets should be minified.
Create your playground on Tech.io
This playground was created on Tech.io, our hands-on, knowledge-sharing platform for developers.
Go to tech.io
codingame x discord
Join the CodinGame community on Discord to chat about puzzle contributions, challenges, streams, blog articles - all that good stuff!
JOIN US ON DISCORD
Online Participants