Qwaq in WSJ

We were in the Wall Street Journal - with a picture! Check it out here:

Virtual World Gets Another Life

It includes an image of the new "Business Avatars" which have not been release yet, but look wonderful.

Interoperability

I have been spending a large amount of time talking to people about interoperability in virtual worlds. One problem is defining what it means - and why it is important. From what I can tell, the main thing people are looking for is a way to easily traverse from one virtual world to another. It would be great to be able to jump through a portal from Second Life into Qwaq and back. We already support URLs as links between Qwaq spaces. Adding a Second Life island would be a bit tricky, but I think it could be done.

There is also mention of having one's avatar go along for the ride, but it turns out that this is not that important, and may not even be a good idea. One way to think about it is people already have multiple identities online. I have a work email address, personal email, and a number of random older email addresses that I still get mail from. I don't like mixing them, and I have different expectations for the kind of mail I get from them, and people have different expectations from me depending on whether it is a work or personal email. That doesn't even begin to address the difference in security requirements.

Avatars are context specific artifacts. My avatar in World of Warcraft makes no sense in my business world. An obfuscated name model like Second Life makes no sense in business either - good business practice is built upon a strong trust relationship. If I don't even know who you are I can't do business with you.

On the other hand, if you like how your avatar looks in world A, it would be nice to have a similar version in world B. I like having the same name for my email addresses at gmail and at Qwaq, even if my role in each is different.

Hydra!

Andreas Raab wrote:

In its ongoing commitment to Open Source, Qwaq has decided to release
the first multi-core capable Croquet VM under the MIT license.

Hydra VM is a virtual machine capable of running multiple Croquet images
side-by-side, therefore being able to effectively utilize multi-core
CPUs. Hydra VM is still in an early phase of development, but given the
(very successful) early results, Qwaq has decided to make it available
to general public in the hope that other people will help Igor to make
further progress in developing Hydra VM.

The offical release is available here:

http://www.qwaq.com/HydraVM


and contains the following files:

* HydraVM-bin.zip - A prebuilt Windows version of Hydra VM.
* HydraVM-src.zip - The (C) source tree for building Hydra VM.
* HydraVM-pkg.zip - The (Squeak) packages needed to build Hydra VM.

Croquet Priorities

Mark McCahill and I have been discussing the top priorities for Croquet moving forward. Here is the list of the top six things that we will be doing for 2008. The main theme is interoperability. This is interoperability at many levels. First, ensuring Qwaq Forums and Open Croquet worlds are interoperable. Looking beyond that is allowing Croquet worlds and avatars to interoperate with other platforms. This will be a large effort, but many of the technical hurdles have already been jumped.


- XML space description: a common space description file format in XML to allow the open source and QWAQ clients to read stored copies of each other's worlds.

Minimizing the size of objects being replicated is important so that spaces may be saved compactly and new user joining the replicated space can do so quickly.

In practice this means meshes and textures should be referred to by name in the replicated space, and fetched by each client
independently of joining the space. By fetching these large objects independently of the replicated space, clients can maintain locally cached copies which speeds joining the space. An XML description of the space also simplifies programatically generating space descriptions, and aids in integration with various search engine technologies.

Moreover, an XML-based space description also allows for the possibility of a croquet browser written in another language or based on a different code base. However, this implies changes to the rendering engine since we would be moving textures/mesh definitions outside the replicated space. QWAQ's forums have shown that this approach has many virtues. Ultimately we might want to use an extended version of Collada - but the first step would be to align the Open source and QWAQ code bases so we can read each other's world definitions.


- robust Jabber client: SSL TLS support ( OpenSSL plugin?)

This work can happen in the open source arena and is relatively independent of changes to space description formats. The current Jabber client does not support SSL transport level security and needs to - since most Jabber servers require SSL TLS. Supporting an open standard IM/Chat is a key for interoperability with the chat world, and ideally would allow cross world chat with other environments (such as Second Life) should those worlds decide to do the right thing and support a standards based chat protocol for inter world chatting. We also need this work so that we can advertise presence outside Croquet using an open standards-base approach.


- message router/timestamper: optional message router/timestamper as an Apache plugin?

The microserver is a message router/timestamper for sites that want a standalone message router to augment the croquet client built-in router. We can leverage the support that the apache server codebase has by providing an option to externalize the message router function.

This also opens the possibility of simplifying access control/authentication integration with existing enterprise AuthN/AuthZ
systems. By creating a microserver that plays in the apache space we can leverage existing Apache web server authentication/access control modules.


- plugin API for extending space definitions: various browsers will extend functionality of spaces by adding new features, we need a definition for how this happens

