Zimmer CSCI 330 Fall 2018 (191) PROGRAM 4- Implementation. Program Implementation... Nov 29, 2018 (printed for class 11/30)

Transcription

1 PROGRAM 4- Implementation Program Implementation... Nov 29, 2018 (printed for class 11/30) You are to complete the following on your own unless otherwise stated. All programs must be written in C++ and be Linux compatible. All implementation code must follow the Program Guidelines posted on my home page. Implementation due date deliverables: No Folder but turn in the following UML (revised) print, staple, and label (label:uml) Submit the following to D2L: Submit Program 4 Work Log and Summary to D2L Assignments dropbox (one file) Submit the following to my testing/grading directory: Submit your electronic files for grading- use the process outlined in Submit Directions o p4t use this directory for testing your implementation o p4f use this directory for grading your implementation o p4ht use this directory for testing your implementation with handle class o p4hf use this directory for grading your implementation with handle class ******************************************************** Update: 11/18/2019 1

2 Create the following items: xxx.h - contains the data types and function declarations associated with an object. xxx.cpp - contains the implementation of functions declared in xxx.h hc.h - contains the handle class declaration hc.cpp contains the handle class implementation p4.h - contains the include for your handle class your header file. YOUR program should NOT include this header file anywhere. THIS IS ONLY FOR MY TEST DRIVER! I will provide: Files to use for this program are in my directory and have not changes since program 2: ~zimmer/csci330/191/p2/ Documentation: Refer to the GAME document for an overview of the game rules. Work Log and Summary: Begin a single Word document using the format described in program 1-design for program 4 and log your hours for the program. Design, Implement, and Test the following C++ class: Make appropriate corrections to your program 3 implementation of PlayerClass hierarchy so that it meets those specifications before you move forward. You are welcome to submit the revisions of player3 files to p3t for a check of your code. Using the UML design provided for the PlayerClass hierarchy, implement and test each of the classes. Modified Requirements: The Humanoid Player should have a pack that consists of a vector of Weapon pointer. The weapon used in battle is considered to be carried/used and the program should maintain a pointer to this weapon. All players have a current weapon pointer. When the Player is carrying no weapon the weapon should be NULL. All Players are created with no weapon being carried and Humanoids are created with an empty packs. Data stored and processed within a class should make sense for that class. No extra public or protected methods should be added just to make things more convenient unless discussed in class. Only instances of Human, Elf, Orc, Troll and Ogre that are given names should be allowed. PlayerClass, Humanoid and Monster should be abstract classes. Use the dice, voc, wpn and gamespace files provided in my directory (UML diagrams provided on website). Use inheritance and polymorphism when it applies. Encapsulate all data types specific to each object. Remove enum datatype RaceType from the class hierarchy. Encapsulate all static constants specific to each object in that object. Update: 11/18/2019 2

3 Additional Public Methods: - Remove methods from the hierarchy: Race( ), IsMonster( ), IsHumaniod( ) Weapon * Humanoid::FindWeapon (Weapon * wpn) Player finds equipment on the ground. If weapon is not NULL the weapon that is passed in replaces the weapon being carried. The weapon replaced is put into the pack if there is room and NULL is returned. If the discarded weapon cannot be put into the pack then it should be returned as the player cannot retain it. Only active players can change their weapon, if no weapon is processed, return the weapon sent in. Weapon * Monster::FindWeapon (Weapon * wpn) Player finds weapon on the ground. If weapon is not NULL the weapon that is passed in replaces the weapon being carried. The weapon replaced is returned. If NULL is passed in then NULL is returned. Only active players can change their weapon, if no weapon is processed, return the weapon sent in. Weapon * Humanoid::ChangeWeapon (string weaponname) Player changes weapon carried with a weapon in the pack. The weapon name passed in is the weapon the player wants as the current carried weapon. If the Player does not have that weapon either in hand or in the pack, then no change is made. If there is a weapon swap then the discarded weapon is put into the pack if possible, otherwise it is returned. If there is no extra weapon that cannot fit in the pack, or the weapon is not available, then NULL is returned. Only Active players can change their weapon. vector<string> Humanoid::Pack ( ) Returns the Player s pack as a list of strings that include the Name and Serial number for the weapons within the pack. Modify Public Method & Top-Level Function: void Write(ostream& out) Output the player data in the following format (no spaces except in the strings themselves): Humanoid: race#voc#level#xp#name#(row,col)#hp#maxhp#[a1#a2#a3#a4#a5#a6]#wname#(skills)<line feed> <tab> (sorted pack by name and serial number sep by commas)#<linefeed> Monster: race#name#(row,col)#hp#maxhp#[a1#a2#a3#a4#a5#a6]#wname#(skills)<line feed> * race and voc should be output as string values. * skills list skills in alpha order separated by commas. If list is empty output empty parenthesis. ostream& operator<< (ostream& out, const PlayerClass* p) Output the player data using same format used in Write( ) Update: 11/18/2019 3

4 Handle Class - Player Implement the polymorphic Clone( ) method at all levels of your hierarchy Implement a handle class named Player as the interface to the PlayerClass hierarchy with the only instance data being the pointer to the PlayerClass hierarchy. Provide access to all PlayerClass hierarchy public member functions ONLY. Implement all methods needed to support standard class operations. Overload Player constructors: Player( ); Player(const Player& player); Player(PlayerClass * ptr); Add the following additional methods to Player: bool IsHumanoid( ) const returns true if player is humanoid, false otherwise bool IsMonster( ) const returns true if player is monster, false otherwise Update: 11/18/2019 4

5 Programmer: Score: /100 Program 4- 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 uses reusable code. Most of the code uses reusable code when possible Little attention was paid is 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 11/28/2018 CSCI330 Fall 2018 (191) 5