System: ARENA

1. Problem Statement

With the arrival of the global broadband network infrastructure, new game concepts are possible and resulted in the creation of a wealth of Multiplayer Online Games (MOGs), for example Quake, CounterStrike, Ultima Online, EverQuest, or WarCraft. These games share common concepts:

But after the broadcasting infrastructure of radio and television was supplemented by two-way network connections, another use of the technology was enabled: peer-to-peer (P2P) networks. Thus far they are mainly used for one-on-one messaging or simple file exchange.
The newly available FRAG framework manages peer-to-peer communication, distributed object synchronization and message transport for object-based 2D or 3D game worlds. FRAG is part of the GlobalSE project ARENA providing an infrastructure for tournaments in mobile environments.

You are asked to develop a peer-to-peer multiplayer online game called SWORD on top of the FRAG framework. Your mission is to demonstrate a functional prototype by the end of the project, which is based on the technologies and infrastructure made available to you. You are free to develop your own rules and game environment, but to keep this manageable, we suggest the story for this game to be set in a fantasy world where a large number of players need to UT:Accomplish missions.

 

Scenario

In the following section, a typical scenario for SWORD sessions is described.

a:Susan finds five of her fellow students with ``available'' status on the network, while she is checking her emails after her lunch break. She invites them to a chat room and asks them if they would be interested in playing a quick game of SWORD until the next lecture begins. a:Michael, a:John, and a:Lyta agree, a:Stephen and Talia still have to finish up something and suggest for the others to go ahead, they would join in later.

a:Susan fires up SWORD and it asks if she wants to play the game in stop-watch mode and set a deadline for the mission. She acknowledges, restricts the game to participants on her buddy list and enters the game. It loads her magician character from the game she played last week and after a short orientation she sends a message to a:John ``Where did you enter the game?'' He replies ``at the graveyard''. She asks him to meet her at the waterfall.

A few special world objects, such as the graveyard or the waterfall have fixed coordinates in the game world, most of the game world is generated from fractal algorithms, though, making it a challenge for both a:Susan and a:John to reach the waterfall. On the way the game calculates the details of the game world from the algorithms as the players UC:Move through the game. The calculations are exchanged between the players.

When a:Stephen enters SWORD, it automatically detects the game already in progress on the LAN and allows him to join.

As a:Susan is on a:Stephen's buddy list, he sees that she is already participating in a game. He is connected and receives enough data to display his immediate surroundings. When he UC:Moves towards areas of the map that have not yet been rendered, his game offers the information of the newly generated part of the world. If the parts have already been calculated by other players before him, the game gets the data from another player.

a:Susan's deadline is approaching while she is fighting a Dragon, so she tells a:Lyta that she will drop the magic sword by the village entrance and wishes her good luck with slaying the Dragon. She leaves the game.

All of a:Susan's game data has been broadcast to the remaining players, ranked by vicinity.

The next day, a:Susan meets three of her friends on her ``U-Bahn'' ride to campus and they wait at the ``Frttmaning'' stop. They decide to pick up the game they dropped the day before, open up SWORD and play until the train arrives at campus.

Requirements

The following sections lists the functional and nonfunctional requirements for the SWORD game.

Functional Requirements

Nonfunctional Requirements

Documentation

Target Environment

The target environment for the game is a wireless network setup of the provided iBooks running Mac OS X v10.2 and the FRAG framework, which is made available for modification and extension in the ARENA CVS repository. The SWORD game is to be integrated into the ongoing efforts of the ARENA project.

Deliverables

Schedule


31 Oct 2002
Analysis Complete: The Halloween Document. By this date the Requirements Analysis Document (RAD) is baselined the review process starts. Part of the RAD is a script and storyboard for the DVD (the Scenarios).
6 Nov 2002
Requirements Analysis Review. By this date the developers have gotten feedback on the RAD and a presentation to the client about the analysis of the irements.

15 Nov 2002
Design Complete. By this date the System Design Document (SDD) is baselined and the review process starts.

20 Nov 2002
System Design Review. By this date the developers have gotten feedback on the SDD and a presentation to the other developers (and possibly the client) about the system design.

29 Nov 2002
APIs Complete. By this date the Object Design Document (ODD), describing the APIs of the subsystems, is baselined and the review process starts.

4 Dec 2002
Unit Test. By this date the developers have gotten feedback on the ODD and API and give a presentation to developers about the use of the APIs and how they can be tested automatically.

13 Dec 2002
Test Drivers and Stubs are complete. By this date every subsystem is implemented enough for other components to compile and run.

18 Dec 2002
Integration Test Suite Presentation. This presentation focuses on how the integration tests are conducted and what is expected of the subsystems.

10 Jan 2003
Client Acceptance Test Preparation Done. By this date the DVD that will be used during the Client Acceptance (CAT) is complete. Also, the presentation outline and nstration script is finalized. This is where the review process for presentation starts.

15 Jan 2003
Client Acceptance Test Dry-Run. By this date the developers have gotten feedback on their planned entation, and conduct a dress-rehearsal of the CAT. After that, the lopers get feedback on what to focus on in the actual CAT.

22 Jan 2003
Client Acceptance Test. This presentation explains all details of the system to the clients, and is filmed for a showcase DVD of the system.

