shrupiga design by lPp9L2

VIEWS: 1 PAGES: 11

									 Shrupiga: Adventure Game
      Software Design Specification




March 7th, 2010
Garrick Williams
Piotr Wojciechowski
Rustin Ault
Shawn Yost
                      1 of 11
1.0   Introduction
      The purpose of this document is to describe the design and architecture of Shrupiga, the
      adventure entertainment software.

      1.1    Goals and Objectives
             The 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 Scope
             Being 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 Context
             Despite 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 Constraints

             1.4.1 Entertainment
                     Shrupiga must be designed regards to standards of entertainment media.

             1.4.2 Style
                     Shrupiga must be designed to fulfill the command-line game style to fit
                     within the software context.

             1.4.3 Simplicity
                     Shrupiga must be designed with simplicity in mind for both game-play
                     and for understandability.

             1.4.4 Genre
                     Shrupiga must be designed with respect to the science fiction fantasy
                     genre.


2.0   Data Design
      2.1    Internal Software Data Structure
             The 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
                                            2 of 11
            permanently store its information and load it during another execution of the
            game, allowing the player to continue adventuring with a character they
            previously created.

      2.2   Global Data Structure
            The only globally available data structures are the item and monster databases that
            store all of the possible monsters and items that can appear in the game.

      2.3   Temporary Data Structure
            Each component may use temporary variables in order to track progress of its
            particular state.

      2.4   Database Description
            Shrupiga 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 use
            an instance of one of the classes found in these databases.

3.0   Architectural Design
      3.1   Program Structure
            Since 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.




                                          3 of 11
         3.2      Architecture Diagram




4.0      Schedule
         4.1      Scheduling Diagram
Component                3/8   3/15      3/22    3/29   4/5   4/12   4/19   4/26
State Component
Implementation
Data Component
Implementation
State Component
Testing
Data Component
Testing
State-Data Integrated
Testing
State-State Integrated
Testing
Final Validation
Final Presentation


         4.2
         4.3      Definition of Milestones
                  Milestone 1 (3/21) – Top-Level Components Implemented
                  Milestone 2 (4/4) – Lower-Level Components Implemented
                  Milestone 3 (4/25) – Prototype Complete
                  Milestone 4 (TBA) –Project Complete


                                            4 of 11
5.0   Component-level Design

      5.1   Main
            5.1.1   Description
                    Main is the top level class in the "call and return" architecture of Shrupiga.

            5.1.2   Component-Interface
                    Input – No parameters

                    Output – Passes CharacterPlayer and map file name to Adventure.

            5.1.3   Processing Detail
                    5.1.3.1 User-Interface Description
                            Prompt 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 character

                           Prompt 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 Structures
                            Main stores the entered map file name as a temporary variable.

                    5.1.3.3 Algorithmic Model

                       1. 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 Constraints
                            No design constraints specific to this component

                                            5 of 11
5.2   CharacterCreator
      5.2.1   Description
              Handles creation of a new character file.

      5.2.2   Component-Interface
              Input – No parameters

              Output – Returns the name of the newly character file

      5.2.3   Processing Detail
              5.2.3.1 User-Interface Description
                      Prompt 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 Net
                      Guardian.

                      Prompt 2: Character Name – Player is expected to enter a string for
                      their character’s name

                      Prompt 3: File Name – Player is expected to enter a string for their
                      character’s file name.

              5.2.3.2 Local Data Structures
                      CharacterCreator stores the player’s choices in local variables.

              5.2.3.3 Algorithmic Model

                 1.   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 Constraints
                      No design constraints specific to this component




                                      6 of 11
5.3   Adventure
      5.3.1   Description
              Handles the adventure mode state, allowing player to explore a map.

      5.3.2   Component-Interface
              Input – PlayerCharacter and map file name

              Output – Returns 0 when the user finishes playing

      5.3.3   Processing Detail
              5.3.3.1 User-Interface Description
                      Prompt 1: Direction – A multiple choice interface where each
                      choice is displayed with a corresponding letter. Player makes their
                      choice by entering the letter of their choice into the prompt. The
                      choices are item screen, up, down, left, and right, but some choices
                      may be unavailable if those directions are blocked by a wall. Item
                      screen calls PlayerScreen, allowing the player to access their
                      inventory.

              5.3.3.2 Local Data Structures
                      Adventure maintains the game space using a Map object and stores
                      the player’s current location and progress via local variables.

              5.3.3.3 Algorithmic Model

                 1. Get the start location of the map.
                 2. Set current position to the start location.
                 3. Loop until the player or the game specifies an end
                        1. Check adjacent spaces for movable locations.
                        2. Display list of movable locations.
                        3. Prompt user for which direction to go or whether to access
                            the PlayerScreen
                        4. Set current position to new location
                        5. If a MapObstacle is on the space, call the MapObstacle's
                            encounter function.
                        6. If a Monster is on the space, call Combat.
                                1. If Combat returns that the player was defeated, end
                                    loop.
                                2. If Combat returns that the player defeated the
                                    monster, remove the monster from the map.
                                3. If Combat returns that the player fled , move the
                                    player to their previous position on the map.
                        7. Save changes to PlayerCharacter to file
                 4. Return 0 to Main

              5.3.3.4 Design Constraints
                      No design constraints specific to this component



                                     7 of 11
