AWG Use Cases

This page will hold all sorts of use cases and should be some brainstorming place. Please add use cases in the form "<Role> <Action>" like "User logs in". If it's a requirement such as "The system needs to support OpenID" write it like that. For now we should aim at one-line descriptions for an overview. For more detailed explanations make the use case a link and explain it there.

Use Cases of the existing system should be marked with an (*) for now. Areas of potential discussion are marked with (??)

Use Case Capturing

We use the defined AWG Glossary. Please use 'user' to only mean a person operating an agent (even if that user is doing so through a bot). If you are talking about something like a web service client querying for data, please use the term 'client'. For more complete use cases, link usecase category to a separate page and use the template here.

Strategic Scope

• Allow private grids with varying levels of autonomy
• Allow very small scale operation of regions, such as home users
• Retain as many useful permissions of those currently available as possible
• Provide for availability of continuous and portable identity across all domains
• Evolve the micropayment economy as gracefully as possible without denying progress
• Create a system that will scale to the numbers expressed in Project_Motivation

System Scope

The use cases below are system scope

Identity related Use Cases

• User creates a new identity (*)
• User updated identity (*)
• User deletes identity (*)
• User retrieves identity information (*)
• User adds a verification method to an identity (age, real name, financial, part of a company, ...)
• User finds an existing identity (multiple criteria) (*)

Agent related Use Cases

Administrative Use Cases

• Administrative User finds an existing agent (multiple criteria) (*)
• Administrative User creates a new agent (*)
• Administrative User deletes an agent (*)
• Administrative User edits an agent profile (*)
• Administrative User "governs" an agent (*)
  • Ban
  • Kick
  • CSR Actions

Information Use Cases

• User retrieves profile information about an agent (*)
• User retrieves identity information about an agent (age, RL info, what about permissions here?)
• User retrieves presence (online) information about an agent (*)

Basic Use Cases

• Agent logs in (*)
• Agent logs out (*)
• Agent sends an instant message to a user (*)
• Agent says something on public chat (*)

Inventory Use Cases

• return inventory for an agent
• store inventory for an agent
• Manipulate Inventory
  • Move/Copy items/folders (*)
  • Delete items/folders (*)
  • Rename items/folders (*)
  • Share items/folders
• Agent rez's something in a Region (*)

Region related Use Cases

• User subdivides land within a region (*)
• Administrative User retrieves debugging information from a region
  • Script Activity (*)
  • Physics Activity (*)
  • Agent Activity
  • Statistics (*)
• Administrative User manipulates Access Control List (*)
• Use of unattended security scripts to stop griefer attacks (??)
• Secure vehicle and AV sim crossings (*)

Company/Organization related Use Cases

• Company/Organization provided server
• Region off the Internet (Extra security, prototyping activities, pre-release activities)
• Portable Regions -(i.e. on a lap top which a sales person, 3rd party might take to a client, customer)
• Geometry Import for existing virtual geometry that exits in companies. Ability to import Industrial Design and CAD data into second life (There are huge amounts of data just sitting out there).
• Geometry Import capability needs to support as many CAD formats as possible from different CAD software, and be able to import large assembly (thousands of parts) of CAD models.
• Geometry Import capability needs to let users to assemble the imported CAD parts into an assembly in-world.

Firewall related Use Cases

• and Region inside of Intranet (Region only accessable from within Firewall)
• Avatar outside Intranet but Region inside intranent

Secruity related Use Cases

• Asset Security
• Region Script Secruity
• Prevention of unauthorized Access

Viewer related Use Cases

SecondlifeTube

"SecondlifeTube" (or "SLTube") is a popular umbrella term for all graphic use cases that lack an avatar at the visual point of presence in the viewed region.

All such use cases offer the possibility of massive scalability for events, ie. potentially millions of observers viewing and navigating through the same region. This possibility arises because increasing the number of observers does not increase client-side processing whatsoever, and therefore scalability for events becomes limited by server-side design and performance alone.

• It must be stressed that the above property relies on observers being unable to affect region state in any manner whatsoever that could give rise to extra processing in other observers' clients. Even the tiniest increment would result in total collapse, at such levels of scaling.

Current "SecondlifeTube" use cases include: (add the others here)

• Interactive TV
• Non-Interactive TV

Use cases that reduce the processing load on the client through reduced rendering of avatars do not scale to arbitrary levels in this way, but are nevertheless highly interesting and useful for smaller populations (they have no special name currently).

Uses cases that perform no rendering reduction at all are informally called the normal use case.

Interactive TV

This use case is the SL-specific version of Use_Cases#Guild Wars "Observer Mode" like setup -- Interactive TV, described further down.

