Assignment 2: Match 3

• 💯 Worth: 6%
• 📅 Due: See due date on Moodle.
• 🚫 Penalty: Late submissions lose 10% per day to a maximum of 3 days. Nothing is accepted after 3 days and a grade of 0% will be given.

🎯 Objectives

• Read and understand all of the Match 3 notes and source code.
• Implement time addition on matches such that scoring rewards the player by extending the time they have to complete the level.
• Gradually add new patterned tiles as the player progresses through the levels. Tiles of a higher pattern should be worth more points.
• The star tile should be a very rare tile that will destroy an entire row on match, granting points for each tile in the row.
• Only allow swapping when it results in a match.
• Implement a “hint” feature such that when the player presses h, it will reveal a pair of tiles that can be swapped to create a match.
• Allow the player to play with their mouse instead of the keyboard.

🔨 Setup

1. Fork (do not download as a zip) the starter repository from GitHub. Make sure you use the link from Moodle to fork the proper repository for this assignment.
2. Start Live Server in VSC by right-clicking on index.html and selecting Open with Live Server. This will open a new tab in your browser with the game running.

🔍 Context

To complete this assignment, you should read and understand all of the Breakout notes and source code and be familiar with the following concepts and classes:

• Tweening: Understanding how to smoothly animate objects on the screen within a given timeframe.
• Timer: Understanding how to create a timer that can be used to track time.
• Input: Understanding how to handle user input via the keyboard or mouse.
• Sounds: Understanding how to load and play sounds.
• Fonts: Understanding how to use load and display fonts.
• Image: Understanding how to load and display images.

Caution

If you’re not comfortable with any of the above, please send me a message on Teams and I can help you! It is your responsibility to ensure you have learned all concepts we’ve seen so far so that you can do the assignment effectively.

Welcome to your third assignment! There was a lot to learn with timers & tweens, but our game is still lacking in a few areas. By extending its functionality, we’ll have something even closer to famous titles such as Bejeweled and Candy Crush!

✅ Requirements

Note

Make sure you’re logged into Moodle to play the videos below. However, don’t just go off of the video! Make sure you understand the feature and read the descriptions before implementing it. The video is just there to give you a visual representation of what the feature should look like.

⏰ Time Addition (15%)

Implement time addition on matches, such that scoring a match extends the timer. You decide how much time is appropriate to reward the player with on each match.

Tip

Currently, there’s code that calculates the amount of points you’ll want to award the player when it calculates any matches in PlayState::calculateMatches(), so start there.

Deduction	Criteria	Details
(-0)	Correct	Confirm that time is only awarded when a valid swap is made.
(-2)	Time is awarded to the player even on an invalid swap.	Make an invalid swap and verify that no additional time is given.
(-1)	Time is awarded inconsistently.	Perform multiple valid swaps and check that the time added is consistent each time.
(-X)	Other reason detailed in comments.
(-4)	N/A

🌈 Patterned Tiles (15%)

Ensure level 1 starts just with simple flat tiles (the first of each colour in the sprite sheet), with later levels generating the tiles with patterns, one new pattern per level. These should be worth more points, at your discretion.

• Level 1: Flat, Star (See star tile in next section)
• Level 2: Flat, Cross, Star
• Level 3: Flat, Cross, Circle, Star
• So on and so forth.
• To detect a match, you’ll still only have to check the colour of the tile; the patterned tiles only change the amount of points gained.
• For example, a flat tile (🟩) could be worth 10 points and a cross tile (❎) could be worth 20. A match that was 🟩❎🟩 (all the same colour of course) would be worth 40 points.
• Patterned tiles should spawn just like flat tiles as the game is played. Meaning, don’t only generate patterned tiles at the start of the level.

Tip

Right now, colours and patterns are chosen in Board::generateTile(). One idea could be to pass in the level variable when a Board is created, and let that influence what pattern is chosen for the given level.

Deduction	Criteria	Details
(-0)	Correct	Ensure that only flat tiles are present on level one, and that more complex tiles (cross, circle) appear in later levels.
(-2)	Level one started with more than just the flat tiles.	Test the game from the beginning and confirm that level one contains only flat tiles.
(-1)	Patterned tiles are not increasingly worth more than previous tiles.	Verify that tile values increase with complexity: flat < cross < circle, etc. Check the scoring system after matches. This one might be easier to check the code than to play multiple levels.
(-X)	Other reason detailed in comments.
(-4)	N/A

🚫 Disallow No-Match Swaps (15%)

