To be first player to pick all 10 cherries from their tree, and put them in your bucket.
Each player gets a turn.
Spin the spinner, it lands on one of the following, with the given consequences:
1 Cherry, remove 1 cherry from, and place into bucket.
2 Cherries, remove 2 cherries from, and place into bucket.
3 Cherries, remove 3 cherries from, and place into bucket.
4 Cherries, remove 4 cherries from, and place into bucket.
Bird, remove 2 cherries from bucket, and place back onto tree.
Dog, remove 2 cherries from bucket, and place back onto tree.
Spilled Bucket, remove all cherries from bucket, and place back onto tree.
These become the fundamental modules
Gameplay
UI
Output Devices
Graphics
Input Devices
Tempting to put in Tree/Bucket/Spinner
These are not high level, “Key” abstractions
Leads to
Turn Manager
Game State
Tree
Bushel
Spinner
Which leads to a set of key abstractions
UI
Graphics
Hardware
Game Manager
Turn Manager
Game State
Spinner
Tree
Bucket
Player
OpenGL
Windows
MyFirmGUI
UI
Graphics
Hardware
Game Manager
Turn Manager
Game State
Spinner
Tree
Bucket
Player
OpenGL
Windows
MyFirmGUI
Who should talk to whom?
What are the responsibilities of each piece
Not HOW, but WHAT
Where is “Hi-Ho” even mentioned?
GameState encompasses all (well most) of the games idiosyncrasies
The other pieces don’t care
They have a higher possibility of reuse
Controls sequence of events
Interfaces to game state
<this is a turn-based game, weill we be making more of these?>
Keep as much “cherry-oh” out as possible
UI
Present current state to the player(s)
Access to setup parameters
Access to preferences
Music/exciters/anims
Graphics
Present images to the screen
Hardware
Get input from user
Game State
Keep #cherries in trees or buckets
Determine end of game factors
Decide winner
Maintain whos turn it is
Project managers, CEOs, marketing schmucks are hoping it is code
Rarely does this occur
However, architecture (the responsibilities and relationships of classes) is what gets reused