5.4   Combat
      5.4.1   Description
              Handles the combat state where the player engages against an enemy
              Monster.

      5.4.2   Component-Interface
              Input – PlayerCharacter and a Monster

              Output – Returns 0 if the player uses or quits, 1 if the player wins, 2 if the
              player flees.

      5.4.3   Processing Detail
              5.4.3.1 User-Interface Description
                      Prompt 1: Combat Action 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 use item or flee.

                     Prompt 2: Item Use -- 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 all items in the player’s inventory that are useable
                     in combat.

                     Prompt 3: Item Target -- 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 possible targets a targetable item can be used on:
                     the player character, the monster, and a choice to exit back to Item
                     Use prompt.

              5.4.3.2 Local Data Structures
                      Combat maintains an instance of Monster and PlayerCharacter,
                      updating them throughout the course of combat. It also uses a local
                      variable to track whose turn it is.

              5.4.3.3 Algorithmic Model

                     Turn Structure

                     1. Create a variable that specifies whose turn it is, such as a
                        boolean value that 'true' indicates it's the player's turn.
                     2. Randomly pick whether the player or monster goes first.
                     3. Loop until combat ends
                           1. If the turn variable indicates it's the player's turn, let the
                               player take their turn. Else, let the monster take their
                               turn. For more details on their turn algorithm, see
                               below.


                                      8 of 11
              2. If the player character has zero health, display a game
                 over message, and return 0.
              3. If the monster has zero health
                      1. Give the player a random item from the
                         monster's inventory
                      2. Return 1, ending combat.
              4. Change the turn variable to the other individual. This
                 will allow the next entity take their turn in the next
                 loop.

       Player’s Turn


       1. Prompt player to either use an item or run
               1. If the player chooses to use an item...
                       1. Display their inventory with each item having a
                          number by it, allowing the player to pick the
                          item by typing in the number next to it. The
                          number 0 should be reserved for a choice to
                          back track to the previous prompt.
                       2. If the item needs a target, prompt the player to
                          either use the item on the monster or their
                          character.
                       3. Call the item's effect function, passing a pointer
                          to the target as a parameter if the item requires a
                          target.
                       4. Player's turn ends.
       2. If the player chooses to run, randomly decide if the flee was
          successful.
               1. If running is successful, end combat (return 2).
               2. If running is unsuccessful, end the player's turn.


       Monster’s Turn


       1. Randomly choose a skill from the Monster's list of skills.
       2. Call the skill's function.
       3. End monster's turn

5.4.3.4 Design Constraints
        No design constraints specific to this component




                       9 of 11
5.5   PlayerScreen
      5.5.1   Description
              Handles accessing the player character’s inventory during Adventure.

      5.5.2   Component-Interface
              Input – An instance of PlayerCharacter

              Output – Returns 0 if the player enters “q” at any prompt and wants to quit
              the game. Returns 1 if the player wishes to exit the screen without quitting
              the game.

      5.5.3   Processing Detail
              5.5.3.1 User-Interface Description
                      Prompt 1: Item Selection – Player is given a list of items in their
                      character’s inventory, each having a number beside it. Player
                      enters the number to select that item. Entering 0 exits the Player
                      Screen, making the component return 1.

                     Prompt 2: Item Interaction – A multiple choice prompt where each
                     choice has a designated number. Choice 0 exits the prompt and
                     returns to the Item Selection prompt. Choice 1 activates the use of
                     the item, but this choice is not available if the item in question
                     cannot be used outside of Combat.

              5.5.3.2 Local Data Structures
                      No major local data structures.

              5.5.3.3 Algorithmic Model

                 1. Display player character's health, mana, and list of inventory items,
                    giving a corresponding number to each one.
                 2. Prompt the user to either enter the number of the item they wish to
                    inspect or 0 to exit the screen.
                        1. If 0, return 1.
                        2. If a number...
                                1. Display Item's description
                                2. Prompt the user for a course of action. The player
                                    can choose 0 to go back to previous prompt, or 1 to
                                    use the item. The latter option is not available if the
                                    item cannot be used outside of combat.
                                        1. If 0, return to item selection prompt
                                        2. If 1,
                                                1. Call the item's use function with the
                                                     PlayerCharacter as the target
                                                2. Return to the item selection prompt.

              5.5.3.4 Design Constraints
                      No design constraints specific to this component


                                     10 of 11
6.0   User Interface Design

      6.1    Description of User Interface
             Since Shrupiga is a DOS game, the user interface consists mainly of listing
             options and prompting the user to enter their choice in command-line.

      6.2    Interface Design Rules
             Every prompt must handle the case the user enters ‘q,’ which signifies the quit
             command and begins the process to end the game.

7.0   Restrictions, Limitations, and Constraints
      Shrupiga’s design is restricted by the command-line nature of the software, which
      prevents use of heavy graphical interfaces and complex game worlds. The software will
      also be constrained by the programming language used for its implementation: Java.

8.0   Appendices
      8.1    Packaging and Installation Issues
             The user will be required to have a DOS program to run the software as well as
             the Java Virtual Machine installed.




                                          11 of 11

								
To top