Assignment Submissions

This project will be submitted in two parts. Both parts of the assessment are equally important for the successful completion of your project, so it is essential that you     understand the requirements of both parts before you start.

● Assignment 2: Memory Match (Part A: Project Plan) Due Date: August 12, 2022, 11:55pm (Week 7)

Marks: This assignment will be marked out of 100 points.

Weighting: 10% of your final mark for the unit.

This  assignment  is  the  first  part  of  a  larger  project,  which  you  will  complete  in Assignment 3. This task consists of your project planning documentation. It will include details of the requirements & analysis of your program, including UML Class diagrams.

The  purpose  of  this  assignment  is  to  get  you  comfortable  with  planning  a  C++ programming project for Assignment 3. The task is detailed later in this assignment specification, as are the specific marks allocation.

● Assignment 3: Memory Match (Part B: C++ Project Implementation) Due Date: September 12, 2022, 11:55pm (Week 10)

Marks: This assignment will be marked out of 100 points.

Weighting: 20% of your final mark for the unit.

This assignment consists of your implementation of your project, as outlined in your Project Planning document (Assignment 2).

Your project must follow your project plan and must be submitted as a CLion, Visual Studio or Xcode project, including all header and .cpp files, and any appropriate text files to ensure the program compiles and runs.

This assignment consists of one Application file and associated custom Class files. The purpose of this assignment is to get you comfortable with designing and implementing basic   multi-class   C++   programs.  The  task   is   detailed   later   in  this   assignment specification, as are the specific marks allocation.

Late submission:

●    By submitting aSpecial Consideration Form or visit this link: https://lms.monashcollege.edu.au/course/view.php?id=1331

●    Or, without special consideration, you lose 5% per day that you submit late (including weekends). Submissions will not be accepted more than 14 days late. This means

that if you got Y marks, only (Y - Y×n×0.05) will be counted where n is the number of days you submit late.

●    Assessment items will not be accepted after more than 14 calendar days unless a   Special Consideration application has been approved. This 14-day time frame does not apply to assessments due in Week 11 or Week 12, instead the last day will be  Friday of Week12.

Plagiarism: It is an academic requirement that the work you submit be original. If there is any            evidence of copying (including from online sources without proper attribution), collaboration,           pasting from websites or textbooks, zero marks may be awarded for the whole assignment, the unit or you may be suspended or excluded from your course. Monash Colleges policies on plagiarism,      collusion, and cheating areavailable hereor see this link: https://www.monashcollege.edu.au/__data/assets/pdf_file/0010/17101/dip-assessment-policy.pdf

Further Note: When you are asked to use Internet resources to answer a question, this does not mean copy-pasting text from websites. Write answers in your own words such that your              understanding of the answer is evident. Acknowledge any sources by citing them.

Submission Instructions:

This project will be submitted in two parts:

● Assignment 2 – Part A: consists of your project planning documentation.

This  document  will  include  an  outline  of  your  program  structure  and  UML  Class diagrams.

The assignment must be created and submitted as a single Word or PDF document to the Moodle site. This document must clearly identify both your Name and Student ID to facilitate ease of assessment and feedback.

Your document file MUST be named as follows: “YourFirstNameLastNameID_A2.docx” or “YourFirstNameLastNameID_A2.pdf” . This file must be submitted via the Moodle assignment submission page.

The document should contain the project plan and the UML diagrams. You can use Microsoft Visio to draw the UML diagrams or you can use any other software, provided that the diagrams are included in your submitted document.

Explicit  assessment  criteria  are  provided,  however  please  note  you  will  also  be assessed on the following broad criteria:

●   Detail of a proposed project plan for the overall project.

●   Creating accurate and complete UML diagrams.

●   Applying a solid Object-Oriented Design (OOD) for the overall project

●   Using appropriate naming conventions, following the unit Programming Style Guide.

Assignment 3 – Part B: consists of your implementation of your game project.

Your project must follow your project plan and must be submitted as a CLion, Visual Studio or Xcode project, including all header and code files, and any appropriate text files to ensure the program compiles and runs.

You may complete the tasks in your preferred IDE, however you MUST create a CLion, Visual Studio or Xcode project in order to submit. Your project folder must be identified by using your name and assignment number, such as YourFirstNameLastNameID_A3 .

The entire project folder must then be zipped up into one zip file for submission. The zip  file MUST be  named “YourFistNameLastName_A3.zip” .  This  zip  file  must  be submitted via the Moodle assignment submission page.

Explicit  assessment  criteria  are  provided,  however  please  note  you  will  also  be assessed on the following broad criteria:

