Every group should read all task descriptions even if the topic is not
assigned for the group. Some task descriptions give or refer to some
background information useful in other exercises.
Some tasks are so useful, that some groups may wish to do them even if
didn't select them. That is allowed, but funtionality of such extra
features is not graded.
Maximum points for exercises, mentioned below, are only general
guidelines about the weight of that exercise during the assessment. It
might seem that it is possible to get more than 5000 (maximum of the
project) points from the tasks. However, if you manage to do that,
project points, when calculating the final graded, are scaled down to
6000. You should also remember that not only the functionality is
assessed. Design, documentation, and usability are also counted when
points are given.
All the groups have U1 (Unit-testing exercise) mandatory for the first
iteration. All team members should participate for it. In addition,
each 3 person group has 5 possible additions for the first iteration
from where the group has to choose 3. For the second iteration there
are 4 exercises available, from where each group selects 3. All other
exercises except U1 should have one responsible author mentioned in
the project plan.
Exercises for the first iteration/submission:
-------------------------------------------------------
U1 - Unit-testing exercise (max 600 points)
-------------------------------------------
The function `position_compress' in file `ai.c' tries to canonify the
position before encoding it into a concise bit-level representation.
Such canonicalizations (hint: http://en.wikipedia.org/wiki/Canonicalization)
include relocating the origin of the X- and Y-coordinates,
transposing, and changing the direction of the coordinates.
Your task is to write a test program which evaluates how well this
canonicalization process works. It might for example work by generating
many, say 10000, random positions, transforming copies of them as
described above, and checking how frequently the position and its
transformed copy are canonified to identical compressed positions.
You can also try to identify if there are any typical rules when the
canonification process fails.
E1 - User interface improvements (max 200 points)
-------------------------------------------------
Add ALT-tags to the images, e.g.
<IMG SRC="/pix/cross-white.gif" ALT="X">
E2 - Port number as command line parameter (max 300 points)
-----------------------------------------------------------
Currently the ToroidToe server listens to port number 6666. Having
the port number fixed in the code has a number of drawbacks: no two
servers can run on the same computer, if a port remains reserved after
a non-clean exit the server can't be immediately restarted, many
firewalls may not pass connections to this port, etc.
Your task is to add a command line option `-p port' which, if given,
makes the server listen to the given port instead of the default port
6666. Remember to update also the usage text accordingly.
E3 - Disallow illegal moves (max 500 points)
--------------------------------------------
The current code allows the user to continue play after the game has
already ended, or where a cross or nought has already been placed.
Fix this by making links corresponding to such illegal moves
non-active.
Even if the above task has been done, it is still possible to make
illegal moves by typing them manually as URLs in the browser. Fix this
also.
E4 - User interface improvements (max 500 points)
--------------------------------------------------
Write functionality that somehow highlights/visualizes which move was
made by the computer and how the computer evaluated its chances in the
game.
E5 - User interface improvements (max 500 points)
-------------------------------------------------
Add functionality that highlights the winning row. You can, for
example, use the GIF images with green backgrounds supplied with the
original source code.
E6 - User interface improvements (max 500 points)
-------------------------------------------------
As an alternative method to help the user, add functionality which
partially wraps open the torus by rendering four lines above and below
and four columns left and right of the playing area. You can use the
GIF images with grey background supplied with the source code four
those lines and columns.
E7 - User interface improvements (max 500 points)
-------------------------------------------------
A torus is difficult humans to grasp, so add functionality which
allows the user to move the viewpoint of the rendered playing area
during the game. For example, the following two games are actually the
same, only the viewpoint is different.
ooooxo oooooo
oooooo oooooo
oooooo oooxoo
oxoooo ooxooo
xooooo oxoooo
ooooox xooooo
E8 - Allow the user play nought (max 500 points)
------------------------------------------------
Allow the user to choose on the first page with a radio button whether
he plays nought or cross. However, keep on mind that cross should
allways start the game.
See for example http://www.faqs.org/docs/htmltut/forms/_INPUT_TYPE_RADIO.html
for the HTML code used to produce the radio button, and either read
more manuals or observe the HTTP requests to learn how to detect the
user's choice.
E9 - Allow the user to choose AI level (max 500 points)
-------------------------------------------------------
Allow the user to choose (on the first page) with a radio button how
hard an AI opponent he plays.
See for example http://www.faqs.org/docs/htmltut/forms/_INPUT_TYPE_RADIO.html
for the HTML code used to produce the radio button, and either read
more manuals or observe the HTTP requests to learn how to detect the
user's choice. I suggest you support four levels which correspond to
values 1, 3, 5, or 7 as the last argument to the function 'ai_move'.
Exercises for the second iteration/submission:
---------------------------------------------------------
H1 - Save the rote learning hash table (max 800 points)
--------------------------------------------------------
When the toroidtoe server dies, the contents of the
rote_learning_hash_table are lost. Add functionality which appends
each new value stored in the table also to a file, and reconstructs
the most recent contents of the table when the server restarts. (In
other words, nothing is ever removed from the file, and it is possible
that a subsequent invocation has a different HASH_TABLE_SIZE.) The
name of the file is given with a command line option '-r filename'.
H2 - Limited undo (max 800 points)
-----------------------------------
The current code does not allow the user to undo moves. Add
functionality which allows the user to undo three moves during the
game, but not more. It should be possible to do several (three at
most) undo operation in a row.
H3 - The last page shows the whole game (max 1000 points)
---------------------------------------------------------
After the game has ended, present an easy-to-read move-by-move summary
of the whole game. Annotate the summary with the values (or their
human-understandable interpretation) returned by corresponding calls
to ai_move. For full points, a nice graphical implementation is required.
H4 - Identify and rank players (max 1300 points)
------------------------------------------------
Identify the users with a user-name and password on the first page and
maintain a high-score list based on the games they have played. You
can use forms
http://www.faqs.org/docs/htmltut/forms/_FORM.html
as the HTML that asks for the user-name and password, and the ranking
can be based on attributes such as whether the user played nought or
cross, what level he plaid, how the game ended, how long the game
lasted, number of undos, etc., whatever relevant for your group. Pay
a little attention to the risk that many game servers can be fooled to
not penalize for lost games by the user never finishing a game he sees
he will lose. Add a page which presents the ranking and add a link to
it from the first page.