Sirikata

With 0.0.25 just released, we’ve also started building installers for Windows and Mac to make it easier to get started with Sirikata. They contain the same binaries as the plain archives, but they have a few other nice features.

1. Setup slauncher to launch links for Sirikata automatically. Then you can click on a Sirikata link to automatically launch a client, for example one of our demo worlds.
2. Make sure some dependencies that you otherwise need to install manually on Windows are available.
3. An updater and uninstaller are included. The updater doesn’t currently run automatically, but it let’s you easily check for and install newer versions of Sirikata.

They’re provided as options on the download page.  Thanks to BitRock for the free InstallBuilder license that let’s us easily create these installers.

We’ve also moved some of our documentation, specifically the guides, to the wiki. While not as pretty as the ones generated by Sphinx, hopefully this will make it easier to contribute to the guides and keep them up to date. The API documentation for the C++ code base and Emerson are still auto-generated and kept in the same place as before.

Today we’re releasing KataSpace, a simple web-based application built on the Sirikata platform.  Utilizing many new HTML5 features, WebGL, and Sirikata’s server, KataSpace provides a shared space where users can chat and interact with each other, right from their browsers. KataSpace is being developed by Katalabs as the basis for the BE community. They’ve open-sourced the application and the code is now under the Sirikata umbrella.  Here’s what it looks like:

Even better, you can test a live demo at http://kataspace.sirikata.com (be sure to use a WebGL-enabled browser — Firefox 4 Beta 7 works well on all platforms).

High level overview

Anatomy of a Web-based Virtual World

Kataspace is an example of how to build a web-based application on the Sirikata platform.  Here’s the architecture of the application:

A web-based application built on Sirikata is built of three major components:

• Space server— The space server is the “world” itself, managing the shared space and interactions between objects. This is the standard C++ client found in the main Sirikata repository.
• Client— The client runs in the user’s browser and is built on the KataJS object host. KataJS is a library that connects to the space server to give you basic functionality in the world, as well as a WebGL display.
• Web server— A web server hosts the application (a web page and collection of scripts) and the content.

Try It For Yourself

Building a real virtual world application is tough — all the components need to be coded, configured, and connected. To make trying out and extending KataSpace for yourself as easy as possible we’ve provided some scripts which let you easily build and deploy on a bare Ubuntu EC2 image (or really any recent Debian or Ubuntu computer).  Instructions can be found in the README in the KataSpace repository.

One of the features of Sirikata is that its core services are not application-specific, so the space server running the world isn’t modified for each application.  All the code specific to the KataSpace application is HTML, CSS, and JavaScript and runs in the browser.  This means you can easily dig in and make modifications — just edit and hit refresh!

Getting Involved

We’d like the community to get involved in developing all aspects of Sirikata — from systems developers working on the space server, to web developers focusing on building applications, to content creators building content for use in Sirikata based worlds.

Specifically the KataSpace application has the basic chat and display features described above.  It also shows how to build other common features of virtual world applications, such as animated avatars and customized user interface elements. With 1500 lines of code; KataSpace hopefully feels reasonable to dig into.

See the Getting Involved for some pointers on getting started, or get in touch with us directly.

[This is a cross-post from Princeton S* Network Systems (SNS)‘s Dirty Slate Design Blog]

Introduction

I’m currently working on a project called Sirikata, an open, programmable, scalable, secure, and extensible virtual world.

One aspect of this virtual environment is application-level messaging. Users can create objects in our world, and these objects can communicate with each other. To get an idea of what application-level messaging looks like, we wanted to take a look at one of the world’s biggest virtual worlds: World of Warcraft (WoW).

In WoW, users can create an “Addon”: a user-interface modification component that can add enhancements to the game. To communicate, these addons (written in Lua) have access to a function called SendAddonMessage.

WoW SendAddonMessage Function

Sends a message to the hidden addon channel.

SendAddonMessage("prefix", "text", "type", "target")

• prefix: String – Message prefix, can be used as your addon identifier.
• text: String – Text to send.
• type: String – AddOn channel to send to. Valid types are “PARTY”, “RAID”, “GUILD”, “BATTLEGROUND”, “WHISPER”.
• target: String – Used only for “WHISPER” communication – the player to whisper to.

Example:

SendAddonMessage( "CTRA", "User Data: XYZ", "RAID" );

Notes:

• Calling this function results in the event CHAT_MSG_ADDON being invoked on:
  • <target>’s client if <type> is “WHISPER” or
  • all clients in the <type> chat channel, otherwise
• The combined length of message and prefix can be at most 254 characters (255th is the tab character used to delimit the two)
• Length above 254 will disconnect you.

