Jul 30 2010

KataSpace Application Built on Sirikata

Ewen Cheslack-Postava

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

Here are some distinguishing features of our platform:
  • WebGL/HTML5 client lets you login from modern web browsers with no additional installs or downloads
  • The Sirikata backend server is based on ongoing research into building a better more scalable multiuser platform
  • COLLADA support secures an open import path from just about every 3D tool out there as well as existing repositories
  • All code is available under the liberal BSD license

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.

Jul 30 2010

Application-Level (Addon) Messaging in World of Warcraft

Jeff Terrace

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


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.


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


  • 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 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.


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


GathererGatherer 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.


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


RecountRecount 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.


  • 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.


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.


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