About

king-of-the-hill indicates a game where the submissions interact with each other. The game needs to have well defined rules and scoring, and the goal is to write a maximally competitive program.

Note the related asymmetric tag. Challenges under the asymmetric tag over overlap with king-of-the-hill as they involve some form of competition between answers.

Make sure you write your controller before posting one of these challenges, which is a program that can simulate the game and run the bots. Controllers can also include example bots, or even use the API to retrieve bots automatically.

KotH challenges often take considerable work. Below are some tips and potential problems to be aware of.

General Tips

This is of course a little subjective, but there are a few things to be considered when designing a fun king of the hill challenge:

• Consider the entry barrier of your challenge. It's a lot more interesting when there's a variety of bots, so ensuring it's easy to get started making a bot is important. This includes making your documentation easy to understand, including an example bot, and making your controller easy to use.
• Aim for a high skill ceiling. An optimal solution shouldn't be very easy to figure out, if one exists at all. This can be hard to determine before posting, but try thinking through a few strategies to check if any are too powerful.
• Make sure bots can interact, and in varied and important ways. Putting bots in a maze and having them escape wouldn't be a fun KotH, as the optimal strategy is mostly the same without other bots. This can include things which seem to have interaction on the surface, but this interaction doesn't meaningfully affect the bots' decision making. A good example would be rock, paper, scissors. Although the bots' actions affect each other, they don't have enough information to be able to make interesting decisions based on the other bots' actions.
• Be creative! Pretty much any real life game can be made into a king of the hill, as well as entirely unique ideas. Some challenges involve a 2d (or even 3d!) space, while others may be based on card games, auctions, or simple guessing games.

Communication

There are various ways for bots to communicate, with the options available depending on the language used. Common choices include:

• Players write a function or implement an abstract class or interface in the language of the controller. All implementations are added to controller's project and can be interacted with directly through function calls.

  Example: Survival Game - Create Your Wolf

• Players write a script that can be run from the command-line. Input and output are handled through STDIN and STDOUT.

  Example: Caveman Duels (or: Me poke you with sharp stick)

Hybrid approaches are also an option, which usually increases accessibility of the challenge, though KotHs are one of the only challenge types where restricting submissions to a single language is common.

Randomness

If the scoring program contains (pseudo)-randomness or submissions are allowed to use randomness, this can greatly affect the leaderboard of a single trial. You should either seed your pseudo-random number generator (PRNG) and tell your participants to do the same or you should run a specified number of trials and take the average or median, say, of the individual scores.

You can also require that bots be deterministic. This removes some of the fun of making unpredictable (though often trivial) bots, but can make testing much easier.

One important thing, regardless of whether bots must be deterministic, is to group rounds into games. Between rounds, bots may store information. Between games, all bots are completely reset. This prevents games from having drastically different results depending on how a random bot acted in the first few turns or rounds of the game.

Important restrictions

King-of-the-hill challenges tend to be quite prone to loopholes. Consider including these restrictions to your challenge:

• Any attempt to tinker with the controller, runtime or other submissions will be disqualified. All submissions should only work with the inputs and storage they are given.
• Bots should not be written to beat or support specific other bots. (This might be desirable in rare cases, but if this is not a core concept of the challenge, it's better to rule it out.)
• Bots should at least attempt to win. It's fine if a bot is terrible as long as it's not actively trying to lose.
• Reserve the right to disqualify submissions that use too much time or memory to run trials with a reasonable amount of resources.
• A bot must not implement the exact same strategy as an existing one, intentionally or accidentally.