Difference between revisions of "Project Motivation"

From Second Life Wiki
Jump to: navigation, search
(We're not going to refer to competition as "wolves at the gate"...ugh. There's no point in putting an unadorned link to a consumer-facing website in an architecture discussion)
(Additional scaling factors)
Line 25: Line 25:
 
:* Scripting load will grow roughly in proportion to prim numbers, as well as proportional to population through attachments.
 
:* Scripting load will grow roughly in proportion to prim numbers, as well as proportional to population through attachments.
  
 +
There also are numbers that are ''not'' expected to grow but still may have a significant impact on technical decisions regarding architecture, so they may be used to "anchor" anticipations and as a base for designing the rest of the architecture. These are the expected end-user capacities:
 +
:* The maximum number of concurrent interactions with other people per player is not expected to increase. There is only so many people we can consider and be attentive to simultaneously, that making more people visible or heard makes no useful difference or even degrades experience.
 +
:* The maximum chatting output per player isn't growing anytime soon either.
 +
:* The maximum number of concurrent world interactions is pretty fixed: there is only so many prims we can modify, scripts we can interact with, objects we can manipulate simultaneously ; and we can only manage to maneuver so fast, that flying, driving and taking sharp turns faster is impractical.
 +
:* The update frequency required to simulate smooth movement or make a curved, arbitrary trajectory not appear disjointed or jerky is not going to increase over a few dozen Hz, and there is only so many moving objects we can be attentive to and in whose movement we can detect discrepancies.
  
 
[[Category:Architecture Working Group]]
 
[[Category:Architecture Working Group]]

Revision as of 03:04, 12 October 2007

According to Zero Linden, the project was motivated by thoughts a year ago when Second Life was growing rapidly and Linden Lab was thinking about how to scale the grid.

There have been two timeframes set back then: The next few months and the next years. This architecture discussion is about the next years.

Scary numbers

If we assume that virtual worlds will be a significant part of the future, then the following numbers might not be so far off:


Scalability of world extent:

  • 60 million regions (probably more) (60 was mentioned here by Zero Linden )

Scalability of world population:

  • 2 billion users

Scalability of concurrent users:

  • 50 - 100 million concurrency (on whatever device)

Scalability for events (concurrent users in a single region):


These numbers will not be possible with the grid right now and additionally some more use cases need to be solved like connecting 3rd party hosted regions to the grid.

Additional scaling factors

The above scary numbers stem from population pressure alone, but there are other areas of growth which compound the impact of those numbers still further:

  • Prim count expectations grow naturally. Limiting them to current values is not tenable.
  • Scripting load will grow roughly in proportion to prim numbers, as well as proportional to population through attachments.

There also are numbers that are not expected to grow but still may have a significant impact on technical decisions regarding architecture, so they may be used to "anchor" anticipations and as a base for designing the rest of the architecture. These are the expected end-user capacities:

  • The maximum number of concurrent interactions with other people per player is not expected to increase. There is only so many people we can consider and be attentive to simultaneously, that making more people visible or heard makes no useful difference or even degrades experience.
  • The maximum chatting output per player isn't growing anytime soon either.
  • The maximum number of concurrent world interactions is pretty fixed: there is only so many prims we can modify, scripts we can interact with, objects we can manipulate simultaneously ; and we can only manage to maneuver so fast, that flying, driving and taking sharp turns faster is impractical.
  • The update frequency required to simulate smooth movement or make a curved, arbitrary trajectory not appear disjointed or jerky is not going to increase over a few dozen Hz, and there is only so many moving objects we can be attentive to and in whose movement we can detect discrepancies.