Only allow swapping when it results in a match. They way you let the player know it’s an invalid move is up to you, but you should have both a visual and audio cue.

Tip

The simplest way is probably just to try and test if there was a match after a swap and revert back if there was no match. Look in /assets/sounds for a sound that you can play when the player tries to make an invalid move. You can use your own sound if you’d like.

Deduction	Criteria	Details
(-0)	Correct	Try to swap two tiles that do not create a match and confirm the game does not allow the swap.
(-4)	Player is able to make invalid swaps.	Test multiple invalid swaps and ensure none are accepted.
(-2)	No audio or visual feedback is given when attempting an invalid swap.	Check if there is any sound or visual cue (e.g., shaking tiles) when attempting an invalid swap.
(-X)	Other reason detailed in comments.
(-4)	N/A

🐭 Mouse Input (15%)

Allow the player to play with their mouse instead of the keyboard.

• When the player moves their mouse over the board, the tile underneath the mouse should be outlined, the same as when the players presses w/a/s/d.
• When the player clicks on a tile, the tile should be selected, the same as when the player presses the Enter key.
• This feature can be see in the star tile demo video below.

Tip

Use the Input class’s mouse methods to get where the mouse position is, if the mouse was clicked, and use that information to highlight and select tiles.

Deduction	Criteria	Details
(-0)	Correct	Move the mouse over the board and confirm that the correct tile is selected on click.
(-2)	The board cursor does not follow the mouse position.	Move the mouse over the board and ensure the cursor aligns with the correct tile.
(-2)	The tile underneath the mouse is not selected when the mouse is pressed.	Click on a tile and confirm that the correct tile is highlighted or selected.
(-X)	Other reason detailed in comments.
(-4)	N/A

⭐ Star Tile (30%)

The star tile (the last of each colour in the sprite sheet) should be a rare tile that will destroy an entire row or column on a match (depending on the match direction), granting points for each tile in the row or column.

• For example, if you have a match in a column of 3 orange tiles, one of the tiles in the match being an orange star tile, then that entire column should be removed and points should be awarded for every tile in that column, regardless of if they’re orange or not.
• Take care to make sure the points are being added up correctly and that no tile is being counted multiple times.
• No, you do not need a fancy animation for the star tile, but you can if you’d like.
• Star tiles should spawn just like other tiles as the game is played. Meaning, don’t only generate star tiles at the start of the level.
• You’ll notice in the video below that clearing a row with the star tile is 65 points. This is because the star tile is worth 30 points and the rest of the flat tiles are 5 each, so 30 + 5 * 7 = 65.

Tip

First, think about how to generate the star tiles such that they show up on every level but are rare. Second, you’ll have to detect that a match contains a star tile when running Board::calculateMatches() and remove the entire row or column.

Deduction	Criteria	Details
(-0)	Correct	Test a match that includes a star tile to confirm the entire row/column is removed.
(-3)	When a horizontal match contains a star tile, the whole row is not removed.	Create a horizontal match with a star tile and ensure the whole row is removed.
(-3)	When a vertical match contains a star tile, the whole column is not removed.	Create a vertical match with a star tile and ensure the whole column is removed.
(-1)	The points for the entire row/column are not calculated correctly.	Make sure the points awarded include all tiles in the row/column when the star tile is matched. The star tile itself should be worth more points than a flat tile.
(-X)	Other reason detailed in comments.
(-10)	N/A

❓ Show Hint (30%)

Show the player a hint when they press the h key. A hint is showing the player 2 tiles they can swap which will result in a match. The way you display the hint is up to you; it can be a simple rectangle or a fancy animation using timers and tweens.

Tip

One way to do this is to loop through the board, do a temporary swap in memory (i.e. not visually), check if that resulted in a match, then revert the swap.

Deduction	Criteria	Details
(-0)	Correct	Verify that hints are working and displayed correctly in the UI.
(-1)	The number of available hints is not displayed in the UI.	Check if the remaining hint count is visible and updated when hints are used.
(-1)	The player can use an unlimited number of hints per level.	Ensure that there is a limit to how many hints can be used per level.
(-4)	When the player presses ‘h’, there is no visual indication that reveals two tiles that can be swapped for a match.	Press ‘h’ and confirm that two swapable tiles are visually indicated (e.g., highlighted, flashing).
(-X)	Other reason detailed in comments.
(-6)	N/A

📝 Dev Log (5%)

