Professional Documents
Culture Documents
Cale Dunlap
DeVry University
Architecture Comparison 2
Abstract
This paper discusses a comparison of the Second Life architecture and the Multiverse
architecture and why one may prove more scalable than the other.
Architecture Comparison 3
Second Life and Multiverse while at the surface may appear to be roughly the same thing,
they are two entirely different animals when viewed behind the scenes. Second Life is a largely
in-house developed system which scales to incredible masses and runs on a relatively thin client.
Multiverse also scales to large masses but seems to use more existing technology to achieve its
goal. This may prove to seal Multiverse‟s fate as nothing more than a „Second Life clone‟ and
The Art
Second Life uses an art development process based around primitives instead of meshes.
The primary reason was that meshes couldn‟t be compressed enough to gain the speed that the
Second Life developers needed in order to incorporate their largely scalable server architecture
and thin-client design. They instead opted for an approach based on mathematical equations
applied to primitives. This kept the size of the content low which allowed them to pass this
information between simulation hosts (servers) and the clients very rapidly, not requiring a lot of
bandwidth.
Multiverse uses standard formatted artwork but uses tools to export this format to another
format that the Mutliverse renderer can understand. Since Multiverse really seems to be meant to
be a rapid prototyping platform marketed to developers of video games, they‟ve left their
systems very open-ended through extra content and scripting. With specific regard to art, since
Multiverse doesn‟t seem too concerned about scaling each of their customer‟s applications to the
size that Second Life does, they chose to make the client download the artwork before-hand.
After the assets are all created, they go up on the Multiverse network, which provides a
repository for the clients to download all required artwork before entering a world.
Architecture Comparison 4
The Servers
The Second Life servers are centric to a specific area of their world. Second Life runs a
section of their entire world on specific servers in order to divide up the workload. Each grid
location on their map represents a server. These servers share information only with their nearest
four neighbors in order to reduce the complexity of scaling later on—why share information with
more than for servers when you don‟t need to? In a grid pattern, each square is only adjacent to
no more than four other nodes. It is a very efficient way to divide workload and scale the system
so that it will not experience the growing pains that an entire mesh topology may experience
Multiverse doesn‟t use such a process, since their business model is basically a giant
repository for smaller games, one could probably consider each of these games “instances” of an
application that runs inside of the Multiverse “cloud”. Each of these games can decide how it‟s
server architecture will work. It may choose to use instance-based, shard-based, or zone-based
servers depending on the game‟s requirements. Compared to Second Life, this is a much broader
solution that was made in order to accommodate many different types of requirements where
Second Life only had its own set of requirements; Multiverse has to deal with a much broader
The Client
The Second Life client runs on practically any system imaginable—essentially anything
that supports OpenGL. Second Life has a client for Windows, Mac, and PC. This was the driving
force behind their decision to use OpenGL has the graphics renderer.
Multiverse client, while not explicitly specifying which type of operating system they
support (at least in the document that I read), since it uses C# to extend its capabilities I‟m very
Architecture Comparison 5
certain that their client will only run (easily) on Windows machines. While there are ways to get
C# code to run on different operating systems, the common user may not know this option is
available or may not know how to do it. This is definitely a limiting factor in Multivers‟s design.
The Economy
Second Life uses an exchange-rate based economy to manage supply and demand in their
virtual world which ultimately drives their content. If the content is not desired, it will not sell,
and thus will not survive in the game. This is a very clever way to manage the content
appropriation instead of allowing their players to essentially have a giant sandbox with which
Multiverse hasn‟t implemented such an economy. The economy in the Multiverse games is
economy. Multiverse doesn‟t use an economy to manage the content of its games. In a way I feel
this is a good thing for Multiverse‟s business. If they choose not to have a specific type of
economy, they can attract a larger market of developers—even if those developers do not pay to
use their service. If developers choose not to charge their uses to use their virtual world, then
Multiverse in turn does not charge the developers. This means that Multiverse gets free market-
share and the developers get a free place to build their virtual world—in turn allowing users to
play a game for free. On the other hand if Multiverse‟s customers decide to charge for their
game, the model at which they do so is up to them, Multiverse simply provides a fulfillment
Conclusion
While not all topics of MMOG design are covered, four of the most important ones have
been. These are the client, server, art pipeline, and economy. Multiverse‟s system architecture is
Architecture Comparison 6
designed to be more of a fulfillment platform for MMOG developers who are on a budget. This
is sort of converse that of Second Life which is in itself a research laboratory turned MMOG
developer. Second Life had the resources to develop their own MMOG engine while Multiverse
is striving to be a platform (or engine so-to-speak) to other MMOG developers who need one
quickly. This difference in goals produced two different architectures in system design even