Match-3
Objectives
- Read and understand all of the Match-3 source code from Lecture 3.
- Implement time addition on matches, such that scoring a match extends the timer by 1 second per tile in a match.
- Ensure Level 1 starts just with simple flat blocks (the first of each color in the sprite sheet), with later levels generating the blocks with patterns on them (like the triangle, cross, etc.). These should be worth more points, at your discretion.
- Creat random shiny versions of blocks that will destroy an entire row on match, granting points for each block in the row.
- Only allow swapping when it results in a match. If there are no matches available to perform, reset the board.
- (Optional) Implement matching using the mouse. (Hint: you’ll need
push:toGame(x,y)
; see thepush
library’s documentation here for details!
Demo
by Edward Kang
Getting Started
Download the distro code for your game from cdn.cs50.net/games/2018/x/projects/3/match.zip and unzip match.zip
, which should yield a directory called match
.
Then, in a terminal window (located in /Applications/Utilities
on Mac or by typing cmd
in the Windows task bar), move to the directory where you extracted match
(recall that the cd
command can change your current directory), and run
cd match
A Match (3) Made in Heaven
Welcome to your fourth assignment! There was a lot to learn with timers, tweens, and more in this lecture, but unfortunately, 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 Saga!
Specification
- Implement time addition on matches, such that scoring a match extends the timer by 1 second per tile in a match. This one will probably be the easiest! 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! - Ensure Level 1 starts just with simple flat blocks (the first of each color in the sprite sheet), with only later levels generating the blocks with patterns on them (like the triangle, cross, etc.). These should be worth more points, at your discretion. This one will be a little trickier than the last step (but only slightly); right now, random colors and varieties are chosen in
Board:initializeTiles
, but perhaps we could pass in thelevel
variable from thePlayState
when aBoard
is created (specifically inPlayState:enter
), and then let that influence whatvariety
is chosen? - Create random shiny versions of blocks that will destroy an entire row on match, granting points for each block in the row. This one will require a little more work! We’ll need to modify the
Tile
class most likely to hold some kind of flag to let us know whether it’s shiny and then test for its presence inBoard:calculateMatches
! Shiny blocks, note, should not be their own unique entity, but should be “special” versions of the colors already in the game that override the basic rules of what happens when you match three of that color. - Only allow swapping when it results in a match. If there are no matches available to perform, reset the board. There are multiple ways to try and tackle this problem; choose whatever way you think is best! The simplest is probably just to try and test for
Board:calculateMatches
after a swap and just revert back if there is no match! The harder part is ensuring that potential matches exist; for this, the simplest way is most likely to pretend swap everything left, right, up, and down, using essentially the same reverting code as just above! However, be mindful that the current implementation uses all of the blocks in the sprite sheet, which mathematically makes it highly unlikely we’ll get a board with any viable matches in the first place; in order to fix this, be sure to instead only choose a subset of tile colors to spawn in theBoard
(8 seems like a good number, though tweak to taste!) before implementing this algorithm! - (Optional) Implement matching using the mouse. (Hint: you’ll need
push:toGame(x,y)
; see thepush
library’s documentation here for details! This one’s fairly self-explanatory; feel free to implement click-based, drag-based, or both for your application! This one’s only if you’re feeling up for a bonus challenge :) Have fun!
How to Submit
When you submit your project, the contents of your games50/projects/2018/x/match
branch must match the file structure of the unzipped distribution code exactly as originally received. That is to say, your files should not be nested inside of any other directories of your own creation or otherwise deviate from the file structure we gave you. Your branch should also not contain any code from any other projects, only this one. Failure to adhere to this file structure will likely result in your submission being rejected.
By way of a simple example, for this project that means that if the grading staff visits https://github.com/me50/USERNAME/blob/games50/projects/2018/x/match/src/Board.lua
(where USERNAME
is your own GitHub username as provided in the form, below) we should be brought to the Board.lua
file for Match-3. If that’s not how your code is organized when you check (e.g., you get a 404 error or don’t see your edits), reorganize your repository as needed to match this paradigm.
- If you haven’t done so already, visit this link, log in with your GitHub account, and click Authorize cs50. Then, check the box indicating that you’d like to grant course staff access to your submissions, and click Join course.
The change to /projects/2018
below is intentional, as CS50 courses have changed to a scheme that reflects when the project was initially released. So the 2018 here is correct, even though it’s no longer 2018!
-
Using Git, push your work to
https://github.com/me50/USERNAME.git
, whereUSERNAME
is your GitHub username, on a branch calledgames50/projects/2018/x/match
or, if you’ve installedsubmit50
, executesubmit50 games50/projects/2018/x/match
instead.
-
Record a screencast, not to exceed 5 minutes in length (and not uploaded more than one month prior to your submission of this project) in which you demonstrate your app’s functionality. Upload that video to YouTube (as unlisted or public, but not private) or somewhere else.
- To aid in the staff’s review, in your video’s description on YouTube, you should timestamp where each of the following occurs in your gameplay demonstration. This is not optional; failure to do this will result in your submission being rejected:
- Shiny match destroying a row/column
- To aid in the staff’s review, in your video’s description on YouTube, you should timestamp where each of the following occurs in your gameplay demonstration. This is not optional; failure to do this will result in your submission being rejected:
There is no need to play this game super fast and demonstrate how good you are at it. We want to see features being demonstrated, not game proficiency. If you race through the game so fast and the staff can’t determine what’s going on, your submission will fail. Slow it down.
You can then go to https://cs50.me/cs50g to view your current progress!