You’ll find a .devlog.md file in the project root. This file is your design diary. It’s where you document how you approached the assignment, what decisions you made, what challenges you encountered, and how you worked through them, including how you used any AI tools.

This is not a summary of your final product (that’s what your code and commit messages show). Instead, it’s a reflection of your process and thinking.

What to write:

• What approach you chose and why
• Any bugs or roadblocks you encountered and how you solved them
• How you tested and verified your implementation
• If you used AI tools (e.g. ChatGPT, Claude, Copilot), describe:
  • What you asked
  • What it returned
  • What you kept or changed
  • Include links to relevant chat logs when possible

What makes a good devlog:

• Specific technical insights (e.g. “I struggled with connecting the AI paddle’s movement to the ball’s position. I solved this by…”)
• Honest reflection on what you understood and what confused you
• Commentary on any AI output you received, what was useful, what wasn’t

What makes a weak devlog:

• Restating the assignment prompt
• Only describing what the final code does, without process
• Hiding or omitting AI tool usage
• Generic statements with no technical substance

Be concise. Bullet points are fine.

Caution

This must not be generated by AI since I’m looking for your personal reflection.

Criteria	Standard
Process Reflection	Clear explanation of approach, design decisions, and problem-solving steps
Technical Detail	Specifics about code structure, logic, or bugs encountered and fixed
AI Usage Disclosure	Clearly explains how AI was used, what was kept/changed, with reasoning
Insight & Critical Thinking	Thoughtful reflection on what was learned, understood, or found challenging
Clarity & Format	Concise, readable, well-structured with bullet points or short paragraphs

🤖 AI Involvement Category

At the top of your .devlog.md, you must declare your AI involvement category by selecting the option that best describes how you used AI during the assignment:

Category	Description
No Use	You did not use any AI tools at any point.
Tutor	You used AI to explain code, concepts, or errors. No code was generated by AI.
Assistant	You asked AI for code suggestions or snippets and integrated them with understanding.
Reviewer	You wrote the code yourself, then used AI to review, critique, or suggest improvements.

Danger

You must explain your AI usage in your .devlog.md. If you used AI but do not disclose it, that will be considered academic dishonesty.

💬 Peer Assessment (5%)

You’ll use the Moodle Workshop feature to give feedback on 3 of your peers’ submissions. Peer assessment is a core developer skill. Reading others’ code and giving constructive feedback is something you’ll do constantly in real software teams. It also helps you improve your own work by seeing how others solved the same problem.

Note

If you believe you’ve been unfairly assessed by a peer, come see me. I’ll review your case and make sure your grade reflects a fair and accurate evaluation.

💻 Code Walkthrough

For each assignment, I will randomly select a few students for a short (10-15 minute) one-on-one code walkthrough. You’ll be asked to explain your implementation, reflect on your design decisions, and answer a few questions. This helps ensure understanding, promotes academic integrity, and prepares you to communicate your work which is an essential skill for every developer. You can be selected for any assignment, so always be ready to walk me through your code.

🌿 Git

We will be using GitHub and Gradescope to submit in this course. You can use either the Git CLI or you can also use VSC’s built-in Git GUI client.

	Visual Studio Code (GUI)	Command Line (CLI)
1	Click the Source Control icon (third down on the left sidebar)	git status - View changed files
2	Click + to stage all changes, or + next to individual files	git add . or git add <filename> - Stage changes
3	Type a commit message in the text box, then click the ✔ to commit	git commit -m "Your message" - Commit staged changes
4	Click ... and choose Push to upload your commit to GitHub	git push - Push commits to GitHub

Commit frequently. It’s good practice, and it also creates a traceable history of your progress.

📥 Submission

Once you’ve made your final git push to GitHub, here’s what you have to do to submit:

1. Go to Gradescope, click the link for this assignment, select the correct repository and branch from the dropdown menus, and click Upload.
2. Go to Moodle and click the link for this assignment in the calendar.
3. Click the blue Add Submission button at the top of the workshop page.
   1. Title: A2 Match 3 Submission.
   2. Submission content: Describe which features you implemented in the description of the workshop submission along with anything your reviewers should know about your game/code.
   3. Zip your assignment folder and attach it as a file. To ensure anonymity:
      • DO NOT include your name in any of the files or folders
      • DO NOT include the .git folder before zipping, otherwise it will contain your commit history which has your name and email in it
      • Optionally, you may include your .devlog.md file if you want to share your design diary with your reviewers
4. Click the Save changes button at the bottom.
5. You’ll be able to start assessing your peers the day after the assignment is due.