辅导 Python program程序、讲解 game of Watch

In this part of the project, you will design and implement a Python program to play acomplete game of Watch Your Back!. Before you read this specification, please make sureyou have carefully read the “Rules of the Game” document.The aims for Project Part B are for you and your project partner to leverage the gameplayingtechniques discussed in lectures and tutorials, to develop your own strategies forplaying the game, and to conduct your own research into more advanced game-playingalgorithms, all for the purpose of creating the best Watch Your Back! player the world hasever seen.TaskYour task is as follows:1. Create and submit a collection of Python 3.6 programs, including one program thatdefines a class called Player. Your Player class (your player) must be capable ofplaying a complete game of Watch Your Back!. To do this, it must define themethods described in the following ‘Required methods’ section. We provide a‘driver’ program (referee.py) including a main function which coordinates a gameof Watch Your Back! between two such Player classes.2. Describe your program (including the strategies you have developed, thetechniques you have implemented, and any other creative aspects of your solution)in a text file comments.txt (case-sensitive) (details below).Required methodsYour Player class must define at least the following three methods:1. Set up your player: def __init__(self, colour): …This method is called by the referee once at the beginning of the game to initialiseyour player. You should use this opportunity to set up your own internalrepresentation of the board, and any other state you would like to maintain for theduration of the game.The input parameter colour is a string representing the piece colour your programwill control for this game. It can take one of only two values: the string 'white' (ifyou are the White player for this game) or the string 'black' (if you are the Blackplayer for this game).2. Decide your next action: def action(self, turns): …This method is called by the referee to request an action by your player.The input parameter turns is an integer representing the number of turns that havetaken place since the start of the current game phase. For example, if White playerhas already made 11 moves in the moving phase, and Black player has made 10moves (and the referee is asking for its 11th move), then the value of turns wouldbe 21.Based on the current state of the board, your player should select its next actionand return it. Your player should represent this action based on the instructionsbelow, in the ‘Representing actions’ section.3. Receive the opponent’s action: def update(self, action): …This method is called by the referee to inform your player about the opponent’smost recent move, so that you can maintain your internal board configuration.The input parameter action is a representation of the opponent’s recent actionbased on the instructions below, in the ‘Representing actions’ section.This method should not return anything.Note: update() is only called to notify your player about the opponent’s actions.Your player will not be notified about its own actions.Representing actionsDepending on the current game phase, the actions either player may take on their turnmay involve placing a piece on a square, moving a piece from one square to anothersquare, or forfeiting their turn. For the purposes of the update() and action()methods, we represent each of these actions as follows:• 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), usea nested tuple ((a,b),(c,d)).• To represent a forfeited turn, use the value None.Describing your programIn addition to implementing a Player class, you must write and submit a text file calledcomments.txt (case-sensitive) describing your game playing program:• Briefly describe the structure of your solution in terms of the major modules andclasses you have created and used.• Describe the approach taken by your game playing program for deciding on whichactions to take, in terms ofo your search strategy,o your evaluation function, ando any creative techniques that you have applied, for example, machine learning, search strategy optimisations, specialised data structures, otheroptimisations, or any search algorithms not discussed in the lectures.• If you have applied machine learning, you should discuss the learning techniquesmethodology you followed for training the agent, and the intuition behind using thatspecific technique.• Include any other creative aspects of your solution, and any additional commentsyou want to be considered by the markers.In addition, while working on your project, you may have built extra files to assist with yourproject. For example, you may have created alternative Player classes, a modifiedreferee, additional programs to test your player or its strategy, programs to create trainingdata for machine learning, or programs for any other purpose not directly related toimplementing your Player class. All of these files are worth including when you submityour work, and should also be described in your comments.txt file.Finally, if you have implemented multiple Player classes, please tell us very clearlythe location of the Player class you would like us to test and mark by including anote near the top of your comments.txt file. Specifically, please tell us which Python fileor module this class is contained within. This will ensure that we can test the correct playerwhile marking your project.Playing the gameUsing the refereeThe program referee.py (the referee) is the ‘driver’ program. It will allow you to actuallyplay a game between two Player classes. It has the following structure:1. Get the player class locations and other options from the command-line arguments2. Load a new empty board, and initialise a White player and a Black player3. Set the ‘current player’ to the White player, and the ‘opponent’ to the Black player4. While the game has not ended:a. Ask the current player for their next actionb. Apply this action to the board, if it is legal (otherwise, end the game with anerror message)c. Update the opponent player with the current player’s actiond. Swap the current player and the opponent, and repeat this loop5. Display the result of the gameTo play a game using the referee, you must invoke it as follows:python referee.py white_module black_modulewhere python is the name of a Python 3.6 interpreter, white_module is the full name ofthe module containing the Player class playing as the White player for this game, andblack_module is the full name of the module containing the Player class playing as Blackplayer for this game.The referee offers some additional flags. These can be viewed by running:python referee.py –hPerformance constraintsThe following constraints will be strictly enforced on your program during testing. This is toprevent your programs from gaining an unfair advantage by using a large amount ofmemory and/or computation time.• A time limit of 60 seconds per player• A memory limit of 100MB per playerPlease note that these limits apply to each player for an entire game—they do not applyon a per-turn basis.Any attempt to circumvent these constraints will not be allowed. For example, yourprogram must be single threaded, and must run in isolation (without attempting to connectto any other programs, for example, via the internet, to access additional resources). If youare not sure as to whether some other technique will be allowed, please seek clarificationearly.Allowed toolsYour Player class implementation may make use of any tools from within the PythonStandard Library (without attempting to circumvent the performance constraints). Inaddition, you may use the library of classes available on the AIMA textbook website(provided you make appropriate acknowledgements that you have used this library).Furthermore, for this part of the project, your program may also use the non-standardPython libraries NumPy and SciPy. Beyond these tools, your Player class should notrequire any additional tools or libraries to be available in order to play a game.However, while you are developing your player you may use any third-party tools orlibraries you want. For example, you can use libraries to help you conduct machinelearning (scikit-learn, TensorFlow, etc.). As long as your Player class does not requirethese tools to be available when it plays a game, you can use them freely. If you use anythird-party tools, these should be acknowledged in your comments.txt file.SubmissionAssessmentPart B will be marked out of 22 points, and contribute 22% to your final mark for thesubject. Of the 22 points:• 4 points will be for the quality of your code: its structure (including good use ofmodules, classes, and functions), readability (including good use of codecomments, and meaningful variable names), and documentation (including helpfuldocstrings for modules, classes, and important functions and methods).• 4 points will be for the reliability and correctness of your program. When playing agame, your Player class should not encounter any runtime errors, it should notreturn any illegal actions, and it should not violate the space or time constraints.• 7 points will be based on the performance of your Player class against a set ofother ‘benchmark’ Player classes. These benchmark players will range in difficultyfrom a player who just takes random (legal) actions, to a player using search techniques discussed in lectures with multiple game-specific optimisations andenhancements.• 7 points will be for the ‘creativity’ of your solution. This is a measure of how farbeyond the basic techniques discussed in lectures you have taken yourimplementation (to be discussed further in lectures). Note that your comments.txtfile will be an important part of how we assess this component of the project, soplease use it as an opportunity 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 thedeadline, you should submit anyway. You may be awarded some points for a reasonableattempt at the project.Please note that questions and answers pertaining to the project will be available on theLMS and will be considered as part of the specification for the project.TournamentAfter submission, we will run a tournament between the players of all groups to find outwhich player is the very best, and the top three groups will receive some awards. Yourplayer’s result in the tournament will not affect your project mark.Submission instructionsThe submission deadline for Project Part B is 4.00pm Friday 11th May 2018.One submission is required from each group. That is, one group member is responsible forsubmitting all 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) containingall 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 filesrequired to run your player, your comments.txt file, and any additional files not directlyrelated to implementing your Player class.You can submit as many times as you like before the deadline. The most recentsubmission will be marked.Late submissionLate submissions will incur a penalty of two marks per working day (or part thereof).If you cannot submit on time, you will be asked to provide a medicalcertificate. We will then assess whether an extension is appropriate. Requests forextensions on medical grounds received after the deadline may be declined.Note that computer systems are often heavily loaded near project deadlines, andunexpected network or system downtime can occur. You should plan ahead to avoidleaving things to the last minute, when unexpected problems may occur. Generally, systemdowntime or failure will not be considered as grounds for an extension.Late submission will be through the same section of the LMS. All late submissions must beaccompanied by an email to let us know that you have made a late submission, and whichsubmission you want us to mark.Academic integrityThere should be one submission per group. You are encouraged to discuss ideas withyour fellow students, but your program should be entirely the work of your group. It is notacceptable to share code between groups, nor to use the code of someone else. Youshould not show your code to another group, nor ask another group to look at their code. Ifyour program is found to be suspiciously similar to someone else's or a thirdparty's software, or if your submission is found to be the work of a third party, youmay be subject to investigation and, if necessary, formal disciplinary action.TeamworkProject planIn addition to the tasks described above, as part of your project, you and your partner mustcreate and submit a brief ‘project plan’ describing how you and your partner plan onworking together to complete this part of the project. Specifically, you should include:• A breakdown of how you plan on sharing the workload of this project between youand your partner.• A summary of where and how regularly you plan on communicating about theproject with your partner (e.g. weekly meetings after tutorials, video chat, email).• A list of upcoming deadlines for work in other subjects between now and the end ofsemester.You must submit this document to the ‘Project Plan Submission’ item in the ‘Assignments’section on the LMS by 4.00pm, Wednesday 18th April 2018.Teamwork reflectionEach group member will have an opportunity to individually comment on their experienceafter the final submission of Project Part B. If you would like to make any comments onyour experience as part of your group in relation to the relative contribution of each groupmember, you may individually submit these comments. Note that this reflection should becompleted individually, and is optional (you may choose not to submit a reflection).If you want to complete a teamwork reflection, submit your comments to the ‘Teamworkreflection submission (optional)’ item in the ‘Assignments’ section of the LMS before11.59pm, Sunday 20th May 2018 (the end of week 11).Teamwork issuesIn the unfortunate event that issues arise between you and your partner (such as abreakdown in communication, a dispute about responsibilities or individual contributions to the project, or other such issues), and you are unable to resolve these issues yourselvesfirst, then please contact both Sarah (sarah.erfani@unimelb.edu.au) and Matt(matt.farrugia@unimelb.edu.au) via email at the earliest opportunity. Note that it's inyour best interest that any teamwork issues are identified as early as possible, so that wehave a chance to mitigate the effect that it has on your project’s results.In addition, while completing the project, it is a good idea to keep minutes, brief meetingnotes, or chat logs recording topics discussed at each meeting, and other such documentsrelated to your work. In the event of a teamwork-related issue, such documents (along withthe project plan and teamwork reflections) will help us to reach a fair resolution.