Implementation

This article goes through most of the information that one needs to write an implementation for executor version 3. It contains sections about API details, sections about best practices, and some example code tests and challenges to get a complete picture. It does not cover the challenge editor and its options, neither does it cover the canvas API.

Read more general information about the freecode creator here: Freecode creator

The Challenge class

The context object

The context object given in the Challenge constructor contains data for the current run and has some additional useful functionality. This section goes through them in detail.

level: int

The current challenge level.

canvas

An object that is used to interact with the canvas. It is used to add new graphical elements, more details on them are covered by another document. It is best practice to only modify the canvas in dedicated setup and update methods (by default _setup_canvas and _update_canvas).

console

An object that is used to interact with the console. It has two methods: log and debug. The log method acts similar to print and prints the arguments to the console for all players. The debug method acts identically except it only prints when inside the challenge editor.

solutions: list

The list of solutions partaking in the challenge together for this level. There are more details on the solution objects later in this document. This list will always be the same length as the number of solutions. However, they will all be set to None when generating the initial state of the canvas (this affects the Challenge constructor, not the step method).

parallel

An object that acts as a proxy solution for making parallel solution calls. It has the candidate methods specified in the API specification, but not the solution attributes. More details about calling solutions in parallel is available in a later section.

living_solutions

A method that generates index-solution pairs for each living solution (solutions that have not crashed or timed out). This is the recommended way to iterate through solutions in the step method.

The solution objects

The solution objects contain information about the solutions partaking in the challenge level and is a way to call candidate methods on the solutions. The solutions objects have the candidate methods specified in the API specification which is used to call the solution and get a result. Calling a solution may result in a SolutionException (imported from lib.exceptions) which must be caught (the solution is no longer alive at that point). Note that the challenge must not call a candidate method on a crashed solution. The solution objects also have the following attributes.

name: str

The name of the solution. This will either be the player name or a placeholder name.

index: int

The index of the solution. This should be used to identify a solution.

console

An individual console for the solution. The interface is identical to the global console except that it limits the output to the console of the specific solution.

alive: bool

A flag indicating if the solution is still running or has crashed/timed out.

What to do in the Challenge constructor

The challenge constructor should do the following things (preferably in this order):

• Store the context and select the appropriate level configuration.
• Initialise the required challenge attributes.
• Initialise any additional variables used for the run.
• Setup the canvas.

The constructor should not:

• Call any solution methods (neither individual, nor in sequence or in parallel).

Note that the step method is not guaranteed to be called before the solutions call the API methods on the challenge, so any preparations needed for the API methods must be done in the constructor.

Score strategy

How to score a contest: write the part where you should use a 70/30/0 system for three participants. This is to avoid the issue that otherwise the ELO doesn’t change if the scores are very close.