Assignment 9: Third Time’s a Charm – Three Trios, part 5

Due dates:

• Implementation: before your demo

• Demo: schedule with instructors/TA

There is no self-eval for this assignment, though you will still submit it on the handin server. For evaluation, you will schedule a brief demo with one of the instructional staff. Available time slots will be posted on a Google document with a link on Piazza.

We prefer you complete this assignment with your partner, but if you need to work on it on your own, contact us in advance. We strongly prefer that you present your work together with your partner. If only one of you can attend, you must let us know in advance.

This assignment asks you to implement four sets of features for four levels of extra credit. The levels are somewhat dependent, and also increase in difficulty. Each level is all-or-none: either it works perfectly or it doesn’t. However there are points in each level for designing well, in addition to working correctly.

All extra-credit functionality must be well-designed and tested, to the ability of that feature to be tested. (GUI functionality is hard to test directly, but any related interfaces or classes must be testable and tested.) Also, all extra-credit functionality must work simultaneously: you must not have to comment code out and recompile your program in order to enable different features. You may use different command-line arguments, toggleable menu items, or other UI choices to select among your features.

1 Level 0: Showing scoring hints

As an assist to players, enable a “hint” mode where once the current player selectes a card, each card cell on the grid shows how many cards would be flipped if that card was played on that cell.

Below are examples of hints for the red player that change

Hints must be enableable and disableable at runtime, and for each player independently: you should not have to restart the game to turn hints on or off, and (obviously!) hints for one player should not be shown to the other player. For proper design, you must not modify your rendering code directly to add these hints; it must be a separate decoration that you can add or remove.

2 Level 1: Variant Rule Set 1

In this level, you will reimplement a model that allows for the following variant battle rules to take effect, possibly at the same time. These rules change how the attack values result in capture.

• Reverse: Normally, the game flips Card B if Card A’s attack value is greater than Card B’s attack value in the opposing direction. Now the game flips Card B if Card A’s attack value is less than Card B’s attack value in the opposing direction.

• Fallen Ace: Now a 1 on the current player’s card can beat an A on the opponent player’s card.

Note that when both are applied, this means an A can beat a 1 (because that is the Reverse of the Fallen Ace rule).

These variant rule sets must be applied on the command line. If none are given, the unmodified version of the game is played.

For proper design, both your variant model and your regular model must implement the same model interface(s), and must coexist in your code without e.g. commenting one out and recompiling the other. As with all models, this must be decently tested. Furthermore, you cannot simply make models for all combinations. We have better design patterns we can apply in this case to make for a cleaner design.

3 Level 2: Variant Rule Set 2

In this level, you will reimplement a model that allows for two additional variant battle rules to take effect, but NOT at the same time as each other because they change the criteria under which cards are flipped. For ease, these rules only apply before the combo step. Further note that if two cards match the criteria below, but one of them already belongs to the current player, then only the opponent’s card is flipped.

• Same: Let there be a list of cards adjacent to card A (in the 4 directions of the game). If at least two of those cards share the same value in the opposing direction of card A, then any of those same value cards that belong to the opponent are flipped.

  For example, say we have the following cards, where A was just placed by RED

  • Card A: NORTH is 5, SOUTH is 4, EAST is 3, WEST is A

  • Card B north of A: SOUTH is 6, owned by BLUE

  • Card C south of A: NORTH is 4, owned by RED

  • Card D east of A: WEST is 1, owned by BLUE

  • Card E west of A: EAST is A, owned by BLUE

  In this scenario, A and C, as well as A and E have the same values in those opposing directions. Therefore, E gets flipped. Note that D is also flipped under the regular rules as well.

• Plus: Let there be a list of cards adjacent to card A (in the 4 directions of the game). Consider the sum of two cards in opposing directions as the sum of the attack values in card A and another card in opposing directions. For instance, if card B is above card A, then we look at the sum of the SOUTH attach value of B and the NORTH attack value of A. If at least two cards adjacent to A have the same sum with A in their respective opposing directions, then any of those cards that belong to the opponent are flipped.

  For example, say we have the following cards, where A was just placed by RED

  • Card A: NORTH is 5, SOUTH is 4, EAST is 3, WEST is A

  • Card B north of A: SOUTH is 5, owned by BLUE

  • Card C south of A: NORTH is 6, owned by RED

  • Card D east of A: WEST is 7, owned by RED

  • Card E west of A: EAST is 1, owned by BLUE

  In this scenario, A and B, A and C, and A and D all have sums of 10. Therefore, B gets flipped. E does get flipped under the regular rules as well.

These variant rule sets must be applied on the command line. If none are given, the unmodified version of the game is played.

For proper design, both your variant model and your regular model must implement the same model interface(s), and must coexist in your code without e.g. commenting one out and recompiling the other. As with all models, this must be decently tested. Furthermore, you cannot simply make models for all combinations. We have better design patterns we can apply in this case to make for a cleaner design.

4 Level 3: Combining Both Sets of Variant Rules

In this level, you must modify your design such that someone can play a game with one or both of the variant rules from Set 1 alongside exactly one of the variant rules from Set 2. If you designed the previous levels well, this will be trivial. Note for this level, that means both levels 1 and 2 must both work flawlessly and have a proper design to even get credit.

Proper design should allow you to essentially decorate the model or pass in how to perform the variant rules. This new model design must also be decently tested.

5 Evaluation

You will demo your work to the instructional staff. Please come to your demo slot prepared. You should not have to modify your source code during the demo to demonstrate features (e.g. if you have all four levels working, but you must comment them in or out to demonstrate them, that is not acceptable). Re-running your program with different command-line options to show different levels is acceptable.

You will explain the architectural changes you made to the instructor or TA who is grading you.

You will submit your code to the handin server before you are scheduled for your demo. Please include a readme file explaining which features you implemented and which files were affected, so the grader can quickly orient themselves when you arrive.

6 Grading standards

This assignment will be graded out of a total of 12 points:

• 1pt automated code style (earned only if you demo, no points for simply submitting something!)

• Level 0: 2pts (1pt if the feature works flawlessly, 1pt if it is well designed)

• Level 1: 3pts (1pt if the feature works flawlessly, 1pt if it is well designed, 1 pt if it is reasonably tested)

• Level 2: 3pts (1pt if the feature works flawlessly, 1pt if it is well designed, 1 pt if it is reasonably tested)

• Level 3: 3pts (1pt if the feature works flawlessly, 1pt if it is well designed, 1 pt if it is reasonably tested)

Each of these individual grade items are all-or-none. In particular, clean code that is not properly functioning will not receive those points; likewise correctly functioning code that is poorly designed will not receive those points. As stated above, to receive credit for a feature, it must work completely. Two half-finished feature levels are worth zero points. Focus your attention on making each part of this assignment work well, rather than spreading yourselves too thin across several incomplete features.