31 Jan 2003
Documentation Complete. By this date all developer documentation is completed and reviewed.

7 Feb 2003
Process Analysis Complete. By this date voluntary focus groups are formed and interviewed. A analysis document is prepared and given to the developers for review.

19 Feb 2003
Project archived and structures consolidated. By this date everything that regards the project is consolidated in a project archive, consisting of all project work products, reviews and deliverables. The last step is the deletion of all dispensable data and the closure of the project infrastructure.

Top-level Design

The structure of the system is shown in the figure above. The services that are offered by the individual subsystems are:


1.
Game Layer
2.
Framework Layer


3.
Operating System Layer

Team Organization

The project is organized in teams, which all have specific roles in the project. These roles are:

Client Acceptance Criteria

This is a broad problem statement, and as such, all the functionality that has been alluded to, is not expected to be delivered in one semester. Furthermore, the client is very willing to discuss any all recommendations on changing the requirements specified in this document. During the requirements analysis phase of the project, the functional and global requirements of an acceptable prototype will be published. An initial prototype of the SWORD system is expectedcted four to six weeks after the functional requirements have been published. The delivery of a second prototype of the SWORD system is expected at the end of the semester.The client realizes that all components of SWORD not be functional by the end of the semester; however, the functional units of the prototype that are delivered at the end of the stemester must work in a mobile environment.

Development Environment

The development of the SWORD system makes use of the facilities offered in the clusters on TUM campus, the Software Engineering Laboratory (Aquarium), room 01.09.022 as well as Apple iBooks that will be provided. While the clusters are shared with other students taking other courses, the iBooks are reserved solely for the development of the SWORD System. The Aquarium offers a cluster of 16 Macintosh computers running MacOS X v10.2, the 20 iBooks are running MacOS X v10.2. The Aquarium machines are connected via a Ethernet, the iBooks are equipped with a wireless LAN card.

The provided software packages on these workstations are


Footnotes


...FRAG
Framework for Realtime Ad-hoc Games

...(Zeroconf)
http://www.zeroconf.org/
 

2. Requirements
This section describes the user needs that the system has to support in terms of actors, user tasks, and domain constraints. Actors are entities that interact with the system. User tasks are activities initiated by actors that are supported by the system. Domain constraints are facts that are the system must take into account.
2.1. Actors
2.1.1. Artificial Player
Description:
An A:Artificial Player controls an Adventurer. The A:Artificial Player interacts with the game over the same APIs. It's derived from the superclass A:Player and is controlled by algorithm.
Initiated User Tasks:
Hunt for adventurers
Initiated Use Cases:

No use cases specified.
2.1.2. Human Player
Description:
The A:Player is a person who is able to play one or more games. This is the actual human sitting in front of the game. He or she cannot directly interact with anything in the game world, nor can he or she be manipulated directly by software (yet ;^)
Initiated User Tasks:
Accomplish mission
Communicate with other players
Initiated Use Cases:
Hand over Game
Join game
Play SWORD
Resume Game
Participating Use Cases:
Hand over Game
Move
Instances:
Gina
John
Lyta
Michael
Peter
Stephen
Susan
2.1.3. Player
Description:
Superclass for the A:Human Player and the A:Artificial Player, with the sense to "syncronize" the Control of Adventurers
Initiated User Tasks:
Control Adventurer
Participating User Tasks:
Accomplish mission
Communicate with other players
Initiated Use Cases:
Chat with players
Hand over Properties
Talk with Players through a headset
Participating Use Cases:
Chat with players
Hand over Properties
Talk with Players through a headset
2.2. User Tasks
2.2.1. Accomplish mission
Initiating Actor:
Human Player
Participating Actors:
Player
Task Description:
The user task consists of all actions which can be done to start, end and reach the objective of completing the mission.

The A:Player controls his actor around the map to explore the world. He can Open doors to enter Buildings and Eat food to regain strength.

He can PickUp Items and perform various actions with them, which are UC:Drop item, Explore item and UC:Use item with. He can also Look At item.
Realized in Use Cases:
Hand over Game
Hand over Properties
Join game
Play SWORD
Resume Game
2.2.2. Communicate with other players
Initiating Actor:
Human Player
Participating Actors:
Player
Task Description:
This user task describes the communication between the different A:Players during the game. The communication can take different forms and can be in broadcast mode (to all other A:Players) as well as a one-to-one form.
Realized in Use Cases:
Chat with players
Talk with Players through a headset
2.2.3. Control Adventurer
Initiating Actor:
Player
Task Description:
The Adventurer is controlled by this Task.
Realized in Use Cases:
Drop item
Look at item
Move
Use item with
2.2.4. Hunt for adventurers
Initiating Actor:
Artificial Player
Task Description:
An Adventurer is running around, and Attacks all in game characters in sight, with task to kill or wound Adventurers, preventing/delaying them from mission completion.
Realized in Use Cases:
Search adventurer
2.3. Domain Constraints
2.3.1. Broadcast game data
Type:
Domain Constraint
Description:
Calculations of one A:Player are broadcast to other A:Players.
2.3.2. TCP/IP connection or airport
Type:
Domain Constraint
Description:
there is a tcp/ip or airport needed for playing the game
2.4. Quality Constraints on User Tasks
2.4.1. No interruption on (short) disconnect
Type:
Quality Constraint on User Task
Description:
In case of a short disconnection, all A:Players are able continue the game without significant interruption, and as soon as the connection becomes available again, the game becomes consistent again.
3. Specification
This section describes the specification of the system in terms of use cases, services, and quality constraints. Use cases describe sequence of interactions between actors and the system. Services are features that the system provides that can be used to realize use cases. Quality constraints are constraints on use cases or services that must be met by the system.
3.1. Use Cases
3.1.1. Chat with players
Initiating Actor:
Player
Participating Actors:
Player
Realized User Task:
Communicate with other players
Flow of events:

