PROGRAM 2- Implementation Specifications

Transcription

1 PROGRAM 2- Implementation Specifications Program Implementation Due Date: Mar 18, 2019 (folder for next class meeting) You are to complete the following on your own unless otherwise stated. All programs must be written in C++ and be Linux compatible. Make sure you follow the Assignment Guidelines and Program Guidelines posted on my course webpage and use the templates provided. Implementation Deliverables Include the following in your program folder: (Staple in left top corner) UML (revised) make sure proper headings are included on UML two stapled packets: player2.h, player2.cpp blank blue rubric I will provide this in class by the folder due date Submit the following to my testing/grading directory: Submit your electronic files for grading- use the process outlined in Submit Directions p2t use this directory for testing your implementation p2f use this directory for grading your implementation Submit the following to D2L when implementation is complete: Submit Program 2 Work Log and Summary to D2L Assignments dropbox (one file) Create These Items 1. UML revision of the UML as you implement your program 2. player2.h contains the declarations and documentation associated with PlayerClass 3. player2.cpp contains the definitions/implementation associated with PlayerClass Provided Files Files for the program are provided in my directory: ~zimmer/csci330/192/p2/ Documentation: Refer to the GAME document for an overview of the game rules. Work Log and Summary Continue a single Word document from program 2 - design that contains the table of your work hours with your reflection summary below the table. This is due in the D2L Assignments dropbox by midnight on the day you turn in your program folder. Updated: 3/1/2019 1

2 Design, Implement and Test the following C++ Class Make appropriate corrections to your program 1 implementation of PlayerClass so that it meets program 1 specifications before you move forward. You are welcome to submit the revisions of player1 files to p1t for a check of your code (just let me know you would like to take advantage of this option). Modified Requirements (add these to the list from program 1) The Player s name should be a string of more than 1 character but not more than 10. If less than one character in length the constructor should throw the exception INVALID_NAME from GameSpace ExceptionType. More than 10 characters truncate the name to 10 characters. Be sure to trim leading and trailing whitespace and extra whitespace in the string. Constructors should throw exception INVALID_TYPE (from GameSpace ExceptionType) when an invalid PlayerType is passed. Store name and type as instance constants. Encapsulate class constants as named constants. The following is required: o 2D array for Initial stats constructor values should come from this table o 2D array for Impact Table o 2D array for Critical Wound Table Human player s often carry a weapon for battle. This weapon should be stored as a dynamically allocated Weapon (use my Weapon class) o Store the weapon as a pointer to Weapon. When there is no weapon, the pointer should be NULL. The Weapon class UML is provided. Human players should keep track of the weapon skills they possess. Weapon skills should be stored as a map for quick retrieval and update. Use best practices for maps as you process the weapon and skill data. (Only humans have weapon skill data). Modified Public/Private Constructors/Destructor/Operators: Move the default constructor PlayerClass( ) to private. Replace all parameterized constructors but the copy constructor with one constructor taking two parameters using the default parameter value technique. Provide any additional constructors/operators/destructor needed for the class Updated: 3/1/2019 2

3 Additional Public Methods: int Fortify (int boost) If the player is active and boost is greater than zero the boost is added to the defense. Return the defense. int Expose (int decline) If the player is active and decline is greater than zero the decline is deducted from the defense. If the player s defense drops below zero, set it to zero indicating the player cannot defend itself. Return the defense. int WillPowerAdj (int adjustment) If the player is active the adjustment is applied Will Power. Valid will power is between 0 and 12. If will power exceeds 12, reset will power to 12. If the player s will power drops below zero, reset to 0 and the player is dead and no longer active. Returned the will power. int HitScore( ) If the player is active the hit score is rolled and returned, otherwise 0 is returned. int HitDamage( ) If the player is active, the damage inflicted is returned, other wise 0 is returned. Damage is calculated by using the Weapon Skill for the weapon or player s power if no weapon; add the score from the Damage Value of the weapon used or roll the Physical Damage of player if no weapon. int Impact( ) If the player is active, the impact of a critical wound inflicted is returned, otherwise 0 it returned. The return value is determined from the Impact Table using either the weapon power (if the player has a weapon) or the player s power. A player can inflict no critical wound if they are not active or have no weapon and player power is less than 2. Return -1 if the wound is a mortal wound ( w in the strike table). bool CriticalWound( ) Applies the outcome of a critical wound on an active player. The player s health is reduced by 10 points and the current speed is decreased by half (round down). If player is still alive then consult the Critical Wound Table for the damage to the willpower or the life ending damage. Return true if player is still alive and false if player is dead. Updated: 3/1/2019 3

