Original location of the document: http://www.soberit.hut.fi/T-76.115/02-03/palautukset/groups/GameMasters/de/docs/requirements/requirements.html

T-76.115 User Requirements Document

Contents

1. Introduction
2. System overview
3. Business goals
4. User Groups
5. Functional requirements
6. Properties
7. Constraints
8. Terminology and concepts
9. Acronyms and abbreviations

1. Introduction

1.1 Purpose of the document

The purpose of this document is to define what the system is to do from the user’s point of view. User requirements define system functions that users can see and system properties that customers are ready to pay for.

In short, a requirement is a statement of

• a function that the system must do
• a property that the system must have
• a constraint on the system.

Table 1: Possible readers of this document

1.2 References

List here all the documents that have been used as an information source and are necessary for understanding of this document. List also other specifications that have been used as a reference.

Table 2. A list of all other relevant documents

2. System overview

Name of the system, which requirements are defined in this document, is MrX (Mobile roleplaying eXperience). MrX is a system for creating and running mobile roleplaying games. It contains the game-engine, game creating tools, tools for a gamemaster and a client for playing the game. There is a graph in section 5 explaining the different users and functions of MrX.

3. Business goals

Customer wants the system mainly for research purposes. The object of the research would be to find out how communities using mobile devices could be born, evolve, survive and maybe die. In this case, the community will be a mobile roleplaying community. The system could also be used for testing AI controlled characters in the game and their co-operation with human players. Even though system is aimed at research, the customer hasn't excluded the possibility of gaining profit with it. Another goal of the customer is to collect experience of developement of open source software. That is why customer eagerly wants that group uses existing opensource software where ever it is possible.

4. User groups

This section describes intended users of the system.

Table 3. Users of the system

The amount of players varies -- in each game, the maximum number of players will be specified, but the minimum reasonable amount of players per game might be 10 or more. The number of researchers will depend on the amount of interest in conducting the experiments with MrX. There cannot be more than one Game Creator creating one game at one time, because two creators might create different things to same place at the same time. The reason why game masters and game creators are restricted to one is that the system will not (at least the initial version) support multiple game master clients. Nor can a single game be edited and created by multiple game creators concurrently. Nothing, of course, prevents multiple people switching seats, so to speak, when creating or running the game.

5. Functional requirements

This section defines the services that the system provides to the users. The services were defined using use cases. The following image presents the use case diagram of the over all system.

The use cases are discussed in following sections. The priorities are 1 = must have, 2 = essential, 3 = nice to have.

Player use cases

• Name: Create character
• Summary: The player connects the game website and makes character for him/her.
• Actors: The player of the game.
• Preconditions: The creator of the game has created a game and submitted it into the system.
• Basic sequence:
  • Step 1: The player connects the game website.
  • Step 2: The player chooses Create Character option.
  • Step 3: The player selects the game to which he/she wants to create a character for.
  • Step 4: The player fills in the needed information (list of information is provided by the game creator).
  • Step 5: The player enters a username.
  • Step 6: The player enters and verifies a password.
• Exceptions:
  • Step 4: Some of the filled in information is not acceptable. The player is asked to correct false information.
  • Step 5: The username could be already in use. The player is asked to choose a new username.
  • Step 6: The password is not acceptable. The player is asked to choose a new password.
• Post conditions: The player has now a ready character for this game.
• Priority: 2
• ID: P01

• Name: Join game.
• Summary: The player starts his/her game client and joins the game.
• Actors: The player of the game.
• Preconditions: The player has created a character for him/herself for this game and the game master has started this game.
• Basic sequence:
  • Step 1: The player starts the game client.
  • Step 2: The player sets the username.
  • Step 3: The player sets the password.
  • Step 4: The player chooses the game he/she wants to join.
  • Step 5: The player gets a welcome message
• Exceptions:
  • Step 2: There is no such username in the system. The is player asked to enter the username again.
  • Step 3: The password is wrong. The player is asked to enter it again.
• Post conditions: The player is now in game.
• Priority: 1
• ID: P02

