Due Date: 03/09/2023

Weighting: 30% of your final mark for the unit

Interview: Week 7 (week starting from 04/09/2023)

Overview: Students will work  independently to create a classic arcade 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      .zip     which     extracts     to     a     folder

na med

_

· 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  extera  library  shou  be  RxJS  libraries  supplied with the  starter  code. · Make sure the code you submit executes properly

● Do not submit the node modules or dis folder s

The marking process will look something like this:

1.Extract <studentNo> <name>.zip

2.  Navigate  into  the folder  named  

3.   Execute   npm   run   dev

4.  Open http://localhost:5173 in  a  browser

Please 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 10% per calendar day, rounded up. Late submissions more than seven days will receive zero marks and no feedback.

Task description

In this assignment, we will use the RxJS Observable stream explored from Week 3 to

create the classic Tetris game in an SVG image. 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 is 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 minimum 10x20 minimum   dimensions

Square  blocks  (2x2)  appear  at the top  of the  board  and  move  down  in  discrete

increments

Descending  blocks  can  be  moved  in  fixed  increments left and right by the  user using  keyboard  controls  (constrained  to  the  board)

Blocks  demonstrate  correct  stacking  behaviour

o     There are  no  overlapping  blocks

o  Blocks  move  down  until  at  least  one  segment  collides with  another  block

below  on  the  same  x  coordinate

o  Blocks  stack  as  a  single  cohesive  piece

-Portions      with no blocks   underneath float  rather than  dropping  down  Game  ends  when  at least one column of  blocks stack  to exceed the top of the grid

Full rows of blocks are cleared and add to the  player's current score

Indicate  the  score  for  the  player

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

Keeps  track  of  high  score  achieved  across  previous  rounds

All Tetris pieces that can be built using 4 blocks

o Note: Since the pieces are no longer limited to 2x2 square blocks, it is now  possible to fill single  rows

Correct  shape  rotation,  according  to  chosen rotation system

Clearly  specify  the  rotation  system  you  decided  to  implement

Next  shape  preview

Upcoming  shape  is  randomly  selected

Smooth  and  usable  game  play.

Able to restart when game finishes

o This  must  not  be done  by  refreshing the  page, and must not be  done  by    recursively  calling  the  main function  (you  should  use  state  management  to handle  this)

The game  increases  in difficulty after some number of rows have  been  cleared o  Increase  block  speed,  or

o  Board  starts  with  existing  blocks/obstacles

See video for an idea of appropriate gameplay

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.

Plagiarism

We will be checking your code against the rest of the class and the internet using a

plagiarism checker. Monash applies strict penalties to students who are found to have     committed plagiarism. Additionally, we will be conducting an interview, which gives you a chance to explain your code and help us understand your code better. As long as you wrote your own code, there is nothing to worry about during the interview process.

Al statement

As per the Al statement on Moodle , use of generative Al in this unit is unrestricted. However, all code generated with Al must be properly cited in the form of code comments stating what has been generated and the scope of its use. You must be able  to demonstrate understanding of all code submitted as part of your assignment, inability to explain any submitted code may result in an academic integrity case.

Additional Information: Marking Criteria and

Suggestions

This section is not essential for completing the assignment, and is provided purely for context and additional information to answer common questions students may have.

Marking (30 marks total)

The goal of this assignment is to assess your understanding of FRP and Functional Programming. The marking has three broad sections:

1. Implementation of game features

2. Usage and understanding of proper functional programming style

3. Usage and understanding of RxJS and Observable

It is important to realise that:

● To can receive a Pass grade by implementing the Minimum requirements,

demonstrating application of functional programming ideas from our lectures and applied sessions.

o You can receive up to a Distinction for perfectly implementing the

Minimum requirements and demonstrating an excellent understanding of

how to use Observable to write clean, clear functional Ul code .

· To achieve a High Distinction, you will need to implement the Full game

requirements

· To achieve the maximum possible marks, you will need to implement the full    game requirements plus some aspect of additional functionality, as described below.

Note that it is essential to follow the submission instructions, as deductions may be applied for failing to follow the submission instructions.

We will mark on 5 sections- Report. Functional Programming style. Code Quality,

Observable and RxJS usage, and Game Features(including advanced features) -that

are individually weighted.

Code that does not use Observable will not get a passing grade; games that use imperative, impure, or mutable code will be heavily penalised.

The rubric and marking guide are provided here.

Report (4 marks)

