A class project in java to be completed

This project received 15 bids from talented freelancers with an average bid price of $164 USD.

Get free quotes for a project like this
Employer working
Project Budget
$30 - $250 USD
Total Bids
Project Description

1 Introduction

This project (Project B), and the next one (Project C), will continue with the same theme introduced in

Project A - namely, an implementation of the game of Nim. Please refer to the Project A speci_cation

for a description of the game and its rules.

In Project A, a simple, single-class Java program was created to handle Nim's core gameplay mechanics.

Although it satis_ed the requirements, it did not make use of Java's powerful object-oriented design

methodology. Since the task was relatively small scale, this did not matter too much. However, for

larger scale projects, following object-oriented principles can signi_cantly enhance the modularity of a

program's code, and can make software maintenance and the addition of features a much easier task.

This is particularly relevant here, since Project C will build on the Project B design.

In the next two projects, the objective is to design and implement a more complete version of Nim,

making full use of Java's object-oriented paradigm. In this project, the game's basic structure will be

designed, and core features will be implemented. Project C will focus on adding more advanced features

to the game.

Key Knowledge Points Covered in Project B:

1. Design of the class structure for the project requires the knowledge of UML diagrams (taught in

Week 5).

2. Implementation requires understanding of Classes (taught in Week 4 - 6) and Arrays (taught in

Week 7).

If you would like to commence earlier than week 7, you may learn basics of Arrays by yourself.

2 Requirements

The system needs to maintain a game instance. Since only one game will be active at any given time,

only a single game instance is required. The system should also maintain a collection of players. Initially,

this collection will be empty - players will need to be added in order to play a game.

A game instance needs to have the following information associated with it:

_ A current stone count


_ An upper bound on stone removal

_ Two players

The system should allow for games of Nim to be played, with the rules of the game, and the players,

speci_ed by the user.

A player needs to have the following information associated with it:

_ A username

_ A given name

_ A family name

_ Number of games played

_ Number of games won

The system should allow players to be added. It should also allow for players to be deleted, or for their

details to be edited. Players should not be able to directly edit their game statistics, although they

should be able to reset them.

The game system, called `Nimsys', is a text based interactive program that reads and executes commands

from standard input (the keyboard) until an `exit' command is issued, which will terminate the program.

If a command produces output, it should be printed to standard output (the terminal).

When Nimsys is _rst executed, it should display a welcome message, followed by a blank line. A

