[RULE CHANGE] *Victory by "attrition"* + Bug fixes
[progcomp2012.git] / web / index.html
index 6329e80..8563b14 100644 (file)
 <body>
 
 <h1> Quick Details</h1>
+<h2> git </h2>
 <p> The git repository is listed on <a href="http://git.ucc.asn.au/"/>The UCC git page</a> as "progcomp2012.git" </p>
+<p> <a href="http://git.ucc.asn.au/?p=progcomp2012.git;a=summary"/>Direct Link Here</a></p>
+
+<h2> Mailing List </h2>
 <p> We will use the same mailing list as last year (progcomp). </p>
-<p> </p>
-<p> There is a #progcomp irc channel on the ucc irc server where you can ask questions or help with setting things up. </p>
+
+<h2> irc channel </h2>
+<p> There is a #progcomp irc channel on the ucc irc server (irc.ucc.asn.au) where you can ask questions or help with setting things up. </p>
 
 <h1> Stratego </h1>
 <p> <a href="http://www.edcollins.com/stratego/"/>This site</a> explains what Stratego is. </p>
-<p> I have never played this game. But it sounds cool. So naturally I decided to make a competition based on it. </p>
-<p> My original idea was to force people to write AI for <a href="http://matches.ucc.asn.au/Astral"/>Astral</a>, but then I realised that that was a terrible idea. </p>
 
-<p> There is in fact, already a <a href="http://www.strategousa.org/wiki/index.php/2010_Computer_Stratego_World_Championship"/>World Stratego Championship</a>. However, you have to use Metaforge. Using stdin/stdout will probably make it slightly easier for us. And its better to work out how to do these things ourselves. </p>
+<p> Short Version: It is a board game in which all pieces have a value that is, initially, unknown to the opponent player. The objective is to destroy all enemy pieces, or capture the enemy "Flag". Pieces with higher values destroy pieces with lower values. There are several special pieces/rules. </p>
+
 
-<h2> Programming Competition </h2>
+<h1> Programming Competition </h1>
 <p> Create an AI to play Stratego. </p>
-<p> Yes, I <i> know </i> people are inherently lazy and won't be bothered to do this. But so far in setting this up I have learn quite a lot about inter-process communication, so thats good. </p>
 <p> Programs are written independently and interface through stdin/stdout with a manager program, which queries them on setup and moves. </p>
+
 <h3> The Manager Program </h3>
-<p> The manager program takes two executable paths, one to each of the AI programs to pit against each other. <p>
-<p> It first requests each program to print the setup of its pieces to stdout. Then the programs take turns (Red, then blue, etc) to move one piece. </p>
-<p> The first program is Red (top of the board), the second is Blue (bottom of the board). </p>
-<p> The manager program now has switches to enable/disable graphics and set the move speed of the match. </p>
-<p> Use "-g" to enable graphics (by default disabled) and "-t TIMEOUT" to set the move speed (default 0 (as fast as possible)). </p>
-<p> <b> This program now has a <a href="../manager/manual.txt"/>manual page</a> </b> </p>
-
-<h2> Messaging Protocol and Rules </h2>
-<p> <b> The rules are now also available in the <a href="../manager/manual.txt"/>manual page</a> of the manager program </b> </p>
-<h3> Setup </h3>
-<h4> Query </h4>
-<p> The manager program prints one line in the following format to each program: </p>
-<p>    COLOUR OPPONENT BOARD_WIDTH BOARD_HEIGHT </p>
-<p> At the moment BOARD_WIDTH and BOARD_HEIGHT are always 14. The arguments are followed by a newline. </p>
-<p> OPPONENT will be the identity of the opposing AI program. </p>
-<h4> Response </h4>
-<p> The AI program queried must print <i>four</i> (4) lines containing its initial setup. Each character represents a unit or empty space. The characters are as follows: </p>
+<p> The manager program provides the protocol for two seperate AI to play a game of stratego. It has the imaginative name of 'stratego', but I will probably refer to it as 'the manager program' or 'stratego' with absolutely no consistency. </p>
+<p> It also aims to assist with AI design by providing options for graphical or terminal output and saving/reading games from files </p>
 <p> </p>
