Hello, if you have any need, please feel free to consult us, this is my wechat: wx91due

INFO1113 Assignment 2 - Citadels

Task Description

You are encouraged to ask questions on Ed under the assignments category if you are unsure of the specification – but staff members will not be able to do any coding or debugging in this assignment for you. As with any assignment, make sure that your work is your own, and do not share your code or solutions with other students.

Working on your assignment

Gameplay

Initial Setup

Example output in the command line during this phase:

Enter how many players [4-7]:

District Cards

Character Cards

There are 8 character cards. Each has a special ability (refer to page 14 of the official rules). They perform their turns in the order provided:

At the beginning of this phase, the 8 character cards are shuffled and game randomly discards 1 face down, and depending on the number of players, some also face-up (see Figure 1 below). The King cannot be discarded face-up, if this occurs, the game should try again with another random selection. For example:

Each player will take their turn choosing a character in order, from the remaining character cards handed to them by the previous player. The human player is always Player 1. So in the previous example above (5 player game), Player 5 would choose their character card next, and then Player 1 (human player) would choose, then Player 2, then Player 3.

Turn Phase

On each player’s turn, unless their character has been killed, you must give that player the option of choosing to receive 2 gold, or drawing 2 cards and choosing 1. Then the player may build a district, spending their gold, as long as they can afford to do so with the gold they have. (Each character can only build 1 district per turn, except for the Architect which can build up to 3.) Players can also perform their character’s special ability on their turn (they do not have to use the special ability). For the Assassin and Thief, they are prompted at the start of their turn for who they want to kill or steal from. Characters that receive additional gold for districts in their city will also have this happen automatically at the beginning of their turn, including the merchant who receives 1 additional gold. The King receives the crown token even if they are killed, and that player will go first in selecting characters on the next round. Other characters (Magician, Architect and Warlord) perform their special abilities later during their turn.

For computer-controlled players, you need to incorporate logic to determine the actions a computer controlled player would take, including whether they decide to use a special ability. You may use random values to help with this decision-making, however try to give the computer controlled players some intelligence as well (for example, if they run out of cards or are running low, they might prefer selecting the Architect or Magician characters. And if they have enough gold to build a district, they will build the most expensive one they can. If they don’t have any good districts, they might also prioritise choosing Magician or Architect to make use of those special abilities). 

Your program must provide meaningful feedback to the user and not crash if invalid parameters are entered for any command. If an invalid command is entered, or help, display the help message which describes all commands and information about them. Any time the user is required to type something, you should describe the options [option1/option2] etc. If multiple commands are available, you can wait for the user to type with a prompt: ( ‘>’ sign).

The main general commands that should be available are listed below:

Game End

The player with the most points wins. If there is a tie, the tied player who revealed the character with the highest-numbered rank in the last round wins.

Your program should display a detailed score calculation breakdown for all players and then congratulatethe winning player.

Saving

Application

Marking Criteria (16%)

To submit, you must upload your build.gradle file and src folder to Ed. Please also include sample JSON save files that you have tested with your program. Do NOT submit the build folder (unless you only include the build/reports/ folder which contains the results of your testing and code coverage, and build/libs folder which contains your jar file). Ensure src is in the root directory with the other files, and not part of a zip, then press MARK. Submit your report and UML to canvas.

Demo / Viva (2%)

The demonstration will also involve you showing and explaining the codebase you wrote for Assignment 1 and may involve questions from your tutor about that.

Final Code Submission (8%)

Testcases (3%)

Ensure your test cases cover over 90% of execution paths (Use jacoco in your gradle build) – average ofbranches and instructions. Ensure your test cases cover common cases. Ensure your test cases cover edgecases. Each test case must contain a brief comment explaining what it is testing. To generate the testing code coverage report with gradle using jacoco, run “gradle test jacocoTestReport”.

Design, Report, UML and Javadoc (3%)

You will need to submit a UML diagram in PDF form to Canvas to provide a brief graphical overview of your code design and use of Object Oriented Principles such as inheritance and interfaces. Markers will use this to determine whether you have appropriately used those principles to aid you in your design, as well as figure out whether more should have been done. A general guideline is that markers will be looking for some use of inheritance or interfaces, how extensible the code is, and penalising repeated code. Note that you should not simply use a UML generator from an IDE such as Eclipse, as they typically do not produce diagrams that conform to the format required. We suggest using software such as LucidChart or draw.io for making your diagrams.

Your code should be clear, well commented and concise. Try to utilise OOP constructs within your application and limit repetitive code. The code should follow the conventions set out by the Google Java Style Guide. As part of your comments, you will need to create a Javadoc for your program. This will be properly covered in week 11 but the relevant Oracle documentation can be found here.

Suggested Timeline

Week 8: Familiarise yourself with gradle and the resources provided (game rules, youtube video and cards.tsv). Identify opportunities to utilise Object Oriented Design principles such as inheritance and interfaces and begin to plan a design for the codebase with regards to the classes that you will need to make. Make a rough UML diagram for your design that you can base your codebase from.

Weeks 8-9: Begin writing the actual code for the program. Start small, for example by initially creating the input loop, card deck, and player logic, then gradually add more like characters and other game elements. At the end of the week, you should have a basic version of the game with the character selection and turn phases. If confident, use Test Driven Development (writing test cases at same time as writing the code). Conduct a large amount of user testing to ensure the initial mechanics work as expected.

Weeks 9-10: Develop more gameplay features, such as the special abilities, and computer player decision logic. You should have a fairly high code coverage for your test cases at this stage. If you are noticing any questionable design decisions, such as God classes or classes that are doing things they logically should not be doing, this is the time to refactor your code.

Week 11: Finish developing the remaining features for your program, notably the save/load of game state to a json file and game end score calculation. Additionally, finish writing your testing suite. Create the UML and Javadoc for the program. Fix any remaining bugs that your code exhibits. Submit your code to Ed (by uploading the entire project and pressing MARK) and submit your UML to Canvas in PDF form.

Week 12: Demonstrate the completed program to your tutor during the week 12 lab. They will check each criteria item has successfully been completed, and may ask you questions about how you implemented it to test your understanding.

Academic Declaration

I declare that I have read and understood the University of Sydney Student Plagiarism: Coursework Policy and Procedure, and except where specifically acknowledged, the work contained in this assignment/project is my own work, and has not been copied from other sources or been previously submitted for award or assessment.

I understand that failure to comply with the Student Plagiarism: Coursework Policy and Procedure can lead to severe penalties as outlined under Chapter 8 of the University of Sydney By-Law 1999 (as amended). These penalties may be imposed in cases where any significant portion of my submitted work has been copied without proper acknowledgment from other sources, including published works, the Internet, existing programs, the work of other students, or work previously submitted for other awards or assessments.

I realise that I may be asked to identify those portions of the work contributed by me and required to demonstrate my knowledge of the relevant material by answering oral questions or by undertaking supplementary work, either written or in the laboratory, in order to arrive at the final assessment mark.

I acknowledge that the School of Computer Science, in assessing this assignment, may reproduce itentirely, may provide a copy to another member of faculty, and/or communicate a copy of this assignment to a plagiarism checking service or in-house computer program, and that a copy of the assignment may bemaintained by the service or the School of Computer Science for the purpose of future plagiarism checking.

Appendix – Further Examples