Stacked Tic-Tac-Toe

2021 Project RW113/RW114

Marks First Handin (20% of project mark)

RW113 Marks First Submission

RW114 Marks First Submission

Marks Final Handin (80% of project mark)

RW113 Marks Final Submission

RW114 Marks Final Submission

Student To Demi Allocation For Final Demo

Use the below links to check which demi you have been assigned to for your final demo.

Please book a demo slot with this demi.

This can be done by looking under the project section on sunLearn and clicking on your allocated demi's name. Choose a free slot and book it. Please do NOT book multiple slots and do NOT book a slot with a demi you were not assigned to.

If you student number is not in these lists, please contact me at 19478275@sun.ac.za

Marking Demi Allocation For Final Project Demo Slot

Introduction

Stacked Tic-Tac-Toe is a variant of tic-tac-toe and is way more fun. It is a two-player game (blue and green) and is played on a 4-by-4 board. Each player has twelve pieces, with 4 different size variants. Each player arranges their 12 pieces into three stacks containing four pieces each (the so called external stacks). Only the largest pieces are visible in the beginning.

Please take time to read this page carefully, and to follow the instructions exactly. If you fail to comply with instructions here, you will be penalized.

Objective

The first player to align four of their own pieces (sizes may differ) in a row (either vertically, horizontally or diagonally) wins the game. The game may be ended prematurely and a draw declared if one of the players decides to quit the game (this may be because the players realize that there is no way to be victorious given the board layout or for other reasons).

Introductory Videos

Overview

Project Description

Code Skeleton Explained

Demonstration (part 1)

Demonstration (part 2)

The rules of the game

Tic-Tac-Toe is played on a 4 by 4 board divided into squares. Some of the squares are empty, while others contain pieces or stacks of pieces.

An empty board with the three external stacks for the blue player shown above the board:

Blue starts and players take turns in playing. A player can either introduce a new piece onto the board or move one of their pieces already present on the board (at the top of a stack). When a player introduces a new piece onto the board they must place it on an empty square but there is one exception. If their opponent already has three pieces in the same line then they may cover one of their opponents pieces (one of the three aforementioned pieces only) using a piece belonging to the external stack.

Each player may move one of their own pieces (not the opponents) already on the board to an empty space on the board or cover a piece that is already on the board (their own or their opponents) using one of the pieces that belong to them and is already on the board. If a player has placed all twelve of their pieces on the board they have to keep playing by using only the pieces that is already on the board.

Notes on General Play

Players must play pieces as they appear from the external stacks. A piece from any of the three stacks may be played.

You can cover any smaller piece (even your own and it need not be the next size down).

If you move one of your pieces on the board and this uncovers one of your opponents pieces, and this move reveals a line of four of your opponents pieces they win the game, except if you can place your piece on a different square (other than the one the piece was picked up from) and in doing so you destroy the aforementioned created line of four.

You can't place a piece down at the position it was picked up, in a given turn.

Only one piece can be moved at a time.

An illegal move counts as a move, although the board does not change. The player must be notified if they have played an illegal move. What constitutes an illegal move is defined in the following sections.

Obstacles

Instead of playing a normal move a player can also choose to add one of four obstacles to the board. Each player has two of each obstacle. If an illegal move is played, your obstacle is lost (and the player is notified). If playing an obstacle results in both green and blue achieving a line of four pieces a draw is declared.

Four types of obstacle pieces may be added to the game:

Transporter:

The icon for a transporter piece

A Transporter must be placed on a square containing, at the top of the stack (visible), one of your opponents pieces. The player now has to choose how many pieces must be transported (if more are chosen than exist on the chosen square then nothing must be done). Entering a value larger than the number of pieces available will count as an illegal move and results in the player losing their turn and transporter. Entering a value smaller than or equal to the number of pieces available will result in the number of pieces chosen being moved to the closest (using manhatten distance) open space (if more than one square is closest the one that is associated with the smallest integer label is chosen --- the squares are numbered row by row from left to right starting at the top left corner). If there are no open squares nothing must be done.

Bomb:

The icon for a bomb piece