Actors System
1. The A:Player likes to chat to the other A:Players and press a certain key
2. The system displays a box for typing characters
3. [optional] A:Player presses "chat target" key
4. System shows a box with list of teams and A:Players in game (use S:detectPeers)
5. A:Player selects team or A:Player he want to chat with, default is own team
6. The A:Player types the text he likes to tell the others
7. The system broadcasts the text to the other peers with the name of the writer (use S:sendMessage)

Preconditions:
min. 2 A:Players
Exit conditions:
message sent
Used Services:
detectPeers
sendMessage
Scenarios:
Talk to John
3.1.2. Drop item
Initiating Actor:
No initiating actor specified.
Participating Actors:
No participating actors specified.
Realized User Task:
Control Adventurer
Flow of events:

Actors System
1. The Adventurer selects the item from the inventory.
2. The System displays the item properties. (use S:getProperties)
3. The Adventurer drops the item.
4. The System removes the item from the inventory and places it on the map (use S:dropItem)

Preconditions:
The inventory is empty.
Exit conditions:
The item has been dropped on the ground.
Used Services:
dropItem
getProperties
3.1.3. Hand over Game
Initiating Actor:
Human Player
Participating Actors:
Human Player
Realized User Task:
Accomplish mission
Flow of events:

Actors System
1. A A:Player wants to NFC:hand over his status of his adventurer
2. Another A:Player takes over the adventurer.

Used Services:

No services specified.
3.1.4. Hand over Properties
Initiating Actor:
Player
Participating Actors:
Player
Realized User Task:
Accomplish mission
Flow of events:

Actors System
1. The A:Player decides to NFC:hand over items. (include UC:Drop item)
2. the A:Player wants to tell to other A:Players where he droped the items (include UC:Drop item)
3. other A:Player want to select the items (include UC:Use item with)

Preconditions:
at least one item
Exit conditions:
items handed over
Used Services:

No services specified.
3.1.5. Join game
Initiating Actor:
Human Player
Participating Actors:
No participating actors specified.
Realized User Task:
Accomplish mission
Flow of events:

Actors System
1. The A:Player chooses to join a game.
2. The system shows a list of running games. (use S:detectGame)
3. The A:Player chooses a game.
4. The system tries to connect to the game. (use S:connectPeer)

Exceptions:
No game created. The A:Player cannot join a game, because no such game exists. He is force to create a new game.
Rules:
The A:Player can join the game only if he is authorized to enter the game. He can join the game if he is in the buddy list of one participant of the game
Preconditions:
A:Player started Sword. He has chosen a nick name.
Exit conditions:
mission loaded and connected
Used Services:
connectPeer
detectGame
3.1.6. Look at item
Initiating Actor:
No initiating actor specified.
Participating Actors:
No participating actors specified.
Realized User Task:
Control Adventurer
Flow of events:

