We've got a Visitor!

Visitor pattern seems a little un-needed. I don't know. I have 2 implementations of it, both of which are related to the player class. The first is getting the faction of the other player that they are visiting with. This seems like a neat way to check the faction of the other player and then react to them. But I don't see why this would be better than the check faction method that could go in the Player class. The other visitor pattern is related to the previous in the only way that it concerns the faction of the two involved in the visiting conversation. If they are enemies they will equip their weapons (which will be a change in color when all is said and done). Hopefully these are distance enough for the assignment.

Howto: Get into a new State!

Basically this is the easiest pattern to create thus far. It offers a lot of versatility and malleability. All that is nice, but how do we create it!!?? VERY good question! Follow these steps:

1. Decide on the type of actions that are going to be grouped together (different states something can be it, be it emotions, labor duties, opp-orations that can be performed)
2. Create the State interface that will connect them all (just like the strategy pattern)
3. Inside the State interface include the methods that will be used to change between states
4. Create separate classes for each State the object will be in, and implement the State interface
5. In each class now specify how each of these methods will change to certain states and such forth

There you have it, that's how you use the State pattern. It is that simple. You can make your methods as complicated as you like, but this is the basic structure.

What is my State?

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).

Lets get Linked!

My experience with the linked list is a mixed one. On one hand I was able to construct the rest of a Singly linked list, but on the other hand, the Doubly link list is not going so well. In general the idea of a linked list very logical and seems that it could be easily implemented into my program. But where to put it and how? Those are the questions that everyone is asking. From the completely random and anonymous survey taken by the imaginary test group of Graduate Teaching Fellows (GTFs) at the University of Oregon (UO), it was selected to use a linked list to control where a player will go to next. The idea that will be behind this operation will be as follows:

1. All towns will be added to this list.
2. When a player is trying to decide where to go, they will refer to this list
3. At each next location, the player will call the getState function of the town to get ownership.
4. If the state is not of a certain function the player will set out for that location
5. If the state is of the certain state, the player will call the next item in the list.

One idea I am playing will is maybe getting a distance between the player and the states and will cause the player to move to the closed state to take over. 

On the idea of iterators, I like the idea. I'm a fan of 'if then else' and loops. So I think this concept will be simple to implement once I figure out how my players will interact with them.

How am I going to decorate my project?

In my simulation, it just makes sense to implement the decorator pattern to represent the different potions that may be added to the game. Right now since it is mostly a movement and single action game, the only potion to add is a speedBoost Potion. I have given the Player super-class a method (speed()) that returns a value to the speed. (I am still in the developmental stage of figuring out how this speed is actually going to change how fast the player moves). When the speedBoost Potion is added to the character it will double the speed. This speed value will also be used to determine how fast a player is able to raise the flag to claim a new area. This raises another question to the readers: I want to have the town that the player will change ownership of to control the method to 'changeOwner()'. How do I get the player to call this function so that it will set the correct faction? As for the removing of the 'potion' I have another method call in this class (removeSpeedBoost()) and it will return a value for the speed by taking the current speed and then reducing it by half.

Make everything look pretty!

Lets learn a new pattern! This new pattern is all about decorations. Well, that't not completely true. The decorator pattern is used to add more functionality to a class. It could be used to create a new decoration that a user may see, or it may be more in the background. There are 2 examples I want to entertain, but we will get to those later. First lets learn how to use it. Start with the class that you want to decorate. Say you have a set up players in a game. One of the most useful items in a RPG is the ability to use potions or other items that will either increase or decrease a stat for a short period of time. You extend this class with your decorator. This decorator is then extended further to classes that represent the separate decorations. These decorations will either add to and or modify current methods. For example, with your players, you probably have an attack speed or a movement speed (these may or may not be reliant on the same speed value). If there was a decorator of, say, Potions. One potion may be used to increase the speed value. Now that particular player gets a speed boost. You can make this call by calling the speedboost potion method as such: if you have a player King and you want him to walk faster. He has a speed method that returns the speed value. To make him use the potion you call a similar line to: King = new speedBoost(King.speed());

The other example is one that is more visible to the user. It is the same one that is used in the book for this class. It involves coffee, the decorator pattern will change the cost and description of a drink depending on the additions made to it, be it chocolate, caramel, etc.

"I don't want to be observed!"

This observer pattern seems really great and I think that it is going to make my simulation a lot better when it gets implemented, but that is easier said than done. What I am planning on is having each player be an observer of each other when they are within a certain distance. So there is going to be a (possibly array) list of all player locations. The program will keep running calculation of how far each player is from each other. When players are within X units away from each other they will add to the observers list. Then the players will get the faction of the other and if they are enemies, they will attack if the other player is within Y units and their state is 'Capturing'. I'm not quite sure what I'm doing wrong, but I think my problem is with the update() method in side the observers. Maybe that is the issue. Here is a question to the readers: When the update takes place in this pattern, who calls in and how is that sent to the observer?