Categories
Uncategorized

CSE1IOX Intermediate Object Oriented Programming- Developing Mobile Games

Before you begin

Objectives

This is an individual assignment. Students are not permitted to work in a group when writing this assignment.

Copying and Plagiarism

This is an individual assignment. Students are not permitted to work in a group when writing this assignment. Plagiarism is the submission of another person’s work in a manner that gives the impression that the work is their own. La Trobe University treats plagiarism seriously. When detected, penalties are strictly imposed.

Submission Guidelines

Your assignment submission should be typed, not written/drawn by hand.

Submit the electronic copy of your assignment through the subject LMS.

Submission after the deadline will incur a penalty of 5% of the available assignment mark per day capped at 5 days. No assignment will be accepted after 5 days. If you have encountered difficulties that lead to late submission or no submission, you should apply for special consideration.

Background

You are working in a programming role at GreatestSoft, an organisation that has a focus on developing mobile games. You have been asked to develop the logic for a version of a card game that has aspects similar to the popular card game ‘Uno’. The working title for the game is Quattro (as it has four players).

Game Materials:

  • There are 40 cards in the pack in total
  • Cards can be of:
  • four different colours – Red, Yellow, Green, Blue; and have oa number value between 0 – 9
  • The game is played with four players.

An example selection of 5 cards could be: Blue 5, Red 7, Green 0, Red 2, Green 5

Rules for Gameplay

  1. Each player receives a set number of cards to play (for this game players will receive three cards each). These are referred to as the player ‘hand’.
  2. The remaining cards are placed in a ‘draw’ pile.
  3. The first card in the draw pile is placed in the ‘discard’ pile and its colour and number revealed. It is now the turn of the first player.
  4. The player checks the cards in their hand to see if any match against the top card of the ‘discard’ pile in terms of:

        a. The numbers of the two cards

        b. The colours of the two cards

  1. If they have a match on colour or number, the player removes the matching card from their hand, and it becomes the first (top) card in the ‘discard’ pile.
  2. If they do not have a match, they need to instead take the top card from the ‘draw’ pile and add it to their hand.
  3. Play then moves onto the next player, who works their way through steps 4-6
  4. Play continues until one player has no cards remaining. This player is declared the winner of the game.

There are numerous online videos of people playing ‘Uno’ which is a more complicated version of the game we are developing. Search ‘People Playing Uno’ and check out a couple to get a better idea of gameplay in action if you are unsure of the game mechanics. Note that unlike Uno we are not including any ‘Wild, Draw Two, Reverse, or Skip’ cards into our game.

Also review ‘Sample Gameplay’ below for a description of how a game may play out

Items to note in relation to the solution:

  • This is a text based game only – i.e. you do not have to implement any imagery of cards.
  • You can complete the solution however you like, within the following boundaries
  • You must use the class structure as outlined in the ‘Class Diagram’ below
  • You need to include the functionality as outlined Task 2 below
  • You must complete all Tasks below

Class Diagram

You have done some preliminary work and come up with the following class diagram. Note the following in relation to this diagram

  • The classes with a ‘blue’ background are active classes in this project. They will contain code for the solution that you are creating
  • The classes with an ‘orange’ background are part of a proposed future ‘expansion’ of the game.

They need to be implemented but only as a shell (i.e. they will contain no code towards your current solution)

Figure 1 Class Diagram

1: Program Design

Create a new NetBeans 8.2 Java 8 project called QuattroTest. Add the eight classes from the UML class diagram in a package called ‘quattrotest’ as shown below.

Create a class stub for each class such as below:

Add the necessary additional keywords for classes that inherit from interfaces or abstract classes

This should also be done for classes that do not have current functionality (as highlighted in the diagram above)

2. Functionality