command prompt (a `greater than' sign, i.e., >) should then be displayed.

In following description, all command line displays are put in a box. This is only for easier understanding

the format. The box should NOT be printed out by the your program, only the contents in

the box should be printed. The command prompt is illustrated below:

Welcome to Nim


At any given time, the system can be in one of two states - either a game is in progress, or no game

is in progress. Hereafter, these will be referred to as the `game' and `idle' states, respectively. (Note:

the states are just used to explain the mechanism of Nimsys. You don't need to create a variable called

`state' in your code).

When in the idle state, the system should accept the following commands. These commands are entered

at the Nimsys command prompt. If a command produces output, it should be printed immediately be-

low the line where the command was issued. After the command has executed, a new command prompt

should be displayed. This new command prompt should be separated from the previous command (and

its output, if any) by a single blank line.

Note that in the syntax descriptions below, a term enclosed in square brackets indicates an

optional parameter. The input is assumed to be always valid, but not always correct. Valid

input suggests that entered data have the same type of the corresponding variables, e.g., String data

are entered for String variables, integer data are entered for int variables. Correct input suggests

that the entered data can be correctly processed by the corresponding command, e.g., adding an existing

user and removing a nonexistent user are incorrect input. Unless otherwise stated, you are NOT

required to check validness, but you ARE required to check the correctness of the input,

as shown in the below examples.


1. addplayer - Allows new players to be added to the game. If a player with the given username

already exists, the system should indicate this, as shown in the example execution.

Syntax: addplayer username,family_name,given_name

Example Execution:

(a) add a new user:

>addplayer lskywalker,Skywalker,Luke


(b) add a user who already exists in the system

>addplayer lskywalker,Skywalker,Luke

The player already exists.


2. removeplayer - Allows players to be removed from the game. The username of the player to be

removed is given as an argument to the command. If no username is given, the command should

remove all players, but in this case, it should display a con_rmation question _rst. If a username

for a non-existent player is given, the system should indicate that the player does not exist. The

format of these messages is illustrated in the example execution below.

Syntax: removeplayer [username]

Example Execution:

(a) remove a nonexistent user

>removeplayer lskyrunner

The player does not exist.


(b) remove a user

>removeplayer lskywalker


(c) remove all users


Are you sure you want to remove all players? (y/n)



3. editplayer - Allows player details to be edited. Note that the player's username cannot be changed

after the player is created. If a username for a non-existent player is given, the system should

indicate that the player does not exist, as illustrated in the example execution.

Syntax: editplayer username,new_family_name,new_given_name

Example Execution:

(a) edit a nonexistent user

>editplayer lskyrunner,Skywalker,Laurence

The player does not exist.



(b) edit a user

>editplayer lskywalker,Skywalker,Laurence


4. resetstats - Allows player statistics to be reset. The username of the player whose statistics are to

be reset is given as an argument to the command. If no username is given, the command should

reset all player statistics, but as with the `removeplayer' command, a con_rmation question should

be displayed in this case. If a username for a non-existent player is given, the system should indicate

that the player does not exist, as illustrated in the example execution.

Syntax: resetstats [username]

Example Execution:

(a) reset a nonexistent user

>resetstats lskyrunner

The player does not exist.


(b) reset a user

>resetstats lskywalker


(c) reset all users


Are you sure you want to reset all player statistics? (y/n)



5. displayplayer - Displays player information. The username of the player whose information is to

be displayed is given as an argument to the command. If no username is given, the command

should display information for all players, ordered by username. If a username for a non-existent

player is given, the system should indicate that the player does not exist, as illustrated in the

example execution. Please note when displaying player, the sequence of syntaxes of is

username,givenname, familyname,number of games played,number of games won.

Syntax: displayplayer [username]

Example Execution:

(a) display a nonexistent user

>displayplayer lskyrunner

The player does not exist.


(b) display a user

>displayplayer lskywalker

lskywalker,Luke,Skywalker,3 games,3 wins



(c) display all users


dvader,Darth,Vader,7 games,1 wins

hsolo,Han,Solo,4 games,3 wins

lskywalker,Luke,Skywalker,3 games,3 wins


6. rankings - Outputs a list of player rankings. Players should be ranked by the percentage of games

they have won. Round the percentages to the nearest integer value. Ties should be resolved by

sorting on usernames. Only the top 10 players should be displayed, if there are more than 10. The

output should be formatted according to the example below. For the purposes of formatting the

output, you may assume that no player has played more than 99 games. Note that the vertical

lines need to be aligned, with a single space appearing on either side. This means that in the _rst

column you must have 5 characters consisting of a number, '%', and spaces. The _rst column

must be left-justi_ed.

Syntax: rankings

Example Execution:

(a) rank all users


100% | 03 games | Luke Skywalker

75% | 04 games | Han Solo

14% | 07 games | Darth Vader


7. startgame - Creates and commences a game of Nim. The game's rules, and the usernames of

the two players, are provided as arguments. You may assume that the initial stones and up-

perbound arguments are valid and correct. However, if at least one (i.e. one or two) of the

usernames doesn't correspond to an actual player, the system should indicate this by the output

\One of the players does not exist.", and the game should not commence.

Otherwise, the `startgame' command will commence a game - ie. after executing it, the system is in

the game state. When a game is in progress, the system should proceed according to the gameplay

mechanics discussed in Project A - ie. players should, in an alternating fashion, be asked to enter

the number of stones they would like to remove, with the game state being updated accordingly. In

this project, bounds on stone removal should be enforced - that is, players should only be allowed

to remove between 1 and N stones inclusive, where N is the upper bound or the number of stones

remaining, whichever is smaller. Once all the stones are gone, a winner should be announced, and

the statistics for the two players should be updated accordingly. The system should then return to

the idle state, and a command prompt should be displayed again.

Syntax: startgame initialstones,upperbound,username1,username2

Example Execution:

(a) start game with a non-existent user

>startgame 10,3,lskyrunner,hsolo

One of the players does not exist.



(b) start a game

>startgame 10,3,lskywalker,hsolo

Initial stone count: 10

Maximum stone removal: 3

Player 1: Luke Skywalker

Player 2: Han Solo

10 stones left: * * * * * * * * * *

Luke's turn - remove how many?


7 stones left: * * * * * * *

Han's turn - remove how many?


Invalid move. You must remove between 1 and 3 stones.

7 stones left: * * * * * * *

Han's turn - remove how many?


4 stones left: * * * *

Luke's turn - remove how many?


1 stones left: *

Han's turn - remove how many?


Invalid move. You must remove between 1 and 1 stones.

1 stones left: *

Han's turn - remove how many?


Game Over

Luke Skywalker wins!


8. exit - Exits the Nimsys program.

Syntax: exit

Note that before you call the exit method in Java using [url removed, login to view](0); , you must

print a blank line _rst.

(a) exit the system



As was described earlier, it is important that your design makes good use of object-oriented design prin-

ciples. This is particularly relevant when it comes to implementing the actual gameplay. In a real game,

play proceeds with each player performing the action of removing some number of stones from the game.

Your design should reect this structure.

Don't worry about changing your output for singular/plural entities - ie. you should output `1 games',

`1 wins', `1 stones', etc.

Checklist For Solution

_ Blank line and whitespace related issue.

_ Make sure between the output of last command (including indication for nonexistent users,

con_rmation for all-user operations, display results, and game results) and the next command

prompt, there is one blank line.

_ Make sure there is a whitespace between (y/n) and Are you sure... sentence.

_ Make sure that there is NO whitespace after each comma, e.g., when displaying users, it

should be davader,Darth instead of davader, Darth.

_ Make sure that in game state, there is one blank line before the Initial stone count...

and one blank line after the Player 2:....

_ Make sure that in game state, if a user input an invalid move, there is one blank line between

the user-input move and the indication sentence Invalid move....

_ Make sure that an extra blank line is printed out before calling [url removed, login to view](0); when

command exit is entered.

_ Ranking display related issues.

_ Make sure that the ranking is in a descending order of winning ratio.

_ Make sure that winning ratio is rounded to the nearest integer value.

_ Make sure that users with the same winning ratio are sorted according to the alphabetical

order of the user name, e.g., if username ethan and username tom have the same ratio, you

should rank ethan the higher place.

_ Make sure that the _rst and the second column strictly have 5 and 10 characters, respectively.

_ Display player related issues.

_ Make sure that the displayed list is sorted in an alphabetical order of the username.

_ Game related issues.

_ Make sure to correctly update the statistics for players when game ends.

_ Make sure to check valid move by comparing the move to the smaller one between the current

number of stones and the upper bound for one move.

_ Make sure that after an invalid move, it is still the turn of the player who made the invalid


_ Command line prompt related issues.

_ Make sure that the command prompt appears again after each command is issued (except the

exit command).

_ Make sure that only one command prompt is displayed after a game is over and the system

returns to the idle state.

_ Other issues.

_ Make sure the boxes around above example execution are NOT printed out, they are just for

better illustration.


Important Notes About Submission

Computer automatic test will be conducted on your program by automatically compiling, running, and

comparing your outputs for several test cases with generated expected outputs. The automatic test will

deem your output wrong if your output does not match the expected output, even if the difference is just

having an extra space or missing a comma. Therefore it is crucial that your output follows exactly

the same format shown in the examples above.

The syntax import is available for you to use standard java packages. However, please DO NOT use the

package syntax to customize your source _les. The automatic test system cannot deal with customized


Please use ONLY ONE Scanner object throughout your program. Otherwise the automatic test will

cause your program to generate exceptions and terminate. The reason is that in the automatic test,

multiple lines of test inputs are sent all together to the program. As the program receives the inputs, it

will pass them all to the currently active Scanner object, leaving the rest Scanner objects nothing to read

and hence cause run-time exception. Therefore it is crucial that your program has only one Scanner

object. Arguments such as \It runs correctly when I do manual test, but fails under automatic test"

will not be accepted.

3 Your Tasks

1. Draw a UML class diagram for Nimsys based on the above information. For each class you need to

identify all its instance variables and methods (including public and private modi_ers) along with

their corresponding data types and list of parameters. You should also identify all relationships

between classes.

2. Implement Nimsys in Java according to the above speci_cation and in accordance with your UML

class diagram.

How you edit, compile and run your Java program is up to you. You are free to use any editor or

development environment. However, you need to ensure that your program compiles and runs

correctly on the CSSE student servers, using build 1.6.0 of Oracle's (as Sun Microsystems has

been acquired by Oracle in 2010) Java Compiler and Runtime Environment, i.e. javac and java pro-

grams. You should also remove any Ctrl-M characters which may be inserted if you edit your source _le

under a Windows environment - this can be done using the dos2unix command, available on the CSSE

student servers. Submit your program to the CSSE student servers a couple of days before the deadline

to ensure that they work (you can still improve your program). \I can't get my code to work on

the student server but it worked on my Windows machine" is not an acceptable excuse for

late submissions.

If you want compile the source _les on server, make sure the Java environment is set to 1.6.0. If not,

please ensure the ~=.bashrc _les has been edited to specify the $PATH variable, and source ~/.bashrc.

Looking to make some money?

  • Set your budget and the timeframe
  • Outline your proposal
  • Get paid for your work

Hire Freelancers who also bid on this project

    • Forbes
    • The New York Times
    • Time
    • Wall Street Journal
    • Times Online