4 string WeaponName( ) Return the name of the weapon. Return empty string if there is no weapon. string WeaponNameAndNum( ) Return the name of the weapon name and serial number. Return empty string if there is no weapon. int WeaponSkill( ) Return the weapon skill of the weapon in the player s hand. Return 0 if there is no weapon. Weapon * DropWeapon( ) An active player drops their weapon and leaves the player with no weapon. The method returns the weapon dropped, or NULL if the player is not active or there was no weapon to drop. bool HasWeapon( ) Returns true if player has a weapon, false otherwise. Weapon * GrabWeapon( Weapon* weapon) An active human grabs a new weapon. A human grabs the weapon sent in and returns the weapon they were using or returns NULL if there was not a weapon. If the player is not active or not human, no change is made and the weapon sent in is returned. If the player has skill with that weapon then that weapon skill is used. If the player has never used this weapon before then the skill is set to 1. bool ImprovedSkill( int improvement) An active player that has a weapon improves their skill with that weapon. Return true if the player can update the weapon skill, false otherwise. Improvement should be greater than or equal to zero. The relational operator that compares obj using alphabetic order by name- not case sensitive bool operator==(const PlayerClass& p) const; bool operator!=(const PlayerClass& p) const; bool operator<(const PlayerClass& p) const; bool operator>(const PlayerClass& p) const; bool operator<=(const PlayerClass& p) const; bool operator>=(const PlayerClass& p) const; Updated: 3/1/2019 4

5 Modify Public Methods: void Write(ostream& out) Output the player data in the following format for each player type BUG: ptype#active#name#(row,col,dir)#maxh#health#willpow#power#maxsp#currsp#mom#pdam#defval<lf> HUMAN: ptype#active#name#(row,col,dir)#maxh#health#willpow#power#maxsp#currsp#mom#pdam#defval <lf> <tab> Current_wpnN&N#Current_wpnSkill#wpnName#wpnSkill# <lf> ostream& operator<< (ostream& out, const PlayerClass* p) Output the player data in the same format as the Write( ) method. * ptype should be output as an uppercase string * active should be 1(true) or 0(false) * dir should be output as an uppercase character (N, E, S, W) * physdam should be output using dice notation (3d4) * <lf> is a line feed (endl) * <tab> is a tab stop * The second output line for HUMAN should only print weapons with a skill of 1 or more. Weapons that have not been used have a skill of 0 (zero). The first pair on the second line are the current weapon and current skill if the human has a weapon. If there is no weapon in hand, print just the delimiters. If there are no weapon skills to print then print nothing. Updated: 3/1/2019 5