It is expected that your solution will implement the following functionality (check ‘Rules for Gameplay’ under ‘Background’ for more context on the functionality.

Check as well the ‘Suggested Tips for Implementing for Ideas

Functionality to Implement:

  • The card game has four players
  • Only one of the players is a ‘human’ player (the remaining three players are bots)
  • The program will ask for the human player to give their name.
  • Bot players should have a name as well. This should be given to them by the program.
  • The deck of cards will consist of forty cards in total made up of:
    • 10 Blue cards numbered 0-9
    • 10 Yellow cards numbered 0-9
    • 10 Red cards numbered 0-9
    • 10 Green cards numbered 0-9
  • The order of any collection of cards must be randomized (i.e. the cards need to be shuffled)
  • Each player will be dealt three cards initially from the deck (or ‘draw’ pile)
  • The human (and bot) players will be able to view what cards they have in their ‘hand’
  • The human (and bot) players will not be able to view of what cards opponents have.
  • Once cards have been distributed to players from the draw pile, the first card from this pile is moved to become the first/top card in the ‘discard’ pile.
  • A player needs to ‘match’ the top card of the discard pile with a card they have in their hand.
  • If they have a matching card, it is selected and is then moved from their hand to become the top card of the discard pile. Play then moves onto the next player
  • If they do not have a matching card, the first card from the draw pile needs to be selected and added to their hand. Play then moves onto the next player
  • Each player should have their turn in order
  • Once any player has played their last card a message should be displayed indicating that this player is the winner of the game. The game should end at this point.
  • The human player should be asked at the start of the game what their name is
  • The human player should be provided with the following information during the game where appropriate
  • Their name
  • What cards they hold in their hand
    • What the top card of the discard pile is
    • What cards other players played
    • If other players had to select a card from the draw pile
    • How many cards the other players have in their hand
  • The human player should have some means of indicating which card they would like to play via the console
  • If the human does not enter details of a valid card to play, they should be advised to enter details again
  • If the human does not have a valid card to play, they should be able to indicate this via the console
  • If the ‘draw’ pile is exhausted (i.e. there are no more cards in this pile)
  • The top card of the ‘discard’ pile should be retained in the ‘discard’ pile
  • All other cards in the ‘discard’ pile should be moved to the ‘draw’ pile and randomized (shuffled).

Suggested tips for implementing:

  • Give each of the cards a ‘code’ to identify it i.e. Red 5 could be given the code ‘R5’ or even just a number like ‘16’. What matters is that the code is unique. This code could then be used for the human player to indicate which card they would like to play (along with other functionality)
  • Consider making use of Arraylists for the following reasons:
  • Arrays lists can be used to manage cards in the following locations
    • Hold cards in the ‘deck’ or ‘draw’ pile
  • Hold cards in the ‘discard’ pile
  • Hold the cards for individual players (i.e. each player has their own arraylist of cards)
  • Arraylists can be used to move cards
    • e. A player that has a valid card to play can have that card moved from their ‘personal’ arraylist of cards to the top of the ‘discard’ arraylist
  • e. a player than has no valid card to play can
  • Arraylists can have their contents randomized through the function Collections.shuffle(arraylistname) available through importing java.util.*
  • Use the ‘QuattroTest’ class to run and test your program frequently. It may be that much of the logic that you write for the program ends up in this class.
  • Start by creating the deck of cards making use of the ‘StandardColourCard’ class. As suggested above consider adding the created cards to an arraylist, and develop logic to move cards between a deck and draw pile as required by the game
  • From there, add in a player (Using the Player class), and develop the logic to move cards between the player hand, and the deck and draw piles
  • From there add in the logic to manage the three bot players and player turns.
  • Note the above are suggestions only – so long as all functionality is included and all directions in Tasks 1-4 are followed you can create the program how you wish.

3. Exceptions

You will need to run some checks on the validity of data been entered. It is expected that the program will throw an exception in the following circumstances:

  • If no name is entered for the human player of the game
  • If the human player makes an invalid selection when entering details of a card to play

You must have a catch block that catches these exceptions and displays an appropriate error message.

(You can use the getMessage method of the Throwable class to achieve this).

You do need to manage the exceptions appropriately i.e. the program should alert the user that an exception has occurred, and advise the user how to proceed.

4. Comments

Ensure you include appropriate commetns in your code including:

  • Purpose of classes
  • Purpose of methods
  • Explanatory notes for any potentially confusing items

5. Testing

Testing Tasks

As part of your program implementation you should test to determine how the program performs when the user makes an invalid selection when choosing a card to play (refer Task 03)

  1. What is white box testing and how would you use it to test this feature
  2. What is black box testing and how would you use it to test this feature.
  3. Describe one of the error scenarios that could unfold if a user does enter incorrect data.
  4. Design a custom Java Class to represent a custom exception for Q3. Your solution must follow best-practices from Java’s Exception class hierarchy including:
  • A default constructor
  • A one-time argument with a message
  • The getMessage() accessor method.

Note there is no need to implement this custom exception class.

Short Sample Gameplay

The following is a sample game

  • The human is asked what their name is, and enters ‘Joe’
  • The program welcomes Jane to the game.
  • Joe receives three cards
  • Red 6 oBlue 8 o Green 7
  • The program advises Joe that the top card of the ‘Discard’ pile is a Green 9.
  • Joe enters a code that advises the program that they wish to play the Green 7
  • The Green 7 then becomes the top card of the ‘Discard’ Pile
  • Player 02, one of the bot players, plays a Green 2 – Joe is advised of this
  • Player 03, one of the bot players, plays a Blue 2 – Joe is advised of this
  • Player 04 has no valid cards to play and an extra card is added to their hand – Joe is advised of this
  • Joe plays the Blue 8 and now only has one card left
  • Play continues around until it is Joe’s next turn. The top card on the Discard pile happens now to be a Yellow 6. Joe is advised of this
  • Joe plays the final card in their hand, a Red 6, and wins the game.

Extended Sample Gameplay and Output

The following is sample output of a game followed by explanatory notes

Figure 2 Sample Output- Part 01

Figure 3 Sample Output – Part 02

Sample Game Explanatory Notes

  • Line 1: Player is asked to enter their name
  • Line 3: Player has not entered a valid name and is asked to enter it again
  • Line 5: Player has entered their name (Fiona)
  • Line 7-10: Details of the cards that Fiona holds (Yellow 5, Red 7 and Blue 3)
  • Line 12-13: Details of what the top card on the ‘discard’ pile is (i.e. what card Fiona needs to match against with one of her cards)
  • Lines 14-15: Instructions for playing a card.
  • Lines 16-17: Details of the card that Fiona has played. Fiona has selected the card with a code number of 14, which is the Blue 3 (The Blue 3 now becomes the top card on the ‘discard’ pile)
  • Line 18: Information about how many cards Fiona now has in her hand (having played the Blue 3 the number of cards in her hand drops from 3 to 2)
  • Lines 20-30: Information about what is happening with the other players in the game.
  • Note that Player 2 has picked up a card on Line 20 (added a card to their hand). This would have been due to the fact that they had no valid card to play.
  • Players 3 and Player 4 both have valid cards to play (i.e. they are able to match the top card when it is their turns)
  • Note that Fiona is given information about the number of cards that each other player has, but not what these cards actually are i.e. the player can only see the cards in their own hand.
  • Lines 31-33: A summary of the cards that Fiona has in her hand prior to taking her turn (Yellow 5 and Red 7)
  • Lines 35-36: Details of the top card of the ‘discard’ pile (the last card played by Player 4 – Yellow 2)
  • Lines 37-41: Details of Fiona’s turn. Fiona has played Yellow 5 (Code 26) and now has one card in hand.
  • Lines 42-53: Information about other player turns (Player 4 has only 1 card left and is on level terms with Fiona)
  • Lines 54-56: Detials of the card that Fiona has at the start of their turn (Red 7)
  • Lines 57-58: Details of the top card (Yellow 0)
  • Lines 59-62: Fiona is unable to match the top card (Yellow 0) with the Red 7 that they have. Fiona enters a Code of 0 to pick up a card.
  • Lines 63-67: Details of the cards that Fiona now has (Red 7 and Blue 0. The Blue 0 is the card that has been picked up)
  • Lines 66-74: Information about Player 2 and Player 3 turns
  • Lines 75-77: Player 4 is able to play their last card. With no more cards Player 4 is declared the winner and the game is over.

Submission Requirements

When you have completed, submit your work on the LMS system. You should submit the following:

Task Number

File Name

Description

Tasks 1-4

xxx_cse1iox_assessment3._code.zip

Implementation tasks

Task 5

xxx_cse1iox_assessment3_docs.docx

Documentation tasks

Assessment Marking Criteria

Student Version

Requirement

Criteria

Points

Program

•  All eight classes have been created as part of the package

2

Design

•  Abstract class and Interface have been created as expected

Inheritance

•  The following classes have been correctly implemented to

2

inherit as expected (including from SpecialAbility interface

as outlined in Class

diagram (Figure 1))

o

ColourCard

o

WildCard

o

StandardColourCard

o

SpecialColourCard

Polymorphism

•  The following classes contain overridden methods as

2

required

o

ColourCard

o

WildCard

o

StandardColourCard

o

SpecialColourCard

Constructors

•  Constructors for all classes have been implemented as

2

expected:

•  The constructors in the following classes make use of the

super keyword to call their parent constructor

o

ColourCard

o

WildCard

o

StandardColourCard

o

SpecialColourCard

12

© Didasko 2019. All rights reserved.

12

Methods

•  Getter and Setter methods have been implemented for all

2

non-constant variables

Functionality

•  The functionality as laid out under Task 2 has been included

8

and Logic

and is logically correct

Output

•  Output is laid out in a format that is easy to interpret

4

Exception

•  Exceptions for the following are managed as expected

4

Handling

o  Non-entry of name by human player

o  Entry of invalid card details by human player

Comments

•  Comments are included that cover

2

o

Purpose of classes

o

Purpose of methods

o  Explanatory notes for any potentially confusing items

Explanations

•  Explanations of the following are correct

6

o

White Box Testing

o

Black Box Testing

o  Error scenario on entry of incorrect data

Java Custom

•  Custom Exception Class has been outlined as expected

2

Exception

including

Class

o

A default constructor

o  A one-time argument with a message

o  The getMessage() accessor method.