IT/SD MASTERS TEAM PROJECT 2019-20 Top Trumps Java Game This assignment has a weighting totalling 100% in your grade for the course. Further details are provided in ‘Submission’. You should use programming and database techniques taught in Programming and Database Theory and Applications. Context Top Trumps is a simple card game in which decks of cards are based on a theme. For example, race cars, dinosaurs, and even TV shows like ‘The Simpsons’. Within a deck each card represents an entity within that topic (e.g. T-Rex for dinosaurs or Bart Simpson for the Simpsons). Within a deck each card has the same list of characteristics. For example, dinosaurs can have a height, weight, length, ferocity, and intelligence. Each card has a value for each characteristic of the deck. The objective of the game is to ‘trump’ your opponent by selecting a category (e.g. intelligence) and having a “better” value for your card than the opponent does in their current card. ʹ Gameplay is as follows: x There must be at least two players. The deck of cards is divided between the players. The first player takes their topmost card and selects a characteristic. The value of that characteristic is compared against the value for the same characteristic in the other players’ top card. The player with the best value for that characteristic wins the round and the winner takes all the cards from that round (including their own) and places them at the back of their deck. If there is a draw the cards from the round are placed in a new communal pile and a new characteristic is selected by the same player from the next card. The winner then takes the cards from the round and any in the communal pile. The winner of a round maintains the choice of category until they lose, then the choice moves to the next player. Players lose the game when they have no cards left; the player left with all the cards is the winner of the game. Aim The aim is to build a computer program to allow a user to play top trumps against one or more AI opponents given a deck. The program should have two modes: x Command Line Mode: The game is played only through command line input and output. In this mode, only one game can be plaLJed at a time͘ This mode should be selected ǀia a ͚-c͛ flag ǁhen starting the program͗ o java -jar TopTrumps.jar -c x Online Mode: The game should be hosted as a web service, comprised of a REST API that provides remote access to the core game functionality and one or more web-pages that enable a user to play the game. In this mode, multiple users should be able to play the game concurrently (e.g. in different Web browser tabs). This mode should be selected ǀia a ͚-o͛ flag ǁhen starting the program͗ o java -jar TopTrumps.jar -o Functionality In both modes, the program needs to: x Enable a user to play a game of top trumps with a deck that was loaded in when the program started. x Store the results of past games played in a database as well as visualize that information to the user on- demand. In command line mode only: x Write a ͚test log͛ to file that contains snapshots of the program͛s state as it runs. We discuss each of these requirements in more detail below: Playing Top Trumps The program should implement the top trumps game as described in the Context section above. You can make the following assumptions to simplify the implementation. Do not add additional unnecessarLJ functionalitLJ͘ This is ͚gold- plating͛ and ǁill not result in a better grade͘ If in doubt͕ consult the course co-ordinator. x There should be one human player and up to 4 computer players (AIs) x If a deck does not divide equally between the players, then some players may have less cards. For example, if there are 3 players and 40 cards, then two players receive 13 cards and one player receives 14. x A deck has 5 criteria and the criteria are always positive integers between 1 and 50 (inclusive) x A higher number is always better for any given characteristic x There are 40 cards in a deck.txt file. x The first player should be selected at random x A draw won’t continue until the point where there are only cards in the communal pile ʹ you do not need to deal with this programmatically, just assume that should this happen you are not expected to deal with it The deck we will be using is stored in a text file called ‘StarCitizenDeck.txt’. The first line of the text file should contain a list of the categories in the deck, separated by a space. All decks should have a ‘description’ category to label the individual cards. A description within a deck can be assumed to be unique and a single word. The subsequent lines contain details of one card. You can assume the order of the categories from the first line align with 3 the values provided for the cards and that all cards have a value for all categories in a deck. You can assume that all categories are single words. For example, in a dinosaur deck (numbers bear no resemblance to reality): description height weight length ferocity intelligence TRex 6 6 12 9 9 Stegosaurus 4 3 8 1 8 Brachiosaurus 12 8 16 2 6 Velociraptor 3 5 5 12 10 Carnotaurus 5 6 7 9 8 Iguanodon 2 2 3 1 9 Megalosaurus 9 9 8 6 9 Oviraptor 8 7 4 3 2 Parasaurolophus 7 7 1 3 4 Ornithomimus 10 9 8 7 5 Protoceratops 9 5 4 7 10 Riojasaurus 6 1 4 7 7 Saurolophus 7 1 10 7 8 Styracosaurus 7 3 4 1 1 Xiaosaurus 10 6 5 7 2 and so forth ʹ the star citizen-based deck is provided with the Template Package that can be downloaded from Moodle. The program must first load all card details from the deck and shuffle them (randomly order them). The program should then deal the cards between the players. The user should then be shown the detail from their top card (note there is no need to visualise this in a complex manner, the card details can be shown in text) and the first player is randomly selected. If the player is an AI player it should select a category for play, if the user is the first player they should be allowed to select a category to play the round. The game play should then proceed as detailed in the section Context. Persistent Game Data Upon completion of the game, the user should automatically write the following information about the game play to a database: x How many draws were there? x Who won the game? x How many rounds were played in the game? x How many rounds did each player win? You should select one team member͛s database on the LJacata serǀer͕ from the Database TheorLJ and Applications course, to write to. It is important you do not remove the username and password from the final code, as this allows us to test the software. You should also provide details of this database (username, database name and password) in the report. There should also be possible, so long as a game isn’t currently in progress, for the user to connect to the database and get information about previous games. This should include the following: x Number of games played overall x How many times the computer has won x How many times the human has won x The average number of draws x The largest number of rounds played in a single game These values should be calculated using SQL. Test Log In addition to the functionality described above, you should implement the following to allow for program debugging when in command line mode only͘ When the program is started͕ if a ͚-t͛ flag is set on the command line, then the program should ǁrite out an edžtensiǀe log of its operation to a ͚toptrumps͘log͛ file in the same directorLJ as the program is run, e.g.: x java -jar TopTrumps.jar -c -t If a toptrumps.log file already exists, your program should overwrite that file. Your program should print the folloǁing information to that file͕ separated bLJ a line containing dashes ͞———-͞ at the appropriate times as mentioned below: x The contents of the complete deck once it has been read in and constructed x The contents of the complete deck after it has been shuffled x T
he contents of the user͛s deck and the computer͛s deck;sͿ once theLJ haǀe been allocated͘ Be sure to indicate ǁhich the user͛s deck is and ǁhich the computer͛s deck;sͿ is͘ x The contents of the communal pile when cards are added or removed from it x The contents of the current cards in plaLJ ;the cards from the top of the user͛s deck and the computer͛s deck(s)) x The category selected and corresponding values when a user or computer selects a category x The contents of each deck after a round x The winner of the game Command Line Mode When started in command line mode, the program should ask the user whether they want to see the statistics of past games (see the Persistent Game Data sectionͿ or ǁhether theLJ ǁant to plaLJ a game͘ The user͛s choice should be obtained from standard in (System.in). If they select to see statistics of past games, the program should print the associated statistics to standard out (System.out) and then ask the same question again. If they select to play a game, a game instance should be started, and the core game loop initialized. For each round, the round number, the name of the active player and the card drawn by the player should be printed to standard out. If the user is the active player, then it should ask the plaLJer to select a categorLJ͕ and obtain the user͛s choice from standard in͕ otherǁise the AI player should select a category. The program should then print to standard out the selected category, who won (or whether it was a draw), the winning card and whether the player has been eliminated (they have no cards left). Rounds should continue to be played until a winner is determined (only one player has cards left). Once the user has been eliminated, the remaining rounds should be completed automatically (without user input). At the end of the game, the overall winner should be printed, and the Persistent Game statistics should be updated. The user should then be asked if they want to print the statistics of past games or play another game. An example of the command line output for the program is proǀided in the ͚CLI͘edžample͘tdžt͛ file on Moodle͘ Online Mode Online mode is an extension to the command line mode that provides a version of the game that users can play through their Web browser. A Web application has two main components. First, a back-end Application Programming Interface (API) that provides remote access to the game functionalities (e.g. starting a new game, drawing cards or getting players/cards for display). Second, one or more webpages that use the back-end API to enable the user to play the game. In this case, each web page should be comprised of HTML elements that are displayed and Javascript functions that connect to the API. The webpage design is down to you, but it should display the following: x Upon loading the web page, the user should be presented the option to view overall game statistics (as detailed previously), or play a single game. x During game play, the GUI should display the contents of the user͛s top card and͕ ǁhen theLJ are the actiǀe player, allow the user to select a category to play against the computer. x The GUI should clearlLJ indicate ǁho͛s turn it currentlLJ is͕ and onlLJ alloǁ the user to select a categorLJ ǁhen it is their turn x Once the category has been selected for a round and the values compared, the GUI should display the values of the category for each player and highlight who won the round. x If a draw should occur, the user should be notified of this. x The GUI should contain an indication of how many cards are in the communal pile x The GUI should contain an indication of hoǁ manLJ cards are left in the user͛s deck and in the computer͛s deck(s) x When the round played results in the game finishing, an indication of the overall winner should be presented and the database should be updated with the statistics of the game as previously described A video of an example website is provided in Moodle. Development Working in a team of 4 or 5 students, you are required to design and implement a Java program with the above functionality. Read this entire document carefully before starting work on the design and implementation of your program. This will ensure that you understand exactly what is required. x The project should be developed using Scrum, with 2 sprints each lasting 2 weeks. Your program design should use the MVC (ModelʹViewʹController) architecture, as explained in the Programming course. x Do not be tempted to add functionality that is not actually required (gold-plating). For example, you can assume that the input text-file is correctly formatted, so you need not waste time with data validation. You will not get a better grade for gold-plating. x Fine details of the website design (colour scheme, font size, etc.) are not important. However, a design that addresses usability issues, and how they impact on functionality, is important. Consider, for example, a website in which the text fields have no labels beside them; the program might work, and have all the required functionality, but it is not very usable, since the user has to guess what should be entered into each text field! x You will need to share code between members of your team. The Software Engineering course will likely introduce techniques for managing code, it is recommended that you use them. x If your team has difficulty meeting the deadline, it is better to submit a working program that omits some of the functionality, rather than a non-working program that attempts all the functionality. x After submission your program will be tested, so it is particularly important that your program does not refer to the absolute location of the deck data file. When testing your program within Eclipse, store the deck data file in the current working directory. x Teams are required to build on top of the provided Template Package during development. As the final step of your development, you are required to create a runnable jar-file named TopTrumps.jar (using Eclipse, as explained in Programming). Template Package A software template package is provided that contains a program skeleton for teams to start with. All teams must use this template package as the basis for their implementation. The Template Package provides: x Maven configuration, enabling automatic importing of libraries for creating web services x Basic reading of command line flags allowing the user to select CLI or Online mode x A Web service that can be run out-of-the box with examples The Template Package uses the Maven software project management and comprehension tool to import other libraries it needs to run. In this case, it imports two main libraries: x Dropwizard (http://www.dropwizard.io/1.2.2/docs/) for hosting the Web service Instructions for compiling and running the Template Package are provided in the Launch Lecture Slides available on Moodle. Submission Your team must submit a single zip-file containing the following items: x your group report (see details below) x your individual Java files x your jar-file Your zip-file must be named TeamX.zip (where X is replaced with your team letter or name). Each member must upload it on Moodle using the submission slot available along with their deltas. The final submission is due by Monday 17 February 2020 at 16:30 The UniǀersitLJ͛s standard penaltLJ ;Ϯ bands per working day or part thereof, up to at most 5 working days) will be applied to any project submitted after the deadline. Each member of the team must also submit by Monday 17th of February 2018 at 16:30 in the relevant Moodle submission slot (as a zip file): x an individual report in a single .pdf with the name format surname_individualReport.pdf where surname is replaced with your surname (see details below) x a completed peer evaluation form (template available on Moodle) – if you fail to submit this then it will be assumed you distribute points equally between all team members Group Report Your report must c
oncisely summarise the current status of your program. The report should consist of: x Cover sheet: Show your team name, and the names and GUIDs of all team members. x Scanned copies of all of your user story cards, together with the estimated and actual time (in story points) spent on each story and the story priority. Include stories that did not make it into the final product. x For each sprint: the planning and review reports together with the planned and actual velocity. x The project burndown chart x Assumptions: State any assumptions you have made that have affected the implementation of your program. x Testing: Summarise how you tested your program, giving examples of test cases. x Deficiencies: State any known deficiencies, such as missing functionality or incorrect behaviour. Also suggest how you would fix these deficiencies. x Screenshots: to demonstrate functionality of your GUI , included as an appendix and referenced in the main body of the report. Your report should be a PDF document and have the name TeamXReport where X is replaced by your team letter or name. Individual Report Each team member should submit a personal reflection on using Scrum, which should include: x personal and other team member roles x lessons learned from estimating stories x stories and other requirements that were missed at the start and added later x any requirements that were hard to express in Scrum. The report should be 12 point Times New Roman and be no longer than 3 pages. Marking Criteria The marks for the submitted project are divided as follows: x Requirements Capture and Software Design: 20% x Command Line Version of the Software Product: 50% x Online Version of the Software Product: 30% A group mark is generated and then adjusted based on individual contribution for each team member.
