►Assignment 6: Pawns on the World Stage – Pawns Board, part 2
Assignment 6: Pawns on the World Stage – Pawns Board, part 2
1 Purpose
2 Preparation:   fixing up your models
2.1 Making your models read-only
2.2 Adding missing functionality
3 Visualizing the game
3.1 Required appearance
3.2 Required behavior
3.3 Running your view
3.4 Testing your view
4 Strategic computer players
4.1 Required behavior
4.2 Extra credit
4.3 Testing your strategies
4.3.1 Mocking your model
5 What to do
6 What to submit
7 Grading standards
8 Submission
8.9

Assignment 6: Pawns on the World Stage – Pawns Board, part 2

Due dates:

Starter files: code.zip

1 Purpose

In this portion of the project, you will be building a visual view of your game, and also start building the computer strategies for playing the game. This assignment has several parts. Look over the outline on the left, and skim through the whole assignment, before diving deeply into any one section. The assignment lists requirements in the recommended order you should do them, but future tasks might give you ideas for how to improve earlier ones.

2 Preparation: fixing up your models

2.1 Making your models read-only

As we discussed in class, views should not have the ability to mutate the models they are viewing: this would bypass the controller, making it impossible to reliably control the model.

Refactor your model interface, if necessary, into two interfaces: your PawnsBoardModel interface (or whatever you named it) should now extend a ReadonlyPawnsBoardModel interface (again, choose a name that matches your existing model). The read-only interface should contain all the observation methods of your model, while the mutable sub-interface should contain all the mutator methods.

2.2 Adding missing functionality

The following is a non-exhaustive checklist of functionality that is necessary for Pawns Board to work properly. Your model interface(s) may not yet expose all of these as methods, or might not make it easy to use.

Reexamine the design and implementation of your model from the previous assignment, and improve it to include the functionality above. Document whatever changes you made in a new section of your README, entitled “Changes for part 2” — explain what functionality was missing, and why, and how you chose to add it.

3 Visualizing the game

To implement your view, you will need to use Java Swing. (You are not permitted to use the javalib library we used in Fundies 2, as it conflates the notions of model, view and controller into a single World class. You are also not permitted to use JavaFX, as that has been deprecated and is overly complicated as well.) The code provided with the MVC code and the Turtles activity from class give you a basic beginning using Swing, as well as the exercises in Lab 7.

You have also been provided with an extensive list of different Swing layouts, components, and their uses in the code linked at the start of the assignment. If you need a more visual way of seeing Swing things done, here is a video covering a lot of basic Java Swing components and listeners. Note that if you try to write your code in the way shown in the video or in the way shown in the given code above, you will not do well on the assignment. The video does not follow our design rules nor style rules nor separates code properly into the three components. The code given has no helpers at all nor follows any of our design considerations.

You will likely need to design at least one, and possibly three, interfaces for your view: one should describe what the frame ought to be capable of, and one for each panel might be needed to describe what the panel ought to be capable of. (These may be empty interfaces for now, if you do not see a need for any methods in them yet...but keep reading below for additional ideas.) Note that your textual rendering from the previous assignment does not have to implement this new GUI view interface, and you do not have to force it to do so.

3.1 Required appearance

Your view should give as much information as the screenshots below, but the physical appearance is up to you. Consider the following screenshot which shows the start of the game. Notice we can see the board and the pawns on each, row-scores, and the hand of the Red player.

Here is a view of the game mid-game, also on Red’s turn:

Here is a view of the same game mid-game, but on Blue’s turn. Notice that Blue’s cards have their influence grid already mirrored.

And reminder that the game can be more than 3 rows with 5 columns. Here is an example with 7 rows and 11 columns with a starting hand size of 10 cards, totaling 77 cells PLUS the 11 cards that must be displayed at once (remember the red player draws one card at the start of their turn).

You may decorate the image if you wish, or adjust the color palette, or even change the font, or change how the cards themselves are displayed, but it should still contain the same information as the above. That means a user can easily identify the following:

Here is an example of an alternative view that shows the same information without the same level of polish as the above.

You will notice the following

The point is your view doesn’t need to be exactly the same as the fancier one and do as much drawing. You can get away with drawing much, much less and then add the polishing features as you please.

Looking through the documentation of the Graphics2D class, you’ll find several useful methods for drawing text, lines, ovals, images, and shapes; and for transforming the coordinate system (scaling, translating and rotating) to affect where drawings are placed. We recommend building a subclass of Path2D.Double that represents “a card” of whatever size makes sense in your view. You can then draw multiple such cards wherever needed to make up your rendering: this will be much easier than attempting to draw all the individual edges of the cards separately.

The size of drawn strings is controlled by the size of the font used in the Graphics2D object. I suggest reading up on the Font class to find methods to help change the font size to whatever works best as you resize the window. Furthermore, you cannot print newlines with drawString. Instead, take a look at this Stack Overflow question on how to visualize a newline.

3.2 Required behavior

Your view should have a constructor that takes in a ReadonlyPawnsBoardModel — not the mutable interface! — to ensure that your view is incapable of modifying the model even accidentally.

In preparation for the next assignment (where you will build a controller that delegates to the model and view), you should equip your view with the ability to handle mouse clicks and key presses. This means you will need a stub controller to stand in for the real thing and respond to the events. In particular,

Your view should let the user deselect a selected card in hand or cell on the board by