+<p> Human players are also supported, although the interface is minimal, as this feature is meant for testing. </p>
+<p> If you just want to play a game, without having to write your own AI, try <a href="http://www.probe.imersatz.com/"/>Probe</a> </p>
+
+<h4> Screenshot </h4>
+<img border="0" src="screenshot.png" alt="Graphical output of 'stratego' manager program." title="Graphical output of 'stratego' manager program. Options '-g' for graphics and '-b' to hide Blue pieces that have not taken part in combat yet. Red and Blue are both linked to the 'asmodeus' AI. Taken with scrot on 7/12/11." width="327" height="344" />
+
+<h3> Protocol </h3>
+<p> For the sake of simplicity and keeping things in one place, the protocol is now entirely described in the <a href="doc/manager_manual.txt"/>manual page</a> of the manager program. All updates to the protocol will be reflected in that file. </p>
+
 
-<p><b>Warning:</b> I have changed the characters from mostly letters to mostly digits, indicating the actual worth of a piece</p>
-<table border="1">
-<tr> <th>Name</th> <th>Character</th>  <th> Number </th> <th> Notes </th> </tr>
-<tr> <td>Marshal</td> <td>1</td>  <td>1</td> <td> Dies if attacked by the Spy </td> </tr>
-<tr> <td>General</td> <td>2</td>  <td>1</td> <td> </td> </tr>
-<tr> <td>Colonel</td> <td>3</td>  <td>2</td> <td> </td> </tr>
-<tr> <td>Major</td> <td>4</td> <td>3</td> <td> </td> </tr>
-<tr> <td>Captain</td> <td>5</td> <td>4</td> <td> </td> </tr>
-<tr> <td>Lietenant</td> <td>6</td> <td>4</td> <td> </td> </tr>
-<tr> <td>Sergeant</td> <td>7</td> <td>4</td> <td> </td> </tr>
-<tr> <td>Miner</td> <td>8</td> <td>5</td> <td> Defuses Bombs and survives. </td> </tr>
-<tr> <td>Scout</td> <td>9</td> <td>8</td> <td> May move any number of times in a single direction. </td> </tr>
-<tr> <td>Spy </td> <td>s</td> <td>1</td> <td> If the Spy attacks the Marshal, the Marshal is destroyed. </td> </tr>
-<tr> <td>Bomb</td> <td>B</td> <td>6</td> <td> Immobile. Destroys both self and any unit that attacks the Bomb. </td> </tr>
-<tr> <td>Flag</td> <td>F</td> <td>1</td> <td> Immobile. Capture the opponent's flag to win. </td> </tr>
-<tr> <td>Unoccupied</td> <td>.</td> <td> </td> </tr> 
-<tr> <td>Obstacle</td> <td>*</td> <td> </td> </tr>
+<p> <b> Warning:</b> The accuracy of the above file depends on how recently I pulled it from git. To ensure you get the latest version, find it under "web/doc/manager_manual.txt" in the <a href="http://git.ucc.asn.au/?p=progcomp2012.git;a=summary"/>git repository</a> </p>
+
+<p> <b> Another Warning:</b> AI programs <b>must</b> unbuffer stdin and stdout themselves. This is explained in the manual page, but I figured no one would read it. It is fairly simple to unbuffer stdin/stdout in C/C++ and python, I have not investigated other languages yet. </p>
+
+<h2> Long Term Scoring </h2>
+<p> Several rounds will be played (depending on the number of entries), with contestants given time to improve their entries between rounds. </p>
+<p> Each round is a round robin, with every AI playing several games against each possible opponent. A points system is used to score each AI, 3 points for a Win, 2 for a Draw, 1 for a Loss or -1 for an Illegal response (counts as a Win for the opponent). Scores accumulate between rounds. </p>
+<p> The winning AI will be the AI with the highest score after all rounds have been played. In the event of a tied score, the two highest scoring AI's will play one more round consisting of three games. If the scores are still tied, the official outcome will be a Draw. </p>
+<p> When the competition officially runs, results will appear <a href="results"/>here</a>. Preliminary test results might occasionally appear there for the next few weeks. </p> <p> 
+
+<h2> Sample AI Programs </h2>>
+<p> The following sample programs are currently available (and in a semi-working state - refer to the git repository): </p>
+<table border="0">
+<tr> <th>Name</th> <th>Language</th> <th> Moves </th> <th> Considers... </th> </tr>
+<tr> <td>basic_python</td> <td>Python</td> <td>Randomised</td> </tr>
+<tr> <td>basic_cpp</td> <td>C++</td> <td>Randomised</td> </tr>
+<tr> <td>asmodeus</td> <td>Python</td> <td>Scored</td> <td>Path finding, known combat results, piece values</td> </th> 
+<tr> <td>vixen</td> <td>Python</td> <td>Scored</td> <td>Asmodeus + Probabilities for unknown combat results </td> </th>
 </table> 
