COSC1076 | Semester 1 2020
Advanced Programming Techniques
Assignment 2 (v1.1)
Programming Project (Azul)
Weight: 50% of the final course mark
Group Registration: Week 7 Lab
Progress Updates: Weekly (with your tutor during labs)
Group Deliverable Due Date: 11.59pm Friday 22 May 2020 (Week 11)
Individual Deliverable Due Date: 11.59pm Friday 5 June 2020 (Week 13)
Written Report Due Date: 11.59pm Friday 5 June 2020 (Week 13)
Presentation Marking: Week 14, by registered time slot
Learning Outcomes: This assignment contributes to CLOs: 1, 2, 3, 4, 5, 6
Change Log
1.1
• Removed reference to linked list in Suggestions section.
1.0
• Initial Release
• Group Deliverable
• Written Report and Demonstration
• Enhancements to be released at a later date
1
Contents
1 Introduction 3
1.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Group Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Academic Integrity and Plagiarism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Milestone 1: Base Gameplay (Group Component) 5
2.1 Base gameplay Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Save Game Format and Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Example Base Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Suggestions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.1 User Prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.2 Tiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.3 Game Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.4 Tile Bag Box Lid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.5 Launching the program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.6 Main Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.7 Starting a New Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.8 Load a Game from a file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.9 Credits (Show student information) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.10 Quit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.11 Typical Gameplay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.12 Starting a Round of Azul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.13 A Player’s Turn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.14 End-of-round . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.15 End-of-game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.16 Saving the Game to a file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Milestone 2: Enhancements (Individual Component) 12
4 Milestone 3: Written report Demonstration 13
4.1 Group Component of the Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 Individual Component of the Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5 Managing Group Work 15
5.1 Group Work Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1.1 MS Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1.2 Git Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1.3 Optional Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2 Weekly Progress Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.3 Weekly Update Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.4 Notifying of Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6 Writing and Sharing Tests within your Lab 17
7 Getting Started 18
8 Submission Marking 19
8.1 Notes on Marking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.2 Late Submissions Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.3 Special Consideration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.4 Group Work Penalties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2
1 Introduction
1.1 Summary
In this assignment you will implement a 2-player text-based version of the Board Game Azul .
(a) Qwirle box and pieces
(b) Example game state
For an explanation of the rules and gameplay:
• Review and rules explanation: by SUSD (Youtube)
• Rules explanation: by Dice Tower
• Official Rules: Online Website
In this assignment you will:
• Practice the programming skills covered throughout this course, such as:
– ADTs
– Data Strcutres (Arrays, Vectors, Liked Lists, Trees, etc.)
– Dynamic Memory Management
– File Processing
– Program State Management
– Exception Handling
• Practice the use of testing
• Implement a medium size C++ program:
– Use features of C++14
– Use elements of the C++ STL
• Work as a team
– Use group collaboration tools (MS Teams, Git, etc.)
This assignment is divided into three Milestones:
• Milestone 1, Base Implementation (Group work): In your group of 3, you will implement a fully
functioning version of the base Azul gameplay. This will also include writing tests that show your imple-
mentation is fully functional. The group component is due 11.59pm Friday 22 May 2020 (Week 11). The
group work is worth 30% of the course mark.
• Milestone 2, Enhancements (Individual work). You will individually extend upon your groups base
implementation with additional functionality (called enhancements). The individual component is due
11.59pm Friday 5 June 2020 (Week 13). The individual work is worth 20% of the course mark.
• Milestone 3, Written report (no more than 4 pages) Demonstration. You will write a report
that analyses the design and implementation of your software. The report is sue 11.59pm Friday 5 June
2020 (Week 13). As a group you will demonstrate your group’s work and each individual’s enhancements.
This is where your final work will be graded. Demonstrations will be held during Week 14.
3
The marking rubric shows which elements of the assignment contribute to your group and individual marks.
! To be fair to all groups and avoid giving a head-start, the specification and requirements for the individualcomponent will be released in Week 11.
1.2 Group Work
This group work component completed groups of 3. All group members must be from the same Lab. There
will be no exceptions to this requirement1. Your group must be registered (with your tutor), by your Week
7 Lab. If you are unable to find a group, discuss this with your tutor as soon as possible.
If at any point you have problems working with your group, inform your tutor immediately, so that issues
may be resolved. This is especially important with the online delivery of the course. The weekly progress
updates are for communicating the progress of your group work. We will do our best to help manage group
issues, so that everybody receives a fair grade for their contributions. To help with managing your group work
we will be requiring your group to use particular tools. These are detailed in Section 5.
!
There are very important requirements about keeping your tutor informed of your individual progress,
and if you have been unwell or otherwise unable to contribute to your group (Section5.2).
Remember your actions affect everybody in your group. If you fail to keep us informed, you may
individually receive a lower grade.
To complete this assignment you will require skills and knowledge from lecture and lab material for Weeks 7 to
10 (inclusive). You may find that you will be unable to complete some of the activities until you have completed
the relevant lab work. However, you will be able to commence work on some sections. Note that the mark for
your group work requires consistent work throughout all weeks. Thus, do the work as you can, building in new
features as you learn the relevant skills.
1.3 Academic Integrity and Plagiarism
! CLO 6 for this course is: Demonstrate and Adhere to the standards and practice of Professionalism andEthics, such as described in the ACS Core Body of Knowledge (CBOK) for ICT Professionals.
Academic integrity is about honest presentation of your academic work. It means acknowledging the work of
others while developing your own insights, knowledge and ideas. You should take extreme care that you have:
• Acknowledged words, data, diagrams, models, frameworks and/or ideas of others you have quoted (i.e.
directly copied), summarised, paraphrased, discussed or mentioned in your assessment through the ap-
propriate referencing methods
• Provided a reference list of the publication details so your reader can locate the source if necessary. This
includes material taken from Internet sites. If you do not acknowledge the sources of your material, you
may be accused of plagiarism because you have passed off the work and ideas of another person without
appropriate referencing, as if they were your own.
RMIT University treats plagiarism as a very serious offence constituting misconduct. Plagiarism covers a variety
of inappropriate behaviours, including:
• Failure to properly document a source
• Copyright material from the internet or databases
• Collusion between students
For further information on our policies and procedures, please refer to the RMIT Academic Integrity Website.
The penalty for plagiarised assignments include zero marks for that assignment, or failure for this course. Please
keep in mind that RMIT University uses plagiarism detection software.
1The reason for this is the group updates will be with your tutor each week during labs. These groups updates inform your
final grade. Thus, restricting groups to labs allows us to ensure you can attend the weekly updates, practically manage the groups,
help ensure everybody is on-track and address group issues.
4
2 Milestone 1: Base Gameplay (Group Component)
In your groups you will produce an implementation of the “base” Azul gameplay. This section lists the compo-
nents that your group must implement. Generally, it is up to your group to decide the best way to implement
these components. However, there are some important requirements that your group must satisfy.
!
For the aspects of this specification that are flexible and open to your interpretation, it is up to your
group to determine the best course of action. You will need to analyse and justify your choices in your
group’s written report.
2.1 Base gameplay Requirements
Your group will implement a base Azul gameplay which is defined as:
• A 2-player game, ONLY.
• Both players are “human users” that play the game by interacting the the terminal, that is through
standard input/output.
• Using the original/default Azul Mosaic, with a fixed colour pattern. This is the colour mosaic as picture
in Section 1.1. (Note this pattern is the same for all players).
• Use 5 factories (plus the central factory) as specified in the Azul rules for a 2-player game.
• Automatic moving of tiles to the mosaic and scoring of points at the end of a round.
In addition to the above gameplay, your base implementation must provide the following functionality:
• A main menu, that allows users to perform actions such as setting up a new game, loading an existing
game, showing “credits” (details of the people who wrote the software), and quitting the program.
• Save a game in-progress to a file.
• Load a previously saved game from a file, and resume gameplay from the saved state.
• A way to provide a seed to the random number generator in your program to “turn off” and randomness
in the program.
• A way to represent and display the Azul mosaics and factories to the user.
• A User prompt for entering all commands from standard input.
• Provide sufficient help to the users about how to use your program (that is help for the commands that
can be entered at the user prompt), For this you may assume that the users know the rules of Azul, and
just need to know how to use your program.
• Full Error checking of all user input (and save-game files). It a user ever enters an invalid command, your
program should notify the user of the reason their input is incorrect and resume operation in a suitable
manner. Your program must never crash or exit unless:
– The user explicit requests for the program to terminate.
– The EOF character is given on standard input.
! Of course your program must also be error free, should not segfault, crash, or contain logic errors.
How your group implements the above functionality is mostly up to you. This includes the Data Structures,
ADTs, Classes and STL libraries you choose to use. However, as part of this course is about analysing data
structures, you are required to use a particular set of data structures in your implementation. Thesemandatory
requirements are:
• You must use at least one linked list to store or represent some aspect of the game.
• You must use at least one C++ STL vector to store or represent some aspect of the game.
• You must use at least one 1D or 2D array to store or represent some aspect of the game.
• You may only use the C++14 STL. You may not incorporate any additional libraries.
Remember, that in your report your group will be marked on the justifications and analysis of the above choices.
You need to be careful which data structures that you choose to represent the aspects of Azul, and the reasons
behind these choices.
! Your program must stick to this base functionality as enhancements is part of Milestone 2.
5
2.2 Save Game Format and Testing
The layout of saving a game to a file to very important. You will need to be able to test if your program is
correct. For testing, we will use the load/save game functionality. That is, you can load a game from a file, then
execute a given set of commands, before saving the game. A test can then compare the contents of the saved
game file against an pre-determined saved game to see if the files match and the program functioned correctly.
Section 6 describes this in more detail. In particular, in labs you will be designing the format of the save-game
file. This means that groups in your lab can share tests! This way it will be easier for everyone to check their
programs are running correctly.
! Hopefully, you will be sharing tests with other groups in your lab!
2.3 Example Base Program