Design Exercise: Changing Features Helps Clarify the Design

This exercise is intended for you to update your Object-Oriented design based on feedback from your mentor TA and based on additional game features. The world changes constantly, and software needs to change as well to stay useful, and good design should support making it easy to incorporate new features. This exercise will not be explicitly graded but, instead, serve as practice for future exercises in the course. Thus, you will get the most out of this assignment by putting in a good faith effort.

Submission

Submit a Markdown formatted plain text file, named design03_fluxx_variant.md, to the individual portfolio_NETID repository provided for you in the course's Gitlab group.

Specification

Consider a variant on Fluxx called Zombie Fluxx.  In particular, there are two new card types: Creeper and an Ungoal. 

Here are the differences in Zombie Fluxx from the original:

• Some Keeper Cards have instructions like “If you have this card Zombies cannot keep you from winning” or “On your turn you may kill any 1 Creeper”
• Creeper Cards (aka Zombies): Must be put on the table in front of you as soon as it is drawn.  This does not count as a play.  Creepers can also have instructions, like “You cannot win if you have this creeper” or “When you kill this zombie, pass it to the person on your right”
• Ungoal Card: Once played, if any player meets the conditions of the UnGoal, then the game is over and everyone loses (the zombies win).

Here is the complete list of cards in Zombie Fluxx. The following examples highlight some new features to consider as you update your design:

• Zombie Repellent Keeper: Each Zombie you have is instantly moved to the player of your choice
• Zombie Baseball Team Goal: Baseball Bat + at least 9 zombies
• Food for Thought Goal: Brains + Coffee + no Zombies
• Larry Creeper: You cannot win if you have this card, even if the Rules or Goal currently allow for victory with Zombies.
• Zombie Quartet Creeper: When killed, place this card on top of the draw pile instead of the discard pile
• Zombie Victory Ungoal: If there are at least 5 Zombie Creepers in play and all have at least 1 Zombie, then everybody loses. (The Zombies win!)
• Zombies Ain’t So Bad Rule: You can win if you have Zombies in play even if the current Goal says you cannot
• Zombie Boss Rule: The player with the most Zombies is the Zombie Boss until someone else has more.  The Zombie Boss draws 1 extra card each turn, is ignored by the “Eaten by Zombies” action, and wins the game if the game ends due to the Ungoal.
• Look, Over There! Rule:  During your turn you may move 1 of your Zombies to any player who has any of the following Keepers: Brains, Donuts, Coffee, Sandwiches, or a Friend.
• Return of the Dead Action: Take all Creepers out of the discard pile and deal them out to all the players
• Zombie Jamboree Action: Gather up all the Keepers and Creepers in play, shuffle them together, and then deal them back out to all the players, starting with yourself.
• Eaten by Zombies Action: The player who has the most Zombies in play must discard one of their Keepers.  If there’s a tie, all players involved must discard a Keeper, unless no one has a Zombie.

Add four new Use Cases to test your updated design based on the any of the cards above.

Update your design, the objects with their behaviors and relationships, and the Use Cases that test it to also support multiple versions of the game. Additionally, note the following as you make your changes:

• List all the changes needed in order to support the Zombie Fluxx version (new/different classes, methods, and parameters)
• Note any that involve changing existing code logic rather than making a new class or method
• Summarize how your new design attempts to reduce future logic changes

Abstraction

Try not to get too invested in how to implement the specific details given above because the larger goal to keep in mind is that Fluxx has dozens of versions, each with their own set of changes and details. Instead, use the details to help you make a design that builds on the parts of your classes that are common and provides support for the parts that are different to support both versions of the game. The key is to focus on active abstractions, i.e., superclasses, in your project that can have multiple concrete implementations, i.e., subclasses but specifically only on their behavior, i.e., methods, rather than state, i.e., instance variables. If done well, most of your code will be written using the abstractions without needing to know about specific implementation details because they are substitutable.

That is why it is important for you to keep track of what will change about your design in order to handle playing Zombie Fluxx (or any variation). The hallmark of the Open-Closed Principle is to ensure the changes you need to make involve making new classes, not changing existing code/logic.  The Single Responsibility Principle supports this by encouraging you to make the pieces of your design (classes and methods) small and focused enough that they can be usefully substituted. These principles make your design is more robust against changes (and easier to debug!)