Iteration 8: Frameworks and MiniDraw

Deadline

At 23.59 on the day that your class has agreed with the TA.

Any late hand-in must be agreed with your TA; failing to do so will allow the TA to reject evaluating your hand-in.

Workload Estimate

High

Learning Goals

The learning goals of this week is frameworks aspects: analyzing your current HotStone system as a framework, as well as adding a graphical user interface for HotStone using the MiniDraw framework.

Prerequisites

Ensure you have completely solved the Observer pattern exercise from Iteration 7. If not, you will never get the GUI running!

Carefully read FRS 37.7 "Frameworks" as it details the design you are required to implement, and the support code. You must carefully merge your own code with the provided code base 'hotstone-framework-start (ZIP)' code, the link is given below. See the hints below.

My slides from Week 9 on "HotStone GUI" provides further details and hints on the exercises.

Exercises

Frameworks

Analyse whether your HotStone production code is a framework, using the framework characteristics.

1. Contrast HotStone with the characteristics of frameworks (Section 32.2).
2. Find examples of frozen and hot spots.
3. Find examples of TEMPLATE METHOD in your HotStone

... as detailed in the Iteration 8 report template below.

Merge MiniDraw Starter Code

Download the hotstone-framework-start (ZIP) and merge it carefully into your HotStone project using the process I outline below in the Hints section. If you just extract the zip in your HotStone folder, you will overwrite some of your existing code!

From Domain to GUI

This exercise is partially solved in the handed-out code base.

Complete the implementation of the provided but incomplete HotStoneDrawing class such that all state changes in a Game are observed and reflected in proper GUI updates.

Visual test class: ShowUpdate (package: hotstone.domain2gui), gradle target: update. Be sure to read the details in FRS 37.7.3!

It is advisable to integrate directly with a simple, real HotStone variant (for example AlphaStone) compared to using a Test Double/FakeObject. See the explanation in FRS 37.7.3.

From GUI to Domain

This exercise is partially solved in the handed-out code base.

Complete the implementation of the MiniDraw Tools such that all graphical interactions are translated into the correct game mutator calls.

Visual test class: ShowTools (package: hotstone.gui2domain), gradle target: tools. Be sure to read the details in FRS 37.7.4!

SemiStone System Testing

Develop a complete GUI based SemiStone for system testing: Combine your developed SemiStone variant from the previous mandatory sprints with the solutions to this iteration's exercises.

Main class: HotSeatStone, gradle target: hotseatstone. Executing this target should start a full HotStone game in hotseat mode, allowing you to play with a group member. Congratulations :).

Deliveries:

1. Develop on a feature branch named "iteration8" and release using a merge.
2. Documentation for your work on framework analysis by following the requirements defined in the iteration 8 report template (pdf) (LaTeX source), including any backlog items you have.
3. Create one 6-12 minute screencast that details your solution to the SemiStone System Testing. Specifically, your screencast must be structured with
   1. Intro: State your names and group name
   2. Execute your 'hotseat' target and demonstrate "playing a couple of turns" involving card play, minion attack, hero power use, and swapping players/ending turns.
   3. Explain how your code handles updating graphics correctly when a minion attacks another minion, by running the 'update' target showing this aspect; next show and explain the HotStoneDrawing code which handles the respective observer notifications ('onAttackCard()', 'onCardUpdate()', etc.)
   4. Explain how your 'MinionAttackTool' works by running the gradle target 'tools' and demonstrating how the game's method is called; next show and explain the tool's code.
   In your screencast, you should clearly indicate which of the above parts you are about to cast ("We next describe item 4: The code for our MinionAttackTool looks like this, ..., and here we see it in action as we drag a minion ..." etc.).

Notes and Hints

Merge MiniDraw code into your existing code base

You have developed a lot of code, and now comes a new ZIP with even more code which poses the challenge of overwriting stuff. Be sure to make an 'integration' branch of your code and merge/extract the Zip file there, so you can "Do Over" in case it messes up.

I advice to unzip the supplied framework starter code in a distinct folder, and test that you can run the visual targes, like ShowText etc., correctly, before you merge. Take small steps, Keep Focus.

The process is that you can simply unzip or copy the contents of the Zip file onto your own code base (ensure that folders align up). This WILL overwrite some of your implementation files (probably 'StandardHotStoneGame.java' and 'TestAlphaStone.java'), so keep a backup ready or selectively merge from your main branch.

Next compile and test, and fix all issues until all is fixed. Run also the visual tests, like 'gradle update', etc.

When all your own test cases work; and the newly added programs run (ShowTools, etc.); then merge back into your main branch and push to the repository.

playCard() and DropZone

If you play HearthStone or have tried playing the PiStone variant on the HotStone server, you know that many card effects modify minions next to the position where the card is dropped on the battle field. This is the reason for the atIndex parameter of the playCard(who, card, atIndex) method in Game - it allows playing the card where the benefit is greatest.

How does this translate to the MiniDraw UI? The provided code has a class DropZone which can translate graphical (x,y) coordinates to a proper index. You can use it like the following example shows in your PlayCardTool:

  @Override
  public void mouseUp(MouseEvent e, int x, int y) {
    // Note: no check if draggedActor is null, as it is guaranteed
    // Invoke related facade method, if figure is a card
    boolean isHittingField = y < GfxConstants.Y_LIMIT_OF_FIELD;
    boolean moveCardBack = true;

    if (isHittingField) {
      Card associatedCard = draggedActor.getAssociatedCard();
      int index = DropZone.computeFieldIndexOfDropPosition(editor.drawing(),
              draggedActor.displayBox().getX(),
              draggedActor.displayBox().getY());
      ....
              
        

In the code above, the index will be assigned the proper value to pass on to the playCard() method.

Alternatively, just always drop the card at index 0.

Evaluation criteria

Your submission is evaluated against the learning goals and adherence to the submission guidelines. The grading is explained in Grading Guidelines. The TAs will use the Iteration 8 Grade sheet to evaluate your submission.