-<p> The AI program can't place any obstacles, and must at least place the Flag for its setup to be valid. </p>
-<p> RED will always occupy the top four rows of the board, and BLUE occupies the bottom four rows. </p>
-
-<p> All pieces except the Scout, Bomb and Flag can move 1 square horizontally or vertically (not diagonally). </p>
-<p> When two pieces of different ranks encounter each other, the piece with the highest rank (lowest numbered rank!) is the victor, unless a special rule applies. </p>
-<p> When two pieces of <i>equal</i> rank encounter each other, the victor is randomly chosen </p>
-<p> Pieces of the same colour may <i>not</i> pass through the same squares </p>
-
-<h3> Turns </h3>
-<h4> Query </h4>
-<p> RED starts the game. The manager queries RED to make the <i>first</i> move by printing: </p>
-<p>    START </p>
-<p> Followed by a WIDTH*HEIGHT grid. '*' or '#' characters are used to indicate positions of unknown (BLUE/RED) enemy units. </p>
-
-<h4> Response </h4>
-<p> The AI program must respond with a <i> single </i> line of the following form: </p>
-<p>    X Y DIRECTION [MULTIPLIER]</p>
-<p> Where X and Y represent valid co-ordinates, upon which there is a piece of the AI program's colour. </p>
-<p> DIRECTION must be either "UP", "DOWN", "LEFT", or "RIGHT", and is, obviously, the way the piece is supposed to move </p>
-<p> MULTIPLIER is optional, and should only be given if the AI program is moving a Scout. Scouts may move multiple times in the same direction if possible. </p>
-<p> </p>
+<p> It is planned to implement the equivelants of these samples in C++ and Python at least, possibly other languages later. </p>
 
-<h4> Outcome </h4>
-<p> The manager program will indicate the result of a move by responding with: </p>
-<p>    X Y DIRECTION [MULTIPLIER] OUTCOME </p>
-<p> Where X, Y, DIRECTION and MULTIPLIER are as above. </p>
-<p> OUTCOME signals the result of the turn, and will be one of the following: </p>
-<table border="1">
-       <tr> <th> OUTCOME </th> <th> Description </th>  </tr>
-       <tr> <td> OK </td> <td> The piece was successfully moved, nothing eventful happened </td> </tr>
-       <tr> <td> FLAG </td> <td> The piece moved onto the opposing Flag; the game will end shortly </td> </tr>
-       <tr> <td> KILLS RANK1 RANK2 </td> <td> The piece landed on a square occupied by an enemy, and destroyed it, moving into the square </td> </tr>
-       <tr> <td> DIES RANK1 RANK2</td> <td> The piece landed on a square occupied by an enemy, and was destroyed. The piece is removed from the board. </td> </tr>
-       <tr> <td> BOTHDIE RANK1 RANK2</td> <td> The piece landed on a square occupied by an enemy, and <i>both</i> pieces were destroyed. </td> </tr>
-       <tr> <td> ILLEGAL </td> <td> The moving player attempted to make an illegal move, and has hence lost the game. The game will end shortly. </td> </tr>
-</table>
-<p> If printed, RANK1 and RANK2 indicate the ranks of the moved piece and the defending piece (the piece who occupied the destination square) respectively. </p>
-<p> Originally RANK1 and RANK2 were never printed, but when I actually tried to write an AI myself I got very annoyed at this restriction... indicating it was probably a bad idea :P </p>
-               
-
-<h4> Additional Turns </h4>
-<p> The Outcome of each turn is printed to <i>both</i> AI programs. </p>
-<p> The state of the board is then printed to BLUE, who makes a move, then the process repeats. </p>
+<h2> Submissions </h2>
+<p> You must submit the full source code, and build instructions or makefile(s) for your program. </p>
+<p> Also include the name of the executable or script, the name of the AI, your name, and optionally a description of your AI and its tactics. </p>
+<p> Please email matches@ if you have a submission. </p>
+<p> <b> Code which attempts to comprimise the host machine, or interfere directly with the functioning of other programs will be disqualified. </b> </p>
 
