Assignment 4: Meet Your Match, Part 3: Changing the Game
Due dates:
Implementation: Thursday, February 22 at 8:59pm
Self-evaluation: Friday, February 23 at 11:59pm
Note: Homeworks 5 through 8 will begin a new project, and you will be
working with a partner for them. Start thinking about who you’d like to
partner with. You will sign up with your partner on the handin server, and you
will not be able to submit subsequent assignments until you are part of a team
on the handin server. If you do not know (or remember) how to request teams,
follow
these
instructions. Please request teams no later than the start of homework 5,
which is Feb 26 —
1 Purpose
The benefits of the model-view-controller architecture shine when we need to add new features, by isolating relevant parts of our design and changing them independently. In this assignment we will see those benefits pay off by supporting other forms of SameGame. The goal of this assignment is to give you a chance to critically examine your earlier design choices, and either leverage or revise them to enable adding variations of this game with minimal change and duplication of code.
With one exception (main), all new classes and interfaces for this
homework should be in the cs3500.samegame.model.hw04
package. All classes written in previous assignments, even if improved upon,
should remain in their respective packages.
There will be two submissions for this assignment:
Your actual implementation and full test suite
A self-evaluation, due one day plus three hours later than the actual implementation, where we will ask you to reflect on your implementation and testing choices.
The same late-day policy as on the previous homework applies: each of these submissions independently may use up to one late day, and you are still able to submit your self-evaluation on time even if you submit your implementation late.
You are expected to use your code from the previous assignment as the starting
point for this assignment. However, please ensure all of your new code is
in the cs3500.samegame.model.hw04
package. Additionally, your code from
the previous assignment should remain in the cs3500.samegame.model.hw02
,
cs3500.samegame.view
and cs3500.samegame.controller
packages.
For all implementations below, no method must exceed 50 lines of code!
2 SameGame with gravity
The SameGame implementation described in homework 2 allows pieces to float in space. While simpler to implement, this decision removes some strategy from the game. Mainly, removing a matching block to make room for a bigger one.
You will make a version of SameGame called GravitySameGame
which will force
pieces to fall as long as there is a missing piece beneath them. The game should otherwise
behave like FourPieceSameGame except whenever the game starts or a move is applied, gravity
is applied to any floating pieces.
Suppose the board, after starting the game or making a move, is left in the "Before" state. Gravity will then force the green and blue pieces in the third column to fall as well as the green piece in the fourth column and the other blue and green pieces in the fifth column, resulting in the "After" state. Notice how gravity creates a new matching block, one that would not have been found in our previous implementation.
| ||
Before gravity is applied |
| After gravity is applied |
X G B X X X X X R G X X G B X Y X G B Y G R R X X G B Y R G B Y X G B |
| X G X X X X X X R X X X G B X Y B X X Y G R R G G B B Y R G B Y G G B |
3 SameGame with auto-matching capabilities
SameGame is a predecessor to match-3 games: games that ask the player to
swap pieces to create a matching block of 3 or more pieces. That matching block is then
removed along with any other matching block on the board. You will be implementing
the same mechanism. In this version, whenever a swap or match is made,
the model will remove any existing matching blocks on the board until none are left.
Each match is increases the player’s score as if the player had made the match themselves (i.e. each auto-match is still worth N - 2
points, where N
is the number of pieces in the matching block}.
Consider the example below. The user will try to remove the matching block of red pieces, colored in red. The underlined blue pieces are part of another matching block. Once the user removes the red matching block, auto-matching will remove the blue matching block as well. This increases the score by 4 for the red matching block and then 3 for the blue one, resulting in a score of 7.
| ||
Before |
| After an R matching block |
X G B X X X X X R B B X G B X Y R B B Y G R R R R G B Y R G B Y R G B Score: 0 |
| X G X X X X X X R X X X G B X Y X X X Y G X X X X G B Y X G B Y R G B Score: 7 |
Implement a version of SameGame called AutoMatchSameGame
which will automatically
remove existing matching blocks from the board after the player makes a move. Note this
does not apply to the starting board of the game: all matches there must be left unchanged.
4 Assignment Requirements and Design Constraints
Design classes implementing the Gravity and AutoMatch variants of SameGame. Both classes should clearly implement
SameGameModel
, and clearly share some commonalities with the existingFourPieceSameGame
. In your implementation, strive to avoid as much code-duplication as possible among the three models, while making sure that all three fully work properly. If done correctly, none of your code from before should break or be affected. You may need to refactor your earlier code, though, to make it more flexible and enable better code reuse for these new classes.Design a factory class, named
SameGameCreator
, as described below.Implement a
main
method to allow you to choose different game variants from the command line, when running your program. (This is described below.)If you had to change any part of your design from prior assignments, document those changes in a README file. (This must be a plain-text file.)
Test everything thoroughly: make sure the new models work properly, and that the controller can control them as well as it could the original model. You do not need to test your
main
method.
You must complete these requirements while respecting the following constraints:
You are not allowed to change the interface of the model (
SameGameModel
) at all from before.You are not allowed to change the controller interface (
SameGameController
) at all from before.As before, you are not allowed to add any additional public methods in your classes, with the exception of any expected constructors.
You must create separate model implementations, without eliminating
FourPieceSameGame
from before. That is, models that represent all variations of the game must co-exist.
In this assignment it is important not only to have a correctly working model, but also a design that uses interfaces and classes appropriately. Make sure you minimize replication of code. You may refactor your earlier designs to do this. You may also have to change earlier implementations to remove bugs. This is OK, but must be properly documented and justified.
5 Hints
You should always plan out things in detail before you code. But this assignment is designed to be significantly more difficult if you jump into the code prematurely and try to figure out things as you code!
For each variant, go through each operation of the model interface, and think about how that operation works for this variant of the game. Planning out every operation before coding will save you a lot of time!
Recall that your view needs to be able to work with any model implementation, without knowing which one!
You may be tempted to discover all possible abstractions beforehand. Make sure you minimize code repetition, but not over-abstract so much that some methods lose meaning. Even private helper methods should have a specific purpose! While it is good to anticipate abstraction, there is nothing wrong with thinking about abstraction after implementing all the code. It’s the end result that counts!
6 The SameGameCreator
class
Design a class with the above name. The class should define a
public enum GameType
with three possible values: FOURPIECE
,
GRAVITY
and AUTOMATCH
. It should offer a static
factory method
createGame(GameType type)
that returns an instance of (an appropriate subclass of)
SameGameModel
, depending on the value of the parameter.}
7 The main()
method
Add the following class to your project:
package cs3500.samegame;
public final class SameGame {
public static void main(String[] args) {
// FILL IN HERE
}
}
This main()
method will be the entry point for your program. Your
program needs to take inputs as command-line arguments (available in your
program through the argument args
above). Review the
documentation
for command-line arguments in a Java program.
The first command-line argument must be a string, specifically one of
fourpiece
,gravity
, orautomatch
. This argument will decide which game variant (and hence which model) you should use.The user may optionally pass one, two, or three more arguments
R
,C
,S
, all three of which should be parsed as integers, where R specifies the number of rows of the board, C specifies the number of columns of the board, and S specifies the number of swaps allowed. If unspecified, you should use 10 rows, 10 columns, and 10 swaps as the defaults.
The following are some examples of valid command lines, and their meanings:
fourpiece
produces a basic game of SameGame with four pieces with default number board size and number of swapsfourpiece 10 10 10
achieves the same thing, but explicitly sets the size of the board and the number of swaps.gravity 6 2
produces a game of SameGame with gravity on a board with 6 rows and 2 columnsautomatch 8
produces a game of SameGame with automatch matching with 8 rows and the default number of columns and swapsautomatch 7 8 5
produces a game of SameGame with automatic matching with 7 rows, 8 columns, and 5 swaps
You may add additional methods to your SameGameCreator
class, but
you must maintain the create
methods specified above, for our tests to
compile against your code.
This command-line specification also does not allow for the user to specify a board ahead of time. It is an interesting challenge to think how you might design such configuration options.
This is not an exhaustive list; other command lines are possible.
When you specify command-line arguments, they are always treated as strings, even if they are not within quotes. However, quotes are necessary if you want to pass a string that contains spaces in it.
These arguments will appear in the String[] args
parameter to your
main
method; you can use them however you need to, to configure your
models. For this assignment, you do not need to explicitly handle
invalid command lines (e.g. by producing an informative error message).
However, your code should not crash when given a bad optional argument: that is,
the bad optional arguments must not produce any exceptions. How you choose to handle this
beyond not crashing (e.g. print a message or ignore it) is up to you. However, your
program must throw an exception if the given game type is not valid and can thus crash
in this way alone.
7.1 To actually run your program with command line arguments in IntelliJ IDEA:
Go to
Run > Edit configurations
Click the
+
button in the upper left, and selectApplication
from the dropdown that appears.Give the new configuration a name that you’ll remember (e.g. "Fourpiece 7/3").
In the
Main class
textbox, entercs3500.samegame.SameGame
– the fully-qualified name of the class with yourmain
method.In the
Program arguments
textbox, enter the command line arguments you want to use for this configuration, e.g.fourpiece 10 10 10
Leave everything else at their defaults, and click Ok.
You can repeat this process as many times as you want, to make as many run configurations as you need. Then to choose among them, use the dropdown menu next to the run icon in the toolbar:
and press Run.
8 What to submit
For your implementation: submit a properly-structured zip containing
All your code from before (with as few changes to the classes as possible, and any changes fully explained in comments)
Your implementations of SameGame with gravity and SameGame with automatic matching, and any support classes needed
Your
SameGame
class with themain()
method.Tests for all models in one or more JUnit test classes. It is a good idea to include your earlier tests as well, for regression testing. We certainly will...
Your README file documenting your changes.
Your main class should be in the cs3500.samegame
package,
while all other new
classes and interfaces for this homework should be in the
cs3500.samegame.model.hw04
package. All classes written in previous
assignments, even if improved upon, should remain in their respective
packages.
As with Assignment 3, please submit a zip containing only the src/
and
test/
directories with no surrounding directories, so that the
autograder recognizes your package structure. Please do not include your
output/
or .idea/
directories —
9 Grading standards
For this assignment, you will be graded on
Whether you had to modify any previously written interfaces,
whether your code implements the specifications (functional correctness),
how well your code is structured to avoid duplication, improve readability, etc.
the clarity of your code,
the comprehensiveness of your test coverage, and
how well you follow the style guide.
Please submit your homework to https://handins.ccs.neu.edu/ by the above deadline. Then be sure to complete your self evaluation by its deadline.