A Bomb can only be placed on a square containing one of your own pieces (visible). The bomb removes all the pieces on the square it is placed on and returns them to the external stack (the pieces should be returned to the external stack, filling it up from left to right or in other words with order priority from stack 1 to stack 3). The immediate neighboring squares (I.e. those 8 cells neighbouring the cell onto which the bomb was placed, taking into consideration board wrapping around edges of the grid) are affected differently. In their case, only the visible piece is returned to the external stack (again filling it up from left to right). If one of the neighbors are empty it becomes a sink hole square (and becomes red). The next time a user places a piece on it, it is immediately returned to the external stack (filling it up from left to right). The sink hole square then reverts back to a normal square.

In the situation where a sink hole is in the neighbourhood of a newly placed bomb piece, nothing happens to the sink hole, there is no x2-type ability, the sink hole remains as is and when (during the following game play) a piece is placed on that sink hole then the piece is returned to the external stack and the sink hole dissapears as it would if only 1 bomb had affected it.

In the situation of returning pieces back to the external stacks (because of the bomb obstacles and resulting sink holes), it does not matter in what order you return the pieces back to the external stacks, in a given turn. The order of placement back into the stacks should be from stack 1 (first priority) to stack3 (3rd priority). And for each piece you should see if it can be put in stack 1, if not then stack 2, if not then stack 3. The stack should not be in a format such as "B2 B1 B3 B4" since the sizing rules would be broken here, when returning pieces to the external stack you can 'pick up' pieces in the external stack to place the one from the board in the correct configuration position. Example: Say stack 1 is "B1 B3" and you want to put "B2" back in the stack, then you can do so and change stack 1 to "B1 B2 B3" not "B2 B1 B3". Thereafter if you want to put another B2 back you'll have to put it in stack 2 or 3 since the placement for B2 is taken in stack 1.

Shifter:

The icon for a shifter piece

A Shifter can only be placed on an empty square. The user needs to choose whether they want to implement clockwise or anticlockwise shifting. The ring of squares around the shifter is then shifted by one place. Wrapping is implemented at corner and edge pieces. The shifter piece shifts the entire stack at each position, not just the top piece of the stack.

submission format

Paintbrush:

The icon for a paintbrush piece

A paint brush can be placed on any non-empty square, it changes the colour of any piece it is placed on to grey for three turns. The affected piece then returns to its original colour. It should remain grey for three turns, even if it is covered or moved back into the stack due to a bomb. The affected piece's colour only reverts back to its original colour at the start of the fourth turn. A grey peice cannot be moved, with the exception of the bomb (in which case the grey piece is moved to the external stack (again filling it from left to right)) and shifter obstacles affecting it.

Requirements

The project will be submitted in two parts. The first hand in will require the game functionality excluding obstacle pieces and requires the implementation of text mode only (20% of project mark). The final hand in will require the full game functionality including obstacle pieces as well as both text mode and graphics modes (80% of project mark). Graphics mode provides an interactive graphical user interface (GUI) for the game.

First Project Submission: 16 May 23h59 CAT (20% of the project mark) - handin date moved 1 week forward from 9th May
The first project submission will open at midnight (CAT) on the 2nd of May and will close at midnight (CAT) on the 16th of May.
  • 1.1 Your program must implement the rules of the game.
  • 1.2 Your program must take in one command-line argument and operate in text mode.
  • 1.3 Your program must interpret the command-line argument as the name of the input instructions file (e.g. input.txt).
  • 1.4 Your program must read the input file based on the format described in the input file format described below.
  • 1.5 Your program must print all relevant output to the command-line, the output must be in the format described below.
  • 1.6 Your program must implement the following pieces, their stacks on the board, and their functionality
    • blue player
    • green player
    • empty spaces
  • 1.7 Your program must execute the instructions in the input file one-by-one onto the initial empty board configurations with 3 stacks per player, each stack containing 4 different sized pieces of the player's colour.
  • 1.8 If the next move is legal, your program must update the board accordingly.
  • 1.9 If the next move is not legal, your program must output "Invalid move" and continue game play of the alternate player (no board should be printed, no change to the board was made). I.e. an illegal move counts as a move, although the board does not change.
  • 1.10 If the next move is a quit move (defined by a '-1' integer on a single line in the input file), the String "Quit" should be printed followed by the statistics of the game. Nothing else should be displayed and then terminate. Your program must NOT display anything else.
  • 1.11 If only the green player has a winning configuration, your program must output the winning board configuration, "Green wins!", the statistics as defined below and terminate. Your program must NOT display anything else.
  • 1.12 If only the blue player has a winning configuration, your program must output the winning board configuration, "Blue wins!", the statistics as defined below and terminate. Your program must NOT display anything else.
  • 1.13 If both the green and blue players have winning configurations then your program must output the winning board configuration, "Draw!", the statistics as defined below and terminate. Your program must NOT display anything else.
  • 1.14 If all the instructions have been executed and the end of the input file is reached, your program must output the "No winner, input file ended", display the current board according to the format described below, the statistics as defined below and terminate. Your program must NOT display anything else.
  • 1.15 After each player's move board state should be displayed (see sample output files)
  • 1.16 Tip for getting strated. Representing the board would require the use of one of the 3 following strategies (or some other clever strategy you can come up with)
    • 1. Use of a 3D array to represent the board
    • 2. Use of 4 2D arrays to represent the different layers of the board
    • 3. Use of a 2D array of stacks to represent the board
