AvatarPortability

There are a lot of technical hurdles to make first avatars, and then their inventories, move between worlds. It's certainly an appealing end goal of virtual world interoperability, but I believe there are significant gains to be had in virtual world interoperability way before those problems are solved. For an insight into where we'll be spending the next six months, take a look at the back-end telemetry use case.

If your article is explicitly about moving an avatar between systems, then even there there are sevaral different levels of interoperability. The simplest case might look like this:

1. I have an avatar in System A (say, an OLIVE based corporate virtual world).
2. I want to use that avatar for a social gathering in System B (say, the Pimp My Ride virtual world by MTV).
3. I register at the PMR site. When time comes to specify my avatar and user name, I instead tell the system to "go get my identity from over there," pointing it at my OLIVE based virtual world.
4. The PMR system will fetch avatar data such as clothing, name and appearance from that other system, using an open protocol that's yet to be determined.
5. When I log in to PMR, I get my regular avatar, and others see him as well.

Note: I'm not announcing any particular support for this; I just used two random virutal world names to come up with an example to illustrate how it could work in an early step.

Just to get that example to work, we need at least:

• A way to perform requests of "copying" avatar information around, with some way of handling authentication. This is a Web 2.0 style problem, and solutions might be emerging but there's no "winning" standard yet.
• A way to transfer geometry and textures in a format that makes sense to the destination system. Example standards might include the COLLADA file format.
• A way to represent "remote identity" in the destination world -- someone using that world should see me as "Jon Watte @ OLIVE Corporate World" because that's my "identity" in this case. An existing standard is OpenID; I'm not sure how much modification it would need to fit.
• An approach for how (and whether) to allow write-backs to the identity in the original world, if I change something of the avatar in the destination world. Again, this is a Web 2.0 style problem, and solutions emerging in that space might be re-used.

For that to happen, though, there needs to be economic incentive. People would have to want to pay for that capability, else virtual world providers won't spend time and money implementing something like that. It would be interesting to see the results of a survey trying to figure out whether, and how much, people would be interested in paying for avatar mobility.

Once this level of interoperability exists, future improvements may include:

• A way of transferring avatar behavior (procedural animation like breathing, eye contact, etc)
• A way of transferring emotes/animations.
• A way of transferring inventory; first as "dead items" that just serves as decoration; later as actual objects with physical simulation behavior (that's a very tough nut to crack).

Until that point, you would still be using client program A to access world A, and client program B to access world B. The problem being solved is basically a content translation and authentication/ownership problem.

However, an alternative way of providing interoperability and avatar identity management is to open up systems to share in the same virtual simulation. If I build a world C, I could let users from world A and world B share that world, still using their existing systems A and B. This could be accomplished by interconnecting the simulation servers on the back-end, and having them agree on the basic parameters of the simulation (this is what the link above talks about). Interaction between worlds is then on the semantic level ("I move there; He says 'hello'") and is presented to each world user using that worlds' native conventions. At that point, each virtual world back-end provider is an "avatar service provider," much like an ISP is an "internet service provider" today. Doing interoperability on the semantic level, rather than the mundane content level, would be a big win in my opinion.