• A user logs in and runs the normal 3D graphic viewer. (Lightweight authentication schemes qualify as well.)
• Some regions provide a new permission, ObserverMode_Permitted. The user chooses a landmark for one that does.
• A new operation Teleport_As_Observer(Landmark) atomically activates Observer Mode and teleports agent to Landmark.
• When in Observer Mode, the agent's avatar, HUDs and attachments are not instantiated at the point of presence.
• When in Observer Mode, the agent is listed on an Observers_List for that region.
• When in Observer Mode, the agent is not detectable by any other means (eg. sensing). (very important for scalability)
• When in Observer Mode, all camera controls and navigation work exactly as in normal mode.
• When in Observer Mode, the agent is denied all means of interaction with any object in the region.
• In all other regards, all objects, agents, and everything else in the region are treated normally.
• When in Observer Mode, only terrain and sky are visible beyond the boundaries of the current region, to prevent covert spying.
• A region permitting Observer Mode explicitly places everything on display to the world, by design and on purpose.
• Exiting the region by any means cancels Observer Mode for the user, unless it is to another such region.
• The sum total of these features and properties is that client-side obstacles to arbitrary scalability for events disappear.
• Expected examples of this use case include mass live music events, spectator sports, reality TV, and online education.
• Personal navigation/camera controls distinguishes this method of viewing events from passive video and television.

Non-Interactive TV

• Disabling navigation/camera controls in Interactive TV turns that use case into passive viewing for non-interactive experiences.
• It is worth noting that since all clients receive the same visual information in this use case, stream fanout issues are relatively simple, similar to those in current streaming audio and video services, ie. requiring only stream replication.
• Because this use case requires no per-client object handling for downloads, it has a much-reduced server-side footprint.

Internet Radio leading to Interactive Music Videos

• Internet radio stations already have the audio infrastructure for massive service delivery to clients. As a result, up-scaled 3D virtual world visuals can tie very easily into their existing business model.
• The zero-avatar SecondlifeTube use cases are the most appropriate here, as listeners need have no world presence, and visuals fall mainly into the category of information and fun.
• Normal visuals in this use case would include all the resources currently offered on the radio websites, including webcams, music video screens, playlist information, listener statistics and others. Interacting with such resources when in Observer Mode would have to be done in ways which are not visible by other observers, otherwise the massive scalability would collapse. This still leaves open many solutions though.
• With the support of bands, the visuals could be extended to delivering "3D Interactive Music Videos" at the same time as the music is played, a form of theatrical presentation. The "Interactive" side of this refers only to private client navigation within the performance.
• Note that regions delivering such a service can still be visited by avatars in the normal manner for interactive purposes or for purely social ones (inevitably, dancing to the radio), but with greatly reduced viewer numbers. The relatively few whose avatars are present would of course be viewable by huge numbers of others whose avatars are not present, ie. the two use cases combine.

Limited Capability Clients

Any type of computer or device that can establish a connection to SL could be an LCC.

Because of the relatively low power of the hardware on which they run, many types of LCC are likely to use one of the avatar-free models under the SecondlifeTube heading, and hence benefit from the massive scalability for events that is inherent in this category.

• Handheld - too underpowered and undernetworked to handle SL in it's raw form. Could be cellphone or a PDA or a UMPC.
  • Text Chat
  • Audio (land stream or world)
  • Voice Chat
  • Position control by waypoint or following
  • Limiting factors
    • Power
    • Networking
    • CPU/GPU
    • Interface
      • keypad
      • touchscreen
      • tiny keyboard

• Web browser - JavaScript, Java, Silverlight, Flash
  • Anonymous
    • No customized avatar
    • No inventory
  • Text Chat
  • Audio (land stream or world)
  • Position control by waypoint or following
  • Limiting factors
    • Networking
    • CPU/GPU
    • Interface

• Telephone
  • Voice Chat
  • Limiting factors
    • Voice Only
    • Only a touchpad (or oh god... a rotary)
    • No screen

Extended Capability Clients

At the other end from Limited Capability Cients would be optional enhancements to the client, such as

• Windlight
• Voice

• Voice morphing
• Voice control
• Text to speech

• Weather
• Enhanced user interfaces

A Second-Life aware user interface could accept optional input from other optional enhancements, such as Windlight, and modify/animate the GUI skin according to user controlled input.

Examples might include:

• Windlight/weather-enhanced skins that reflect the theme of the sim (combat/forrest/goth/etc)
• Subtle animations of the GUI based on input/settings from user preferences and/or messages from the skins--lightning flicker for goth sims, explosion flickering for combat sims, rainy day animations to reflect weather conditions, etc

• HUD-client interactions

A HUD could evoke GUI elements in the client and the client would implement mouse tracking and provide feedback to the HUD, to free up sim resources that would otherwise be required to change the position of sliders, content of text input boxes, etc.

Game Clients

This spectrum of clients runs orthogal to the Limited vs Extended axis of classification, because gaming platforms already cover the smallest cellphone to the most hardcore enthusiast's gaming machine. This type of client is distinguished by one or more of the following attributes:

