For my implementation of the State pattern, since we are required to have 2 implementations of it, the first will be a PlayerState. This state will control how the player interacts with other players. For instance, when it gets an update from the observer pattern (ahhhh a link between patterns!) it will set its state to be defending or attacking. Then the player will either move or start capturing. Then there is the combat state but this basically will just have a roll function to determine if the opponent stops what they are doing to dies.
The second implementation of the State pattern is with the areas that the Players are fighting over. They are Controlled, BishopControlled, KnightContrlled, NotControlled. There are methods that you will be able to see when I submit the code. Right now these states only have println statements but will later change the color of the location to indicate control. The PlayerState portion is much more complex interaction. The reason for this, I think, is due to the process at which we are creating these projects. We create it, add everything we want, then change how most things are done and therefore having multiple methods doing the same thing. When I get some extra time I will go through the player classes and create new ones from scratch with just what is needed. Just as a side note to the instructor and GTF's, I will be working on the UML and pseudo code for this during small breaks and then doing the big change later in the week (Ideally).
Looks good, not much to comment on. Cheers.
ReplyDelete~GTF Paul