●   Meeting functional requirements as described in the assignment description

●   Demonstrating a solid understanding of C++ concepts, including good practice

●   Demonstrating  an  understanding  of  specific  C++  concepts  relating  to  the assignment tasks, including object-oriented design and implementation and the use of Pointers

●   Following the unit Programming Style Guide

●   Creating solutions that are as efficient and extensible as possible

●   Reflecting on the appropriateness of your  implemented design and  meeting functional requirements as described in the assignment description

NOTE! Your submitted files must be correctly identified and submitted (as described above). Any  submission that  does  not  comply will  receive an  automatic 20 marks penalty (applied after  marking).  For assignment 3, your  CLion/Visual Studio/Xcode

project should include all .cpp and .h files.

If you have any questions or concerns please contact your tutor as soon as possible.

Assignment 2: Memory Match (Part A)

In this assignment, you are to implement a computer-based variant of the card game Memory Match. This is a card game mainly for two players who play against each other but it can also be played by a single or multiple player. The basic game of Memory match  is  a  simple  press-your-luck  game  with  one  winner.  Players  score  points  by catching pairs. The player with the highest points is the winner!

You can watch a video on how to play here:

https://www.youtube.com/watch?v=492bM_dhdR4

or online rules here:https://www.classicgamesandpuzzles.com/Memory.html

In your version, for the basic assignment you only need to implement a 2-player game. For Part A of the assignment you will focus on the planning of the project. In Part B you will focus on creating the various interactive objects in the game and program the player interactions.

Basic Game Play

In this program, the computer (dealer) controls a deck of cards. The deck is made up of 16 cards for the basic game having 2*8 cards i.e. 2 cards with the same word on

them. This is NOT a standard deck of playing cards.

The basic game play is as follows:

● Initialize: Shuffle the deck and lay out the cards face down in a 4*4 matrix on the table. Make sure the cards are not touching each other. They need to be flipped over without disturbing any cards around them.

● To start the game, select a random player to go first.

● On First Player’s turn: The player gets two choices:

o Choose: The First player chooses a card and carefully turns it over. Then the player selects another card and turns it over. If the two cards are a matching pair, for example two cards with the number [2] then they take the two cards and start a stack.

▪     If you get a pair, you score points.

▪     If not, then the cards are turned back over and the turn goes to the next player.

o Pass: You can surrender (pass) instead of taking a card. And the turn will go to the next player.

● Match: When you get a match, you score. And the player is awarded another turn for making a match and goes again.

o    For example, if you catch the correct pair, you score 10 points.

o On Second Player’s Turn: The next player chooses the card and turns it over. If it is a match for one of the cards the previous player turned over then they try  to  remember  where  the  matching  card  was  and  turn  it.  If  they  are successful at making a match they

place the cards in their stack and choose another card. If the first card turned over was not a match for one previously turned over the player selects  another  card  in  an  attempt  of  making  a  pair.  If  they  are unsuccessful in making a match they flip the cards back over and play is passed to the next player.

● Ending the Round: A player’s turn is not over until they are unable to make a matching  pair  or  decide  to  pass.  The  game  continues  until  all  the  cards  are matched.

● Reshuffling: As soon as all the cards are played, the round is over. Just shuffle and continue the next round.

● Winning the Game: There is only one winner. Once all the cards have been played and the player selects not to play again then the player with the highest score is declared as a winner.

Note: There are many variations to this basic game, some of which you will be able to implement as a part of the extra functionality for your assignment.

Project Plan

Having a clear plan for your project before you begin coding is essential for finishing a successful  project  on time  and with  minimal  stress. So,  part  of this  assignment  is defining what will be in your project and what you need to do to actually develop it.

Important: \on 山n2车 以\2o \6以q 车p6 \6dn\\6山6\车2\o\；22\?\山6\车 3 \\ o\q6\ 车o p6 以p\6 车o co山b\6车6 车p6 qocn山6\车以车\o\ \6dn\\6q\o\；22\?\山6\车 S.

The documentation you must submit will include the following:

✓ A description of “How to Play”

This will be the information you display on the opening screen of your game to inform the player what they need to do in order to play and win the game. Do not just copy the game play description above, make your own description.

Note: This description must be saved as a text file and read into your game when the program begins. You can also use this as a convenient way to display “help” if the player asks for it.

✓ A development outline of your game

Using a simple outline format (numbered or bullet points) state the main actions that the program will have and then, as sub-points, state the things you will need to do to make that happen.

