Iteration 10: Distribution using Broker II

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

Medium

Learning Goals

The primary learning goal of this iteration is to implement pass-by-reference handling in the Broker architecture, and do system testing. A secondary goal is to refactor the Invoker code so it uses multi type dispatching.

The project goal is to have a fully distributed HotStone system with the GUI integrated.

Prerequisites

Handling pass-by-reference involves quite a few new moving parts in Broker, and some FakeIt/scaffolding code from 'Broker I' needs to be undone. Be sure to study my lecture slides "W12-1" carefully, or find the lecture on Panopto/Zoom.

Exercises

Broker 2.1. TDD of pass-by-reference methods in Game.

Implement the remaining Game methods that return object references (getHero(), getCardInHand(), getField(), etc.) and use object references in parameter lists (playCard(), attackCard(), etc.) using TDD.

Find details in the report template about how to document your work.

Broker 2.2. System test.

Develop and manually system test/demonstrate that two HTTP based hotstone clients (target: 'hotstoneClient'), each presenting the user with the MiniDraw based GUI can execute properly as a distributed system, connected to the hotstone server (target: 'hotstoneServer') hosting a SemiStone game.

Find details in the report template about how to document your work.

• play cards
• attack with cards
• use the hero power
• end the turn
• refresh the GUI by clicking the 'Opp. Acts' Button
• GUI match game's state correctly

Broker 2.3. Refactor into SubInvokers and implement Multi Type Dispatching.

Refactor the "Blob invoker" from the previous exercise so it is split into subinvokers, and integrate into a full Multi Type Dispatcher system.

Find details in the report template about how to document your work.

Deliveries:

1. Develop on a feature branch named "iteration10" and release using a merge.
2. Document your group's work by following the requirements defined in the iteration 10 report template (pdf) (LaTeX source)
3. Create one approximately 4-8 minutes long screencasts with audio narration, which demonstrates starting your HotStone server, then start two graphical clients, and perform/explain the system tests outlined in exercise Broker 2.2.

Notes and Hints

Getting started

I strongly advice to have a good look at the code base of the GameLobby system as well as the corresponding explanation in the "Flexible, Reliable, Distributed System" book. You should not implement a game lobby system but review the code to get the ideas for how to implement pass-by-reference and name service.

System testing using MiniDraw GUI

Review the process hints and coding hints in the W12-1 slide set.

In summary the exercise entails:

1. Complete the HotstoneGameClient main() program
2. Run HotStoneDrawing in the OPPONENT_MODE mode
3. Refactor the actorMap in HotStoneDrawing so the key is unique card IDs (and the HotSeat program still works.)
4. Create a new Tool that correctly handles tool state, so it allows playing remote games.
5. Implement 'brute force' redrawing when a game mutator method is called, to fix the issue of the missing Observer.

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 10 Grade sheet to evaluate your submission.