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 Components and Roles. "User" refers to an so far undefined entity. This might be some web service client querying for data.

Strategic Scope

• Allow private grids with varying levels of autonomy
• Allow very small scale operation of regions, such as home users
• Preserve the current level of DRM that is provided (??)
• Provide for availability of continuous and portable identity across all domains
• Preserve the micropayment economy (??)
• Create a system that will scale to 500 million active users with 500 thousand regions

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 (*)

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 features are relevant:

• 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: watch without being able to move the camera. This is similar wo watching a video on YouTube but with real time created content. Advantage: heavy proxying/caching possible as all observers get the same data.

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.