Python. Application idea You shall develop a game of medium complexity with not to many classes. The game is executed in the terminal and you will use the feature cmd support for line-oriented command interpreters (Links to an external site.) to implement the game loop. There are two game ideas from which you shall choose one to implement. Idea 1 - Pig (dice game) Review the rules for the game at Wikipedia on Pig (dice game) (Links to an external site.). Decide what variation you want to implement. Here are some suggestions for classes you might want to implement: Game, Dice, DiceHand, Histogram, Intelligence, HighScore, Player Idea 2 - War (card game) Review the rules for the game at Wikipedia on War (card game) (Links to an external site.). Decide what variation you want to implement. Here are some suggestions for classes you might want to implement: Game, Card, Deck, CardHand, Histogram, Intelligence, HighScore, Player Requirements These are the requirements that must be met. Functionality The game should be played by one player towards the computer and as a two player game. Each player should be able to select a name for themself. A player should be able to change their name. There should be a persistent highscore list where statistics on each player and their played games, are stored and visible. The statistics should remain if the player changes their name. One should be able to see the rules of the game. One should be able to play a whole game round. One should be able to quit the current game and restart it. There should be a cheat which one can use for testing purpose and reach the end of the game faster. This cheat should contain a information text som one knows how to use it. The game should have a nice graphical (by text since we are in the terminal) representation so it looks like fun to play it. When the computer is playing, it should have some type of intelligence for playing the game. There might be several settings fr the level of intelligence for the computer playing. These should be configurable by the user while playing. Your game should be resilient and continue to work if/when the user enters bad input. You should document the basics of the game in the projects README.md. For example you should describe how you choosed to implement the intelligence part. Structure You application should be divided into classes where each class resides in its own file. Use object-oriented programming style. Feel free to add functional programming style where you feel its suited. Try hard to make small enough methods. It would be real good if you store your work in a Git repo. Feel free to publish your project to a service like GitLab or Github. You can then use this repo when you submit your assignment results. If you use Git you should have more than 50 commits and 10 tags. Treat it as a guideline. Your project should contain a README.md that provides a description of the project and an instruction on how to install and run the game. There should be a requirements.txt containing the essential packages to install to be able to run the application. Feel free to use a Makefile to make it easier to build and test your project. You shall have a file RELEASE.md where you document each release you do. Feel free to use Git tags for tagging your project. Add a LICENSE.md to your project. Try to do your best to code in a pythonic manner and follow the PEP 20 guidelines. Unittesting Your code shall be covered by unit tests. The unit tests shall be stored in one file per class. Each class should have a complete set of unit tests. If you have modules and functions then these should also be covered by unit tests and these should be stored in their own files so it is obvious which unit tests belong to a certain class or module. Your README.md should contain a section on how to run the complete testsuite and how to get the coverage report. Feel free to implement make test and make coverage or something similair. You shall measure your code coverage and you shall try to reach at least the following metrics. More than 90% code coverage. At least 10 testcases fore each class. At least 20 assertions for each class. Document by comments Your code must be well documented using python docstrings. Generate documentation from comments It should be possible to generate documentation from your code and the python docstrings. You should use a automated tool for this purpose. You may choose a tool of your liking. Feel free to add a make doc target to solve this issue. The documentation should be readable as html and included in your project below the doc/api directory. You README.md should contain details on how one can regenerate the documentation from your code. Generate UML diagrams from code You should generate a UML documentation from your code using a tool that reverse engineer your code to create UML diagrams. You should use a automated tool for this purpose. You may choose a tool of your liking. Feel free to add a make uml target to solve this issue. The documentation should be included in your project below the doc/uml directory. Create a index.html where you display the diagrams in a web browser together with . You should at least generate a class diagram and a package diagram. Document in your README.md on how to regenerate the UML diagrams of the documentation. Use semantic versioning You shall use semantic versioning to document your releases of your application. Use git tags if you are using Git. Always write the major releases into your RELEASE.md document with the version number, the release date and notes on what has changed. Code style You must add linters as a tool to ensure you have a proper code style and to avoid bad coding practises. You must use at least the tools pylint and flake8 with the flake8-docstrings and the flake8-polyfill. Feel free to add make lint as a target to execute the linters. Try to be as pythonic as you can, regarding to the code style. Try to avoid silencing the linter warning messages, try to rewrite your code so it passes. Try to avoid creating a "friendlier" cofiguration file for the linters. Try to be as hard and pythonic as possible. README.md The grading of your game will start in the README.md. It is essential that this file contains what is needed for each of the requirements above. Presentation video You are to record a video presentation of your project where you show how your project implements the features and fullfills the requirements. You should also present a few highlights from your source code and elaborate on why you feel the code is good/bad. The video scene should contain a cam where your face is visible. Start your video by clearly stating your name, acronym and display an id card. The tool OBS is a free and opensource tool you can use to record the presentation video. The video should be 5-7 minutes. You can save the video somewhere online and link to it. Services like YouTub provides for sharing not public video by links. The teacher might reach out to you to ask for a oral examination, one-on-one, if deemed needed on a case by case. Record one video per group. Grading This assignment is graded PASS or FAIL on a group basis. Individual grading might happen on a case by case basis whenever feel needed. To achieve PASS the requirements should be implemented to a level of good quality on all levels. Self test Before you submit you should (at least) perform this self test to ensure your application is ready for delivery. Can you install a fresh copy of the game from the zip-file/repo and run the game from the instructions in the README? Does the project work when using bad inputs? Does the project pass for codestyle and issues when using pylint? Execute the unit tests and validate you have sufficient coverage. Can you regenerate the documentation for the project? Can you regenerate the UML documentation for the project? Is there a RELEASE.md and a LICENSE.md? Do the project fulfill the overall requirements? Submission Submit your code to Canvas as a zip-file and name it game.zip. You may also add a link to the repo, if you are using such a feature. Record the presentation video and add a link to it on Canvas by using a comment on your original submission. You may do this the next day after the actual deadline. Opposition You will receive a project from another student group and your group shall analyse that project and provide feedback of it. In your review you shall focus on performing the self test explained above. You should also provide answers to the following questions. If it is a git repo, analyse the commits and tags, are they sufficient? What are youre feeling of the overall quality of the game? What are youre feeling of the overall quality of the code and organisation of classes and modules? What are youre feeling of the overall quality of the build environment, for example make install test coverage doc uml or equal build tool? Write your summary in a pdf-document and submit it onto Canvas. The document should contain a first page where you state the name of your group members and the project name and the group members for the project you reviewed.