6 Required Public Methods from Program 1 string Name( ) Return the player s name int Type( ) Return the player s type string TypeStr( ) Return the player s type as a string ( EXPLORER, WARRIOR, HORNET, KILLERANT, SPIDER ) int Row( ) Return the player s cell row int Col( ) Return the player s cell column int Dir( ) Return the direction the player is facing. int MaxHealth( ) Return the player s maximum health int Health( ) Return the player s health int WillPower( ) Return the player s willpower int MaxSpeed( ) Returs the player s maximum speed int CurrentSpeed( ) Return the Player's current speed int Momentum( ) Return the Player's momentum int Power( ) Return the player s power int RollPhysDam( ) Return the player s physical damage int Defense( ) Return the player s defense value bool IsHuman( ) Return true if player is a human, false otherwise. bool IsBug( ) Return true if player is a bug, false otherwise. bool IsAlive( ) Return true if the player is alive, false otherwise. bool IsDead( ) Return true if the player is dead, false otherwise. bool IsActive( ) Return true if the player is active, false otherwise. An active player must be alive and considered in play. bool IsMyEnemy(PlayerClass* p) Return true if the player p is my enemy, false otherwise. Updated: 3/1/2019 6

7 bool MakeActive( ) Sets player to be active unless player is dead. Return true if player is active, false otherwise. bool MakeInActive( ) Sets player to be inactive. Return true indicating player is inactive. (always returns true). bool MakeDead( ) Sets the health, willpower, momentum, and current speed to zero to indicate a player is dead. Player is set to inactive. Return true indicating player is dead. (always returns true). int Wounded(int damage) If the player is active and damage is greater than zero the damage is deducted from the health. If the player s health drops to zero or below then the player is dead and no longer active. Return the health. int Invigorate(int vigor) If the player is active and vigor is greater than zero the add vigor to the health. Health cannot exceed max health. Return the health. bool Heal( ) If the player is active updates the appropriate values to indicate player has healed. Return true unless player could not be healed because the player is not active or dead. int ResetCurrentSpeed( ) If the player is active then current speed is reset to the max speed. Return the current speed. int ResetMomentum( ) If the player is active momentum is reset to the current speed. Return the momentum. int UseMomentum(int amount) If the player is active and amount is greater than zero the amount is deducted from the momentum. The momentum cannot drop below zero. Return the momentum. bool SetCell(int newrow, int newcol) Updates the player s current coordinates regardless of player s state. If both newrow and newcol > -1 then the coordinates are set. If both newrow and newcol are -1 then coordinates are set (indicates player not on board). In all other cases, coordinates should not be set. If coordinates are set, return true. In all other cases, return false. bool SetDir(DirType dir) Updates the player s current direction regardless of player state. If the direction is updated return true, in all other cases, return false. int SlowDown(int hazard) If the player is active and hazard is greater than zero the hazard is deducted from current speed. The current speed cannot drop below zero and momentum should never be above current speed. If necessary, reduce the momentum to the value of current speed. Return the current speed. Updated: 3/1/2019 7

8 Programmer: Score: /100 Program 2 - Implementation Rubric Outstanding 4-5 points Developing 2-3 points Needs Improvement 0-1 point UML Proper structure, organized, and complete Small structure issue or a few missing members UML structure incorrect or incomplete or missing Documentation The documentation is well written The documentation consists of and clearly explains what the code some simple header is accomplishing and how. documentation that is somewhat Includes clearly stated pre/post useful in understanding the code. conditions. The documentation is some simple header comments separating routines. Readability The code is exceptionally well The code is mostly easy to read. organized and very easy to follow. The code is readable only by someone who knows what it is supposed to be doing. Implementation Requirements All implementation items done per specifications. Some items do not meet required specifications Many items are not implemented per specifications Memory management Allocation and deallocation is done responsibly. A few problems with memory management. Poor memory management or specifications not followed Reusability The code is created for reusability and code reuses when possible.. Most of the code is created for reusability or uses reusable code when possible. Little attention was paid to reusability. Efficiency The code is extremely efficient The code is mostly efficient The code is brute force and without sacrificing readability and without sacrificing readability and unnecessarily long. understanding. understanding. Outstanding points All methods work and meet all of the specifications. Developing points All observer methods work and most of the transformer methods work and produce the correct results. Needs Improvement 0-25 points Most methods do not work and do not produce correct results. Specifications 3/1/2019 CSCI330 Spring 2019 (192)