The outline structure should contain all the elements of your game, as this is a high- level description of your approach to the development of your program. You should include at least the following headings and provide examples of what happens under each section.

# The game setup (everything that happens before the game starts)

# The player’s turn (the sequence of events that happen during a turn)

令 Processing player input (include each of the commands your player can use)

令 Providing feedback to the player (in response to the player’s interactions)

令 The end game conditions (include all win and lose conditions)

令 Additional Features included, if any – see Assignment 3

令 Outline the functionality of all your game classes – see Assignment 3

Here is an example to get you started with your project outline:

令 The Game Setup

▪  Display an overview of the game rule so the player knows what to do to win.

o read this information from a text file.

▪  Initialise the game elements:

o add the player – ask for the player’s name, set default variables

o all the other things that will happen during initialisation including

●   creating the hazards and the game world

●   initialising other game variables (list them here)

As you can see, you only have to describe the actions the program will take, not the code, for the outline. The idea here is to give you a starting point for when you start writing your code as you can use this as a checklist of the things you need to include

✓ UML Diagrams

UML diagrams are designed to make

structuring

your program is easier. How to create

them will be covered in class, but the

general structure is shown here – see

Assignment 3 for more details about

classes.

You will need UML diagrams for each

of the classes you include in your game

– at least a Player, Location and

Application (main) class.

Assignment 2: Marking Criteria [100 marks in total]

1. Requirements and Analysis Document (Project Plan) [70] 1.1.  Description of the rules (the introduction to your game) [8]

1.1.1. Description of how to play the game [4]

1.1.2. Clear description of all the rules [4]

1.2.  A development outline of your game contains all the elements (from Part B) [12] 1.2.1. The game setup (everything that happens before the game starts) [1]

1.2.2. The player’s turn (the sequence of events that happen during a turn) [2] 1.2.3. Processing player input (include each of the commands your player can use) [3] 1.2.4. Providing feedback to the player (in response to the player’s interactions) [1] 1.2.5. The end game conditions (include all win and lose conditions) [1]

1.2.6. Additional Features included, if any – see Assignment 3 [1]

1.2.7. Outline the functionality of all your game classes [3]

1.3.  Each section is broken into logical tasks [15]

1.3.1. Each element of game outline is broken down into sub tasks [10] 1.3.2. The tasks are explained in correct program flow [5]

1.4.  Tasks are performed in a logical order [15]

1.5.  Task descriptions given provide sufficient detail [20]

2. UML Diagrams [20]

2.1. Correct structure used (Name, Attributes, Behaviours) [4]

2.2. Included the correct designations for public (+) and private (-) data [8] 2.3. All variables and functions have meaningful names [8]

3. Report Structure 10] 3.1. Title page [1]

3.2. Table of Contents [1]

3.3. Page number [1]

3.4. References and in text citations [2]

3.5. Grammar punctuation and spelling [2]

3.6. Overall structure (layout), presentation and formatting [3]

Assignment 3: Memory Match (Part B)

You are to implement the memory Match card game you started in Assignment 2 by creating a Visual Studio Project using your project plan as described in your previous submission.

Your completed Memory Match card game must demonstrate the following:

You MUST implement your program using the following classes, as a minimum, you may include more (as appropriate for your game design):

● Player class: holds the player’s details including their name, current score and a collection of cards (the player’s stack in the game).

● Card class: holds the card’s details including its value, a visual representation of the card and its status – in the deck or paired.

● Application file: holds the main() function and controls the overall flow of the game.

You may include other relevant attributes and behaviours to these classes, as identified in your project plan.

●   The Player must be able to do the following:

●   assign a name which is requested at the start of the game and used in the feedback given

●   decides to take a card (choose) or pass and see appropriate feedback as a result

●   continue playing until the round ends – someone gets a pair or pass

●   quit the game at any time – during or after a game

●   The Cards in the game should have the following characteristics:

●   have a value any 8 numbers in a pair

●   if the card is paired by the player, it should be unable to be used again

●   display a visual representation (eg: [1] = a 1 card [2] = a 2 card) when turned over by a player

●   The Game Application must do the following:

●   display the “how to play” information at the start of the game

●   create the players and a deck of 16 cards consisting of 2*8 eight cards in pairs of matching values.

●   display an appropriate and uncluttered user interface providing  relevant information to the player at all times

●   ask for and allow the player enter an option to choose a card or pass

●   display the updated player score after each card is dealt – all unmatched cards are visible at all times

●   terminate the game (a player wins) when all the cards in the game are matched

●   provide player stats at the end of the game (wins, loses and score)

●   the player should be able to QUIT the game at any time

Program Reflection

