Академический Документы
Профессиональный Документы
Культура Документы
1 Introduction
1.2 Submission
All submissions are to be made to the assignments.cs.up.ac.za page under the COS
110 page, and for the correct assignment slot. Submit your code to Fitchfork before the
closing time. Students are strongly advised to submit well before the deadline as no
late submissions will be accepted.
1.3 Plagiarism
The Department of Computer Science considers plagiarism as a serious offence. Disci-
plinary action will be taken against students who commit plagiarism. Plagiarism includes
copying someone elses work without consent, copying a friends work (even with consent)
and copying textual material from the Internet. Copying will not be tolerated in this
course. For a formal definition of plagiarism, the student is referred to http://www.ais.
up.ac.za/plagiarism/index.htm (from the main page of the University of Pretoria site,
follow the Library quick link, and then click the Plagiarism link). If you have questions
regarding this, please ask one of the lecturers, to avoid any misunderstanding.
1
usage of C++11 or additional libraries outside of those indicated in the practical, will
not be allowed. Some of the appropriate files that you submit will be overwritten during
marking to ensure compliance to these requirements. If the specification makes use of text
files, for providing input information, be sure to include blank text files with the specified
names.
1.5 Classes
The class is one of the foundations of the Object Oriented (OO) paradigm. The purpose
of classes is to organise methods and data into logically coherent units that provide can
reusable functionality to building complex programs. Strongly associated with classes,
are their two most recognisable features of a class that allow for creating and destroying
instances of that class.
1.6 Scenario
Battleships is a game that is based on two players taking turns to guess at locations of
ships located on a grid board. Correct guesses damage ships of the opposing player, and
incorrect guesses reflect missed shots. The goal of the game is to correctly sink all of
the enemy’s ships before yours are sunk. For this assignment, you will be implementing
a variation of this game with a number of key gameplay changes ranging from different
style of tokens, to a simultaneous turn resolution mechanic.
Activity Mark
(Task 1) Ship Class 20
(Task 2) Player Class 30
(Task 3) Game Class 40
Total 90
2 Assignment
The assignment is broken up into 3 separate tasks that follow on from each other. In each
task, you will be required to implement code, and design components that will be used
by later tasks to build more complex systems. It is recommended to work sequentially
from Task 1 to Task 3.
2
2.1.1 Game Board
The game is played on a square board made of NxN characters where N is a number.
The square board is meant to represent open seas and thus there is no special terrain or
features beyond the ships. The board is numbered of course, with the top leftmost corner
representing the coordinates (0,0). The subsequent rows and columns increase as they
move away from this position.
01234
0#####
1#####
2#####
3#####
4#####
This is a board made of 5x5 tiles. Each tile represents the open sea and the board
is currently completely empty. The positions of the each tile, in terms of coordinates
it reflects is given by the numbers. The top leftmost corner is (0,0) and the bottom
rightmost corner is (4,4)
Unlike Battleships, this game does not use differently shaped tokens to represent ships
on the board. Instead, a ship is represented by a ∗ symbol whose coordinates represent
the location of the ship on the board. All ships are represented this way, indicating that
there are no specialised tokens for ships.
Both players get an equal number of tokens for the match, and they must place them
on the board. Neither player knows, or should know, where their opponent’s pieces are
placed and thus, both place their tokens on the board ignoring the positions of the other
player’s tokens. In effect, this creates two initially identical boards that then get their
tokens placed on. Tokens belonging to the same player cannot overlap in their placements
on the board; each must be uniquely placed. However, enemy tokens can share.
So Player A cannot have two tokens on position (0,0) but Player A and Player B can
both have one token on (0,0).
The game is played in a number of turns. The number of turns is the size of a board
length so a 5x5 board would then have a game consisting of 5 turns. In each turn, both
players will make their guesses for where the enemy ships are on the board. This happens
simultaneously with each player making a number of guesses also equal to the size of the
board length.
So again, a board of 5x5 would have turns where each player makes 5 guesses for where the
3
enemy ships are. After resolving the guesses, feedback about their positions is provided
as well. This would then be used to inform the next turns’ moves.
The game ends when either the turns have elapsed, or one side loses all of their ships. The
winning side is calculated then through a scoring mechanic. As it is possible for the two
sides to destroy each other during a simultaneous turn resolution, there is an additional
scoring mechanic in place that is used to resolve the game.
01234
0*####
1#####
2##*##
3###*#
4#*###
There are no restrictions generally on token placement but it is advisable to try to avoid
a predictable placement such as all of the ships in a straight line.
ship
-id:string
-value:int
-xCoord:int*
-yCoord:int*
------------------------
+ship()
+ship(newShip:ship*)
+ship(i:string,val:int,x:int,y:int)
+∼ ship()
+getID():string
+getVal():int
+getX():int
+getY():int
+setID(a:string):void
+setVal(a:int):void
+setX(a:int):void
+setY(a:int):void
4
• id: A unique string id that identifies each of the ships. The ID has the form of a
string with the format of ”(X,Y)” where X is the X coordinate of the ship and Y
the y coordinate of the ship. Since each ship must be uniquely assigned, these ids
are all unique to each player.
• value: A numerical value in the range [0,5) that assigns additional worth to each
ship.
• ship: The default and empty constructor for the ship class.
• ∼ship: The class destructor. This deallocates any allocated memory of the class.
It also prints out (on a new line), the following message: ”Ship <ID> destroyed”
where <ID> refers to the ID of the ship that is deallocated.
• iostream
• string
5
2.3 Task 2: Player Class
The next most important component is the Player class. It is comprised of two files:
player.h and player.cpp. You will be required to produce both of these files for yourself.
A definition for the class is provided below:
player
-score:int
-shipList: ship**
-shipsDeployed:int
------------------------
+player()
+player(score:int,deployed:int)
+player(newPlayer:player*)
+∼ player()
+addShip(newShip:ship*):int
+removeShip(id:string):void
+tallyShips():int
+addToScore(s:int):void
+getScore():int
+getDeployed():int
+getValueOfShip(id:string):int
• score: The current score of the player. This is accumulated over a number of turns.
• shipList: A dynamic array of ship objects that reflects all the tokens of the player
left in the game.
• shipsDeployed: The original number of ships that the player had at the start of the
game.
6
• addShip(newShip:ship*): This function receives a ship object and then adds it to
the current list of ships. The object’s values should be used to create a new instance
of the ship class at the first, from index 0, open space. The function returns the
index of the element where the ship object was created. If the list is full, that is all
spaces are taken, then it should return -1.
• removeShip(id:string): This function removes the ship in the list at the id. It will
deallocate the element, and set it to null. In the event that the id is not found, or
already null, nothing happens.
• addToScore(s:int): A function that adds a provided value to the current player score.
• getDeployed(): This returns the number of ships that were originally deployed.
• iostream
• string
game
-playerA: player*
-playerB: player*
-numTurns: int
-numTokens: int
-boardLength:int
-boardA: string**
-boardB: string**
-seed:int
------------------------
+game()
+game(a:player *,b:player *,boardName:string, aBoard:string,bBoard:string,seed:int)
+∼ game()
+playGame():void
+getTurns():int
+getLength():int
7
+getBoardAt(x:int,y:int, player:string):string
+createPlayerAFeedback():void
+createPlayerBFeedback():void
+playTurn():void
• numTurns: The number of turns the game is to be played for. This should be equal
to the length of one board side.
• numTokens: The number of deployable tokens for each player at the start of the
game.
Read in the player boards from both files, and create the respective boards with
their token allocations. Once the tokens are allocated, all of the ships from their
respective boards are assigned to the players. When each ship is added, its value
variable should be set to a random number in the range [0,5).
• ∼game(): The class destructor. This deallocates any allocated memory of the class.
It also prints out (on a new line), the following message: ”Game Over”.
• getTurns(): This returns the number of turns that are going to be played during
the game.
8
• createPlayerAFeedback():This function creates a textfile that contains the outcome
of player A’s turn with regards to their guesses. This file is always called feed-
backA.txt and should always overwrite the latest file. The result of the guesses
applied to Player B’s board is the basis of their feedback.
• playTurn(): This is the function that plays the turn for both player A and player B.
The function asks for an input of moves for player A and player B. The convention
for these files will follow the convention of moves<A|B> <X> where <A|B> refers
to A or B and X is the turn number. For example, movesA1.txt is the file of moves
for player A during turn 1. The input looks as follows:
Once the input files are provided, the function, starting with player A, will iterate
through the list of moves and determine the effect of each move. Determining the
effect requires examining the cell indicated by the move. If a ship is found at that
location on the board, it is destroyed and that position is then converted to the X
character. If the guess is a miss, that cell is converted to the O character. In this
way, player A will modify player B’s board and vice versa.
The score of the player who made the move is updated by adding 5 points plus
the value of the ship to the player’s score. Then, the ship is removed from the
appropriate list. This process is repeated until all guesses have been examined for
each player.
• playGame(): This is the overall control function of the game. It will conduct all
of the turns, for each player, as well as check if the game is over. The game ends
when a player has no more ships remaining, or the number of turns has expired.
Therefore, the overall structure of the game is as follows:
– Initialise the board and placement for both players (done during class con-
struction).
– Check if the turn limit has expired.
– Check if one player is out of ships (both can be at the start of a turn)
– If the game is still ongoing, conduct a turn.
– Send the feedback for each player.
When the game is finished, print the following information in the following format:
Player A Score: 20
Player B Score: 12
Player A Wins!
9
Each should be on a new line. You are allowed to make use of the following libraries:
• iostream
• string
• fstream
• sstream
• cstdlib
2.5.1 Board
3
4
The first line of the file, is the size of the board length. The second line is the number
of tokens per player. The size will not be known beforehand so keep this in mind during
construction of the boards.
2.5.2 Placement
#*#
#*#
##*
Consider the above 3x3 board where player A has placed 3 tokens. Each one is a unique
ship that should be included on their player profile.
2.5.3 Moves
3,4
0,1
4,3
2,3
This is a list of guesses in terms of X and Y coordinates separated by commas. You can
assume that the coordinates will always be valid in some way and that repeats will not
be included.
10
2.5.4 Feedback
#O#
#X#
##O
The above is an example of the feedback file that needs to be produced. The file references
the results of a turn. The X and O symbols refer to hits and misses respectively. The
matrix is reproduced in the textfile as it is for the corresponding player. However, the
position of the remaining enemy ships is not revealed, only the hits and misses.
Given a 3x3 map with the following placements for player A and B and the start of
the game:
A
##*
*##
##*
B
*##
*##
#*#
A
1,1
2,2
1,0
B
1,2
2,1
0,0
11
##O
2.7 Submission
You will have to submit your code to 3 separate upload slots. You will have a maximum
of 5 uploads per slot for this assignment. The slots are very limited so do not rely on
Fitchfork to debug your code.
• ship.h
• ship.cpp
• main.cpp
• makefile
• ship.h
• ship.cpp
• player.h
• player.cpp
• main.cpp
• makefile
• ship.h
• ship.cpp
• player.h
12
• player.cpp
• game.h
• game.cpp
• main.cpp
• makefile
• input1.txt,input2.txt,input3.txt
• board1.txt,board2.txt,board3.txt
• placeA1.txt,placeA2.txt,placeA3.txt
• placeB1.txt,placeB2.txt,placeB3.txt
• movesA1.txt, movesB1.txt
• movesA2.txt, movesB2.txt
• movesA3.txt, movesB3.txt
• movesA4.txt, movesB4.txt
• movesA5.txt, movesB5.txt
The text files should be blank. These will be replaced during testing.
Be sure to work incrementally and test as you go to ensure that your code is robust
under a number of possible conditions. The very limited number of uploads means that
the margins for error are relatively low and therefore caution is advised. Remember that
while your code might appear to be working, there could be a number of non-obvious
problems under the surface.
13