The Goal: Create a game mechanic or mini-game in under a week that involves the Observer Design Pattern in the code's implementation.
1. What does the player do in the game that sends data from your Subject class to all of your Observer classes (with the observer design pattern) while the game is running?
The location of the player is sent to the observers whenever they move, and the isBarking bool is sent to the observers whenever the left mouse button is pressed or released.
2. What data does the Subject send to the Observers, and what do the Observers do with that data?
The subject sends its location (as a Vector2) to the observers, which use that data in their own movement code to move away from the player under certain conditions. The subject also sends the status of an “isBarking” boolean which the coyote observer specifically uses to decide how to move.
3. When and how are Observers registered, subscribed, or added? (It is okay if this is done on Start or Awake, but Observers could be registered or subscribed while the game is running.)
Observers are registered/added as soon as they are spawned in, which is done through Start().
4. What were the benefits of using the Observer Pattern to make your mini-game?
Using the observer pattern made it easy for me to keep track of what game objects knew/used what variables, and how they were connected. Specifically with the minigame I made, I found it easier to design how the object’s movement interacted since they had a preestablished subject/observer relationship.
5. Did you find any drawbacks to using the Observer Pattern? If so, what were they?
If I was to make this same minigame without the observer pattern, I would have still been able to easily have the two variables that were shared be communicated between the three classes. Because of that, it felt pretty contrived to try and fit the observer pattern into this game, even if in the end it made the code more efficient. Basically, this would be a better pattern for a large game, not so much a minigame.
6. What is the player’s goal in your mini-game and what makes it challenging?
The player’s goal is to keep the sheep present on the screen and the coyotes away from them until time runs out. This is made challenging by the fact that the sheep are constantly moving around, and the coyotes are trying to get to your sheep to eat them.
7. How does the game communicate its goal(s) to the player?
The game has the goals clearly stated under a “How To Win” section of the start menu, along with the basic controls. The game also automatically ends when a sheep escapes the screen or a coyote gets them, showing the player the fail conditions.
8. How can the player fail at the game and how does the game detect it?
If the player allows a sheep to get off the screen, trigger walls that line the outside of the screen destroy the sheep game object and trigger the game to end. If the player allows a coyote to eat a sheep, the trigger of the coyote will act the same as the out of bounds trigger walls, causing the game to end.
9. How does the game give players feedback about how well they are doing?
There is a timer counting down in the top left hand corner that tells the player how much longer they have to hold out, and every time you fail you can see the cause of that, along with how long you had left.