You must also provide a 300-word written reflection of your object-oriented design and how well you believe it was to implement. You should cover the following areas:

●   Discuss why you designed it the way you did.

●   Why did you create your classes that way?

●   How does this reflect an OO design or approach?

●   Discuss how well you were able to code it

●   Highlight any issues you found once you tried to implement your design.

●   How did you resolve these issues?

●   If you were to do this project again, discuss how you might change your design to make your solution easier to implement, more efficient, or better for code reuse.

This must be a Word or PDF document which must be included in the same folder as your *.sln file. Your document file MUST be named as follows:                                            “YourFirstNameLastNameID_A3.docx” or “YourFirstNameLastNameID_A3.pdf” .

Extra Functionality

The marking criteria indicates that you should make some individual additions to this in order to achieve the final 20% of the mark.

Following is a list of additional features you can include, with the maximum number of marks [x] you can earn for each one. You may implement one or more features from the list, but you will only score up to the maximum of 20% of the total assignment marks or 20 marks.

You should aim to add some additional creative elements to the gameplay, as well as advanced object-oriented design elements or advanced use of pointers.

1.  The player can set the number of cards that they want to play with. [2]

2.   Use  chips  for  score.  Each  player  starts  with  4-12  chips  (2x  the  number  of players). When a player is not able to find a match, he pays one chip to every player. Once a player loses all their chips, they are out of the game. The last player with all the chips is the winner. [3]

3.  You could use any other random formula for calculations. The formula must be given in the instructions or game rules. [3]

4.   Display the cards  using ASCII art. You can  use different  images  related to a theme or “pip” patterns for the numbers. [5]

5.  Allow the game to be played with different values such as words, colours or images. [4]

6.   Create a Hand class to hold all the details of each player’s stack of matching cards for each round. A player’s hand is emptied at the start of each round. The Hand class must be incorporated into the Player class. [5]

7.   Continuous  Memory  Match  alternative game  play  option. The  players  must select which version of Pairs (such as numbers, words or colours etc.) to play at the start of the game. This version is almost the same as the basic one, but it is a single  long  round,  rather than several short ones. When all the cards are matched  then  also  the  player  can  select  to  play  again  but  with  increased difficulty such as next level with more cards or next level with words etc. [10]

8.  Allow the game to be played with one or more computer players. The player can  select the  number  of opponents to  play  against. The  computer  players should make reasonably intelligent choices based on the visible cards in the other player’s cards. [10]

9.   Implement a more sophisticated AI for the computer players. You may create different player types, each with their own strategies for playing, such as an easy player, a cautious player, an

aggressive player, etc. The human player can select the opponent’s difficulty level and number of their opponents at the beginning of the game. [10]

You  certainly  do  not  have to  implement  all  of the  above to  earn  marks for  extra functionality. Just remember the maximum number of marks you can earn are given in [x]. It is up to you!

Assignment 3: Marking Criteria [up to 100 marks in total]

Does the program compile and run? Yes or No

A 50 marks penalty will be applied for a non-compiling program.

1. Class Design [15] 1.1.Player Class [5]

1.1.1. Has an appropriate header file? [2]

1.1.2. Required data members and member functions using meaningful names [1]

1.1.3. Contains only aspects that relate to a “player” (has no data members or member functions that are not directly related to a Player) [2]

1.2.   Card Class [5]

1.2.1. Has an appropriate header file [2]

1.2.2. Required data members and member functions using meaningful names [1]

1.2.3. Contains only aspects that relate to a “Card” (has no data members or member functions that are not directly related to the Card) [2]

1.3.    Game Application [5]

1.3.1. Has an appropriate header file [2]

1.3.2. Has appropriate variables and functions using meaningful names [2]

1.3.3. The main() function has appropriate function calls to keep it uncluttered [1]

2. Functionality [35]

2.1. Game set up including: displaying “how to play” information, initialising the player and game variables, creating a collection of cards, etc. [5]

2.2. Implementation of a clear and uncluttered User Interface display [5]

2.3. Successful implementation of the basic game mechanics (choose and pass) [5]

2.4. Successful implementation of dealing and monitoring the cards of all players [5]

2.5. Successful implementation of Implementation score tracking and updating as required [5]

2.6. Successful implementation of action processes and feedback displayed to the player [5]

2.7. Appropriate end game conditions triggered [5]

3. Quality of Solution and Code [20]

3.1.Does the program perform the functionality in an efficient and extensible manner? [12]

3.1.1. Appropriate use of functions and function calls [1]

3.1.2. Appropriate use of data types [1]