Example Addons

EPGP

EPGP is an Effort/Gear reward system and addon for World of Warcraft.

It is a DKP system, described below:

Dragon kill points or DKP are a semi-formal score-keeping system (loot system) used by guilds in massively multiplayer online games. Players in these games are faced with large scale challenges, or raids, which may only be surmounted through the concerted effort of dozens of players at a time. While many players may be involved in defeating a boss, the boss will reward the group with only a small number of items desired by the players. Faced with this scarcity, some system of fairly distributing the items must be established. Used originally in the massively multiplayer online role-playing game Everquest, dragon kill points are points that are awarded to players for defeating bosses and redeemed for items that those bosses would ‘drop’. At the time most of the bosses faced by the players were dragons, hence the name.

EPGP uses the messaging system to send information between users of the addon about the values of loot. For example, if an item drops for the first time, the “loot master” might assign a value to the item. This value is then shared with other people using the epgp addon.

Properties

• small message size
• very infrequently sent
• must be delivered

Gatherer

Gatherer is an addon for herbalists, miners and treasure hunters in World of Warcraft. It’s main purpose is to track the closest plants, deposits and treasure locations on your minimap.

In WoW, players can gather resources. The resources are spread across the world and spawn in what seems to be a randomized fashion. In fact, though, the spawn locations are actually preset, so this addon tracks the location where users find resources to make it easier to find later.

Gatherer uses the messaging system to share the location of found resources between players. For example, when you find a resource, you can have it automatically share the location with your guild members. This way, if many people in your guild use the addon, you will get a nice compiled database of resource locations.

Properties

• small message size
• medium send frequency
• not important if messages are delayed
• not important if some messages are completely lost

Recount

Recount is a graphical damage meter.

In WoW, players fight bad guys. To do this, they have to deal damage. A metric for evaluating players is to look at the amount of damage they deal per second (DPS).

Every action that players within your party take is logged, which includes actions that result in damage being dealt. However, you only get log information for players that are within a short range of you. Because of this, in some encounters, some players might be too far away from you for their actions to be logged.

To make the meter more accurate, Recount uses the messaging system to aggregate logging data about damage being done.

Properties

• Medium size messages
• Heavy traffic load during encounters (about 10 seconds to 6 minutes)
• Latency effects instantaneous accuracy during an encounter
• Syncing algorithm still works if some messages are lost

Data Collection

To study WoW, I wrote an AddOn called AppMsgLogger. This AddOn collects three pieces of information:

1. A timestamp every time the user logs in or out
2. For every addon message received (the CHAT_MSG_ADDON event), a timestamp, the zone the user is in, the channel it was received on (PARTY, GUILD, RAID, etc), and the length of the message in bytes
3. A list of the AddOns the user is running

I had several players run this AddOn for me and send me the data they collected. As a result, I have data consisting of 49 hours of time played across eight players.

Results

Out of the 173,456 messages received, here is the breakdown of the channel they were sent on:

• Battleground: 262 (0.15%)
• Whisper: 1,240 (0.71%)
• Party: 3,185 (1.84%)
• Guild: 21,439 (12.36%)
• Raid: 147,330 (84.94%)

So, only less than 1% of the traffic is unicast (Whisper) while the majority is broadcast traffic related to combat (Raid) and social organization (Guild).

Next, I wanted to look at the breakdown of message size. Here’s a histogram plotting message size frequency:

You can see in this histogram that the vast majority of messages are small (< 50 bytes), with a small cluster of messages near the maximum size of 254 bytes. This is probably because most addons use a library called AceComm which splits messages longer than 254 bytes into multiple messages.

Next, I wanted to see the distribution of messages across the different addons sending them. I matched each prefix string to its corresponding addon and plotted their message frequency:

Note the log-log scale. What we see here is that a small number of addons send the majority of messages, with a long tail of addons that send a very small number of messages.

Next, I wanted to look at how bursty the message traffic was. To get an idea, I took a single user’s 24-hour play time (over multiple sessions), strung it together, and calculated the average byte rate of each 1-minute interval (click for full size).

What you can see in this graph is that there is considerable variability: some periods show a high rate (up to 14 Kbit/s) while others show a rate of almost zero.

To put these numbers in context, I added a background color that alternates every time the user switched zones. For zones that were longer than 10 minutes, I also added the name of the zone in the center of its colored region. As expected, high-rate periods are seen during raids (Icecrown) while the user was engaged in combat. Low-rate periods are seen when the user was presumably idling in capital cities (Orgrimmar, Dalaran).