We expect that various browsers will extend functionality of spaces by adding new features. We need a standard way to describe these plugins that allows less well endowed clients to at least display a placeholder for content they cannot render and point to how to get the required extension. This is analogous to plugins for web pages.

Note that these plugins may affect both the replicated space -and- the non-replicated inside-the-helmet user interface of a croquet client.


- scripting for user-defined behaviors: Javascript, Lua, panels, roll-your-own, and all that jazz

If we have a common XML format for describing spaces we have half of what we need. The other half is a common way of describing user-created behaviors, so a scripting language - like lua or javascript - would allow for actions to be stored along with models and textures. This implies that browsers will all need to support the scripting language.


- avatar definitions: enabling Akbar 'n Jef's Avatar Hut

Users of social spaces care a lot about their representation in-world
- we need to converge on avatar standards so that each implementation of croquet is not re-inventing this particular wheel. That, and a good babyfur avatar should be a lifetime investment.

More Scripting

I am sure everyone has their own opinion about scripting inside of Croquet. Here are mine:

- The scripting we use should be a popular language. Javascript is the obvious choice. Lua gets high marks for coolness, but most people have never even heard of it. It would be great to include any language, but getting the first one to work is a big enough project.
- It needs to work INSIDE of the Island. That is, it should offer the exact same guarantees of determinism that Croquet Islands provide.
- It must utilize the same numerics package that we have added to Squeak/Croquet. (Otherwise the previous will fail.)
- It must be enhanced to support #future messages directly. You MUST NOT loop to simulate in Croquet. Bad bad bad.
- The interface for editing the scripting language must be INSIDE of the Island. In other words - extreme programming on steroids! Scripting is a form of communication. When we came up with the idea for Croquet the intent was not to have a virtual mall and hang out. It is intended to be a high bandwidth communication medium. This includes the ability to dynamically express a simulation as part of the conversation! Hence the expression itself is a part of the communication. The editing is part of the argument between the participants.

This is probably more important to me than others, but until this is available, it ain't Croquet.

Qwaq + Intel = Collaborative Mirimar

Qwaq and Intel just announced that we will be collaborating to bring Mirimar technologies that were developed at Intel to market. This is exciting for a number of reasons. Mirimar is a beautiful and seamless interface with the users desktop, which will make Qwaq Forums even more of a compelling experience. And of course we get the opportunity to work directly with Intel and in particular with John David Miller, one of the principals behind Mirimar to develop and integrate this technology. JDM is definitely one of us - and we have had a lot of fun working with and learning from him over the last year. It will be fun to roll this product out the door.

Press release here:
Intel-Qwaq Press Release

Official video of Justin Rattner's keynote including a guest appearance by Greg Nuyens. This seems to require IE and a PC:
Intel Developer Forum Webcasts

This is just the video part - no slides, but seems to work everywhere:
Intel Developer Forum Video

Scripting

I have been spending a great deal of my time lately thinking about scripting issues. Most people are a bit wary of diving into Smalltalk to get things done. Of course, it is really a marvelous scripting language in many ways, but people tend to find it a bit difficult. I think the reason for this is the same reason Lisp is a bit difficult. Both Smalltalk and Lisp have extremely regular syntax structure. In Smalltalk, even the traditional control structures (if/then, while, for) are just normal object messages that look the same as any other object messages. Most other languages have "exceptional" syntax, in that they have a number of reserved key words, and often have specific non-regular syntax to support these "exceptions". This makes it easier to visually parse, as most developers also tend to format their code around this non-regular syntax. This is especially useful to new programmers, because they can use this as a way to understand the code they are looking at.

Smalltalk and Lisp programmer usually format their code in a way to hilight the flow of control as well, but since every line of code starts with an actual object followed by a message, even this is still harder to immediately recognize.

Scratch is beautiful visual scripting language developed by the Lifelong Kindergarten group at MIT where they have moved very strongly in the direction of hilighting these very same control structures by using multiple shaped and colored tiles. What is nice about this is it makes it very easy to understand the structure of a program at a glance, and the program itself is simply "assembled" like you might put Lego blocks together. Interestingly, Scratch is built on top of Squeak - a version of Smalltalk.

We have been looking at a number of scripting languages over the past year, and have even integrated Python directly into Qwaq Forums. We are also looking very closely at Javascript and Lua. In particular, I love Lua, as it really gives me a lot of the capabilities I miss in Smalltalk - functions are first class objects and it has full closure support. This allows for some very interesting capabilities in code. I have been saying that I was thinking about building Wicket in Python in the past, but I believe Lua would be a much better choice.