Actors System
1. the A:Player wants to look at an Item, and therefore points at that item
2. it is checked, if the item is too far away
[too_far_away (use S:distanceToObjects)
3. the properties of the the item are displayed
[no_possible_item] (use S:lookAtItem)

Exceptions:
[no_possible_item] nothing happens
[too_far] nothing happens
Used Services:
distanceToObjects
lookAtItem
3.1.7. Move
Initiating Actor:
No initiating actor specified.
Participating Actors:
Human Player
Realized User Task:
Control Adventurer
Flow of events:

Actors System
1. Using some system input device, the A:Human Player commences to UC:Move his/her Adventurer towards the desired position.
This could be done step by step using the keyboard controls or as a straight movement by clicking once with the mouse on the new position.
2. The System gets the property [position] from the Adventurer, the coordinates of the desired position on the map, then calculates the trajectrory and decides whether the movement is possible. If not throws exception [movement not possible] (use S:getProperties)
3. Should any obstacles (i.e. other Adventurers, Items or objects of the game world) hinder the movement of the Adventurer, the A:Human Player corrects the direction.
4. The System calculates the new input and (if OK) alerts the Object Manager about the necessary updates in the state of the Adventurer. (use S:move)
5. The System alerts the View Contoler of the world that presents the view to the A:Human Player and scrolls if needed/updates the map view. The System updates the property [position] of the Adventurer as well. (use S:setProperties)
6. The A:Human Player exits/deactivates the movement sequence.

Exceptions:
[movement not possible] The Adventurer simply remains on its current position when the obstacle lies straight next ti it.
Rules:
Check each time whether movement is possible and if not throw exception, so that the A:Human Player selects a new position to be moved to.
Preconditions:
An Adventurer to UC:Move, new position coordiantes, sufficient space for the movement.
Exit conditions:
The movement sequence is interrupted by the A:Human Player.
Quality Constraints:
Exeptions defined
Used Services:
getProperties
move
setProperties
3.1.8. Play SWORD
Initiating Actor:
Human Player
Participating Actors:
No participating actors specified.
Realized User Task:
Accomplish mission
Flow of events:

Actors System
1. The A:Player double clicks the SWORD icon on her/his computer.
2. SWORD asks, if the A:Player likes to join an existing game (and displays them) or he likes to create a new one (use S:detectGame)
3. SWORD asks, if the A:Player likes to load a saved game and displays them (use S:detectSavedWorld)
4. the A:Player likes to create a new game (or see UC:Join game) (include UC:Join game)
5. or the A:Player chooses to resume a worl and selects one [no_saved_world] (include UC:Resume Game)
6. SWORD asks for preferred mission. (use S:setMission)
7. The A:Player chooses a mission.
8. SWORD asks for the preferred game mode. (use S:setGameMode)
9. The A:Player chooses the stop-watch mode and sets a deadline. [invalid format]
10. SWORD asks if the A:Player wants to set any restrictions. (use S:setRestrictions)
11. The A:Player restricts the game to her/his buddy list.
12. SWORD asks the A:Player which character he likes to play with and displays the A:Players saved characters (use S:loadCharacter)
13. the A:Player chooses a game character
14. SWORD loads the A:Player's character. (use S:createNewGame)
15. The A:Player enters the game and plays.
16. The A:Player presses the exit botton
17. SWORD asks if he likes to UC:Hand over items
18. the A:Player hands over special items (include UC:Hand over Properties)
19. SWORD asks, if he likes to save his character and/or the world
20. The A:Player wants to save his character and the world, and wants to s:Leave the game
21. the character is saved (use S:saveCharacter)
22. the world is saved (use S:saveWorld)
23. Exit game

Exceptions:
[invalid format]:
1. system displays message box.
2. The A:Player gets a second try.
[no_saved_world] message: not possible
Preconditions:
The A:Player has installed SWORD on her/his computer
Used Services:
createNewGame
detectGame
detectSavedWorld
loadCharacter
saveCharacter
saveWorld
setGameMode
setMission
setRestrictions
Scenarios:
Initiate a SWORD session
Quest for the golden armor
Rescue of Angelina
3.1.9. Resume Game
Initiating Actor:
Human Player
Participating Actors:
No participating actors specified.
Realized User Task:
Accomplish mission
Flow of events:

Actors System
1. the A:Player likes to resume a saved world
2. the world is loaded (use S:loadWorld)

Used Services:
loadWorld
3.1.10. Search adventurer
Initiating Actor:
No initiating actor specified.
Participating Actors:
No participating actors specified.
Realized User Task:
Hunt for adventurers
Flow of events:

Actors System
1. randomly Run around
2. computes if there is an Adventurer close by (use S:distanceToObjects)
3. go to Adventurer

Exit conditions:
Adventurer Runs away and is out of the visual range
Used Services:
distanceToObjects
3.1.11. Talk with Players through a headset
Initiating Actor:
Player
Participating Actors:
Player
Realized User Task:
Communicate with other players
Flow of events:

Actors System
1. one A:Player likes to chat with other A:Players and presses a certain key
2. displays a list of possible A:Players (use S:detectPeers)
3. selects certain A:Players
4. opens a "cummunication channel" [no_connection] (use S:communicationChannel)
5. communicate to A:Players
6. press certain key for closing connection

Exceptions:
[no_connection] there is no connection because of low bandwith
Preconditions:
minimum 2 A:Players
Exit conditions:
the Communication channel is closed
Used Services:
communicationChannel
detectPeers
3.1.12. Use item with
Initiating Actor:
No initiating actor specified.
Participating Actors:
No participating actors specified.
Realized User Task:
Control Adventurer
Flow of events:

Actors System
1. The A:Player selects an Item from his backpack.
2. The system highlights the object.
3. The system gets the Properties of the selected Item. (use S:getProperties)
4. The A:Player drags the Item to the other Item, taht has to be used.
5. The system measures if the distance between the objects is not too long. (use S:distanceToObjects)
6. The A:Player Drops the Item over the other Item. (include UC:Drop item)
7. The System gets the properties of the A:Player and ... (use S:getProperties)
8. ...calculates wether the A:Player is able to use this Item with each other. (use S:itemSuitsObject)
9. The System combines the to objects. In more detail the process of combining is changing the status of one item and deleting the other. (use S:useItemWith)

Rules:
There are curtain rules wich Item should be used with each other.
Preconditions:
One of the Items is in the backpack of the A:Player.
Exit conditions:
One item is deleted or at least one item has changed its status.
Used Services:
distanceToObjects
getProperties
itemSuitsObject
useItemWith
3.2. Services
3.2.1. communicationChannel
Description:
the system "connects" the peers and offers a Communication channel the A:Players are able to talk with
Inputs:
peers to connect, speech
Outputs:
Communication channel, speech
Use cases:
Talk with Players through a headset
3.2.2. connectPeer
Description:
If the A:Player chooses to join an existing game, his computer has to connect to all computers invovled in the game, to check if the A:Player is allowed to participate, and to integrate itself in the game.
Inputs:
identifier of the game
Outputs:
information if connecting was successful
Use cases:
Join game
3.2.3. createNewGame
Description:
Creates a new game instance with a given, network-unique identifier (name)
Inputs:
The identifier of the game to be created
Outputs:
information if creation of the game was successful
Use cases:
Play SWORD
3.2.4. detectGame
Description:
The A:Player can browse all running games on the local network.
Outputs:
list of running games
Use cases:
Join game
Play SWORD
3.2.5. detectPeers
Description:
all A:Players participating in this game are detected
Inputs:
network component
Outputs:
participating A:Players
Use cases:
Chat with players
Talk with Players through a headset
3.2.6. detectSavedWorld
Description:
gets a list of all saved games, this A:Player was in
Inputs:
A:Player name (computer id)
Outputs:
list of saved games
Use cases:
Play SWORD
3.2.7. distanceToObjects
Description:
When a actor discovers an object then he must stand in front of the object on a specified distance to do something with it.
Inputs:
distance in meters or in dots to the object
Outputs:
if the object is reachable for the actor.
Quality Constraints:
distance of objects to use
Use cases:
Look at item
Search adventurer
Use item with
3.2.8. dropItem
Description:
Removes item from character's (Adventurer) equipment pool (backpack). Adds item to map's container, and assigns it position on the map.
Inputs:
Data about which item is to be dealt with.
Outputs:
Item is no more in backpack, but assigned a position.
Use cases:
Drop item
3.2.9. getProperties
Description:
Provides information about an actor or an object
Inputs:
Actor/Object Identification
Outputs:
Actor/Object Properties;

For Actors: Life status, magic status etc
For Objects: Any useful information, describing the condition/properties of the object
Use cases:
Drop item
Move
Use item with
3.2.10. itemSuitsObject
Description:
The system measures weather the two Items that are used together suit each other.
Inputs:
Two Items
Outputs:
Message
Use cases:
Use item with
3.2.11. loadCharacter
Description:
a list of saved Characters, this A:Player saved, is displayed
Inputs:
A:Player id
Outputs:
list of saved characters
Use cases:
Hand over Game
Play SWORD
3.2.12. loadWorld
Description:
Load a saved (resumed) game. The status of the game as of the time it was saved is recreated.
Inputs:
identifier of the game (name, corresponding to the file)
Outputs:
the data of the saved game
Use cases:
Resume Game
3.2.13. lookAtItem
Description:
from a certain item are the properties displayed
Inputs:
the item
Outputs:
certain important properties of item
Use cases:
Look at item
3.2.14. move
Description:
This system service supports the navigation of the Adventurer in the game world. The A:Human Player can choose the point/position, to which he/she wants to UC:Move his/her Adventurer. This could happen for example by clicking once with the mouse (or using keyboard's up/down/left/right keys) on the new position on the map or anywhere in the nearby visible environment. The system computes the new coordinates of the Adventurer, displays it on the new position (including the animated process of movement) and updates the coresponding [position] property of the Adventurer. Optional, the A:Human Player can UC:Move his Adventurer in faster mode (i.e. Run) simlpy by pressing a specific button, holding the joystick longer forwards etc.
Should any hindrances lie on the path between the old and the new position, the Adventurer is moved only to the first one.
Inputs:
New position coordinates, to which the A:Human Player wants to UC:Move his/her Adventurer.
Outputs:
Animation of the movement of the Adventurer towards the desired position presented to the A:Human Player's view;
The Adventurer standing at the desired position.
Use cases:
Move
3.2.15. saveCharacter
Description:
The properties, invertory, lifestatus of the Character are saved
Inputs:
Character
Outputs:
saved character data
Use cases:
Hand over Game
Play SWORD
3.2.16. saveWorld
Description:
After exiting the A:Player is asked to save the game. If he wants to save the game, it is being saved on the computer.
Inputs:
Shot of the game.
Outputs:
File in the system.
Use cases:
Play SWORD
3.2.17. sendMessage
Description:
A A:Player can Send Messages to other A:Players in the game.
Inputs:
The message to be sent
Quality Constraints:
timely message delivery
Use cases:
Chat with players
3.2.18. setGameMode
Description:
The A:Player can choose between differnt game modes: stop-watch mode or no time limit. And deathmatch or cooperative mode.
Inputs:
game mode, and if needed deadline
Outputs:
mode set
Use cases:
Play SWORD
3.2.19. setMission
Description:
the A:Player selects one mission
Inputs:
selected mission
Use cases:
Play SWORD
3.2.20. setProperties
Description:
To change the status of an actor, or the status of an object
Inputs:
Character/Object ID
What to change
Outputs:
Updated actor/object status
Use cases:
Move
3.2.21. setRestrictions
Description:
restrictions are displayed:
-buddy list
-persons to select
-all persons, who likes to play
The choice of the A:Player is noticed
Inputs:
the names of A:Players, who are allowed to play in this game
Outputs:
names to the network component
Use cases:
Play SWORD
3.2.22. useItemWith
Description:
This system service is used to combine two item objects. There are predefined rules wich objects should be able to merge to a new one or to create new event(s) in the game. If the items are not related, a message is being send to the A:Player.
If there is a rule, how the objects are to be used together, the system changes the status of one of them and deletes the other. If neiter the one nor the other Item is to be deleted a new Event is created. In this case no Item is deleted.
Inputs:
Two item objects.
Outputs:
New Event.
One Item with changed Status
Quality Constraints:
distance of objects to use
Use cases:
Use item with
3.3. Global Functional Constraints
3.3.1. Broadcast data
Type:
Functional Constraint
Description:
calculations of one A:Player are broadcast to other A:Players
3.3.2. disconnect reconnect
Type:
Functional Constraint
Description:
In case of an connection loss all A:Players are able to continiue the game without significant interruption. As soon as the connection becomes available again, the game becomes consistent again.
3.3.3. hand over data
Type:
Functional Constraint
Description:
a A:Player can UC:Hand over Properties or other data to any other A:Player
3.3.4. hand over game state
Type:
Functional Constraint
Description:
A:Players can hand over any game state
3.3.5. join game
Type:
Functional Constraint
Description:
A:Player can join the game already in progress
3.3.6. start sword
Type:
Functional Constraint
Description:
A:Player can start the game at any time and without network configurations
3.3.7. suspend
Type:
Functional Constraint
Description:
A:Players can s:Leave the game at any time, preserving their game state localy
3.4. Quality Constraints on Use Cases
3.4.1. Exeptions defined
Type:
Quality Constraint on Use Case
Description:
UC can be interrupted or aborted by external events. No UC may caught "unprepared". E.g a character gets hit by an arrow while talking to somone. The system has to know that the character must stop talking and start dieing.
Constrained Use Cases:
Move
3.4.2. Precondition check
Type:
Quality Constraint on Use Case
Description:
For every use case the defined precondition must be fullfilled. Otherwise the A:Player will be notified by a system message
3.4.3. pause
Type:
Quality Constraint on Use Case
Description:
All Use Cases need to be interuptible and resumable.
3.5. Quality Constraints on Services
3.5.1. distance of objects to use
Type:
Quality Constraint on Service
Description:
the NFC:distance of objects to use should only be about one meter. At this distance the A:Player can make something with the object.
Constrained Services:
distanceToObjects
useItemWith
3.5.2. timely message delivery
Type:
Quality Constraint on Service
Description:
the message has to arrive in a timeframe of maximum 2 seconds
Constrained Services:
sendMessage
4. Examples
This section provides examples of the system in use in terms of actor instances and scenarios. These serve an illustrative purpose and support the discussion of details related to actors, User tasks, and Use cases described in previous sections.
4.1. Actor Instances
4.1.1. Gina
Actor:
Human Player
Description:
No description specified.
4.1.2. John
Actor:
Human Player
Description:
No description specified.
4.1.3. Lyta
Actor:
Human Player
Description:
No description specified.
4.1.4. Michael
Actor:
Human Player
Description:
No description specified.
4.1.5. Peter
Actor:
Human Player
Description:
No description specified.
4.1.6. Stephen
Actor:
Human Player
Description:
No description specified.
4.1.7. Susan
Actor:
Human Player
Description:
No description specified.
4.2. Scenarios
4.2.1. Enter the running game
Instantiated Use Case:
No use case specified.
Initiating Actor Instance:
No actor instance specified.
Flow of events:
When a:Stephen enters Sword, it automatically detects the game (a:Susan, a:Michael, a:John, a:Lyta) is already in progress on the LAN and allows him to join (UC:Join game).

As a:Susan is on a:Stephen's buddy list, he sees that she is already participating in a game. He is connected (Connect to Game).
4.2.2. Fight for the Map
Instantiated Use Case:
No use case specified.
Initiating Actor Instance:
No actor instance specified.
Flow of events:
After entering the game, the Adventurers Desiderata, MacDuff, Paul the baptist and Conan try to locate the map to the secret treasure and get to it ASAP. Walking around, each of them tries to stay away from the others, cause otherwise he/she is risking to get killed before even making it to the map. Desiderata finds the map first and proceeds towards the place X, where the treasure lies. Meanwhile the other Adventurers are informed by the System that Desiderata has the map. Conan happens to be nearby and Runs to cross her way. He sees her and pick a fight to get the map. Conan wins, takes the map from the fragged Desiderata and proceeds towards the place X. Before even making a step he is being attacted by Paul the baptist, who has been secretly watching the fight between him and Desiderata, and brutally killed from ambush. Happy, though careless not to watch on all sides for other enemies, Paul the baptist Walks through the forest. It is getting darker and darker with each step he is making forwards. At some time he gets lost and even the Overview map cannot help him (it could if he had gathered more herbs). Lost and desperate Paul the baptist bumps repeatedly his head in the nearby tree without even noticing the approaching Barkeeper MacDuff.
MacDuff on his side can finde his way through, because he gathered as many as possible bottles of booze (lying all over the terrain). Cunning as he is, MacDuff offers with UC:Hand over item to Paul the baptist to have "just a sip" from his newest beverage. Obsessed from sorrow Paul the baptist accepts the drink, takes "just a sip" and falls instantly drunk on the ground. With a smirking smile on his face, MacDuff jumps over the snoring Paul the baptist and goes straight to the place X.
He finds there the secret treasure, which in this scenario turns to be a new recipe for alcohol-free beer... Game Over
4.2.3. Hunt for treasure
Instantiated Use Case:
No use case specified.
Initiating Actor Instance:
No actor instance specified.
Flow of events:
Our heros meet a thief in a bar. He tried to steal one members money, and is captured. To prevent himself from being ripped apart (we are in rough times), he tells the heros the story of enormios treasure covered by un unspecified monster. After some "offers he cant refuse" he is willing to tell the place of the Traesure with Monster.
The heror proceed their way to this place. The nearer they come to the treasure, they are bothered by monsters serving the "big chief", highly motivated to protect the treasure and the chief.
After killing most monsters, they figure out the big chief is a big Dragon, who can only be satisfied by an virgin princess.
So they have to find a virgin princess, feed her to the Dragon. Beeing stuffed, the treasure can be taken without further resistance.

And for those, who were not killed, their life turns to never known wealth.
4.2.4. Initiate a SWORD session
Instantiated Use Case:
Play SWORD
Initiating Actor Instance:
No actor instance specified.
Flow of events:
a:Susan finds five of her fellow students with "Available" status on her iChat Buddy List while she is checking her emails after her lunch break. She invites them to a iChat Chat Room and asks them if they would be interested in playing a quick game of Sword until the next lecture begins. a:Michael, a:John, and a:Lyta agree, a:Stephen and Talia still have to finish up something and suggest for the others to go ahead, they would join in later.

a:Susan fires up Sword (NFC:start sword) and it asks if she wants to play the game in stop-watch mode and set a deadline for the mission (Set game mode). She acknowledges, restricts the game to participants on her Sword Buddy List and enters the game. It loads her magician character from the game she played last week.
4.2.5. Leave the game
Instantiated Use Case:
No use case specified.
Initiating Actor Instance:
No actor instance specified.
Flow of events:
a:Susan's deadline is approaching while she is fighting a Dragon, so she leaves the game (Exit game).

All of a:Susan's game data has been broadcast to the remaining A:Players (a:Michael, a:John, a:Lyta, a:Stephen), ranked by vicinity (NFC:Broadcast game data).
4.2.6. Quest for the golden armor
Instantiated Use Case:
Play SWORD
Initiating Actor Instance:
No actor instance specified.
Flow of events:
a:Susan decides to make a game(NFC:start sword) so she starts the game, selecting Collect the Golden armor mission (Choose mission), a:Lyta, a:Michael and a:Stephen decide to join. a:Susan makes her own team. Then, a:Stephen creates a new team, and a:Michael joins it. Then, a:Lyta joins a:Susans team several minutes later (UC:Join game).

In the meantime, a:Susan selects Desiderata the Witch as a character, and appears in the battle map near team 1s camp. a:Stephen takes a Conan the Fighter, and is joined by a:Michael as Paul the baptist at the team 2s camp. a:Lyta delayed a bit by a phone call and can join the game only in some minutes.

The task is to find the golden armor, which contains golden helmet, chest armor, gloves and a clad. Desiderata has a spell book, woodstock and a knife in the beginning. She UC:Moves (Walk) on and spots Ystarayon, a magic plant in the bush. She picks it up (Gather magic grass) and adds it to her magic equipment, learning the spell curse. But as she picks it up, a Wolf Runs on her (UC:Search adventurer), and starts biting, but she kills the beast (Fight enemy) with several hits with her woodstock. She loses some life points. Then she spots golden helm, and tries to get close to it, but gets a shot from a hidden bow, which makes her life points dangerously low. She Runs on (Run) and spots a magic spring (religious place), where she drinks (Eat) and so can restore some hit points.


During the same time, Conan and Paul the baptist UC:Move on. Conan has full leather armor on him, and metal helm, while Paul the baptist has only a leather jacket. Conan carries a knife, short sword and a shield, while Paul the baptist has a pike. They see the river and behind it golden gloves. But the small bridge is raised, and as they approach it, a huge Bear appears (UC:Search adventurer), protecting the bridge. Conan takes out his sword (Arm Self) and a shield, and starts a fight (Fight enemy), while Paul the baptist prays, healing Conan's wounds (Heal character). They manage to kill the monster, and then both Paul the baptist and Conan lower the bridge, and pick up (Pcikup item) an artifact. Paul the baptist starts chat session locally to Conan (UC:Chat with players) and they discuss, how they go on. The artifact is finally picked up by Paul the baptist.

In the meantime, a:Lyta joins the game (UC:Join game), selecting Brunhild the Fighter as character. She gets another equipment, meaning a battleaxe, knife and armored vest. She chats with Desiderata (UC:Chat with players), and they decide to meet at the big tree near the mountain. As Brunhild Run (Run) to rendezvous, she finds a four-clover, but she cannot Cast spells so she takes it (PickUp Item), to bring it to Desiderata.

Paul the baptist and Conan decide to split and search, one to the north and one to the south, and meet in 5 mins. Paul the baptist spots Desiderata and Brunhild, and a golden clad. He calls Conan and attacks Brunhild from behind with his pike (Fight enemy), causing damage to her, but Desiderata casts a curse spell on him (Bewitch people), which makes him moving very slowly, so Brunhild finishes him off with her axe. He looses his artefact, and can't fight any more. So he has to return to his camp to refill his live energy. Desiderata and Brunhild now have three artifacts, and pick up the fourth finally. They need to bring it to a hut over the mountain. They UC:Move (Walk) along the road there, but Conan waits for them, and attacks (Fight enemy). His sword destroys Brunhilds battleaxe, and her knife can't cause enough damage to him. Desiderata has no mana, and therefore can't help Brunhild, who is out of action now. So Desiderata attacks Conan with a woodstock, and hits him badly, but then she is out of action too. Conan however has very low hit points now. Desiderata and Brunhild use public chat (UC:Chat with players) to call Conan bad boy as he attacked girls. He continues his way in the meantime, but attacked by the wolves (UC:Search adventurer), who put him out of action. But Paul the baptist is cured by the time, and finds the items on the road, picks them up (PickUp Item) and carries them to the hut, thus completing mission.
4.2.7. Rescue of Angelina
Instantiated Use Case:
Play SWORD
Initiating Actor Instance:
No actor instance specified.
Flow of events:
Paul the baptist, MacDuff and Conan are Adventurers in a game. They try to get an overview and Walk around (UC:Move) for a short to discover their area. Then the characters start Walking towards each others by orientating using the Overview map. While Walking they try to pickup as many items (UC:Use item with inventory) as possible. Suddenly MacDuff finds a big gold nugget(UC:Use item with). Meanwhile Conan passes a small village. MacDuff notifies his mates about (UT:Communicate with other players using UC:Chat with players) his finding. Conan invites him to come to the village and MacDuff agrees. Meanwhile Paul the baptist is struggeling(UC:Move) through the deep forest and finds an ancient spell on a clearance (UC:Use item with), while MacDuff and Conan are exchanging (UC:Hand over item) the gold against an powerfull hammer in the village.
Suddenly they are attacked by an Dragon (UT:Hunt for adventurers). So Conan must protect MacDuff and himself (Use item (sword)with Dragon) by fighting the Dragon. Because Conan was hit twice by the fire he has lost energy, and he reports that to Paul the baptist (UC:Talk with Players through a headset) to get Paul healing him. They agree on meeting at the water fall, which both see one the Overview map.
MacDuff decides to Walk around by himself. Although he is not strong, he has no fear of wild creatures.
And so he is struggling through deep forest, when he is suddenly detected (Hunt for adventurer) by a mob of Orcs. They try to hit him (Fight enemy) him but he is quick and gives them bottles of alkohol (UC:Use item with orc) and they fall asleep. As fast as possible he walk (UC:Move) away and suddenly stands in front of a castle.
He alerts his mates (UC:Chat with players), who tries to join him as fast as possible.
While MacDuff was treated by the Orc mob, Conan and Paul has met at the waterfall, where Paul the baptist tried to Create religious place (UC:Use item with place) to get Conan healthy again. Then they get the message from MacDuff to join him at the castle.
While Walking there, Paul the baptist discovers a hidden door in a tree with the objective of coming to the castle. Conan Walks there. After a short while he arrives there, and the three Adventurers find the door closed. So Conan use the hammer to open the door (UC:Use item with door), but nothing happens. So they deliberate on that matter using their headsets (UC:Talk with Players through a headset). And overcome, that Paul should try using the spell (UC:Use item with door) he found to open the door. But the door is strong and still resists. But when Conan treats it with his massive hammer (UC:Use item with door), it can't stand that any more. So they can enter the castle. After Walking around for a short while there is another wall made of stone where the hammer from Conan has no effect (UC:Use item with wall). Now MacDuff has an idea to push the stones while Paul the baptist is reading the spell (UC:Use item with spell), he found. Now the wall goes up like a door and the Adventurers can enter the room of the princess and rescue her.
4.2.8. Resume yesterday's game
Instantiated Use Case:
No use case specified.
Initiating Actor Instance:
No actor instance specified.
Flow of events:
The next day, a:Susan bumps into three of her friends (a:John, a:Lyta, a:Michael) on her "U-Bahn" ride to campus and is stranded at the "Frttmaning" stop, due to an arena construction closeby. They decide to pick up the game they dropped the day before. They open up Sword and play until the train arrives on campus.
4.2.9. Talk to John
Instantiated Use Case:
Chat with players
Initiating Actor Instance:
No actor instance specified.
Flow of events:
a:Susan sends a message to a:John: "Where did you enter the game?"

He replies "at the graveyard".

She asks him to meet her at the waterfall.
5. Glossary
Now there exists too versions of REQuest, one shows the game world in detail, and the second one shows the System Design as it is considered by the Object and Dynamic Model.
As basis for the Analysis the second one is used.

 


This page is hosted by the Chair for Applied Software Engineering of the Technische Universität München.
Imprint (Impressum)