The last thing I wanted to see was what percentage of messages were wasteful. Since messages are broadcast to their corresponding channels (GUILD, RAID, etc), users in the channel will receive all messages sent to the channel regardless of whether they have an addon actually listening to a given prefix string. Since I had a mapping of prefixes to the sending addon, I calculated the percentage of messages that were received by each user with a prefix string for an addon that the user wasn’t currently running. The percentages for the users that I collected data from are as follows: 58.9%, 28.2%, 15.9%, 12.6%, 9.5%, 86.1%, 83.9%, 17.0%. Since the sample size is low and variability is high, I’d be hesitant to draw any conclusions from those numbers, but it leads me to believe that a significant amount of traffic that is broadcast is wasteful.

Conclusion

I hope you’ve found this analysis useful. We’ll be using some of this information as we continue to design and implement Sirikata.

A couple of days ago, I managed to upload code that changes our ad-hoc TCPSST protocol to a wire protocol compatible with the recent websocket IETF drafts.  Additionally in the months of September and October, Patrick has been working on ProtoJS, an implementation of google’s protobufs inside javascript, allowing javascript to speak the linga franca of our message serialization format: protocol buffers. What this means is that we’re taking a step towards breaking down the proverbial wall between web apps and heavyweight fat clients and servers that currently dominate the realm of 3D virtual worlds and games.

By allowing javascript-enabled webpages to invoke connections to Sirikata servers,  we suddenly open the floodgates to mashups that display statistics about virtual worlds, chat interaction, 2d clients using the new canvas tags or adobe flash to display objects in the world.

But we can take this one step further: as the WebGL standard is approaching finality and O3D is becoming more mature, there is the possibility to make a webpage that can display and interact with a beautiful 3D Sirikata world with the click of a link. As we build a web-based client on javascript and as Sirikata clients begin to speak to ever more servers, like OpenSim, it is possible to imagine a world wide world: the democratization of virtual worlds to the point where anyone can host a world and anyone can join a world as long as they have a browser in front of them.

This makes me imagine a youtube-like usecase where people are sharing their virtual worlds and enjoying popular worlds together.

(This is Part II of the KataSpace post-mortem. Part I focuses on the visitors and browsers they visited with while this post focuses on technical details.)

Besides collecting useful information about how users access KataSpace and their experience with it, we also got a lot of good technical feedback from our initial deployment of KataSpace.

The Good

Overall, we were very happy with the way the system performed. There were 3 main components to consider: the KataJS-based client including the KataSpace code, the Sirikata space server on the back-end, and the “CDN” which is just the web server. The web server, of course, was not a problem. The space server held up very well. We saw a maximum of about 20 concurrent users and the space server didn’t break a sweat — it rarely even showed up in top. We expected this since the server has previously been tested under simulation with thousands of simulated objects, but a real world test always stresses the system in ways you might not have expected.

Finally, the client code also did quite well — users reported relatively good experience with a bit of performance issues, primarily complaining about jerkiness due to somewhat low frame rates. This was expected for two reasons. First, the code is relatively new and less tested than other parts of the system. In this case, we were pleasantly surprised with how rare functionality (as opposed to performance) issues were. Second, since we focused on functionality before this demo, we were aware of some performance issues. The good news is that since performance hasn’t yet been addressed, we know there’s a lot of room for improvement.

We feel we have validated that rich multiuser 3D experiences can be delivered though leading edge web tech. As we focus more on issues like performance, we hope to be able to even rival native application experiences.

Bugs

By far the most useful aspect of releasing KataSpace and running a public instance were the bug reports. Overall, we had surprisingly few bugs (although quite a few feature requests). KataSpace is built from a number of components, so we break the bugs down between the application and the supporting libraries and services. The short version: most of the bugs found are in the libraries and services, and as they get fixed they’ll improve all Sirikata-based applications, not just KataSpace.

KataSpace

As mentioned above, KataSpace itself had very few bugs. Most of the “bugs” we heard about are actually feature requests — physics and terrain, avatar customization, more complicated navigation controls, and so on. While these are features that Sirikata-based worlds should and can support, KataSpace is also intended as a simple demo and one which could be used as a skeleton for other applications. We won’t focus on getting these features into KataSpace’s master branch, but we are building other applications on the KataSpace base which will have many of these features.

KataJS

Because the KataSpace application code is relatively simple (about 1,500 lines), most of the bugs in KataSpace were actually bugs in KataJS. KataJS is the JavaScript library that handles connecting to and interacting with Sirikata servers as well as handling display, all from within a browser. It is a full, in-browser version of Sirikata’s “object host,” using JavaScript as the object scripting language. These bugs fell into two categories.