• Name: Leave game.
• Summary: The player stops playing the game and exits the game client program.
• Actors: The player.
• Preconditions: The player must be in game.
• Basic sequence:
  • Step 1: The player selects Exit Game command from the client.
  • Step 2: The player is out of the game.
• Exceptions: None.
• Post conditions: The player is off game.
• Priority: 1
• ID: P03

• Name: Perceive.
• Summary: The player gets information about the surrounding virtual world.
• Actors: The player of the game.
• Preconditions: The player is in game.
• Basic sequence:
  • Step 1: The player selects the Look Around command.
  • Step 2: The player receives a general description of surrounding virtual world.
  • Step 3: The player may inspect the virtual world more by selecting Inspect More command.
  • Step 4: The player is presented a list of possible objects to inspect.
  • Step 5: The player chooses one of the objects.
  • Step 6: The player receives a more detail description of that object.
• Exceptions:
  • Step 6: If the player moves between steps 3 and 6, the object list might not be valid anymore i.e. the player is no longer near the selected object and therefore the player can not be presented more dateiled description of that object.
• Post conditions: None.
• Priority: 1
• ID: P04

• Name: Modify character.
• Summary: The player of the game modifies his/her virtual character.
• Actors: The player of the game.
• Preconditions: The player must be in game.
• Basic sequence:
  • Step 1: The player selects Modify Character command.
  • Step 2: The player chooses the object to modify from a given list
  • Step 3: The player chooses a modification action from a given list
  • Step 4: The player enters the possibly asked modification information.
• Exceptions:
  • Step 4: The player might enter invalid information. The player is asked to enter the information again.
• Post conditions: The status of the virtual character is now different.
• Priority: 3
• ID: P05

• Name: Interact.
• Summary: The player carries out some action relevant to the game.
• Actors: The player of the game.
• Preconditions: The player is in game.
• Basic sequence:
  • Step 1: The player selects Actions Menu from his/her client.
  • Step 2: The player selects either Actions List or Objects List from the Actions Menu.
  • Step 3: If the player selected Actions List, the player can now select an action from a given list. If the player selected Objects List, the player can now select an object from a given list
  • Step 4: If the player selected an action, the player can now select a possible target for that action from a given list. If the player selected an object, the player can now select an action for that object from a given list.
  • Step 5: The player can possibly set some attributes to the selected action-object pair (e.g. if the action is Shout and the object is Frank the attribute could be "Hey!").
• Exceptions:
  • Step 5: If the player is moving during this use case, the target of selected action might not be valid anymore.
• Post conditions: The system is now aware of the happened action.
• Priority: 1
• ID: P06

• Name: Receive event.
• Summary: The player receives messages from the system about events in the game.
• Actors: The player of the game.
• Preconditions: The player is in game.
• Basic sequence:
  • Step 1: A message pops to the screen of the client.
  • Step 2: The player possibly selects how to respond to this event by selecting an action from a given list.
• Exceptions: None.
• Post conditions: None.
• Priority: 1 (responding 3)
• ID: P07

• Name: Delete character.
• Summary: The player deletes the character he/she has made for him/her.
• Actors: The player of the game.
• Preconditions: The player has created a character.
• Basic sequence:
  • Step 1: The player connects the game website.
  • Step 2: The player chooses the Delete Character option.
  • Step 3: The player enters the username of the character and the password.
• Exceptions:
  • Step 3: The username or password is invalid. The player is asked to enter it again.
• Post conditions: The character has been deleted from the system and can not be used for playing anymore.
• Priority: 3
• ID: P08

Game master use cases

• Name: Join game.
• Summary: The game master starts his/her client and joins the game.
• Actors: The game master.
• Preconditions: The creator of the game has created and submitted a game to the system and the game has been started by the game master.
• Basic sequence:
  • Step 1: The game master starts his/her client.
  • Step 2: The game master selects selects the game to join from a given list of started games.
  • Step 3: The game master enters the password needed to master this game.
• Exceptions:
  • Step 3: If the password is wrong the game masters is asked to enter it again.
• Post conditions: The client of the game master is now active in this game. The game master can start following the game.
• Priority: 2
• ID: M01

