This is a preview
This playground version isn't public and is work in progress.
It's highly recommended to publish a contribution as "WIP" first to get feedback from the community. => More details about moderation
Contributions must be written in English.
The description must be clear and unambiguous.
- Keep it clear and consise - Avoid flavour text - Don't address the reader directly - Avoid controversial topics
The default code must be working for all languages.
Test cases must be properly defined. (for all games but multiplayer games)
- Test cases should cover all specifications - Test cases must have explicit names - Each validator must differ from the correspond test - Each validator should check the same case as the corresponding test - The first test case must be a simple one
Contributions must be original. (for all games but Clash of Code)
The referee program should be robust and reliable. (for all games created with the sdk)
- 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. - Indices must start at 0, not 1. The origin is always the top left pixel/tile.
The graphics are clear and represent the progression of the game well. (for all games created with the sdk)
Clash of Code
CoC puzzles should be solvable in less than 5 minutes.
The main goal of a CoC battles is to be short (except in the "Shortest" mode). CoC players don't expect to learn something from solving a CoC puzzle; they'll choose practice puzzles for that.
CoC close duplicates are allowed.
If the puzzles' themes differ, it's ok to accept multiple versions of the same programming problem.
No CoC puzzle is too easy.
No CoC puzzle should be rejected because it's too simple.
- It must be very difficult to approach the optimal score.