First, there were display bugs such as these two. These are potentially bugs in the underlying display library (GLGE, which has made building KataJS significantly easier). Some of these are fixed already, but compatibility with various user configurations and graphics drivers is an ongoing challenge for any application like this — WebGL applications are no different.

The second group of bugs were in the interaction with the Sirikata server. These were issues with location updates, proximity queries, and their interaction. These are mostly bugs which became more apparent with larger volume of users and it became clear that fixing them would significantly improve the user experience. All of these bugs have been fixed and any application built on KataJS will benefit from the fixes.

Sirikata Space Server

The final component is the Sirikata space server, which coordinates all the clients and allows them to interact. The space server held up pretty well as we over the course of those days had 5000 users connect to it. We only caught two new critical bugs which could cause the server to crash. One was easily fixed and the other is relatively rare.

The heavy traffic, especially the high churn of users logging in and out, revealed some memory usage problems. This was the main cause of instability since the space server’s process has its memory usage capped to avoid swapping to disk. Some memory usage issues have already been addressed and the situation has significantly improved — it takes significantly longer and more users to reach the same memory cap. However, there are still some memory issues to be worked on. Having a real deployment to test against is invaluable, and stresses the server in ways we aren’t able to otherwise.

Extending KataSpace

Since KataSpace is open source and intended as a sample application for web-based Sirikata worlds, we were also interested how people would pick up the code and run with it. Soon after the release we had a few people asking about how to build, deploy and extend the code. This helped us work out a few kinks in the script to run on EC2 (or really any Ubuntu installation). If you want to try extending KataSpace or build a new application using KataSpace as a template, the code is available here. Since the layout of the code hasn’t been well document in the repository itself, a thread on the mailing list describes the basic setup and how you go about modifying different parts of the demo.

Overall, we were very happy technically with the first public test of KataSpace — we discovered many bugs, but none of them were show stoppers and at least a few other developers have built and tested their own deployments. And of course, if you’ve discovered any bugs as you’ve worked with KataSpace, please let us know via the KataSpace, KataJS, or Sirikata bug trackers or on a mailing list or in IRC.

(This is Part I of a two part post. This first part will focus on the users and visitors and the second part will focus on some technical details.)

It’s been more than a week since we announced KataSpace and we want to let you know what we learned. We weren’t expecting quite as much attention as we got (thanks Ars!) so we didn’t focus on collecting statistics. However, we were able to collect some interesting information from the web server and space server logs. These stats are collected from the first five days of traffic. The biggest surge of traffic occured over days 2-3, following the Ars article.

Sessions

Over the five days we were looking at we saw:

• About 20,000 visitors
• About 5,100 users actually access the login screen
• About 4,300 logins to the server (3,900 unique)

Because we’re using very new technology for this demo, the majority of users that clicked through didn’t already have a browser that supports all the features required for the demo (e.g. WebGL and WebSockets). About 25% of the visitors did have a supported browser and made it to the login screen. The fact that only 5,100 users accessed login screen content implies that we successfully notified most users that they would be unable to run the demo (thanks to Modernizr‘s excellent feature detection). We were surprised that such a large fraction of visitors did have a supported browser since a recent beta or dev channel build is required. We expect this fraction to increase as browsers turn WebGL on by default with new releases, but this number is already encouraging.

Of those that made it to the login screen, about 85% were successfully logged into KataSpace (logged by the space server and verified by the web server logs for content which is only requested after a successful login). We can’t be sure why the remaining 15% didn’t make it through, but a large fraction may have turned away for non-technical reasons. Some may simply not have attempted the login or got confused by the name field, thinking they had to have an account.

User Distribution

We also broke down the visitors who hit the front page and successfully logged in by browsers:

Not surprisingly, Firefox and Chrome make up the bulk of both graphs. Since we suggested Firefox’s most recent beta version to users with an unsupported browser, it isn’t surprising to see it dominate for users that logged in. Interestingly, a few visitors with user agents that suggested an unsupported browser successfully logged in — at least one iPad and even an IE6 user agent! Presumably at least the IE6 user is overriding their user agent string. This is a great reason to use feature detection rather than browser version sniffing. Hopefully other browsers will start making larger appearances in these graphs soon.

User Experience

We didn’t automatically collect any information on user experience, but through much of the 5 days, at least one person involved in the KataSpace’s development was logged in. Based on the feedback both in KataSpace and via email and comments, the vast majority of users that got logged in seemed to have a successful experience. Basic functionality worked for most people, with the majority of issues having to do with either graphics loading too slowly or incompatibilities on platforms we did less testing on.

