Support Infrastructure

Last month was the month of the item server. This month I am working on the support infrastructure.

The client is supposed to paint avatars and objects on Web pages. To do this, it needs a fair amount of support.

The client needs:
  • a user account on the server. The user account will be created when the client starts for the first time.
  • an XMPP account to connect to the XMPP server. The XMPP account is created automatically so, that users do not have to care,
  • avatar images and a way to select avatars,
  • an item inventory contains all the stuff you find, trade, or make,
  • an identity service which provides avatars and items to the client.
  • all this data wants to be stored persistently in several databases. 

These are the services I am currently building.

The goal is to make using the Open Virtual World client very easy. Just install and go.

Hello Item Server

About a month after the architecture definition, the first draft version of an item server is ready. It shows objects as bots in chat rooms.

Key features:
  • distributed architecture
  • transactions
  • item management
  • item bots
  • room-inventory management
  • separate database backend as webservice
  • identity updates
  • identity storage as webservice
  • admin GUI
I will now turn back to the client to add displaying of objects and interaction with objects.

[Why is there an Asgard Mothership? The item server was called "Odin". The backend project "Mirmir" and the complete framework, which for sure will get more components: "Asgard"]

Object Layer Architecture

Some time ago we started discussing the architecture of virtual objects on Web pages. In this posting I will try to explain some key questions and considerations in building an infrastructure for virtual objects which appear on web pages.

First I will quickly write about our goals:

  • We will put objects on Web pages in addition to avatars. 
  • People will have inventories as known from many other games. 
  • Objects can be installed on Web pages by dragging them from the inventory to the page.
  • People can use objects on Web pages in various ways including crafting.
  • Objects can interact on Web pages.
  • Objects encourage communication.
  • Objects are used for gaming in casual and highly engaged variants.