• Name: Leave game.
• Summary: The game master shuts his/her client and stops following the game.
• Actors: The game master.
• Preconditions: The game master is joined to the game.
• Basic sequence:
  • Step 1: The game master select Leave game option from his/her client.
• Exceptions: None.
• Post conditions: The game master is not connected to the game anymore and he/she can't follow the game anymore.
• Priority: 2
• ID: M02

• Name: Follow game.
• Summary: The game master follows the flow of game by wathing a real-time list of events happening at the game.
• Actors: The game master.
• Preconditions: The game is up and running.
• Basic sequence:
  • Step 1: The game master watches the screen of his/her client.
• Exceptions: None.
• Post conditions: None.
• Priority: 1
• ID: M03

• Name: Modify world.
• Summary: The game master modifies the virtual game world.
• Actors: The game master.
• Preconditions: The game is up and running.
• Basic sequence:
  • Step 1: Game master selects the Modify World command from his/her client.
  • Step 2: Game master selects the object to modify from a given list.
  • Step 3: Game master selects the property to modify from a given list.
  • Step 4: Game master modifies that property.
• Exceptions:
  • Step 4: Modifying certain property might not be possible because of some in game event (e.g. the object might be in use by some character in game and therefore it could be not modified at this moment).
• Post conditions: The state of the virtual world is now different.
• Priority: 2
• ID: M04

• Name: Control NPC.
• Summary: The game master interacts with the virtual world using a NPC.
• Actors: The game master.
• Preconditions: The game is up and running and there are NPCs in the game.
• Basic sequence:
  • Step 1: The game master selects Control NPC command from his/her client.
  • Step 2: The game master selects which NPC to control from a given list.
  • Step 3: The game master selects an action for that NPC from a given list.
  • Step 4: The game master selects a possible target for that action from a given list.
  • Step 5: The game master sets some possible additional properties for the selected action.
  • Step 6: The NPC performs the action.
• Exceptions:
  • Step 6: Performing certain action might not be possible anymore because of some in game event (e.g. the target of the action might not be available anymore if the NPC or the target is moving during this use case).
• Post conditions:
• Priority: 3
• ID: M05

• Name: Administer.
• Summary: The game master administers the game.
• Actors: The game master and possibly some players.
• Preconditions: The game is up and running and there are some in game players.
• Basic sequence:
  • Step 1: Game master selects Administer command from his/her client.
  • Step 2: Game master selects the player to administer from a given list.
  • Step 3: Game master selects the administer action from a given list.
  • Step 4: The in game players receive a notice for this administrative action. The off game players receive a notice the next time they join the game.
• Exceptions: None.
• Post conditions: None.
• Priority: 3
• ID: M06

Game creator use cases

• Name: Create game using game editor tool.
• Summary: The game creator creates a complete role playing game for this system using the Game Editor tool.
• Actors: The game creator.
• Preconditions: None.
• Basic sequence:
  • Step 1: Game creator goes to game creation web site.
  • Step 2: Game creator selects create game option.
  • Step 3: Game creator chooses a name for the game.
  • Step 4: Game creator creates a textual backgroung story or plot of the game.
  • Step 5: Game creator creates a map for the virtual world. That is, the game creator defines a set of virtual circular areas.
  • Step 6: Game creator ties the virtual map with a real one by giving all the areas real physical coordinate center points and radiuses.
  • Step 7: Game creator defines the player character types. Defining character types includes defining character type name and the different variables of the character type.
  • Step 8: Game creator creates the objects of this game. Each object has a type, a set of information name-value pairs and a unit list that tells which units are connected to this certain object.
  • Step 10: Game creator populates the map with the objects. That means that the game creator assigns every object to some virtual area.
  • Step 11: Game creator defines the startup properties that the game master must set before starting the game.
  • Step 12: Game creator defines the end conditions of this game.
  • Step 13: Game creator defines the shutdown properties that the game master must set before stopping the game.
• Exceptions: None.
• Post conditions: Creator has created a complete game.
• Priority: 3
• ID: C01

• Name: Create game using plain text editor.
• Summary: The game creator creates a complete role playing game for this system using a plain text editor.
• Actors: The game creator.
• Preconditions: None.
• Basic sequence:
  • Step 1: Game creator writes the whole XML game file using a normal text editor tool.