Clicking outside the boundary of the grid or the hand must not cause your view to crash, throw an exception, or otherwise break.

You may want to revisit the discussion of the observer pattern from Lecture 14: The Observer Pattern, and this may influence your view interface designs. This will also help you plan out your true controller ahead of the next assignment.

Finally, we should be able to resize your window larger and smaller and all of the above functionality should still work correctly. Note you are not responsible for the visual artifacting (read: anything that looks weird) that can occur at extremely small or large sizes.

3.3 Running your view

Add the following placeholder class to your project:

package cs3500.pawnsboard;

public final class PawnsBoardGame {
  public static void main(String[] args) {
    YourModel model = ...create an example model...
    YourView view = new YourView(model);
    ...whatever other setup you need...
    view.setVisible(true); //or the equivalent in your system
  }
}

As we’ve done several times, our main() method simply instantiates a model, instantiates a view using that model, instantiates anything else needed, and tells the view to get started. In later assignments we will augment this to create controllers, players, and make the game playable.

3.4 Testing your view

Testing views can be quite tricky, since you cannot simply use JUnit assertions to check them for “equality”. For this assignment, you do not need to unit-test your visual view, but you should include in your submission at least four screenshots of your view, each screenshot being of a 5 row and 7 column game:

Name the screenshots appropriately, so you and graders can easily tell what they represent. Also, make sure the screenshots are reasonably sized (e.g 600 px height is the height used for the screenshots on this page). There is no reason to have a 4K png of your view.

4 Strategic computer players

Playing Pawns Board for any amount of time quickly leads to noticing two aspects of the strategies required for key play: which card to choose and then where to place the card.

  1. Fill first: Choose the first card and location that can be played on and play there.

  2. Maximize row-score: Choose a card and location that will allow the current player to win a particular row by making their row-score higher than the opponent’s row-score. Rows are visited from top-down. If the current player has a lower or equal row-score than their opponent on that row, this strategy chooses the first card and location option that increases their row-score to be greater than or equal to the opponent’s row-score. If there is no play that would make the current player's row-score greater than the opponent's, move on to the next row. If after visitng all rows, there is still no move to make, report there is no move to make (meaning the player should pass).

  3. Control the board: choose a card and location that will give the current player ownership of the most cells. In a tie between positions, choose the uppermost-leftmost (so uppermost first, then leftmost). In a tie between cards, choose the leftmost (or closest to first) card.

  4. A fancier approach might choose the move that leaves their opponent in a situation with no good moves. (This approach minimizes the maximum move the opponent can make, and is known as a minimax strategy.) To calculate the "best" move an opponent can make, you must make some guess as to what strategy that opponent is using...and it might be any of these strategies we’ve seen so far.

(There are far more sophisticated strategies than these, but these will do for now!)

4.1 Required behavior

Implement the first two of these strategies. Note that those two strategies cannot have tied choices. If there are no valid moves, your player should pass.

Hint: Keep in mind that a strategy needs to know which player it’s trying to pick a move for!

You must test these strategies, and in particular demonstrate that it resolves ties correctly.

Hint: You may have an easier time implementing your strategies if you generalize their signature somewhat: Unlike the Tic Tac Toe strategies, where moves didn’t have a numerical value, moves here do have a potential score. The possibility of ties in some strategies implies that your strategy’s signature should return more than just a single move possibility...

4.2 Extra credit

As we discussed with Tic Tac Toe, you can chain these strategies to form strategies of varying sophistication. A simplistic strategy would just use option 1; a smarter strategy might stack on options 2 and 3, as well to further break ties in option 1. Some of these strategies may result in multiple, equally-good options: in case of such ties, again choose the move with the uppermost-leftmost location first and then the leftmost card in the hand.

Some of these strategies may result in no valid moves: you must figure out how to represent such situations and what they should (eventually) do in the model.

Your task to get extra credit:

In your README, explain what the extra credit strategies you implemented were and where we can find their implementations and tests. If your README does not state this, you will get no extra credit.

4.3 Testing your strategies

The elegant feature of strategies is that they are simply function objects, and so they are eminently testable. Build a collection of example games in known configurations, ask each strategy where it would choose to move for a given player, and check that the result is as expected.

If you’ve implemented multiple strategies, test them thoroughly: in particular, make sure you test scenarios that demonstrate the differences between them.

4.3.1 Mocking your model

One of the challenges of testing your strategies is that they depend on your model working correctly: the model needs to implement the complicated game logic of legality checking and scoring, and if those are buggy, your strategies may give unexpected results. But obviously, you can’t execute a strategy without some model object to examine!

In class we discussed mocks, that are stub implementations of interfaces that can give simulated answers and that can record a transcript of what methods were used. Here are two ideas for mocking your model; you should use these (and probably several more) to test your strategies:

5 What to do

  1. Refactor your model to split it into read-only and mutable interfaces.

  2. Design your view interfaces, and then begin implementing your views.

  3. Design your strategy interface(s) and implementation(s). Test them, using mocks of your models as necessary.

  4. Update your README file to include explanations of all the new classes you’ve designed. Be sure to include a “Changes for part 2” section documenting what you changed from your initial design.

6 What to submit

To create a JAR file, do the following:

7 Grading standards

For this assignment, you will be graded on

8 Submission

Please submit your homework to https://handins.ccs.neu.edu/ by the above deadline. Then be sure to complete your self evaluation by its due date.