Here is an impression of many different kinds of objects (in practice you won't discover all of them on the same page):

Issues to take into consideration while discussing the software architecture:

1. One World
There is only one Web. All users can see each other and chat everywhere. All objects should be visible to all users. There should not be separated servers as in many Online RPG (called realm in World of Warcraft and shard in Ultima Online). 
2. It's Big
We expect many users and many objects. The amount of data and processing required is more than fits onto one physical server. Clearly the system must to be distributed. It needs multiple servers. Each server manages a part of all objects. Preferably the architecture is a shared nothing system which organizes itself without a management layer. 
3. Interaction
Objects belong to users. They are in a user's inventory, but at the same time, objects interact with other users and other user's objects on Web pages. A distributed system where objects interact with other objects on remote servers is very difficult. So, we try to make interactions local on a single server. This means, that only objects in the same room can interact. This sounds reasonable.
4. Open World Assumption
The object layer on Web pages should be open to other object systems. This project will create software to put objects on Web pages where avatars already are. Other projects or companies should be able to create their own object system and send their objects into the same chat rooms on the same Web pages. All users should see all objects of all object systems. They might not be able to use all objects, but everyone has the same view to the world. 
5. Chat and Messaging
We are living in a world of chat systems. Avatars on Web pages are created through chat rooms and chat protocols. Objects on Web pages should use the same or similar protocols. Objects should fit into the existing world. 
Architecture design decisions:
  • All objects belong to users. 
  • An object server manages user inventories which in turn contain objects. 
  • A chat room on a Web page is like an inventory.
  • An object is in only one inventory or room at a time.
  • Objects can migrate between inventories.
  • Object servers host complete inventories.
  • Interactions happen only between objects in the same inventory hosted by the same server.
  • If an object is moved from user inventory to a Web page, then it migrates to the object server which hosts the chat room of the page. 
  • Users trade objects via temporary trade rooms .
  • Rooms, inventories, trades are identified by utf-8 strings.
  • Objects are identified by (large) numbers. The numbering is globally unique across all inventories. 
  • Object servers create chat bots to put objects into chat rooms.
  • We are planning for 100 k concurrent users (10 Mio. registered)
  • We are planning for 100 objects per user inventory by average. Stacks of identical objects count as one. An inventory may contain 1 Mio. objects, though this needs hierarchical organisation, aka folders.
Here is an architecture diagram:

Now we can start programming.

OVW Meeting 6

I am happy to announce the 6th Open Virtual World meeting.

  • Current developments
  • Roadmap
  • Items on web pages
  • Item server architecture
  • Item protocol
  • Q&A
Date: Monday, October 3rd, 2011, 18:00 h GMT+2

Come join us. The meeting is open to everyone, devs, users, supporters...


Web Avatar Ready for Developers

Just in time for GDC Europe 2011: the Open Virtual World client is now "Ready for Developers" who want to build their apps on the Web Avatar platform.

The Open Virtual World client is
  • a Web Avatar platform.
  • a Concurrent Casual Gaming platform
  • a platform where you can build your casual game
The Open Virtual World client has
  • an avatar on every web page
  • a WebKit based rendering engine
  • modules and APIs
  • everything a client app needs: protocols, logging, configuration
  • open source
"Ready for Developers" means:
  • it is working
  • it can be used by developers
  • it is not ready for end users
  • it needs customization and packaging
  • it needs gaming extensions and a game server if you want your users to do gaming
  • it needs an item shop and inventory if you want to sell virtual goods
  • it needs integration with your user profiles if you want to make the Web Avatar as a feature for existing games
  • it is not a product yet
  • but: it is a working platform for you to make a product
  • and: it is free and open source
The Open Virtual World project will soon publish a complete client which users can download. Until then, developers get early access to the platform.

Need help? mail to

Three Musketeers

Chrome support arrived.

We now have extensions for all 3 major browsers: Chrome, Firefox, Internet Explorer. See the image where I am on this blog page with my avatar and 3 different browsers at the same time.

If my avatar moves in one browser, then it moves in all browsers. If I chat in one browser, I chat in all at the same time. The client logs in to the chat room only once. But the avatar is shown on all browsers.

This is very different from weblin where you could only be on a page with on browser. Other browsers of the same page/domain had no avatars at all.

Initially I wanted to defer Chrome support until after the release. But it is much better to have Chrome support, because I Chrome is my main browser. The client needs lots of day to day testing. Now it is being tested all the time while I am doing my normal web browsing.

By the way: a weblin just private chatted to me, but there is no private chat yet. I just saw it in the logfile, but I could not reply. Do we need private chat early?

Roadmap Update

The core software of the client is ready to be released. I am already using the client day to day. I wish there were a Google Chrome extension. But it has only Firefox and IE currently. So I am using more Firefox than usual.

The biggest remaining problem: although the software is ready, it needs configuration. If you have a web server which hosts an avatar description and if you have an XMPP account and if you are prepared to add both to the config file like I did for my tests, then the software works for you. This is probably not the case for most of you. Therefore, I have to add a bit of auto-configuration before I can release the software (is this correct?). I can release now, but would you want it with so much work on your side? Tell me what you think.

Anyway, I updated the roadmap and I will keep it up to date from now. Here is the task list:

IE Plugin, Installer, Setup, VS10, Support Software

Just a short notice what's currently happening: I am working on
  • some issues with the IE support. Stability is very good, but avatars were "behind" the browser window
  • installer for the IE extension
  • simple setup process which starts after downloading/installing, where you can select install browser extensions, select a nickname/avatar.
  • I upgraded to MS Visual Studio 2010. There are some migration issues to be solved. But I feel, that it is better to migrate now than during the beta phase.
  • There is now a separate code repository for the WebKit SDK. It has 1.5 GB headers, libraries and DLLs, which are needed to build and run the WebView module. Surprisingly the result is not larger than 10 MB.
Still next on the list:
  • Finishing Setup and browser extension installers
  • Simple Web site
  • Installer packaging and final testing

Asynchronous and Messaging

Our extensive unit test suite discovered, that
  • if two WebKit instances are loaded simultaneously, which use the same JS file from the local disk, then initializing one of the JS engines sometimes fails.
The average WebKit programmer will never experience this. The average WebKit programmer uses WebKit to make a web browser. And web browsers do not create many instances simultaneously. You press CTRL-T to open a new tab. Then another. Not two at the same time. Especially not from the local file system. Maybe that's the reason why nobody discovered the "feature" before.

Anyway, this means, that creation of WebKits must be serialized. This in turn, introduces all kinds of asynchronous behavior, which must be handled properly in many places. Asynchronous programming is always more challenging than spaghetti coding. Fortunately the client is message based. The image shows events which wait for other things to complete, before they are forwarded. In other words: the display must be loaded before it can show something. As simple as that.

This kept me busy several evenings and made a huge commit. Now I can continue with the setup/install process.

Internet Explorer Plugin, Autostart and System Tray

Three of the remaining six tasks are done:
  • IE Support: I implemented an IE browser helper which connects to the client and tells about opening and closing of tabs, about URL navigation and tab switches.
  • System Tray Icon: a small fun project. Since the client has no window, we need something else to control it. I created a small system tray icon which can start and stop the client.
  • Autostart: this was the easiest task. Just a registry setting, configured by the system tray icon menu.
Now remaining:
  • Settings dialog (do we really need this, we could start with config files and add a settings dialog later)
  • Simple Web site
  • Installer packaging and final testing
Next is the Web site. We need some place to download the installer and a simple way to configure the avatar, e.g. change animations and nickname.

Finally, we have to bundle all files and create an installer for Firefox and IE extensions. Not a simple task, especially the IE installer. And finally, finally there is much testing required because we want the installer to do it's job smoothly.

Translations and Release Packaging

In the last blog post I mentioned a list of remaining tasks:
  • Translations
  • Release packaging
  • Installer testing
  • Auto start
  • Tray icon
  • Settings dialog
  • Browser compatibility
  • Web portal
I just ticked off 2 tasks: Translations and Release packaging. This is the remaining list in the most likely work order:
  • IE Support
  • Auto start
  • Tray icon
  • Settings dialog
  • Simple Web site
  • Installer testing
Most of these tasks are of medium size. We might defer Google Chrome support until after the first beta release. Maybe someone from the community wants to take this task. We hope to complete these tasks until August 2011.

There are more tasks which should and will be done after the beta release:
  • Google Chrome support
  • Personal inventory of virtual items
  • Virtual Items on Web pages
  • Real Web portal with item shop and (avatar) trading
  • Facebook, Twitter, OpenID authentication
  • More social interactions (wuscheln and more)
  • Porting to MacOS
Some of these tasks are big chunks of work. But most will be done until the end of this year.

Chat Window

This is the brand new chat window.

It is a normal chat window as you would expect. But there are few facts worth mentioning:

It is a module. Actually, it is a display module. This means, that while you are in the chat, you will stay in the room, even if the browser is closed. This is a feature which many weblin power
users wanted.

It is HTML based. See the bold user names: a single line CSS style. See the resize bars between chat-out panel, chat-in panel, and participants panel: just a few lines of HTML with the help of jQuery UI Layout.

Do you remember a blog post one year ago about "Starting Avatar Display Development"? This was after the client core and protocol was implemented, but before you could see avatars.

Now the chat is implemented and I can paint a new picture with a blue box around the finished chat module (there is also a grey cross over the IRC protocol. We do not need it now. IRC is just a future option).

All this means, that the client is basically complete.

There are only small things missing, like:
  • Translations: there is a translation module, but not all visible texts are translated,
  • Installer: there is an installer, but the client must be packaged and tested before release,
  • Auto start with windows: currently you have to start as any other program by double clicking the icon,
  • Tray icon: would be nice
... and some bigger parts:
  • Settings and configuration dialog: there are config files and a config database, but no dialog yet,
  • Browser compatibility: currently only Firefox works, but we want IE and Chrome as well,
  • Web portal: a portal like would be nice where you can change avatar images.
There is still much to do. It is not configured for normal users. It is for people who know what they are doing. It has still less features than weblin. It is an alpha version. But it's cool and it's on the way.

Tabs and Windows

I am working on support for multiple browser tabs. Good old weblin had only one room per browser window. If you changed the tab, then you changed the room. If you switched between tabs very often, then you switched between rooms all the time.

For the OVW client we will support multiple tabs in the same browser window. Each tab will join a chat room. If you change the tab, then you stay in the room. The client will always show the avatars of the visible tab. If the tab is changed, then the next set of avatars will be shown and avatars of the hidden tab will be made invisible.

With weblin there was only one avatar display for each room. If you opened the same page twice in two different browser windows, then you saw avatars only on one of them. The other browser had no avatars. This was sometimes confusing. Now, there will be avatars on all browser windows, even if they show the same page. You can chat in one browser and see the chat also in the other window. You move your avatar in one browser and it magically also moves in the other browser. This is made possible by a real MVC implementation. The avatars will be duplicated. They are just a view of the scene model.

We currently have a Firefox plugin. But of course, we also need IE and Chrome. These plugins are much more complex, than the simple windows message hook of weblin. In other words: they are more work. But they will provide much richer features in the future and ... tabs.

Avatar Display

Do you see the difference?

On the left is the new OVW client. On the right is a Weblin display. The OVW client still lacks the points below the nickname. But it has a green glow around the nickname instead. Otherwise, they look almost identical. That's the point.

There is now an avatar display in the new OVW client. It is programmed in HTML and JavaScript with support from the C++ core.

There are still features missing. For example, avatars do not walk yet, they slide. But there has been significant progress. Because of the HTML/JavaScript environment, we can use jQuery for effects and event handlers. This makes programming very quick - and fun.

Just as an example, here is how the nickname is changed. It is a piece of JavaScript code:
SetAvatarNickname: function (hParticipant, sNickname)
$('#' + hParticipant + ' .cNickname').html(EscapeHTML(sNickname));
Pure JavaScript with jQuery. Very simple.

Windows and Dialogs

Based on Brent's WebKit transparency feature I created 2 modules:
  1. a WebView module, which manages transparent browsers of any kind
  2. a Dialog module, which shows a dialog frame and the real content inside
1. WebView Module

The WebView module is used for all user interface elements. For a settings dialogs, for a chat window, for avatars on Web pages, for toast windows. Everythng you can see on the screen.

The display of WebView windows is completely created by HTML. Dialogs are designed with HTML, images, CSS, Javascript. The main reason for using WebKit as a user interface engine is portability. Modules and dialogs created with HTML will run on all platforms.

WebKit makes the user interface platform independent. Besides, it is really fun to program the user interface in HTML/Javascript.

2. Dialog Module

The Dialog module configures window border and window controls. The outside is identical for all dialogs. The window content is managed by whatever HTML page is put inside, be it a local page from the file system or a remote Web page.

Examples: an inventory window and the current test dialog.

The window can be styled with CSS. We have themes. I present the beloved - and sometimes passionately hated - wood theme:
Do you prefer the Mac theme?

Remember: it's all HTML. You can tell, that it is HTML from the small (reload) button on the window border. This button is for testing only. It will disappear later.

Next is the avatar display.

Transparent Browser Bounty Awarded

Brent's changes to the WebKit code have been added to the trunk (

WebKit can now be used as a transparent browser. Brent also made a sample for how to do Javascript calls between the browser engine and C++.

We now have an HTML renderer at our disposal to create a UI with web technologies. Expect UI development soon.

The Open Virtual World project awards the bounty to Brent for step 1 and step 2. We agreed to redefine steps 3 and 4 for more advanced features later. We thank Brent for his contribution to the project. This was really fun.

(We also thank Lupus Labs for sponsoring the OVW project, which made sponsoring of a WebKit feature possible.)

OVW Transparent Browser Bounty About to be Claimed

Brent Fulgham is currently working on the transparency feature for WebKit. Brent is the developer of the WebKit-Cairo port. It looks like the bounty will be claimed soon. Here are first impressions of the test.

What does this mean for the project? We will soon be able to start working on the GUI. The GUI is the last missing part of the new OVW avatar client. Thanks to Brent, the GUI will be purely HTML based. That's the future folks: Web technologies, CSS, HTML, SVG, Canvas, WebGL.

Later we might also incorporate the multi-process rendering and WebGL developments of WebKit. This means, that rendering will be even faster in the future and we can support real 3D avatars.

Also, thanks to Lupus Labs for sponsoring this open source bounty.

OVW Transparent Browser Bounty

The OVW project needs a transparent browser as GUI platform. Transparent browser means, that if I set CSS transparency of the HTML-body to 0.5, then I want to see the desktop partially. All graphics and dialogs of the OVW client will be displayed by this browser. There will be no other native windows or GUI components. There are so many other things to do in the OVW project. We would like to outsource this task to people who have browser library know how. We would like to sponsor your open source work, and work on other OVW parts in the meantime.

The transparent browser will be used by a OVW client plugin module. We will wrap the OVW specific module around the transparent browser library. What we need is a transparent browser DLL, which our GUI module DLL can use. To be able to integrate the transparent browser into our project, we need a MS VisualStudio project which compiles all required components, links them into one or more DLLs and has a driver program which teaches us how to use the transparent browser. We would like to add features later, hence the need for a compileable project, not just a release DLL. Yes, we know that we can build WebKit from SVN, but it's not simple and there is so much else to do.

Key properties of the project:
  • transparent browser, no default window background
  • in other words: window alpha channel controlled by CSS only
  • only libraries which can be distributed with a BSD like license
  • Cairo or Skia does not matter, but not CoreGraphics
  • Synchronous calls into and out of the browser's Javascript
  • normal performance, meaning no bad hacks, which make transparency, but harm performance
  • Keyboard input and mouse move, click, scroll
  • IFRAME-Support
  • max. 20 MB for everything needed before compression
  • better no app installation required, no registry prep, just plain DLLs
  • preferably as MS Visual Studio 2005 Project, 2008 possible
  • Release + Debug builds
  • Unicode and CJK-script support, right-to-left script is nice to have
  • BSD license
Chromium comes to mind as a base technology because this is where the buzz currently is. There are also Chromium derivatives like Awesomium and Berkelium which could be a starting point. Pure WebKit is also an option. We might migrate to speedy Javascript, out-of-process rendering, and WebGL later. Gecko is also possible.

The bounty is max. 4.000 € in 4 steps:
  • 1 k € for a DLL which paints a web page on a transparent window incl. a sample driver program (which has a URL input). We can compile it.
  • 1 k € for keyboard/mouse input, IFRAME support, and max 20 MB.
  • 1 k € for synchronous calls with arguments between the driver program and the Javascript engine. Int and String type arguments should be enough, Dictionary arguments would be cool. BeforeNavigate, DocumentComplete notifications similar to the MSIE component.
  • 1 k € for additional cool stuff to be defined later, e.g. MSVC 2005 because it lets us omit recent C runtime libs making the package smaller, helping us actively to use the thing, shrinking to 10 MB including all support DLLs (beware of the ICU data DLL), WebGL support, DOM API support, helping us to channel HTTP over the OVW client's HTTP component, etc.
More about the Open Virtual World project: