King-of-the-hill indicates a game where the submissions interact with and compete against each other in some form of game. Competitions which pit programs against each other without interaction should rather use [code-challenge].
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.
Make sure you write your test framework / scoring program before posting one of these challenges. In fact, it is strongly recommended that before posting you upload the test framework, one or two simple example bots, and a build script as a public repository on a site such as GitHub. Then competitors can easily download and build the other bots when developing a new one, and might even send you a pull request with their new bot and its build script. See, for example, https://github.com/pjt33/ppcg36515 , which has a
make setup that allows building the test framework and the bots in one step.
These challenges are usually a big undertaking for the host of the challenge, so here are a few common practices.
How to communicate with the bots?
There are several options to realize this. Common choices are
- Players 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. These scripts are invoked at each turn and given input via arguments, while their output is read from STDOUT. Example: Caveman Duels (or: Me poke you with sharp stick)
- Players write a script that can be run from the command-line. These scripts are invoked once (and the processes kept running), communication is done via STDIN and STDOUT using persistent pipes. Example: Hunger Gaming - Eat or Die
Hybrid approaches are also an option, which usually increases accessibility of the challenge.
How to handle 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.
What makes a good challenge?
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.
- 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.
King-of-the-hill challenges tend to 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 ruled out.)
- 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.