Guides/Architecture

From Sirikata Wiki
Jump to navigation Jump to search

Sirikata Architecture

Introduction

This document describes the basic components of a Sirikata world at the highest (and hopefully non-technical) level. Whether you're developing an application in a Sirikata world or creating and deploying your own world, you'll need to understand these basic components. World developers need to understand these components because they will configure and run them to pull together a virtual world. Application developers need to understand them because they interact with each component.

At the highest level, Sirikata is composed of three parts, the space, the object hosts, and the content distribution network:

Object Host
Simulates object behavior in the world by running scripts. User clients are object hosts that also know how to run a display.
Space
A collection of one or more servers that simulate the world. Mediates interaction between objects, such as physics and communication.
Content Distribution Network
Stores semi-permanent to permanent data and delivers it to the other components. For instance, meshes that are used to display objects are stored on a CDN and client object hosts can download them to view the world.

All of these components are required for a functioning world. Without object hosts, there wouldn't be any scripted behavior and no objects would connect to the world. Without the space, object hosts wouldn't know how to interact and other centralized global services like physics wouldn't be available. Without the content distribution network, there wouldn't be a place to store and retrieve data lets us display the world.

These components can be put together in different ways to create different types of worlds:

Deployment open.png Deployment game.png

These images show two ways to deploy Sirikata. In the first, one company runs the infrastructure for the world (space), but leaves other services up to users and third parties. In the second, to ensure game rules are enforced and a good user experience, the game company runs all servers except for object hosts acting as clients.

The rest of this document gives a little more detail on these components, but tries to remain non-technical. For more technical detail, look at the Platform Development Guide.

Space

The space is what you might think of as the laws of the world: it isn't the objects but the set of rules they must follow and how they interact with each other. In Sirikata this boils down to only a small set of services: the space manages objects locations, physics simulation, lets objects learn about other nearby objects, and enables those objects to communicate with each other. All the rest of the functionality of the world can be built on this very small base.

Spaces may also provide additional services. For example, a world could function perfectly well with sounds handled entirely by exchanges between objects. However, it might be more cost effective to have the space manage sound to efficiently generate sound for each object that wants to listen.

Spaces can be simulated using a single server, but are commonly simulated across a number of space servers, enabling them to handle larger regions, more objects, and more clients.

Object Host

An object host simulates objects, allowing them to specify their behavior in scripts and providing them access to spaces and CDNs. At their core, object hosts are simple: they embed a scripting language for objects and expose ways for the objects to connect to spaces and CDNs and usually provide some easier methods for interacting with other objects.

The earlier examples of deployment suggest how object hosts might be used. In an open world, anybody running an object host can connect to the space. The owner adds their scripted objects, which connect to that space and start interacting with other objects. They might add code while they are in the world to extend the behavior of objects, perhaps teaching it how to interact with a new type of object or provide a new service to other avatars.

In the second example, a company is developing a game. Because they want complete control over how objects behave in the world, they run all the object hosts containing objects in the world (from mountains, to swords, to goblins), except for those with the players.

In both cases, clients are just a special type of object host that knows how to display the world and respond to user input. The object that manages this is the avatar. This means that clients and objects in the world aren't differentiated, both can be and are scripted using the same tools.

A graphical display isn't the only extension an object host can have. Object host can support a variety of plugins: display of the 3D world, input from the user, sound input and output, different scripting languages, access to permanent storage (e.g. disk), and interoperation with other systems (e.g. HTTP access) are just a few examples.

Content Distribution Network

The content distribution network stores and serves long-lived content the world requires to run. The most obvious example is mesh data, which often can't be distributed up-front (for instance, because users add objects with their own meshes to the world).

A "content distribution network" can be as simple as a web server, and in fact that is a common solution. The CDN really only needs to be able to serve requests for files. However, the CDN might be much more complicated, handling a very large number of users, intelligently serving data from servers near the source of requests, doing advanced processing of content (like simplification, conversion to progressive formats for streaming), and caching files to reduce the cost of running the CDN.

The Sirikata Ecosystem

Sirikata isn't a monolithic piece of software. At its most basic, Sirikata is an architecture and set of protocols that allow the components of that architecture to interact. Implementations of these components allow a world developer to collect and tie together all the pieces necessary to run a world.

The above described the high level components of Sirikata and below we list the available implementations. To run a world, you'd select at least one implementation for each component and tie them together. Within implementations there may be a lot of configuration flexibility as well. For example, the C++ implementation has a wide variety of plugins and feature toggles.

Protocol

There is one source for the protocols that allow Sirikata components to interact. The repository is at http://github.com/sirikata/sirikata-protocol and is referenced by all implementations listed here. Note that some components which support distributed deployment (e.g. the C++ space server) have additional, internal protocols. These internal protocols are always maintained within the repository for the specific project. Other implementations are not required or expected to support these internal protocols. Only protocols in the protocol repository should be used or relied on.

Space Server

  • C++ Space Server -- http://github.com/sirikata/sirikata -- Currently the only implementation. Easy setup for running a single server, but also supports large, distributed deployment.

Object Host

  • C++ Object Host -- http://github.com/sirikata/sirikata -- Plugin based scripting.
    • JavaScript - embeds Google's V8 and exposes core C++ object host API to JavaScript.
    • Emerson - A custom, domain specific language for virtual world scripting. Built as an extension on the Javascript plugin.
    • .NET Languages (Mono) - embeds the Mono .NET runtime and exposes core C++ object host API to .NET. Depends only on the runtime and is therefore language agnostic.
  • KataJS -- http://github.com/sirikata/katajs -- Runs in modern web browsers.
    • WebSockets for communicating with space servers.
    • WebGL for 3D graphics.
    • WebWorkers support for parallelism, script isolation.
    • HTML5 for UI and interaction.

Content Distribution

So far, content distribution has been focused around HTTP based solutions.

  • Web Server (e.g. Apache)
    • Trivial implementation that just serves up static files.
    • Good for centrally controlled content, e.g. not incorporating user generated content.
    • Currently only CDN for KataJS since access from the browser requires using stock HTTP requests.
  • Progressive HTTP CDN -- http://github.com/sirikata/sirikata
    • Allows content to be intelligently chunked and progressively loaded.
    • Scripts on top of web server, based on HTTP using additional headers.
Retrieved from "http://www.sirikata.com/wiki/index.php?title=Guides/Architecture&oldid=1280"