Shrupiga: Adventure GameSoftware Design SpecificationMarch 7th, 2010Garrick WilliamsPiotr WojciechowskiRustin Ault1 of 12Shawn Yost2 of 121.0 IntroductionThe purpose of this document is to describe the design and architecture of Shrupiga, the adventure entertainment software.1.1 Goals and ObjectivesThe objective of Shrupiga is to provide an entertaining experience to the user while paying homage to command-line games of past generations. Shrupiga’s design goal emphasizes simplicity and durability in game-play.1.2 Statement of ScopeBeing an entertainment software program, Shrupiga prompts the user for various input regarding to game-play. It outputs and continually augments player character data so the user can continue playing at a later time.1.3 Software ContextDespite the availability of high resolution games with cutting-edge graphics and complex game-design paradigms, some players continue to enjoy simpler command-line games with little to no graphic interface. Shrupiga steps into the market for those particular players as its potential audience, modeling popular command-line games such as NetHack.1.4 Major Constraints1.4.1 EntertainmentShrupiga must be designed regards to standards of entertainment media.1.4.2 StyleShrupiga must be designed to fulfill the command-line game style to fit within the software context.1.4.3 SimplicityShrupiga must be designed with simplicity in mind for both game-play and for understandability.1.4.4 GenreShrupiga must be designed with respect to the science fiction fantasy genre.2.0 Data Design2.1 Internal Software Data StructureThe major data structure that all components share is PlayerCharacter. PlayerCharacter is a data structure that stores the statistics and inventory of the player’s character throughout the game. This structure also writes to a file to permanently store its information and load it during another execution of the 3 of 12game, allowing the player to continue adventuring with a character they previously created.2.2 Global Data StructureThe only globally available data structures are the item and monster databases thatstore all of the possible monsters and items that can appear in the game.2.3 Temporary Data StructureEach component may use temporary variables in order to track progress of its particular state.2.4 Database DescriptionShrupiga has two major databases: Item and Monster databases. The Item database is a class that holds all of the different Item classes the game can have. Similarly, the Monster database holds all the different Monster classes in the game. Whether a monster or item is needed in a game session, the game states usean instance of one of the classes found in these databases. 3.0 Architectural Design3.1 Program StructureSince states in the game have an hierarchical structure, Shrupiga uses a “call and return” architectural model. Each component responsible for a state calls other state components, which return a value when the lower-level state component has the data the higher-level component has, or when the lower-level component has finished processing.4 of 123.2 Architecture Diagram4.0 Schedule4.1 Scheduling DiagramComponent 3/8 3/15 3/22 3/29 4/5 4/12 4/19 4/26State Component ImplementationData Component ImplementationState Component TestingData Component TestingState-Data Integrated TestingState-State Integrated TestingFinal ValidationFinal Presentation4.24.3 Definition of MilestonesMilestone 1 (3/21) – Top-Level Components ImplementedMilestone 2 (4/4) – Lower-Level Components ImplementedMilestone 3 (4/25) – Prototype CompleteMilestone 4 (TBA) –Project Complete5.0 Component-level Design5 of 125.1 Main5.1.1 DescriptionMain is the top level class in the "call and return" architecture of Shrupiga.5.1.2 Component-InterfaceInput – No parametersOutput – Passes CharacterPlayer and map file name to Adventure.5.1.3 Processing Detail5.1.3.1 User-Interface DescriptionPrompt 1: Load or Create Character – A multiple choice interface where each choice is displayed with a corresponding number. Player makes their choice by entering the number of their choice into the prompt.Choices are load character, and create characterPrompt 2: Map File – Player is expected to enter a string for a file name. If the file name is invalid, the user is informed and this prompt appears again.5.1.3.2 Local Data StructuresMain stores the entered map file name as a temporary variable.5.1.3.3 Algorithmic Model1. Game starts 2. Prompt user whether to load character or create new one 1. If create new character... 1. Call CharacterCreator, which should return the name of a newly created character file 2. If load new character 1. Prompt user for character file name 2. Check if file exists. If not, go back to previous prompting the user to load or create new character. 3. Initialize new PlayerCharacter and load character file into it 4. Prompt user for file name for a map 5. Check if the map file name is valid. If not, prompt user again for one. 6. Call Adventure with the map file name and PlayerCharacter as parameters. 7. End game when Adventure returns 0. 5.1.3.4 Design ConstraintsNo design constraints specific to this component6 of 125.2 CharacterCreator5.2.1 DescriptionHandles creation of a new character file.5.2.2 Component-InterfaceInput – No parametersOutput – Returns the name of the newly character file5.2.3 Processing Detail5.2.3.1 User-Interface DescriptionPrompt 1: Class Choice – A multiple choice interface where each choice is displayed with a corresponding number. Player makes their choice by entering the number of their choice into the prompt.The choices are Cosmo Marine, Astro Scaper, Net Hacker, and NetGuardian.Prompt 2: Character Name – Player is expected to enter a string fortheir character’s namePrompt 3: File Name – Player is expected to enter a string for their character’s file name.5.2.3.2 Local Data StructuresCharacterCreator stores the player’s choices in local variables.5.2.3.3 Algorithmic Model1. Display character class choices, prompting player to choose one 2. Prompt user to name their character 3. Prompt user to name the character file 4. Create new character file 5. Return name of character file 5.2.3.4 Design ConstraintsNo design constraints specific to this component7 of 125.3 Adventure5.3.1 DescriptionHandles the adventure mode state, allowing player to explore a map.5.3.2 Component-InterfaceInput – PlayerCharacter and map file nameOutput – Returns 0 when the