• Exceptions: None.
• Post conditions: Creator has created a complete game.
• Priority: 1
• ID: C02

• Name: Submit game.
• Summary: The game creator submits a complete game to the system.
• Actors: The game creator.
• Preconditions: The game creator has created a complete game.
• Basic sequence:
  • Step 1: The game master submits the complete game using the game submission web page.
• Exceptions:
  • Step 1: The name of the game could already be taken. Game creator must change the name of the game and submit the game again.
• Post conditions: There is a game ready to be started in the system.
• Priority: 1
• ID: C03

AI player use cases

• Name: Receive input.
• Summary: The AI player receives information about some event that has happened in the virtual world.
• Actors: The AI player.
• Preconditions: The AI player is in game.
• Basic sequence:
  • Step 1: The AI player receives a message that describes the event.
• Exceptions: None.
• Post conditions: The AI player is now aware of the event.
• Priority: 3
• ID: I01

• Name: Report action.
• Summary: The AI player sends a message to the system describing the action the AI player.
• Actors: The AI player.
• Preconditions: The AI player is in game.
• Basic sequence:
  • Step 1: The AI player sends a message that describes the action.
• Exceptions: None.
• Post conditions:
• Priority: 3
• ID: I02

Administrator use cases

• Name: Start game-engine.
• Summary: The administrator of this system starts the game-engine.
• Actors: The administrator.
• Preconditions: The game-engine is down.
• Basic sequence:
  • Step 1: Administrator executes start game-engine script.
• Exceptions: None.
• Post conditions:
• Priority: 1
• ID: A01

• Name: Stop game-engine.
• Summary: The administrator of this system stops the game-engine.
• Actors: The administrator.
• Preconditions: The game-engine is up.
• Basic sequence:
  • Step 1: Administrator executes stop game-engine script.
• Exceptions: None.
• Post conditions:
• Priority: 1
• ID: A02

• Name: Start game.
• Summary: The administrator starts some Mrx game.
• Actors: The administrator.
• Preconditions: The creator of the game has created and submitted a game to the system.
• Basic sequence:
  • Step 1: The adimistrator starts one submitted game using a script or some dedicated administration tool.
• Exceptions: None.
• Post conditions: The game is now up and running. Players and game masters can join the game.
• Priority: 1
• ID: A03

• Name: Stop game.
• Summary: The administrator stops the game. If there are any active players, they will all be notified and they will all leave the game.
• Actors: The administrator and possibly some players.
• Preconditions: The game is up and running.
• Basic sequence:
  • Step 1: The administrator stops one running game using a script or some dedicated administration tool.
• Exceptions: None.
• Post conditions: The game is not up and running.
• Priority: 1
• ID: A04

• Name: Read logs.
• Summary: The administrator of this system reads the system logs.
• Actors: The administrator.
• Preconditions: None.
• Basic sequence:
  • Step 1: Administrator reads system logs.
• Exceptions: None.
• Post conditions:
• Priority: 2
• ID: A05

6. Properties (quality requirements, non-functional requirements)

As the game engine itself will be used by industry experts and is propably going to be under constant development, the main characteristics of the system will be:

• Expandability
  
  • Adding new modules and features and changing old ones should be made easy.
• Functional system
  
  • It is more important to get a working, perhaps incomplete system than an unstable system packed with fancy features
• Scalability
  
  • The system should be able to scale up when new users, games, functions, features etc. are added.

7. Constraints

The system should be made and run using free systems, platforms, server software, libraries and services (e.g. Java, MySQL, Linux, Apache, Tomcat, Jabber) because the project organization does not have the resources for using commercial software and the project results will be published under BSD license.

The system has to be able to run on a low-end Linux system and still be able to cope with a reasonable number of users. When the load increases, the hardware requirements should not increase dramatically.

At the moment the mobile terminals constitute harsh constraints on the clients, but in the future these constraints will be diminished and this must be taken into account in the design.

8. Terminology and concepts

The following terms and concepts are used in the project and it's implementation:

The following picture shows the relationships of the main concepts:

9. Acronyms and abbreviations