> 2
Enter the filename from which load a game
>
Azul game successfully loaded

It is highly recommended to conduct validation checks such as:
1. Check that the file exists.
2. Check that the file contains a valid game.
To load a game, your program will need to read the contents of the saved game file, and update all data
structures in the program. Specifically, the program should take note of:
• The player’s name and scores
• The state of the factories and player mosaic’s
• The order of the tiles in both bags
• The current player - the next player to take a turn
Once the game has been loaded, gameplay continues resumes with the current player.
2.4.9 Credits (Show student information)
The program should print the name, student number, and email address of each student in the group.
2.4.10 Quit
The program should safely terminate without crashing .
2.4.11 Typical Gameplay
In Azul, 2 players take turns drawing tiles from factories and placing them in storage on their individual mosaic,
starting with the first player. Once all tiles a drawn, the round ends and scoring automatically happens. Scoring
should happen automatically. Then either the next round commences, or the game ends (including the end-
of-game scoring).
10
2.4.12 Starting a Round of Azul
At the beginning of a round, the factories need to be filled by drawing tiles from the Tile Bag. To ensure con-
sistency (and help with testing), your might want to fill factories in order, starting with factory 1. Remember,
if the tile bag runs of out tiles, then all of the tiles from the Box Lid are placed back into the Tile bag. Don’t
forget to add the 1st-player marker should be added to the “centre” factory (number 0).
2.4.13 A Player’s Turn
A player might take their turn using the command such as
turn
The command contains three elements:
1. A number of the factory to draw from
2. The colour to take from the factory
3. The row in the mosaic storage to place the tiles
After the player enters the turn command, the game should:
• Validate that the turn is legal, checking the player’s action against all of the rules of Azul
• Update the game-state based on the player’s turn, then continue with the next player’s turn.
2.4.14 End-of-round
Once all tiles have been drawn from the factories, the program should:
• Move tiles from each player’s storage to their completed mosaic grid, as per the rules of Azul. (Don’t
forget to move excess tiles to the Box Lid)
• Update the players score as the tiles are moved.
• Subtract points for broken tiles (Don’t forget to move these tiles to back to the Box Lid).
You might want to then show:
• The mosaic for each player
• How many points each player scored on that round
• How many total points each player has
The game play then either:
• Proceeds to the next round. Remember to re-fill the factories from the tile bag!
• If the end-of-game condition is met (that is, one player has finished a full row of their mosaic), termi-
nates gameplay, showing the winner.
2.4.15 End-of-game
If the end-of-game condition is reached (at least one player has completed a whole row of their mosaic), then the
game ends. Don’t forget to complete the end of game scoring, in particular, for completed rows, columns,
and colour sets. You should then show the winner.
2.4.16 Saving the Game to a file
At any point during gameplay, the current player may save the game to a file using a command such as:
save
Your program should save the current state of the game to the provided filename (overwriting the file if it
already exists).
The format for the saved-game is up to you to decide in your labs.
! Remember that you will decide the format of the file in your labs to that you can share tests!
11
3 Milestone 2: Enhancements (Individual Component)
In Milestone 2, as an individual you will expand on the functionality of your group’s Azul program. You
will select your enhancements from a suggested list, to be provided around Week 11. You may also negotiate
potential enhancements with your tutor.
Enhancements will be classified as minor or major. Minor enhancements are smaller in scope, and require
only a small modification to your software design. Major enhancements are large in scope, and require signif-
icant modifications to your software design. Enhancements only count towards this Milestone if they are fully
functional and error-free. Additionally, if you break your Milestone 1 implementation, this will count against
your Milestone 1 grade. So, be careful to make sure everything you have done is working.
You will commence this work after your group submits their assignment.
! Enhancements will be released around Week 11. This specification will be updated in this section oncethis announcement is made.
12
4 Milestone 3: Written report & Demonstration
Your group must write a report, that analyses what your group has done in this assignment. Additionally, each
individual must write a short report that analyses their individual enhancement(s). The report is due at the
same time as the individual submission.
• The report should be A4, 11pt font, 2cm margins and single-space.
• The section of the report describing the group’s work must be no more than 4 pages.
• Each individual must add 1 additional page about their individual work (ie, their enhancements).
• Thus the final report must not exceed 7 pages (for a group of 3).
• Only the first 4 pages (group), and 1 page (individually) will be marked. Any contents in the report that
is over-length will not be marked. Modifying fonts and spacing will count as over length.
• Figures, Tables and References count towards these page limits.
In this assignment, you are marked on the analysis and justification of the choices you have made for different
aspects of your assignment. Your report will be used (in conjunction with the demonstration) to determine the
quality of your decisions and analysis.
Good analysis provides factual statements with evidence and explanations.
Statements such as:
“We did because we felt that it was good” or “Feature is more efficient”
do not have any analysis. These are unjustified opinions. Instead, you should aim for:
“We did because it is more efficient. It is more efficient because . . . ”
4.1 Group Component of the Report
In the group section of your report, you should discuss aspects such as:
• Your group’s use of at least one linked list, and the reasons for where the linked list is used.
• Your group’s use of at least one C++ STL vector, and the reasons for its use.
• Your group’s use of at least one 1D or 2D array, and the reasons for its use.
• Your group’s choices of ADTs, and how these leads to a “well designed” program.
• The efficiency of your implementation, such as the efficiency of your use of data structures.
• The reason for the tests that your group contributed to the lab.
• Your group co-ordination and management.
4.2 Individual Component of the Report
In the individual section of your report, you should discuss aspects such as:
• The design of your enhancements, including any changes (and additions) to the data structures and ADTs
you had to make when enhancing your group’s base implementation.
• The efficiency of your enhancements, such as the efficiency of your use of data structures.
• Limitations and issues that you encountered with your group’s base implementation.
• The overall quality of your individual work.
!
Analysis is about breaking down your work into its parts and then determining how those parts:
• are necessary and serve a purpose
• interrelate with each other
• affect the structure and performance of your program
4.3 Demonstration
During Week 14, your group will demonstrate and discuss your Azul program to your tutor and/or lecturer. In
your demonstration you should:
13
• Demonstrate your base Azul gameplay implementation by running the program.
• Demonstrate how your test cases prove your implementation is correct
• Discuss the design and efficiency of your software
Additionally, each individual will demonstrate their individual enhancements by running their program.
• Each individual student will be required to make a short demonstration.
• They should not be interrupted or assisted by other students during this time.
Each presentation will be 20 minutes long. Make sure you prepare for the demonstration and have a plan of
what you want to show. It is up to your group to decide how to best conduct this presentation. The purpose
of the presentation is to demonstrate and convince the assessor of the quality of your group’s software, each
individual’s enhancements and the quality of your overall work. In particular for your group work, you are
marked on how well you demonstrate what your group did, how easy it is to understand your group’s work, and
how honest you are about limitations and issues your group encountered.
14
5 Managing Group Work
! Having effective group work will be critical to the success of your group and reducing your stress levels.
This group assignment will (most likely) be conducted entirely online, without you ever meeting your group
members face-to-face. This isn’t a problem. What changes is the way you (and your group) must manage
yourselves and work together. The challenge for you is not using online apps, it is using those apps effectively.
You will need to make extra efforts and be very dedicated and diligent in working with your team
members. This will include setting up dedicated times for meetings, group programming session, and even just
hanging out.
! This 5 Minute Video from the Minute Physics YouTube channel contains a number of really good sug-gestions for how to work effectively as a team from home.
5.1 Group Work Tools
To help manage your group work, and demonstrate that you are consistently contributing to your group, we
are going to require you to use a set of tools3. Your first group update will including setting-up these tools.
5.1.1 MS Teams
Each group will be required to create a team on the RMIT MS Teams platform. Your group must add your
tutor to your MS team. You may also set up various channels to discuss aspects of the assignment.
Your MS team will be the only official communication platform for the assignment. This means you must:
• Keep the weekly tutor update spreadsheet in the Files section of the “General” channel.
• Only us the MS Team channels for group chats
• Hold all team meeting through MS Teams
• Record all team meetings
If there are disputes over group work, we will use the record on MS Teams as the source of evidence.
5.1.2 Git Repository
Your group must have a central private Git repository that hosts your group’s code for the assignment. This
may be on BitBucket or Github. Your group must add your tutor to this repository. This git repository will
be used as the evidence of your individual contribution to your group. Therefore your commits will be used
as the evidence of your work. Git has officially been taught as a tool in this course (see the Week 5 Echo360
videos), therefore there is no excuse for having insufficient individual contributions recorded in Git4.
For the individual component you may make either a new branch or fork of this repository before commencing
your individual work.
5.1.3 Optional Tools
These tools may optionally be used by your group. However, they must be linked to your group’s MS Team.
• Trello, for task allocation and management
• MS Planner, to layout weekly work
5.2 Weekly Progress Updates
Every week during your lab, you will update your tutor on your group’s progress. You can discuss:
3These requirements are different from previous year’s. However, we know working fully online will be a new experience, so we
are putting some very clear rules in place.
4“A sufficient contribution” does not necessarily mean a large number of commits. It means you have contributed a sufficient
amount of work to the group, and this work is evidenced by commits you have made.
15
1. The stage of implementation that your group has achieved
2. Your individual progress and contributions
3. Your software design and implementation
4. Any issues that have arisen
The final grade for your group-work will be informed by these notes, however, the grade will not be decided
until the demonstration in Week 14.
5.3 Weekly Update Record
Part of this update will the weekly progress record. This is a spreadsheet that will officially record you groups
weekly progress. It will be stored in your group’s MS team. A template for this record is provided on Canvas.
Before your update each week, you (and each member of your group) will need to fill-in this record with:
• Your contributions for the week.
• Any issues that your have encountered through the week.
During the update with your tutor they may add additional notes to the record.
The record also tracks if your group is on-track with the assignment. Each week there are a series of tasks which
your group should complete by the Friday of that week5. Your tutor note if your group is:
• Ahead of schedule
• On-track
• Falling behind schedule
• Well-behind schedule
Additionally, as we are using Git, in the update for week N, your group can show what you achieved by Friday
of week (N-1), which is especially useful for labs that are earlier in the week.
If you are unable to attend an update, then you must still fill in the record, and this will be used as your update
for that week. You should review any comments from your tutor.
The tasks for each week are flexible if your group does run into issues, such as a student being sick. If you do
tell us of issues you can negotiate with your tutor for revising the weekly tasks so that you still finish on-time.
Note your tutor won’t grant an extension, instead, the tasks will be re-arranged.
5.4 Notifying of Issues
If there are any issues that affect your work, such as if you are unable to contribute for some weeks (eg. being
sick), you must keep your group informed in a timely manner. Your final grade is determined by you (and
your group’s) work over the entire period of the assignment. We will do our best to treat everybody fairly, and
account for times when issues arise when marking your group work and contributions during the demonstrations
in Week 14. However, you must be upfront and communicate with us.
!
You must keep both your group and your tutor informed of any reasons that you are unable to contribute
to your group, in a timely fashion, that is, as soon as you are able. If you fail to inform us of issues
and we deem that your actions significantly harm your group’s performance, we may award you a reduced
grade. It is academic misconduct if you are deliberately dishonest, or otherwise lie to and mislead your
group or teaching staff in a way that significantly harms your group.
5As labs are held on different days, there will be different expectations for each day. Friday labs will need to be mostly finished.
Wednesday classes should be well on track to finishing. Monday classes will need to show they have started the week’s task, and
have a suitable plan to finish.
16
6 Writing and Sharing Tests within your Lab
A big challenge in this project is making sure your software is fully functional and correct. To do this you
will need an ability to test your program. There are many ways of going about this. For the purposes of this
assignment we will use a similar black-box testing to assignment 1. However, instead of using standard I/O, we
will use file I/O through the save/load functionality.
Still, writing a lot of tests will be hard work. Thus to help, you are going to be writing tests with your labs.
By the end of this sharing process, your lab should have a pretty comprehensive set of tests. Your group will be
marked on how well they contribute to the sharing of tests. To do this, however, your lab will need to decide
on a format for the save-game file. Your group’s Azul program should then both load a game from this format,
and save a game using this format. Note that because of this, the tests for every lab will be different.
! During Weeks 7 & 8, your lab will decide on a format for the save-game file. From Week 8 onwards,your group will be sharing your test cases with other groups in your tutorial!
Once the saved-game format is determined, a single test is then 3 files:
• An input file to load a game.
• A file with a command (or series of commands) representing the user(s) making moves in the game.
• An expected output file which is the game state once the commands are run and the game state saved.
The file of commands to run, can be given through standard input. it might look something like below:
2
test.input
turn 2 B 3
save test.output
Of course, the commands might be slightly different depending on what your group does. This means as you
share tests with your lab, you might need to adjust the commands file so it works with your group.
To help your lab make the saved-game file format, you might want to think about representing things such as:
• Factories, including the centre factory. Note factories might be empty.
• Mosaics, including the storage grid, partially-filled grid, and broken tiles.
• Tile Bag contents.
• Box Lid contents.
• Player details, including name, and score.
• Current player
• Ability to provide a comment about the file (such as at the very top of the file)
17
7 Getting Started
This assignment requires you and your group to make a number of design choices including:
• Where to use linked lists, vectors and arrays
• How to create ADTs
• The format for getting input from the user
It is up to your group to determine the “best” way to implementing the program. There isn’t necessarily a single
“right” way to go about the implementation. The challenge in this assignment is mostly about software design,
not necessarily the actual gameplay.
It is very important that you think about these ADTs early in your work. In an early group update you will
need to show your tutor the classes and ADT interface methods that your group would plans to use for the
assignment. These ADT methods should be detailed enough so that your tutor can see how your group can
develop a base implementation of Azul.
Since you may not have designed many pieces of software before, to help you get started, we recommend that
you think about ADTs for the following aspects:
• Game - This store all of the state of a game of Azul. You will need to think about where you load and
save a game state. This could be inside the Game ADT, or another part of the code that uses methods of
the Game ADT.
• Factories - An ADT within Game that stores all information about the factories. You should think about
if you need a further AFT for an individual factory.
• Mosaic - An ADT within Game that stores one mosaic for a player, including the storage rows, mosaic
grid and broken tiles.
You can get help about your ideas and progress through the lab updates. This is where you can bring your
ideas to your tutor and ask them what they think. They will give some and ideas for your progress.
18
8 Submission & Marking
To submit, follow the instructions on Canvas for Assignment 2.
8.1 Notes on Marking
The marking rubric is available on Canvas. You notice there are not many marks for “trying” or just “getting
started”. This is because this is an advanced course. You need to make significant progress on solving the task
in this assignment before you get any marks. Additionally, the HD+ category is reserved for the absolute best
programs and groups. If you are aiming for full marks, your assignment needs to be impressive, and one of the
best in the course.
The purpose of this is for you to focus on successfully completing each Milestone one-at-a-time.
8.2 Late Submissions & Extensions
For Milestone 1, the late submission penalty is built into the marking rubric.
For Milestone 2, late submission accrue a penalty of 10% per day up to 3 days, after which you will lose ALL the
assignment marks. This penalty is applied to the full mark of the assignment, NOT the individual component.
Extensions will not be given for this assignment.
8.3 Special Consideration
!
In addition to special consideration processes, you are required to keep your group and tutor informed
of when you are unable to contribute, in a timely manner . If you apply for special consideration, but
do not notify of issues before doing so, then you have failed to keep everybody informed.
Where special consideration is granted, generally it is awarded on an individual basis, not for the entire group.
Extensions of time will not be granted, instead an equivalent assessment will be conducted which may take the
form of a written or practical test. Further, to ensure equivalence of assessment, this equivalent assessment will
only count towards the non-group components of the Assignment 2 rubric. The group-work component will be
assessed based on your group participation for the duration of Assignment 2 for which you were unaffected and
able to contribute. This will take into consideration how well you kept your group informed of your ability to
work and contribute to the group.
8.4 Group Work Penalties
In severe cases of poor group work, we may undertake the following actions:
• We may apply an individual mark to any or all categories of the rubric, rather than using one mark for
the whole group. This may include a reduced individual grade.
• If we determine that a student has been deceitful or untruthful in a manner than has a severe adverse
academic impact on the other students in the group, either wilfully or by ignorance, we may file a charge
of academic misconduct.
!
Be aware that:
• All activity on MS Teams, Github and group collaboration tools
• Weekly Group updates
are official records and will be used as evidence of your group participation for the purposes of academic
judgement and marking.
19