Due date: 3/17 @ 3pm

Objective: to gain experience with a passive model-view separation and to deepen your understanding of the observer pattern

Note:Thus far, the assignments concerned the model of the game only. If you already made an attempt to visualize the game, you probably tried to "test via looking." This is a bad idea, which is why I strictly design in a "model-first" manner. This is also what we teach now in CSU211. -Even if you have tried to implement a visualization, you will -- still have to reorganize your code to fit the observer protocol. See below.

---

The Observer Interface: The model-view architecture assumes that you have strictly separated your system into components that implement the actual data manipulation and those that visualize (and often allow interaction with) the model. A visualization component is naturally an observer, just like the player. This suggests the refactoring of the interface hierarchy:

  (define observer<%>
    (interface ()
      other-score-and-token ;; Follower Number Number -> Void 

      placed-follower ;; tile<%> Follower Position -> Void 
      ;; some player placed f on t at position p 

      placed-tile ;; tile<%> -> Void 
      ;; some player placed t during a turn 
      ))

  (define player<%>
    (interface (observer<%>)
      take-turn ;; turn<%> -> Void
      
      score-and-token ;; Number Number -> Void 

      inform ;; String -> Void 
      ))

Now the player consists of two pieces: a player proper and an observer that watches other players as they play.

Task 1: Implement this reorganization with a separation of player proper and observer. [POINTS: 5]

Additional Information: Implementing the visualization observer requires a modification of the server:

   (define admin<%>
    (interface ()
      ... 
      
      register-observer ;; observer<%> -> Void 
      ;; sign up an observer for the game
      
      get-graph ;; -> drawable-graph<%>
      ;; get the drawable graph from the admin 
      ))

  (define drawable-graph<%>
    (interface ()
      left ;; -> Number
      ;; the left-most x coordinate

      top ;; -> Number
      ;; the top-most y coordinate

      list-of-tiles ;; -> Listof[tile<%>]
      ;; the list of tiles that make up the graph
      ))

That is, the administrator must now accept an additional kind of observer and it must allow this observer access to the graph (in a controlled manner via drawable-graph<%>). To make the tiles drawable, you will need to extend their interface, too (or add a drawable interface):

  (define tile<%>
    (interface () 
      get-x ;; tile<%> -> Number
      get-y ;; tile<%> -> Number
      index ;; tile<%> -> Index
      
      snip  ;; tile<%> -> snip<%>
      ;; a drawable version of the tile
      ))

The first three are definitely needed. The last one is useful in a graphical context; if you choose others (say html, text), you will need alternative methods.

Task 2: Implement an observer that visualizes the game. You may choose your favorite visualization context. I have used a GUI context and display the state of the game as follows:

On the left, you see a scrolling text field that displays the actions; on the right you see a visual presentation of the graph. - No matter what visualization medium you choose, use the above interfaces to implement it. [POINTS: 12]

---

Product: Mail a tar bundle with a a single subdirectory labeled YourName_Project8. The subdirectory must contain your entire project. The README file must contain instructions for running and visualizing the game [POINTS: 3]; it must also give a brief high-level overview of the visualuzation context you chose to use.