Final Project Submission: 13 June 23h59 CAT (80% of the project mark)
The final project submission will open at midnight (CAT) on the 6th June and will close at midnight (CAT) on the 13th June.
  • 2.1 Your program must be able to operate in both text AND graphics mode.
  • 2.2 When no command-line arguments are given, your program must operate in graphics mode.
  • 2.3 When one command-line argument is given, your program must operate in text mode.
  • 2.4 In text mode, your program must interpret the first (and only) command-line argument as the name of the input file path.
  • 2.5 Your program must implement the following pieces, obstacles, and their functionality
    • blue player
    • green player
    • empty spaces
    • transporters
    • shifters
    • bombs (difficult)
    • sink holes (difficult)
  • 2.6 Bonus Marks (maximum of 5% bonus, capped at 100% handin mark):
    • paintbrushes (very difficult)
    • grey pieces resulting from the paintbrush obstacle (very difficult)
  • 2.7 For text mode: Your program should follow the instructions detailed for the first hand in as well as the following:
    • 2.7.1 Placing an obstacle on the board and specifying details of its effect on the game. At the begining of the player's turn:
      • Input for the transporter/bomb/shifter/paintbrush obstacles are each given on a single line in the input file with the format detailed in the input file section below. If any rules are broken or the move is invalid then the "Invalid move" error should be printed to console and the player's move skipped; otherwise the operation performed and the number of available respective obstacles for the player decremented.
    • 2.8 For graphics mode:
      • 2.8.1 Your program must display a graphical representation of the game on the screen. The GUI must include the following elements:
        • The grid which can contain green, blue, and gray pieces as well as the sink hole pieces.
        • The 3 external stacks for the current player (only the top element of the external stack is necessary to display) and the corresponding characters which can be typed to select the top element of the stack.
        • The obstacles still available to the current player and the correlating characters which can be typed to use these obstacles on the board.
      • 2.8.2 Allowing the user to identify a specific position on the board. A focus box is used to allow the user to identify the grid position currently in focus as well as to move around the grid and ultimately select a position on the board by clicking enter. This focus box should allow easy identification of which position is currently in focus, for example your program could use a red box to outline the grid position in focus. The user must be able to click enter to identify their selection of the currently in focus position on the board. Note: the focus box should be able to wrap around the left and right edges of the grid but cannot wrap around the top and bottom edges of the grid. The following keys should be used to allow the user to move from position to position on the board.
        • If the user types a single "w" keystroke (without pressing enter), your program must move the focus box one position upwards (if possible) and react accordingly.
        • If the user types a single "a" keystroke (without pressing enter), your program must move the focus box one position left and react accordingly.
        • If the user types a single "s" keystroke (without pressing enter), your program must move the focus box one position down (if possible) and react accordingly.
        • If the user types a single "d" keystroke (without pressing enter), your program must move the focus box one position right and react accordingly.
      • 2.8.3 Taking a piece from the stack and placing it on the board. At the begining of the player's turn:
        • If the user types a single "A" keystroke (without pressing enter), your program must position the focus box on the grid and allow the user to identify which position they want to place the top element of stack 1. If the position chosen results in a valid move, the piece should be placed on the board at that position but if the position chosen results in an invalid move then "Invalid move" should be output on the console and the player's move skipped.
        • If the user types a single "B" keystroke (without pressing enter), your program should act according to the rules in the above point but with stack 2.
        • If the user types a single "C" keystroke (without pressing enter), your program should act according to the rules in the above point but with stack 3.
        • If the chosen stack is empty then you should print "Invalid move" to the console and skip the player's turn.
      • 2.8.4 Moving a piece from one position on the board to another. At the begining of the player's turn, if the user types a single "a", "s", "d" or "w" then the focus box should be used twice to determine the position of the piece to move and the position determining where the piece should be placed. If an invalid move is made then "Invalid move" should be output on the console and the player's move skipped. If a valid move is made then the respective piece should be moved to another position on the board (or stacked over other pieces on another position on the board).
      • 2.8.5 Placing an obstacle on the board and specifying details of its effect on the game. At the begining of the player's turn:
        • If the user types a single "t" keystroke (without pressing enter), your program must use one of the player's available transporter obstacles. If the player does not have any transporter obstacles left then the error "Invalid move" should be output on the console and the player's move skipped. If the user has an available transporter then the focus box should show on the grid and be used to identify the position at which it should be used; a visual promp should then alert the user to input (via the keyboard) the number of pieces to transport. If any rules are broken or the move is invalid then the "Invalid move" error should be printed to console and the player's move skipped; otherwise the operation performed and the number of available transporters for the player decremented.
        • If the user types a single "b"/"r"/"p" keystroke (without pressing enter), your program must use one of the player's available bomb(b)/shifter(r)/paintbrush(p) obstacles. If the player does not have any bomb(b)/shifter(r)/paintbrush(p) obstacles left then the error "Invalid move" should be output on the console and the player's move skipped. If the user has an available bomb(b)/shifter(r)/paintbrush(p) then the focus box should show on the grid and be used to identify the position at which it should be used. If any rules are broken or the move is invalid then the "Invalid move" error should be printed to console and the player's move skipped; otherwise the operation performed and the number of available bomb(b)/shifter(r)/paintbrush(p) obstacles for the player decremented.
      • 2.8.6 Quiting the game. At the begining of the player's turn, if the user types a single "q" keystroke (without pressing enter), your program must output to the GUI AND to the console "Quit, draw!", and terminate. (It is recommended to use stdlib's stopwatch library to pause the display here for 2 seconds, just long enough to read the message before your program terminates.) Your program must NOT display anything else.
      • 2.8.7 If the user types anything else, your program must ignore it completely.
      • 2.8.8 After making a move, your program must update the graphical display of the board.
      • 2.8.9 After each player's move the information for the alternate player should be displayed in the GUI and the other player's turn taken.
      • 2.8.10 If only the green player has a winning configuration, your program must output to the GUI AND to the console "Green Wins!", and terminate. (It is recommended to use stdlib's stopwatch library to pause the display here for 2 seconds, just long enough to read the message before your program terminates.) Your program must NOT display anything else.
      • 2.8.11 If only the blue player has a winning configuration, your program must output to the GUI AND to the console "Blue wins!", and terminate. (It is recommended to use stdlib's stopwatch library to pause the display here for 2 seconds, just long enough to read the message before your program terminates.) Your program must NOT display anything else.
      • 2.8.12 If both the green and blue players have winning configurations then your program must output to the GUI AND to the console "Draw!" and terminate. (It is recommended to use stdlib's stopwatch library to pause the display here for 2 seconds, just long enough to read the message before your program terminates.) Your program must NOT display anything else.

    Input file and command-line output formats for text mode

    This section describes the format of the input instruction file and the statistics output file for text mode. Your program must follow these formats precisely: the tests will use these formats and if your program does not implement them, it will fail the tests.

    Input file format

    • Each line in the input file contains an integer value of -1,1,2,3,4 or 5. Each identifies a different instruction for your program and the characters following this instruction identifier value contains information relating to the respective instruction. Your program must read the instructions, one line at a time, and execute them accordingly. Each line identifies a single player's turn; each odd line (lines 1,3,5,...) identify the blue player's move and each even line (2,4,6,...) identifies the green player's move. The blue player plays first.
    • For lines that start with the value -1, which indicates a quit command. The String "Quit" should be printed followed by the statistics of the game. Nothing else should be displayed.
    • For lines that start with the values 1, 2 and 3, which indicates the use of a piece from an external stack:
      • When a line starts with the value 1, it identifies that the top element of external stack 1 must be used for placement on the board. Two integer values follow the 1 and identify, in that order, the row and column values of the position at which the piece should be placed.
      • When a line starts with the value 2, it identifies that the top element of external stack 2 must be used for placement on the board. Two integer values follow the 1 and identify, in that order, the row and column values of the position at which the piece should be placed.
      • When a line starts with the value 3, it identifies that the top element of external stack 3 must be used for placement on the board. Two integer values follow the 1 and identify, in that order, the row and column values of the position at which the piece should be placed.
    • For lines that start with the value 4, which indicates the action of moving a piece from one location on the board to another location on the board.
    • The integer value of 4 is followed by 4 other integer values. The first set of two integer values identify, in that order, the row and column values of the position at which the piece to move is located. The second set of two values integer values identify, in that order, the row and column values of the position at which the piece is to be moved to.
    • For lines that start with the value 5, which indicates the use of an obstacle piece (only necessary for the second hand in). The integer 5 is followed by the character 'T', 'B', 'S' or 'P':
      • When the integer 5 is followed by the character 'T', one of the player's transporter pieces must be used. The 'T' is followed by three integers. The first two indicating, in that order, the row and column values of the position at which to use the transporter and the third integer indicating the number of pieces in the stack of the chosen position to transport.
      • When the integer 5 is followed by the character 'B', one of the player's bomb pieces must be used. The 'B' is followed by two integers which, in that order, identify the row and column values for the position on the board at which to place and use the bomb.
      • When the integer 5 is followed by the character 'S', one of the player's shifter pieces must be used. The 'S' is followed by three integers. The first two indicating, in that order, the row and column values for the position on the board at which to place and use the shifter and the third the integer value of 0 or 1 where 0 means clockwise rotation and 1 means anticlockwise rotation.
      • When the integer 5 is followed by the character 'P', one of the player's paintbrush pieces must be used. The 'P' is followed by two integers which, in that order, identify the row and column values for the position on the board at which to place and use the paintbrush.

    Here is an example of an input file:

    1 1 1
    1 2 1
    1 1 2
    1 2 2
    1 1 3
    1 2 3
    4 1 2 2 3
    4 2 1 2 3
    5 P 2 3
    

    Command-line output format

    Your program should output the board to the command-line once before any move has been made and once after each move. The last thing your program should output is statistics for the board and external stacks as described below (unless a player quits the game, in which case no new output should be displayed in the command-line). Please see the sample files to ensure your program outputs to the command-line correctly since the test scripts will mark according to this output format. The output format for the board shows the labels r1, r2, r3 and r4 for each row of the board and c1, c2, c3, c4 for each column of the board. It separates squares of the board on the same line with a '|' character and the following character sequences are used to identify pieces on the board:
    • "B1" identifies a blue piece of the largest size.
    • "B2" identifies a blue piece of the second largest size.
    • "B3" identifies a blue piece of the third largest size.
    • "B4" identifies a blue piece of the smallest size.
    • "G1" identifies a green piece of the largest size.
    • "G2" identifies a green piece of the second largest size.
    • "G3" identifies a green piece of the third largest size.
    • "G4" identifies a green piece of the smallest size.
    • "SH" identifies a sink hole piece (only for final hand in).
    • "GR" identifies a greyed out piece (only for final hand in, affected by the paintbrush).

    The statistics of the board and the external stacks are then printed.

    • The String "Statistics for each stack present on the board" is printed on its own line and then for each stack of pieces on the board, traversing from the top left of the board row-for-row until the bottom right, each piece in the stack is printed. Each stack is printed on its own line with the elements ordered from the top of the stack downwards; a space is printed between each element in the stack.
    • The String "Statistics external stacks blue player" is then printed on its own line followed by three lines each beginning with "stack n" where n identifies which stack is being displayed. The corresponding external stack for the blue player is then printed with elements ordered from the top of the stack downwards; a space is printed between each element in the stack. Similarly for the green player the statistics of the green player's stacks are printed thereafter.

       c1 c2 c3 c4
    r1 __|__|__|__|
    r2 __|__|__|__|
    r3 __|__|__|__|
    r4 __|__|__|__|
    
       c1 c2 c3 c4
    r1 B1|__|__|__|
    r2 __|__|__|__|
    r3 __|__|__|__|
    r4 __|__|__|__|
    
       c1 c2 c3 c4
    r1 B1|__|__|__|
    r2 G1|__|__|__|
    r3 __|__|__|__|
    r4 __|__|__|__|
    
       c1 c2 c3 c4
    r1 B1|B2|__|__|
    r2 G1|__|__|__|
    r3 __|__|__|__|
    r4 __|__|__|__|
    
       c1 c2 c3 c4
    r1 B1|B2|__|__|
    r2 G1|G2|__|__|
    r3 __|__|__|__|
    r4 __|__|__|__|
    
       c1 c2 c3 c4
    r1 B1|B2|B3|__|
    r2 G1|G2|__|__|
    r3 __|__|__|__|
    r4 __|__|__|__|
    
       c1 c2 c3 c4
    r1 B1|B2|B3|__|
    r2 G1|G2|G3|__|
    r3 __|__|__|__|
    r4 __|__|__|__|
    
       c1 c2 c3 c4
    r1 B1|__|B3|__|
    r2 G1|G2|B2|__|
    r3 __|__|__|__|
    r4 __|__|__|__|
    
       c1 c2 c3 c4
    r1 B1|__|B3|__|
    r2 __|G2|G1|__|
    r3 __|__|__|__|
    r4 __|__|__|__|
    
       c1 c2 c3 c4
    r1 B1|__|B3|__|
    r2 __|G2|GR|__|
    r3 __|__|__|__|
    r4 __|__|__|__|
    
    Statistics for each stack present on the board
    B1
    B3
    G2
    G1 B2 G3
    Statistics external stacks blue player
    Stack 1: B4
    Stack 2: B1 B2 B3 B4
    Stack 3: B1 B2 B3 B4
    Statistics external stacks green player
    Stack 1: G4
    Stack 2: G1 G2 G3 G4
    Stack 3: G1 G2 G3 G4
    No winner, input file ended
    

    Hand in and demonstration

    When you are done, create a ZIP file that contains:

    • A single .java file with your project's code. This java file must be named in the format SU<student number>. Example: SU12345678.java
    • Resource files required for your program to work such as images and/or audio files.
    • Include, in your root directory, the .java files (from stdlib) that your program uses to run. This is necessary because your program is expected to compile and run as soon as it is pulled from SUNLearn, no additional file additions/alterations should be necessary.
    • Include the filled in and signed plagiarism document available under resources in your .zip submission file.
    • Your ZIP file must use your student number its name. Example: 12345678.zip
    • An example submission format is shown in the image below (the files must of course be zipped as described above):
      submission format

    How to submit your ZIP file:

    • To submit your ZIP file, log in to learn.sun.ac.za.
    • Project submissions will open on SUNLearn 1 week before the due date
    • The first project submission will open at midnight (CAT) on the 2nd of May and will close at midnight (CAT) on the 16th of May
    • The final project submission will open at midnight (CAT) on the 6th June and will close at midnight (CAT) on the 13th June
    • You are allowed to submit multiple times. It is a good idea to submit early, even before you are done, in case anything happens to the system or to your code.
    • Test your ZIP file before you submit: extract the files in a clean directory and make sure that it compiles and runs correctly.
    • If you write your program on a home laptop or PC, be sure to test that your program compiles and runs correctly on the NARGA computers to prevent unwanted issues during your demo.

    NB: Object Oriented Programming (OOP) will not be allowed for this project. Your project must be written in a single java file.

    Your ZIP file must NOT contain any .class files. You will be required to compile the project during the demonstration FROM THE COMMAND LINE. In other words, you are free to develop your project in an IDE such as Eclipse, NetBeans or IntelliJ, but you must be able to compile and run it from the command-line. If you are not able to do this, don't use an IDE.

    Demonstrations

    There will be two submissions for the project. The first will be marked by the demis and feedback given (this handin will make up 20% of the project mark), the final submission will be marked during a live demo will make up the other 80% of the project mark.

    First Project Hand In Submission
  • Students will receive a feedback report and mark once the demis have marked their submission.
  • Final Project Hand In Submission/Demo
  • This hand in will be graded by a live demo during the week of 14th June
  • The demonstrations are like examinations, it is essential that you keep time open in the week and book a demo slot. The demonstration dates have been released with plently time to diarise and keep open, no requests to alter student's demo slots to be outside of the demo week will be accommodated for. It is the student's own responsibility to be at the demonstration during their demo slot.
  • Demonstrations follow the steps below:

    1. Your handed in project is downloaded from learn.sun.ac.za.
    2. You are asked to compile your project from the command-line.
    3. Your marker may run several tests on your program in text mode and/or run your program in graphics mode to check visually that it satisfies the requirements.
    4. Your marker will inspect your code and check that it satisfies the coding conventions.
    5. Your marker will ask you to explain certain parts of your code and make changes to ensure that you wrote the code yourself.
    6. You will be given a chance to query the allocation of marks that you received. If issues of mark allocation are not raised in the demo, the mark will not be changed thereafter.
    Projects flagged for plagiarism will be given a mark of zero and the student will be dealt with according to Stellenbosch University's plagiarism policy.

    Coding Conventions

    It is important to stick to sensible coding conventions.

    1. Be consistent. Whatever conventions you choose to use, be consistent. If you deviate from your coding conventions, you will be penalized.

    2. Indent. Indent consistently and neatly.

    3. Choose sensible names. Variables should be named sensibly. This does not mean that all names have to be long and descriptive: under some circumstances, short one-letter names are more appropriate than long names. Static methods must always have descriptive names.

    4. Comment sensibly. Not everything needs to be commented to death, but there should be enough comments (in the right places) so that someone else can read and understand your code.

    Other Resources

    • Sample test files for the first project submission: samples1.zip
    • Sample test files for the final project submission (updated 31 May): samples2.zip
    • Obstacle pieces images for GUIobstacle_images.zip
    • A modified version of the stdlib library provided by the course textbook (Introduction to Programming in Java by Robert Sedgewick and Kevin Wayne) can be downloaded here: stdlib.zip. This modified version must be used for the project.

      To use the sample input and output files, download and unzip the samples given above. For each of the sample files, run your program in text mode and compare its output to the corresponding output file. An example of this is shown below, be sure to replace SU12345678 with SU<your-student-number>.

    • The project code skeleton can be downloaded here: code-skeleton.zip.
    • rw113 plagiarism document to include with your project submission: Plagiarism document rw113
    • rw114 plagiarism document to include with your project submission: Plagiarism document rw114

    Plagiarism

    Each submission will be tested for plagiarism.

    • If your program is flagged for plagiarism in the first submission, and after a disciplinary hearing is confirmed for plagiarism, you will get 0 for the first handin or receive a reduced mark. It will be required that you rewrite your base code (the code for the first submission) before submitting it for the final submission since your code will again be checked for plagiarism in the final submission.
    • If your program is flagged for plagiarism in the final submission, and after a disciplinary hearing is confirmed for plagiarism, you will get 0 or a reduced mark.
    • If your program is both flagged and confirmed for plagiarism, your name will be added to the dean's list of offenders which is a record kept by the university and will remain throughout your university career.

    What constitutes plagiarism?

    • Copying code directly from the internet or from a friend/family member's code
    • Asking friends/family members to write/give you code
    • Paying someone to write your code

    A strategy to avoid plagiarism

    • We do not discourage you from learning from your peers, in fact we encourage this, but we do not accept plagiarism. A helpful strategy to avoid plagiarism is to discuss concepts/ideas/examples with your peers/friends/etc and then take a 10+ minute break to occupy yourself doing something unrelated to the previous discussion. You can then go back to your work and implement it with a fresh mind that allows you to implement the section from your own understanding and to not simply copy a friend's work.

    GUI Screenshots

    Pieces on the board:

    submission format

    Empty stack:

    submission format

    Blue Wins:

    submission format

    Green Wins:

    submission format

    Quit command entered:

    submission format

    Draw:

    submission format

    Red selection box example:

    submission format

    Option choice prompt for shifter:

    submission format

    Result of shifter after clockwise rotation on cell (2,2):

    submission format

    Paintbrush causing green piece to turn grey:

    submission format

    Grey piece returned to stack as well as sink holes present due to bomb:

    submission format

    Sink hole used to return a green piece to the stack:

    submission format