This is part 2 of an ongoing series about what works and does not work in 3D Virtual Worlds (3DVWs) in hopes of educating anyone thinking of building their own. In part 1, I discussed the importance of avatars. For part 2, I want to discuss the silly but strangely popular idea that if we could access a 3DVW from a web browser it would be a huge hit, and finally bring 3DVW programs to the masses.
The primary attraction for even attempting to create a 3DVW that runs in a web browser is from looking at all the success the 2D virtual worlds have been getting. Conventional wisdom says that the primary obstacle standing in the way of 3D virtual worlds having the same level of success is that people do not like downloading and installing a separate program just to play.
There is some truth to that, studies have shown that only one out of 10 new visitors to a 3DVW website will bother to download the program. So requiring a download apparently drops your audience 90% right off the bat.
I believe this is only an obstacle initially. People will download a good program that promises to benefit them, especially if it is free and comes from a reputable source.
From what I have seen so far, and from what I have heard is in the pipeline, there is no real point in trying to run a 3D virtual world in a browser, its bad conventional wisdom based on faulty logic.
There may be some good reasons to have 3D displays embedded in a web page, if nothing else its an attention grabbing novelty. But 3D multiplayer worlds with chatting and building capabilities do not fit into the web page model the same way they do with 2D virtual worlds.
The state of the art
A quick note on the state of the art (in case you do not follow my blog): There are a few 3DVWs that can run in a browser already. Among the ones currently available are Exit Reality, Just Leap In, and Vivaty. All three still require either a small download or a browser plug-in to work. I have tried all three and they all feel like novelties rather than full fledged 3DVWs. If the primary goal is to add a 3rd dimension to the 2D Virtual World, none of these come close.
There is a largely unrecognized truth in all this: 3D virtual worlds are not 2D virtual worlds with depth. The two attract different kinds of players. Play style and activities are of a very different nature. 2D is much more social, 3D is a more creative outlet. 2D is “point and click” just like the web. 3D is played like a video game.
Once you accept this truth, it logically follows that a 3D virtual world designed to play in a web browser will never work. Playing inside a web browser is too limiting, too simplistic.
A good example is Google Lively. It was probably the greatest 3D virtual world ever to reside in a web browser. It was a failure, because people found it too limiting. Outside of chatting, the two primary activities in 3DVWs is building stuff in 3D, customizing your environment. Lively provided a simple but inflexible interface for building, and no real ways to customize. Exploring what other people have built was not that interesting due to limited content. Every room was variation of the same 5 or 6 rooms. Lively’s legacy is that it mostly killed the dream of browser based 3D worlds.
A downloadable full fledged client may limit your audience, but it makes your world much more flexible, usable, and customizable.
Alternate approach #1: Put the client in a browser
Since it seems that every browser based 3DVW requires a download anyways, maybe the approach is to embed a mini client in a browser. This is the approach being used by Pelican Crossing and 3di. This allows you to create an embed on a web site that opens the Second Life client inside the browser, the user of the embed is taken to a location specified by the embed.
The primary question that comes to mind is “why?” Linking to Second Life locations is already possible via SLURL. There.com and other 3DVWs have ways of creating links to specific locations as well. A client embed looks cool, but it is limiting the size to a part of a web page (which you can click to full screen) but does not add functionality to the client. Multiple embeds on a page are unworkable unless you have a really good computer.
Now what would be cool is a way to convert Second Life places to VRML and embed them so you can show non SL users your creations. People would not have to have an SL account to see it, nor have a full SL client, just some generic VRML viewer. This is actually possible. There are tools available to convert SL objects to XML files for backup purposes, and these could easily be converted to VRML files. The biggest obstacle to this idea is the lack of wide access for SL to XML converters. This is a very sticky issue (maybe you have heard of the copybot controversy?). Still it is a cool idea.
Bottom line it is easier to add a browser to a client, than a client to a browser.
Alternate approach #2: Accessing 3DVRs via interactive streaming video (Cloud gaming)
Cloud gaming via embedded video is coming very soon. At least two companies OnLive and Gaikai are developing interactive web video technology allowing you to play (nearly) lag free video games remotely through streaming video.
Most online games works like this:
1. your computer or console “renders” your environment from game data stored on your computer.
2. you take action
3. action is sent to gaming server
4. gaming server decides outcome which is sent back to your computer
5. go to step 1.
“Cloud Gaming” works like this:
1. Your computer gets a streaming video feed from an online server.
2. you take action
3. action is sent to gaming server
4. gaming server decides outcome, renders the outcome from game data stored on the server, and converts it to streaming video
5. go to step 1.
That seems like an awful lot of work for the game server to handle, but if they can get it to work, there is no real need for powerful gaming computers to use the service. Theoretically, I could play Crysis in high definition detail on my ipod. There would be no need to get the latest hardware, or constantly updating your console.
Sounds pretty good, but unfortunately it could not work with Second Life as it is currently designed, because there is no way the service could handle all the custom textures. Handling the bandwidth of the streaming video is one thing, handling the bandwidth with the Second Life Servers as well would be a networking mess.
Just because SL will not work in a cloud computing environment does not mean another 3DVW could not. If models and texture data were hosted on the same physical network as the rendering, it would eliminate the extra bandwidth. The 3DVW would have to work via submissions like There.com does, rather than instant feedback like SL. Building could be done with offline tools, then submitted. Since the whole technology of “Cloud Gaming” is in its infancy, I do not expect to see a 3DVW built with it for at least another 5 years.
Sounds difficult, but that may be the only way to get a usable 3DVW to play in a web browser.
Really, I don’t see the point.