This is an implementation of a test engine for Brilliant.org's Hunger Games Competition.
This is an OOP solution where player classes are expected to inherit from a base Player
class. The Game
class only expects the methods required by the competition (hunt_choices
, hunt_outcomes
, round_end
).
bots.py
includes the three sample players from the sample code, under the names Pushover
, Freeloader
, and Alternator
. It also contains some user-submitted strategies.
-
First, try
python unittest.py
. You will see some test output. If the last line says anything exceptOK
, there is a bug. Please let me know (see "Bugs", below). -
python app.py
runs a sample game with exactly one of each test bot. You can change the number of bots and Game parameters with arguments to this command (usepython app.py --help
for more details). -
If you want to step through rounds one at a time rather than run the whole game in one shot, you can use
Game.play_round()
instead ofGame.play_game()
. You can also complete the game at any time usingplay_game
even after stepping through some rounds. -
If you're new to Python and just want to test a given solution against the builtin robots, edit
Player.py
and fill your solution in the class at the bottom. -
You can modify the Game options (ie: maximum and average number of rounds) with one of two mechanisms. 1) Editing the defaults in app.py. For example
DEFAULT_AVERAGE_ROUNDS = 500
. 2) Specifying command-line arguments through app.py (seepython app.py -h
for more information). -
All players inherit from
Player.BasePlayer
.
The goal is for Player.py
to be a valid contest submission. To verify against Brilliant's official test script (included in this repo), run python tester.py Player.py
or python unittest.py
.
I will deliberately be keeping this repo free of any strategic information until after the contest, so that using code from it is not cheating. You may copy/modify/submit whatever you want.
If you find a bug, the fastest way to tell me is by submitting an issue on the tracker (I have email notification turned on). You can also email me (address in my profile).
Thanks to the many people who've submitted/suggested changes! I've already gotten more help than I expected. I don't expect everybody to read all of the below, but here's where I'm coming from when I evaluate submissions:
-
I tend to code all at once in single sessions, so whatever you want to do, you're probably not duplicating my work. This is especially true if I posted the Issue myself. If you want to do something, go for it.
-
python unittest.py
must pass at all times. If your code is failing tests but you believe there is an error in the test, post a comment with your pull request or open an Issue (even if you know how to fix it; I want to know if my understanding of the game is wrong). -
Any instance of
Game.py
must conform to the official rules 100%. Any player-visible difference betweenGame.py
and the official rules is a bug. -
Because
Game.py
is pretending to be the server, it will not "trust" player instances at all. It will store its own state information like reputations and food even if the players are also storing that information. -
bots.py
must have no global variables other than class definitions (so thatfrom bots import *
is safe) -
Due to interest from people who don't know Python or even programming at all yet, I imagine there will be some people that just want to run simulations and some that want to patch the engine. To accomodate those people, my goal is that this engine be 100% usable by someone who only edits
Player.py
,app.py
, and perhapsbots.py
. The other files, particularlyGame.py
should be usable as "black boxes". -
Toward that end, my comment philsophy is that
Player.py
should be friendly to even people who learned Python yesterday, whileGame.py
will be a lot sparser because I assume contributors know what they're doing and don't want to clutter the code too much. Detailed docstrings are encouraged everywhere.
Thanks again for all your help!
--Chad