Fluxx Design Exercise
This project is intended to get you to try to design a program without worrying about exactly how it will be implemented. In other words, without writing any actual code you should explore a design in enough detail to convincingly describe it to another programmer.
Specification
Consider designing a software version of the card game of Fluxx by Looney Labs, a card game with dynamically changing rules. Fluxx was designed by ex-NASA engineers and has enjoyed relative superstar status in the gaming world. It is considered part of a family of games with mutable rules; in this case, by playing cards within the game. The game starts out with just two basic rules: each player draws one card, and plays one card during his turn; and no way to win the game! After that, any part of the play can be changed by playing rule or goal cards.
Simply put, the rules and goals are on the cards, so as you play, anything can change. That sounds easy enough at first, until it is put into practice — this means that not only are no two games the same, but no two minutes of a game are the same. In fact, you are not even playing the same game as the game progresses: you may be playing a game that requires you to have a hand of several dozen cards; or a game where no one is allowed to have any cards in hand; you may have to make several plays before the next person can play; or the play order could be rearranged so you will have to wait twice as long before you can play at all; you may be playing someone else's cards; or you may be playing cards that are not even in play. And since the rules are always changing, any and all of these events can take place in a matter of minutes in the same game!
The game has become so popular that it has spawned many variants and expansion packs. However, people seems to be divided on the game between those that love the challenge and variety presented by the game to those that hate the lack of strategy possible. I have even known people to play cards that allow others to win just to end the game!
In groups of 3-4, write down the group's solution:
- A brief description of the primary classes you envision as part of implementing Fluxx, focused on their behavior not state (like CRC cards). Your design description should clearly identify how you plan to allow new rules and variants to be added to the game.
- A detailed description of how the classes' methods will handle the use cases given in the next section.
These links highlight some details to consider when creating your design:
- How the different kinds of cards in the game affect the game play
- All cards in some example game decks:
- Clarifications on rule "ambiguities": The FAQ
Use Cases
The following scenarios are provided to help test your design. By describing how your design handles these scenarios, we will be able to better understand how deeply you have considered the basic design issues. It may help you to role play or draw a diagram of how your classes collaborate to complete each story.
- A player plays a Goal card, changing the current goal, and wins the game.
- A player plays an Action card, allowing him to choose cards from another player's hand and play them.
- A player plays a Rule card, adding to the current rules to set a hand-size limit, requiring all players to immediately drop cards from their hands if necessary.
- A player plays a Rule card, changing the current rule from Play 1 to Play All, requiring the player to play more cards this turn.
- A player plays a card, fulfilling the current Ungoal, and everyone loses the game.
- A new theme for the game is designed, creating a different set of Rule, Keeper, and Creeper cards.
Submission
Use Gitlab's markdown format to record the
group's solution and push it to one person's Gitlab analysis_NETID repository at the end of class. Make sure the solution includes everyone's name that worked on it.