The  report  is  intended  to  demonstrate  your theoretical  understanding  of functional

reactive  programming,  highlight  design  decisions,  and  help  your  marker  appreciate  the work that you  have  put  into this assignment.

Important  considerations  for  the  report:

● Design  decisions  need  to  be  correct

● Need  to  display  understanding  of  course  material

· Reports  must  demonstrate  knowledge  of  FRP  to  achieve  a  passing  mark

● Marks can be awarded for students identifying issues with the code and how they can be addressed

● Avoid filler  in  the  report,  but  include  enough  information  to  show  your  marker that you  have  understood  the  core  concepts

Functional Programming style (8 marks)

This section is about using what we have covered in lectures and tutorials. This involves concepts   like:

● Smal,   granular   function

· Reusable  functions,  avoiding  duplicate  code

● Purity  /  referential  transparency

● Fluent  interfaces  and  fluent  coding  style

● Manipulation  of  different  complex  types  and  generic  types

● HOF,  curried  functions

● Function    composition/chaining

To achieve the maximum available marks, it is important to not only use advanced functional programming concepts, but do so in a useful way   -for   example,

improving  the  readability  of  the  code  or  following  a  declarative  programming  style.  For

example, simply currying all your functions will  not  receive  marks  unless they are partially  applied  somewhere  and  used  appropriately

You may also attempt to use Lambda Calculus concepts in your code; however, be    careful as they can often just make things hard to understand - it will be important to explain their usage in your report, so your marker can better appreciate your work.

Deductions will  be applied for improper usage of types,  including unjustified "any" types.

Code Quality (8 marks)

This section loosely covers anything to do with how readable and understandable your code is. Applying a good functional programming style tends to increase the readability of your code. It is important that your code can be easily understood to help your marker appreciate your work.

Some examples of what we look at are

· Appropriate line lengths (<80 characters)

· Documentation and commenting(should explain why the code is the way it is)

· Logical structuring of functions and variables, including overall flow of program logic

· Appropriate variable naming

· Consistent and understandable formatting

Using a linter and formatter may help greatly with this section. See below for tips and suggestions.

Observable  and  RxJS  usage  (8  marks)

This section covers usage of FRP - did you use Observable well?

Some important considerations:

· Must manage game state in Observable, and use the scan and merge operators to get a passing mark (please refer to the Asteroids example)

● Usage of Observable as per discussed in the lectures, applied sessions,

workshop, and in the Asteroids example, while maintaining purity, is sufficient for a high mark in this section if implemented very well and without issues

· To achieve the maximum marks available, we want to see interesting and cr eative uses for Observable and RxJS operators (original work)

o This can involve implementing custom Observables and research into the

RxJS operators documentation

o Refer to the marking quide for a breakdown of what is required.

Other considerations:

● Side effects should be contained as much as possible

● Using additional RxJS operators that are not covered in class, or using the ones we introduce in interesting and novel ways, will be awarded additional marks

(given that they are appropriate and useful)

Game Features (2 marks)

This section is about whether your game fulfils the requirements, and the overall complexity of your game (and thus the implementation).

Adding features should not come at the expense of the other criteria - a well

implemented game with fewer features may and, often will, achieve a higher mark than a less well implemented game with more features.

Important: You will receive marks for implementing game features, but this mark will

also cap your total mark.

● The maximum mark possible for implementing minimum game requirements is

70(Distinction)

● The maximum mark possible for implementing full game requirements is 90

●

Some

●

(HD)

To achieve the maximum available marks (90+), you must implement advanced requirements

marking considerations:

Extra features must follow FRP

● Advanced requirements can be not just gameplay but extra FRP features too

· Tests: for full marks, tests need to be comprehensive and not just

simple/random test cases - they should guide development

· Bugs and other gameplay related issues will not be deducted from this section

and be deducted from the total mark

The total mark cap will be increased when implementing additional features. It is  possible to achieve an HD by implementing the minimum game requirements and some full game requirements

To achieve the maximum available marks, features should be significant and change how state is managed in interesting ways. Discussed further below.

Bonus marks are available for particularly novel, impressive, or advanced features. Note that marks cannot exceed 100% of the total available marks.

Rubric

The rubric consists of Marking bands that represent the possible grade values for implementing requirements. This will be a cap on your final mark.

The Marking guide is what TAs will be using to mark your assignment, and what will contribute to your final mark/grade for this assignment.

Marking bands (summary of marking guide)