An object approach to our game

• This is from my own little head.
• What are the potential objects or things in the game.
  • Looking at the (By Amazon.com [1], Fair use, https://en.wikipedia.org/w/index.php?curid=20827884) physical game I see
    • Body parts (many different, already an abstraction)
    • Die (done)
    • Game mat or storage box.
  • Reading the description I also see
    • Game
    • Player
    • Bug
  • Are there any others?
• For each, in the context of the game do they have:
  • Values
  • Actions
• We already (I hope) discussed the parts.
  • I see only data.
  • But you might see data and methods.
• Die:
  • Clearly I see this as an object.
  • The big thing is the functionality of re-roll the same series
  • And hiding and protecting that random number generator.
    • People tend to mis-use srand/rand
• The game mat/box
  • This holds the unused parts in the real game.
  • If parts were scarce (they are not) this might be a thing.
    • For n players there were 6n-1 legs, 2n-1 antennae, ...
    • We would have to keep track of how many were still available.
  • It also provides a mapping between die result and body part.
    • But this is really just a function in my mind.
  • But this is not the case, so I don't think I need an object/class to implement this.
• The bug?
  • Definitely data.
    • Probably an array
    • But I could see this being a map as well.
  • And procedures or actions
    • Check to see if the bug is finished.
    • Check to see if a part can be added.
    • Add a part to the bug.
    • Perhaps check to see how many of a given part the bug has.
    • For reusability, perhaps we might want a remove piece action.
  • I don't want the bug to have PrintBug.
    • This is user interface dependent.
    • It might change when the bug is used in a different context.
  • Note, we are not discussing implementation, just what is a bug.
• A player
  • Does a player have any data other than a bug?
  • We really have to decide where the game logic will be implemented
    • Does a player take a turn?
    • Does the game take a turn for the player?
  • Depending on the answers to this we might have an object.
• The Game
  • Same questions as with the player.
• For my game, I decided that a beetle class was necessary.
  • This is responsible for representing the bug in the game.
  • It will make decisions about and record counts of parts it has/needs.
  • It will decide if it is complete or not.
  • It has a member constant (private) PARTS_NEEDED, the array of each type of part needed.
    • This is information associated with the beetle and the decisions it has to make.
    • While this is game base, future versions could have different values through a hierarchy.
  • It has a member variable, the array of body parts.
    • I definitely could change this to be a map of body parts in the future.
  • I added the following member functions
    • int PartCount(BodyPartT b) const;
    • bool NeedsPart(BodyPartT b) const;
    • BodyPartT NeedsFor(BodyPartT b) const;
    • bool CanTakePart(BodyPartT b) const;
    • void GivePart(BodyPartT b);
    • bool Finished() const;
  • I needed NeedsFor which will take a part and and return the immediate part that is missing if the part can not be added or none if it can be added.
  • I had a single hidden internal function that changes a BodyPartT to a size_t for indexing into the array.
  • I have NO I/O in this class, all was moved to the main file.
• In my world, I am not going to implement a player class.
  • This is just a bug with a name.
  • And the name is just an index (perhaps plus 1).
  • There is a chance of this however, if there were anything else like intelligence in playing the game.
• I am not going to implement a game class either.