By far the majority of “bugs” we heard about were actually feature requests — for instance, we knew that users could walk through mountains and would “sink” into the ground because we weren’t using any physics and we intentionally kept the controls simple, so there was no way to walk or run quickly. We think one of the reasons for these complaints is a misconception about KataSpace: it is intended to demonstrate how a simple browser-based virtual world can be built on the Sirikata platform, not as a single monolithic world that has all the features of worlds like SecondLife or BlueMars.

The other major complaint was about performance, both in terms of CPU and memory use. We haven’t started looking into performance optimization much yet, so this was expected. Performance will be an ongoing concern as we move forward.

All in all, we considered the release a success. We had many positive comments and got a lot of valuable feedback. The next post will discuss some of the technical aspects and bugs, which parts of the code we encountered problems with, and our progress on resolving them.

We have been pretty excited about our embedded browser Berkelium and it was good to see Patrick pull the trigger on it. Within our group there is an emerging sense that this technology is going to mean something and I wanted to start sharing a few thoughts-in-progress on this.

Imagine two circles where one is the web and the other represents virtual worlds/immersive environments/3D spaces (this includes the game space). These circles overlap but only very little at this point. Basically Berkelium is an attempt to push these two circles closer together. Lets put the 2D vs. 3D discussions behind us and explore the synergy that lives in the overlap.

During the course of the work on the Sirikata platform I have become increasingly interested in what happens in the webspace. HTML5 looks exciting in large number of ways as does dramatically faster javascript. Both these are central to driving the emergence of rich internet applications. These used to mainly be converted from the desktop but now a new wave (pun intended) with a web native feel is emerging. These born are born in the cloud and works in real-time.

Whether you look at the underlying technology or the resulting apps there has never been a better time to explore the overlap. With Berkelium in place we have started to build the foundation that lets us leverage advances in the webspace. The ultimate goal is to figure out the ecology that takes collaborative 3D to web-scale.

We think that lots of smart thinking is needed to move this forward. For the same reason we choose to make the open source & cross platform Berkelium available as a standalone library so that other platforms may integrate and contribute to it as well. Think smaller piece of a larger pie.

To be continued (but feel free to join in now)

Over the past three months, we’ve been working on a new BSD-licensed browser engine called Berkelium. Berkelium is a library that provides off-screen browser rendering via Google’s open source Chromium and takes advantage of Chromium’s multi-process rendering engine, allowing us to safely isolate browser instances.  Best of all, it is independent of Sirikata—you can incorporate it into any project to get a simple, easy to use API for off-screen web browsers.  We’ve started using it in Sirikata to allow arbitrary 3d objects to contain browsers, and in the future, objects may be able to run a user interfaces and even entire object scripts within the sandbox of a browser window.

Berkelium should support plugins, but currently that support is limited to Flash (on all platforms). Hopefully many needs will be addressed by new features in HTML5. For those that aren’t, we believe Flash is able to fill the gap. (For the curious with some spare time, it may be possible to use a hooked HDC on Windows, and to use the X11 Composite extension to render plugins to OpenGL on Linux. However, we suspect enabling arbitrary plugins and programs in this way would take a good month of work to get right.)

And, of course, we wouldn’t leave you without a demo of the browser in action in Sirikata:

One of the things I have been really excited about was when I get to write about some of the interesting projects that is propelling the development of our little platform forward. This first one, a mixed reality performance, I am very involved in myself. Just got word from Matteo Bittanti that his piece Mixed Reality Performance: An Evening on Sirikata will be featured in WIRED Italy’s September issue. The article describes our upcoming performance at the MiTo International festival of Music in Milan, Italy, on September 12 and 13 2009.

From Matteo’s blog:

Mixed Reality Performance is an experiment in which physical spaces and Musicians from different continents encounter one another on-line. Promoted by MITO SettembreMusica in collaboration with the Stanford Humanities Lab and the Stanford Center for Computer Research in Music and Acoustics, this production is an experiment in on-line interaction among musicians in different locations. While a pianist plays their music is manipulated by other musicians on-line; from across the ocean other acoustic realities are manipulated and appear projected in 3-D on walls. Spectators are immersed in a recreated world of sound in an installation that marks the birth of the performance spaces on Sirikata, the most recent open source platform on the web.

In the post you can also read a bit about some of the tech that will drive this performance. All the work code and art asset work we do for for this will be made available under open licenses so if you have an interest in collaboration around music performance in Sirikata then please be in touch as we already now start the planning for future projects.