COMP3024 Artificial Inteligence
In this part of the project, you wil design and implement a Python program to play a
complete game of Watch Your Back!. Before you read this specification, please make sure
you have carefuly read the “Rules of the Game” document.
The aims for Project Part B are for you and your project partner to leverage the game-
playing techniques discussed in lectures and tutorials, to develop your own strategies for
playing the game, and to conduct your own research into more advanced game-playing
algorithms, al for the purpose of creating the best Watch Your Back! player the world has
ever seen.
Your task is as folows:
1. Create and submit a colection of Python 3.6 programs, including one program that
defines a class caled Player. Your Player class (your player) must be capable of
playing a complete game of Watch Your Back!. To do this, it must define the
methods described in the folowing ‘Required methods’ section. We provide a
‘driver’ program (referee.py) including a main function which coordinates a game
of Watch Your Back! betwen two such Player classes.
2. Describe your program (including the strategies you have developed, the
techniques you have implemented, and any other creative aspects of your solution)
in a text file comments.txt (case-sensitive) (details below).
Required methods
Your Player class must define at least the following three methods:
1. Set up your player: def __init__(self, colour): …
This method is caled by the referee once at the begining of the game to initialise
your player. You should use this oportunity to set up your own internal
representation of the board, and any other state you would like to maintain for the
duration of the game.
The input parameter colour is a string representing the piece colour your program
wil control for this game. It can take one of only two values: the string 'white' (if
you are the White player for this game) or the string 'black' (if you are the Black
player for this game).
2. Decide your next action: def action(self, turns): …
This method is caled by the referee to request an action by your player.
The input parameter turns is an integer representing the number of turns that have
taken place since the start of the current game phase. For example, if White player
has already made 1 moves in the moving phase, and Black player has made 10
moves (and the referee is asking for its 11
th
move), then the value of turns would
be 21.
Based on the current state of the board, your player should select its next action
and return it. Your player should represent this action based on the instructions
below, in the ‘Representing actions’ section.
3. Receive the oponent’s action: def update(self, action): …
This method is caled by the referee to inform. your player about the oponent’s
most recent move, so that you can maintain your internal board configuration.
The input parameter action is a representation of the oponent’s recent action
based on the instructions below, in the ‘Representing actions’ section.
This method should not return anything.
Note: update() is only caled to notify your player about the oponent’s actions.
Your player wil not be notified about its own actions.
Representing actions
Depending on the current game phase, the actions either player may take on their turn
may involve placing a piece on a square, moving a piece from one square to another
square, or forfeiting their turn. For the purposes of the update() and action()
methods, we represent each of these actions as folows:
• To represent the action of placing a piece on square (x,y), use a tuple (x,y).
• To represent the action of moving a piece from square (a,b) to square (c,d), use
a nested tuple ((a,b),(c,d)).
• To represent a forfeited turn, use the value None.
Describing your program
In adition to implementing a Player class, you must write and submit a text file caled
comments.txt (case-sensitive) describing your game playing program:
• Briefly describe the structure of your solution in terms of the major modules and
classes you have created and used.
• Describe the aproach taken by your game playing program for deciding on which
actions to take, in terms of
o your search strategy,
o your evaluation function, and
o any creative techniques that you have aplied, for example, machine
learning, search strategy optimisations, specialised data structures, other
optimisations, or any search algorithms not discussed in the lectures.
• If you have aplied machine learning, you should discuss the learning techniques
methodology you folowed for training the agent, and the intuition behind using that
specific technique.
• Include any other creative aspects of your solution, and any aditional comments
you want to be considered by the markers.
In addition, while working on your project, you may have built extra files to assist with your
project. For example, you may have created alternative Player classes, a modified
referee, aditional programs to test your player or its strategy, programs to create training
data for machine learning, or programs for any other purpose not directly related to
implementing your Player class. All of these files are worth including when you submit
your work, and should also be described in your comments.txt file.
Finally, if you have implemented multiple Player clases, please tel us very clearly
the location of the Player class you would like us to test and mark by including a
note near the top of your comments.txt file. Specificaly, please tel us which Python file
or module this class is contained within. This wil ensure that we can test the correct player
while marking your project.
Playing the game
Using the refere
The program referee.py (the referee) is the ‘driver’ program. It will allow you to actualy
play a game between two Player classes. It has the folowing structure:
1. Get the player class locations and other options from the command-line arguments
2. Load a new empty board, and initialise a White player and a Black player
3. Set the ‘current player’ to the White player, and the ‘oponent’ to the Black player
4. While the game has not ended:
a. Ask the current player for their next action
b. Apply this action to the board, if it is legal (otherwise, end the game with an
error message)
c. Update the oponent player with the current player’s action
d. Swap the current player and the opponent, and repeat this lop
5. Display the result of the game
To play a game using the referee, you must invoke it as folows:
python referee.py white_module black_module
where python is the name of a Python 3.6 interpreter, white_module is the ful name of
the module containing the Player class playing as the White player for this game, and
black_module is the ful name of the module containing the Player class playing as Black
player for this game.
The referee ofers some aditional flags. These can be viewed by runing:
python referee.py –h
Performance constraints
The folowing constraints wil be strictly enforced on your program during testing. This is to
prevent your programs from gaining an unfair advantage by using a large amount of
memory and/or computation time.
• A time limit of 60 seconds per player
• A memory limit of 10MB per player
Please note that these limits aply to each player for an entire game—they do not apply
on a per-turn basis.
Any atempt to circumvent these constraints wil not be alowed. For example, your
program must be single threaded, and must run in isolation (without atempting to conect
to any other programs, for example, via the internet, to access aditional resources). If you
are not sure as to whether some other technique wil be alowed, please seek clarification
early.
Alowed tools
Your Player class implementation may make use of any tols from within the Python
Standard Library (without atempting to circumvent the performance constraints). In
addition, you may use the library of classes available on the AIMA textbok website
(provided you make apropriate acknowledgements that you have used this library).
Furthermore, for this part of the project, your program may also use the non-standard
Python libraries NumPy and SciPy. Beyond these tols, your Player class should not
require any aditional tols or libraries to be available in order to play a game.
However, while you are developing your player you may use any third-party tols or
libraries you want. For example, you can use libraries to help you conduct machine
learning (scikit-learn, TensorFlow, etc.). As long as your Player class does not require
these tols to be available when it plays a game, you can use them freely. If you use any
third-party tols, these should be acknowledged in your comments.txt file.
Submision
Assessment
Part B wil be marked out of 2 points, and contribute 2% to your final mark for the
subject. Of the 2 points:
• 4 points wil be for the quality of your code: its structure (including god use of
modules, classes, and functions), readability (including god use of code
comments, and meaningful variable names), and documentation (including helpful
docstrings for modules, classes, and important functions and methods).
• 4 points wil be for the reliability and correctness of your program. When playing a
game, your Player class should not encounter any runtime errors, it should not
return any ilegal actions, and it should not violate the space or time constraints.
• 7 points wil be based on the performance of your Player class against a set of
other ‘benchmark’ Player classes. These benchmark players wil range in dificulty
from a player who just takes random (legal) actions, to a player using search
techniques discussed in lectures with multiple game-specific optimisations and
enhancements.
• 7 points wil be for the ‘creativity’ of your solution. This is a measure of how far
beyond the basic techniques discussed in lectures you have taken your
implementation (to be discussed further in lectures). Note that your comments.txt
file wil be an important part of how we assess this component of the project, so
please use it as an oportunity to highlight any creative aspects of your submission.
Please note that even if you don't have a program that works correctly by the time of the
deadline, you should submit anyway. You may be awarded some points for a reasonable
atempt at the project.
Please note that questions and answers pertaining to the project wil be available on the
LMS and wil be considered as part of the specification for the project.
Tournament
After submission, we wil run a tournament betwen the players of al groups to find out
which player is the very best, and the top three groups wil receive some awards. Your
player’s result in the tournament wil not afect your project mark.
Submision instructions
The submission deadline for Project Part B is 4.00pm Friday 11
th
May 2018.
One submission is required from each group. That is, one group member is responsible for
submiting al of the necessary files that make up your group's solution.
You must submit a single compressed archive file (e.g. a .zip or .tar.gz file) containing
al files making up your submission via the ‘Project Part B Submission’ item in the
‘Assessments’ section of the LMS. This compressed file should contain all Python files
required to run your player, your comments.txt file, and any aditional files not directly
related to implementing your Player class.
You can submit as many times as you like before the deadline. The most recent
submission wil be marked.
Late submission
Late submissions wil incur a penalty of two marks per working day (or part thereof).
If you canot submit on time, please contact both Sarah ()
and Mat () via email (use the subject header “COMP3024
Project B Extension”) at the soonest possible oportunity (idealy before the deadline). If
you have a medical reason for being late, you wil be asked to provide a medical
certificate. We wil then assess whether an extension is apropriate. Requests for
extensions on medical grounds received after the deadline may be declined.
Note that computer systems are often heavily loaded near project deadlines, and
unexpected network or system downtime can occur. You should plan ahead to avoid
leaving things to the last minute, when unexpected problems may occur. Generaly, system
downtime or failure wil not be considered as grounds for an extension.
Late submission wil be through the same section of the LMS. All late submissions must be
accompanied by an email to let us know that you have made a late submission, and which
submission you want us to mark.
Academic integrity
There should be one submission per group. You are encouraged to discuss ideas with
your felow students, but your program should be entirely the work of your group. It is not
acceptable to share code betwen groups, nor to use the code of someone else. You
should not show your code to another group, nor ask another group to lok at their code. If
your program is found to be suspiciously similar to someone else's or a third
party's software, or if your submision is found to be the work of a third party, you
may be subject to investigation and, if necesary, formal disciplinary action.
Please refer to the ‘Academic Integrity’ section of the LMS, and to the university’s
academic honesty website htp:/academichonesty.unimelb.edu.au/ if you need any further
clarification on these points.
Teamwork
Project plan
In adition to the tasks described above, as part of your project, you and your partner must
create and submit a brief ‘project plan’ describing how you and your partner plan on
working together to complete this part of the project. Specificaly, you should include:
• A breakdown of how you plan on sharing the workload of this project betwen you
and your partner.
• A summary of where and how regularly you plan on communicating about the
project with your partner (e.g. wekly meetings after tutorials, video chat, email).
• A list of upcoming deadlines for work in other subjects betwen now and the end of
semester.
You must submit this document to the ‘Project Plan Submission’ item in the ‘Assignments’
section on the LMS by 4.00pm, Wednesday 18
th
April 2018.
Teamwork reflection
Each group member wil have an oportunity to individualy comment on their experience
after the final submission of Project Part B. If you would like to make any comments on
your experience as part of your group in relation to the relative contribution of each group
member, you may individualy submit these comments. Note that this reflection should be
completed individualy, and is optional (you may chose not to submit a reflection).
If you want to complete a teamwork reflection, submit your comments to the ‘Teamwork
reflection submission (optional)’ item in the ‘Assignments’ section of the LMS before
1.59pm, Sunday 20
th
May 2018 (the end of wek 1).
Teamwork isues
In the unfortunate event that issues arise betwen you and your partner (such as a
breakdown in communication, a dispute about responsibilities or individual contributions to
the project, or other such issues), and you are unable to resolve these issues yourselves
first, then please contact both Sarah () and Mat
() via email at the earliest oportunity. Note that it's in
your best interest that any teamwork issues are identified as early as possible, so that we
have a chance to mitigate the efect that it has on your project’s results.
In addition, while completing the project, it is a god idea to keep minutes, brief meeting
notes, or chat logs recording topics discussed at each meeting, and other such documents
related to your work. In the event of a teamwork-related issue, such documents (along with
the project plan and teamwork reflections) will help us to reach a fair resolution.