-<p> </p>
+<h2> Dates </h2>
+<p> The competition will run in 2012. The exact dates have not been determined. An email will be sent to the list and messages sent to the irc channel. </p>
 
-<h4> Overview </h4>
-<p> This is a description of the signals the AI programs recieve, in order:
-<ol>
-       <li> Previous turn's outcome (other player's move) OR "START" if it is the first turn </li>
-       <li> A BOARD_WIDTH*BOARD_HEIGHT grid indicating the board state, with the AI program's own pieces revealed </li>
-       <li> After the AI program makes a move, the outcome is printed to it, and the other program, which continues from step 1 </li>
-</ol>
-<p> I am considering removing Step 2, since <i>all</i> information needed for an AI to keep the board state is contained in the initial board state and then the movement result messages </p>
-
-<h3> End Game </h3>
-<h4> Query </h4>
-<p> At the end of the game, the manager program outputs the following: </p>
-<p>    VICTORY </p>
-<p> To the winning AI program, and </p>
-<p>    DEFEAT </p>
-<p> To the losing program. </p>
-<p> Both programs then have 2 seconds to exit succesfully, or the manager will kill them. </p>
-<h3> Invalid Responses and Timeouts </h3>
-<p> If any program fails to respond correctly, or gives an invalid move, or does not respond within 1 second, it will lose by default. </p>
-<p> In this case, the message </p>
-<p>    ILLEGAL </p>
-<p> will be sent to the malfunctioning program, and </p>
-<p>    DEFAULT </p>
-<p> to the other program </p>
-<p> Both programs then have 2 seconds to exit succesfully, or the manager will kill them. </p>
-
-<h2> Modifications/Clarifications to Rules </h2>
-<p> Refer to <a href="http://www.edcollins.com/stratego/"/>This site</a> for the original rules again </p>
-<p> Currently, the pieces taking part in the combat are not revealed; only the outcome of the combat is revealed. In a human game, the pieces would normally be revealed. I am planning to reveal the pieces, since not revealing pieces significantly reduces the value of low ranked pieces (normally used for working out enemy piece values). </p>
-<p> It is up to the AI program to keep track of pieces. The manager program will only reveal the identity of the AI program's own pieces; the other player's pieces will be marked with * or # characters. </p>
-<p> In a traditional game, two pieces of equal value will both be destroyed in combat. Currently, only one piece is destroyed and the outcome is randomly chosen. </p>
-
-<h2> Example Programs </h2>
-<h3>"Dummy" AI</h3>
-<p> Dummy randomly moves pieces. It attempts to not make illegal moves (although sometimes it still does). </p>
-<h3>"Forfax" AI</h3>
-<p> Forfax iterates through all possible moves and allocates a score between 0 and 1 to each move based on how desirable the move is. It then selects the highest scoring move. </p>
-<p> Forfax is pretty terrible, but can beat the Dummy AI <i>most</i> of the time. </p>
-<p> It is possible Forfax can be greatly improved by altering the scoring algorithms. </p>
-<p> Since we don't want the Sample AIs to beat every entrance, I'm not really going to try and improve Forfax unless I get bored. </p>
-<p> If you are writing an AI in C++, Forfax already contains a lot of useful functions. </p>
-
-<h2> Longterm Scoring </h2>
-<p> I haven't started a system for pairing AI's and keeping track of scores and winners etc yet </p>
-<p> I'll probably have a bash script that chooses who will play, and stores all the scores in files. I've done this before for a BrainF*** based "survival of the fittest" style thing, so I can probably recycle it </p>
-<p> </p>
-<p> I believe it will make things more interesting if programs are allowed to keep state of who they have played, and the various tactics used. </p>
-<p> Its kind of hard to implement this... at the moment programs are killed every time a game finishes</p>
-<p> Perhaps it will be easier if each program is allowed access to one directory, where it can create and read files? </p>
-<p> This would allow me to keep the manager program which actually plays the games seperate from the program for scoring and matching of opponents </p>
-<p> There'd probably be security issues with that though. </p>
+<h2> Involvement </h2>
+<p> If you want to help set up the competition, email matches@ </p>
+
+
+<p> <b>Last webpage update: 22/12/11</b></p>
 </body>
 
 </html>

UCC git Repository :: git.ucc.asn.au