FIT2102 Programming Paradigms - Assignment 1: Functional Reactive Programming
FIT2102 Programming Paradigms 2024
Assignment 1: Functional Reactive Programming
Due Date: Friday, 30 August 2024, 11:55 PM
Weighting: 30% of your final mark for the unit
Interview: During Week 7
Overview: Students will work independently to create a game using Functional
Reactive Programming (FRP) techniques. Programs will be implemented in
TypeScript and use RxJS Observable streams to handle animation, user interaction,
and other similar stream behaviours. The goal is to demonstrate a good
understanding of functional programming techniques as explored in the first
five weeks of the unit, including written documentation of the design decisions and
features.
Submission instructions
Submit a zipped file named <studentNo>_<name>.zip which extracts to a folder named <studentNo>_<name>
-
● It must contain all the code for your program along with all the supporting files as well as the report.
-
● It should include sufficient documentation that we can appreciate everything you have done.
-
● You also need to include a report describing your design decisions.
-
● The only external library should be RxJS libraries supplied with the starter
code.
The marking process will look something like this:
1. Extract<studentNo>_<name>.zip
2. Navigateintothefoldernamed<studentNo>_<name> 3. Executenpminstallandnpmrundev
4. Openhttp://localhost:5173inabrowserPlease ensure that you test this process before submitting. Any issues during this process will make your marker unhappy, and may result in a deduction in marks.
Late submissions will be penalised at 5% per calendar day, rounded up. Late submissions more than seven days will receive zero marks and no feedback.
● Make sure the code you submit executes properly.
● Do not submit the node_modules or dist folders.
Git Instructions
We will be using Git for the assignment, however, this will mostly be self directed. There are no requirements on how many commits you need to the repo. However, we do recommend following good practices, and having frequent commits with meaningful commit messages. If any issues arise with academic integrity or submission, this will be used as evidence if you have completed your own work on time, if you have no commits, this will likely make it harder for you to clear yourself of any possible academic integrity issues, so we highly recommend you follow good practices.
The assignment uploaded to moodle, will be used for marking, unless there are exceptional circumstances which prevented you from uploading to moodle, at which point, we will be marking the last version committed to Git before the due date.
The instructions for the setup are posted on Ed, and follow them to setup the repo and access the skeleton code.
Task description
In this assignment, we will use the RxJS Observable stream explored from Week 3 to create the classic Guitar Hero game in an SVG canvas. You will be provided with a starter code bundle similar to the applied sessions, including instructions on usage.
The image above and the Wikipedia page are meant to give you an idea of the gameplay, but yours needn’t look the same or work in precisely the same way, especially with regard to graphics. Note that only a subset of the features discussed in the link will be part of the requirements.
You will also need to write a report, as described below.
Requirements
The game must be implemented in a good functional reactive programming style to get marks. A subset of the game’s features will be required to get a passing grade. A greater subset of features will be required to get a higher grade. To achieve the maximum marks for this assignment, you will have to use a little creativity and add some non-trivial functionality of your own choice.
Minimum requirements
All of these requirements must be reasonably executed to achieve a passing grade
-
- A game board with four columns
-
- Circles appear from the top of the board and move down in a continuous
manner, where each circle aligns with a music note.
-
- Notes can be played by using keys for each note when the circles align with
the bottom row.
○ You can use any keys you want to, but this must be documented
somewhere easy to find for your marker.
-
- Notes are read from the file provided as input to the main function (see Note
Specification for specification)
-
- The timing of the notes must align with the given CSV file.
-
- The notes not for the current instrument, will need to be played in the
background (i.e., without being displayed on the gameboard) at the correct
time.
-
- Notes demonstrate reasonable behaviour
- Each
-
- Each
Appear heuristically (a simple heuristic will suffice) across all four
columns
Notes disappear when they have been played
note is played for the correct duration in which they are played.
If the key press, does not correctly align with a note, it will be played for
a random duration between 0 and 0.5s
time a key is pressed
The correct note must be played if the circles align with the bottom row
Otherwise, a random note is played.
-
- Scores must be kept track during the game, for both hitting and missing notes.
-
- The game should end when the song finishes playing.
-
- A short 1-2 page PDF report detailing your design decisions and use of
functional programming techniques discussed in the course notes
Full Game requirements
Meets minimum requirements and has additional features
- If the note is longer than one second, the notes must have tails, where the tail
represents the length of the note.
-
- The user must hold down the correct key for the length of the tail to ensure it is ‘correctly’ played
-
○ The score will update, iff the note is played for the correct duration
-
○ If the player lets go of the key too early, the note stops playing
-
-
- A score multiplier must be included, starting at 1x and increasing by 0.2 for every 10 consecutive notes hit (e.g., 10 notes = 1.2x, 20 notes = 1.4x), and
resetting to 1x when a note is missed.
-
- Smooth and usable gameplay.
-
- See video for an idea of appropriate gameplay. Note: This is not a full
implementation but is meant to showcase what a game might look like.
Additional requirements
See the Additional Information and How to get a High HD sections. Report
Your report should be 300–600 words in length, plus up to 200 words for each significant additional feature, where you should:
-
- Include basic report formatting headings/paragraphs and diagrams as necessary
-
- Summarise the workings of the code and highlight the interesting parts (don’t just describe what the code does, we can read the source code!)
-
- Give a high level overview of your design decisions and justification
-
- Explain how the code follows FRP style and interesting usage of Observable
-
- How state is managed throughout the game while maintaining purity and
why
-
- Describe the usage of Observable beyond simple input and why
-
- Important: Need to explain why you did things
-
- Do not include screenshots of code unless you have an exceptional
reason
-
- This should be concise and straightforward, you may use dot points
Your marker will be instructed to stop reading if your report is too long, and only mark the first 600 (+200 per feature) words.