• Focus on strong support for one specific game, or genre of games
• Removal of non-game GUI elements, such as object edit screens and inappropriate menus
• Removal of non-game UI controls, such as inappropriate mouse and keyboard events
• Addition of game or genre-specific GUI elements such as targets and target selection
• Complete replacement of the normal GUI by a game or genre-specific one
• Full mouse and keyboard remapping, with selectable mapsets if multiple games supported
• High levels of responsiveness for all games, because low responsiveness ruins game enjoyment
• Very high levels of responsiveness for games or genres where success is a function of speed
• Offline playability if appropriate to the game or genre.
• Easy setup of player-vs-player pairings, and/or use at LAN parties or on clan servers

Content Development Use Cases

• Development, debugging, instrumenting (??)
• Publishing and authentication(??)
• Logging usage, behavior and errors(??)
• Customer support and product maintenance(??)
• Sales, licensing, royalty mechanisms(??)

Some possible futuristic scenarios

(add here what scenarios are completely different but maybe should still be possible with this new architecture. This is mainly to get our thinking broader. These can also be described by some bullet points and from these we should later on construct use cases).

EVE Online like setup

• regions are solar systems
• avatars do not (yet) exist and agents are represented by space ships (some sort of avatar)
• objects are planets, space stations, asteroids, etc.
• regions are connected by portals
• regions do not have a predefined size
• objects on regions are mostly fixed
• most of the transactions will be from agents to agents (might be bots)

Earth & Beyond like setup

• both space and land regions
• avatars exist on land regions (in E&B it was only stations)
• space and land regions connected by a station portal
• space regions connected by warp portals
• space features simliar to EVE Online setup
• underwater, underground building support
• different physical constants, e.g. gravity, wind pressure, speed of light(??)

Guild Wars "Observer Mode" like setup -- Interactive TV

The Observer Mode (OM) in Guild Wars (currently the second largest MMOG by recent reports on Slashdot) provides an exact Use Case for interactive event observation without avatar visibility. This bypasses entirely nearly all of the client-side issues arising from scalability for events. The following aspects of OM operation in Guild Wars are relevant here:

• User must already be logged in before OM is selected in the UI.
• A (huge) menu of candidate PvP battles and tournaments of various kinds is offered for selection.
• Upon choosing a venue, the user is teleported to it and the viewer mode switches to OM.
• When in OM mode, the camera can be made to follow any participant present in the venue.
• All personal camera controls are still active, so the event can be examined from any perspective.
• No observer in OM can see any other observer in OM --- they are all just invisible observers.
• Vicinity chat is read-only: all event chat can be seen if desired, but observers cannot interfere.
• Recorded events can be replayed for observation, yet each observer's camera experience is different.
• Forcing a delay w.r.to realtime is used to avoid tournament cheating through external assistance/direction.
• Every detail of the event is visible to observers as if they were physically present, including for example every aspect of skills activation for attack and defence, so OM offers supreme battle training. This viewing mode will probably be collosal in education and entertainment.
• This is a form of interactive TV. Easy prediction: Reality TV in which the viewer manipulates the camera will be popular.
• A variant of this: view without being able to move the camera (static observer mode?). This is similar to watching a video on YouTube but with real time created content. Advantage: heavy proxying/caching possible as all observers get the same data. Examples: speeches, live performances where the camera is focussed onto a stage or a single person/event.
• This Guild Wars-based use case has been developed into a proper SL use case now, Interactive TV.

Corporate subgrid setup

In this scenario e.g. corporate entities might want to have their own protected subgrid for only their controlled agents but these agents might still be allowed into a more public grid. This might also need to support:

• a means of defining on which region a particular object from a particular agent is allowed to be rezzed (agent needs to not be allowed by agent provider to rez certain agents on public regions. A region might also want to define objects from which agents are allowed to be rezzed).
• a means of defining who is allowed on which region from the region point of view (e.g. the corporate grid does not allow public agents)
• a means of defining who is allowed on which region from the agent point of view (e.g. the public grid does not allow corporate agents or agents it does not know about)

Google Earth like setup

• There are layers of objects/information on one defined region (=earth)
• A viewer can decide which layers to load/show
• one could think of these layers as layered regions maybe
• Agents do not necessarily be represented in a region (login-less portal into regions)

Login-Less view of Regions

• via some browser plugin, interactive 3d views of regions could be visible from any web browser, embedded in pages like youtube videos
• Residents could use SL as a platform to create 3d content for viewing in other applications independent of the client
• Residents could build mini applications for other popular sites such as facebook or existing CMS systems
• enhancing existing e-learning content by adding interactive 3d views of environments/objects created and hosted inside SL without requiring presence.

Off-line but Synch-able grids

• User would be able to install a local simulator which would be a snapshot of a particular sim. Most likely a privately owned one.
• User would be able to use local simulator off line. For instance on a sales call where no network is available.
• User would then be able to re-connect later and have simulator re-synch with "online" version.

Misc Use Cases

Tree's Use Cases

Persistent Session Data via llHTTPRequest()

• a viewer can store session information received by llHTTPRequest()
• residents could then build applications in world that would rely on persistent session data (cookies) such as open ID.
• posting a Jira from in world
• sending inventory items to an external wiki
• logging in and updating any existing CMS without forcing a rewrite of the CMS authentication logic specifically for LSL.