Requirements Analysis: Use Cases

By Curtis Wyatt (1/26/06)

• System Overview
  • This software project is an ambitious first-person shooter. Utilizing a network, multiple players will be able to compete in 3-dimensional levels. Players will be able to injure and kill each other using various weapons. The games rules and playing mechanics will be modeled after Halo. The game will completely be multiplayer. If time permits, it may be possible to add rudimentary AI into the system via “bots”, or computer controlled multiplayer characters.
• Application Domain
  • When the game is first loaded, you will have the option of joining an existing party or creating a new one. A level may be chosen, and when all players have joined the party the party leader can start the game.
    • Tasks
      
      • Creating a Party
        • Actor: Game Player(s)
        • Goal: To create a party for other players to join.
        • Precondition: Player wants to play the game, but no party has been created yet.
        • Related use case: Joining an existing Party
        • Steps
          

• 1. Open the program.	2. System prompts to join exisiting party or to create one.
  3. User chooses to create a party.	4. System prompts to enter party parameters (game time limit, level).
  5. User enters parameters.	6. System waits for other members to join the party.
  7. After the desired number of players join, system starts game.	8. 3D environment is loaded and game starts.

• Alternative: User cancels party. If member already joined, new party leader is randomly assigned.
• Joining an Existing Party
  • Actor: Game Player(s)
  • Goal: To join an existing party.
  • Precondition: Player wants to play the game, and a party has been created.
  • Related use case: Creating a Party
  • Steps:
    

• 1. Open the program.	2. System prompts to join exisiting party or to create one.
  3. User chooses to join a party.	4. System prompts to enter party parameters (IP address of host)
  5. User enters parameters.	6. System adds user to party list.
  7. User waits for party leader to begin party.	8. 3D environment is loaded and game starts.

• Alternatives: User decides to leave party.
• Classes:
  
  • Network Connection
  • Party
  • Character
  • Object
• Players will then engage one another. Players will all have the same starting weapon. Each player has a shield and health. The shield will automatically regenerate over time. Health will not. Players will be able to acquire other guns throughout the level, although they will only be able to hold one at a time. Guns will work realistically in that they have limited clip sizes and must be reloaded. The player will also have limited ammunition.
  • Tasks
    
    • Firing a Weapon
      • Actor: Game Player(s)
      • Goal: To fire a weapon
      • Precondition: User has a weapon.
      • Related use cases: Reloading a Weapon
      • Steps:
        

• 1. Hit enter on keyboard.

  2. System checks to see if ammo, if empty clip but has ammo, reload and then fire.

• Alternatives: Character has no ammo, in case of that do nothing.
• Picking up Ammunition
  • Actor: Game Player(s)
  • Goal: To Pick up ammunition.
  • Precondition: User is standing over ammunition.
  • Related use cases: Picking up a Weapon, Reloading a Weapon
  • Steps:
    

• 1. User is over ammunitnion.

  2. System checks to see if it is compatible with the weapon. If so, system checks to see if user has space to hold ammo. If so, system fills up ammuniton.

• Alternatives: User is not over ammo, do nothing. Weapon is not compatible, do nothing. User does not have space to hold ammo, do nothing.
• Picking up Weapon
  • Actor: Game Player(s)
  • Goal: to pick up a weapon
  • Precondition: User is standing over a weapon.
  • Related use cases: Firing a Weapon, Reloading a Weapon
  • Steps:

• 1. User is standing over weapon and hits shift.

  2. System picks up weapon and drops current weapon.

• Alternatives: User is not standing over weapon, do nothing.
• Reloading Weapon
  • Actor: Game Player(s)
  • Goal: to pick up a weapon
  • Precondition: User is standing over a weapon.
  • Related use cases: Firing a Weapon
  • Steps:
    

• 1. User hits r on the keyboard.

  2. System reloads weapon.

• Alternatives: User has no ammo, do nothing. Weapon's clip is full, do nothing.
• Classes:
  
  
  • Weapon
  • Character
  • Controls
  • Object
• The game will consist of interiors consisting of corridors and rooms. Multiple barriers may be placed throughout the rooms. Other guns and ammunition may be placed throughout the level for players to pick up. Once picked up, they will regenerate after a set amount of time.
• When a player shoots another character, the damage dealt is determined upon where the shot landed. For example, headshots take much more damage than a shot in the leg. When a player dies, they are evicted from the game, either permanently or for a period specified by the game leader.
  • Tasks
    
    • Character Shoots Another Character
      • Actor: Game Player(s)
      • Goal: One player gets shot by another.
      • Precondition: Shooting player (a) has a weapon and receiving player (b) is within range and target reticle of (a).
      • Related use cases: Firing a Weapon, Player Dies
      • Steps:
        

• 1. Bullet hits player.	2. System analyzes where the bullet hit and adjusts shield and health accordingly.
  3. Player is injured or dies.	4. System removes player from environment and replaces according to party leader's party parameters.

• Alternatives: none
• Player Dies
  • Actor: Game Player(s)
  • Goal: One player gets shot by another and dies.
  • Precondition: Chacter gets shot and resulting damage decreases health to zero.
  • Related use cases: Firing a Weapon, Character Shoots Another Character
  • Steps:
    

• 1. Player is shot and health is now zero.

  2. Player dies and is evicted from the game. Player reapears after a period of time or not at all as specified by the party leader.

• Alternatives: none
• Classes
  
  • Character
  • Object
  • Weapon
  • Party
• Additonal Sections
  • Networking
    • The networking will be in a server/client relationship. Not peer-to-peer. Each client machine will send all information about what is happening in the game to the host, and that will send it out to everybody else. It will coordinate all communications between the other computers.
  • Graphics
    • Graphics will probably be pretty basic. I don't know the extent of the talent on the team, I know I don't have much graphics experience. Several graphics libraries can be found here: http://www.opengl.org/resources/libraries/higherlevel.html
  • Control
    • Controls will be as follows: Enter or left mouse click is fire, arrow keys will be movement, mouse movement will be aiming, R and 0right click will be reload, and shift will pick up a weapon that the user is standing over. Ammunition will automatically be picked up if it applies to the currently held weapon.
  • Performance
    • Performance is not going to be pretty. I don't think we will have much time to optimize any code. If we get it to work, it will be clunky. I still think it will be usable however.
• Schedule
  • As far as design
    • All planning and design must be finished by February 15th.
  • As far as writing code is concerned, several milestones must be achieved:
    • The user interface (creating and joining parties) (February 28th)
    • 3D environment with players moving around (March 31st)
    • Networking (March 31st)
    • Interplayer interaction and player interaction with the environment (Last day of school)