Future Technology for VW

[Jose L. Salmeron]

Hi all,

I have seen a lot of technologies used for developing virtual worlds. For instance, Squeak/Smalltalk in Croquet SDK, Java in Project Wonderland, and so on.

Anyway, It is possible that browsers will be more accepted that hard clients for virtual worlds. In fact, I think that the VW future is related with Web3D. Maybe, Ogoglio or something like that could be the best option. Are you agree?

Regards

[Hiperia3D - Jordi R Cardona]

The best option is that will be competence as always, and no one gets a monopoly. That way, us all may choose to what we feel is best, and everybody will improve to compete with the other vw platforms. And you can belong to several different virtual worlds because you like different things from one or another. Don't you think?

[Jose L. Salmeron]

I am agree with you. It is possible to belong to different VW as you can belong to differents associations. Anyway, I think that browser-based VW has more options for wide spreading.

[Hiperia3D - Jordi R Cardona]

Yes, I agree with you. Browser based get similar promotion of the browser, specially if it's Firefox. But many people don't like to install plugins. Others don't like standalone programs...
I think browser plugins and browser-based solution have the disadvantage of tending to be buggy, not as standalone apps. Their advantage is that the browsing from 2d to 3d is continuous.
On the other side, standalone apps can be more feature rich, because the developer doesn't have to fight against the browser bugs (just the ones of our programs LOL)

[Jose L. Salmeron]

We are agree in the big issues. Anyway, standards will play an important role.

[Hiperia3D - Jordi R Cardona]

The open standard for 3D on the web is already out there, and is X3D/VRML, and is the only approved by ISO. http://www.web3d.org/

There is no standard for multiuser 3d environments (virtual worlds) because that can't be an standard by definition, as it is an application of many public standards or proprietary technologies.

As an analogy: mobile telephony protocols can be an standard, but Nokia, Sony-Ericson, Siemens... telephones are the applications of that standard. Imagine if we say tomorrow: "All mobile phones should be built over Nokia's specifications"... What would the others think?

I have my favorites for virtual worlds, but free market should always exist in this, to ensure freedom.

What can be done is to develop different public standards and the different vw platforms will adopt what they like most.

[Hiperia3D - Jordi R Cardona]

By the way, thanks for starting this conversation, it's really interesting.

[Jose L. Salmeron]

Sure. This is an interesting thread.

[Bruce Lehmann]

Also, with the advent of newer browsers coming out, come more browser security problems. This can affect both the user and the people writing the browser-based programs. Especially in the case of IE, which seems to become more difficult to get around with each upgrade. Stand alone apps can be more immersive and game-like but there are some browser-based applications that do the same. Also, you can provide rich content with any app if the quality is available there.

[Alto Xeno]

I am not sure what you mean by "browser-based" virtual worlds. Lively is browser-based, but so it Second Life (built on Mozilla code).

If you mean, a user can enter the virtual world using a standard web browser, then you are dealing with virtual worlds that are fairly superficial in what they can display and what the user can do. The limiting factors become bandwidth available to the user (how fast is your ISP connection), and how many concurrent users the Virtual World's software can service without lag.

Highly interactive virtual worlds like Second Life, OpenSim/OpenLife, and HiPiHi need to install a quite large client software on the user machine so that various aspects of rendering can be handled locally and their remote servers are able to deal with large numbers of concurrent requests.

Less interative worlds like Lively can work with quite lightweight browser add-ons, but inevitably they lack the "depth" of user experience found in the "installed" virtual worlds.

The browser based worlds work well as social sites. Take a look at the growth of social worlds like Habbo Hotel (100 million registered users, 10 million unique users each month), or CyWorld (second only to iTunes in global sales of downloadable music) to see how well this works.

The "true" 3-D worlds that are "user created" (Second Life and spin-offs), HiPiHi, to an extent Novoking, have fewer users. They also have somewhat different demographics, with the median ages of their users being higher.

I personally think the real issue is not browser versus installed software; it is bandwidth. In North America, connection speeds available to home users are orders of magnitude slower than the speeds available in many Asian and European countries. Visiting HiPiHi or Second Life on a 70 or 80 MB connection is a very different experience.

[Hiperia3D - Jordi R Cardona]

We were talking about if there should be a mandatory standard or many standards in virtual worlds. If they should be browser based or not is one of the faces of the problem.

We mean browser-based if it is embedded in your web browser. If it's a program that you run independently, it is a standalone application.

This has little to do if it is a small/limited virtual world or not. The example is Runescape. Runescape uses to have 200,000 users online no matter the time of the day you choose. It runs using Java embedded in your browser. The new Runescape HD has good graphics, not fantastic but correct, but what it has over that is thousands of game possibilities, not limited at all.

The browser vs standalone decision is something that the software developer must choose and it is done mainly for reasons like stability or optimization.

I also think that is false that the users reject using a standalone application. SecondLife can be embedded but it's standalone, so does ActiveWorlds, and the majority of vws. If the VW crashes my browser, I prefer to have it standalone, and avoid it.

What the user wants is to be able to watch and browse web pages without having to run their web browsers. ActiveWorlds has a very stable and fast built-in web browser. In SecondLife it is a bit slow and tends to crash, but at least it has one.

[Gary Arthur Douglas II]

Wow great discussion!

People seem agreed on the direction that "virtual worlds" support is likely to take.

That's probably a really good sign too, since let's face it - "we the people" control the browsers, and we set the agenda that the VW providers have to follow (by our choices of platform).

We don't have to look far back to see a pile of dead media delivery platforms that wouldn't meet the public's demand for compatibility. Although, as I recall - there were painful stages going from GIFs to JPEGs - and from 1,000 audio formats to Mp3 (a fracas that's still going).

It might be a good time to don your peril sensitive sunglasses, folks. ;)

[Doctor]

Interesting that you mention Croquet. I am a fan of that system, and of SmallTalk programming over Java or other languages. Croquet does not yet support VRML, but I have considered writing a SmallTalk extension unit for Croquet that can load VRML (a huge task).
There are a few reasons that I like Croquet:
1) It is written in Smalltalk,
2) It is an "Outers" style 3D chat system (i.e. More like the blaxxun outer worlds than any community like Cybertown or SecondLife),
3) it is designed with IRC style communication ability, which means that one need not depend on a single central server being available in order to have multiuser 3D chat (which is unlike blaxxun or bitmanagement based communities or the blaxxun outer worlds),
4) It has a "portal" system that allows one to "walk" ones avatar between worlds in a smooth manner, rather than a discontinuous load of each new world (as in the blaxxun outers),
5) It is open source.

I encourage everyone to try it out and post their opinions.
http://www.opencroquet.org

As for the discussion about browser plugin versus standalone application, I am of the opinion that both have their place. For instance, a user that just wants to add a 3D object (a math surface or simple animation) to their web page then a plugin or jave applet version of VRML/X3D is useful. However, for a multiuser chat in a complex 3D environment with customizable avatars I believe a standalone application like SecondLife is the way to go. The standalone application allows the 3D application designer to have maximal control and flexibility over optimizing the 3D rendering for speed, whereas the plugin strategy comes with limitations and couples the programmer into the design choices and changes made by Microsoft and other 2D browser designers. One can still arrange that the standalone application gets launched when a web link to a VRML/X3D scene is clicked in any 2D browser, it just would run as a separate helper application (not a plugin). In such a case, the 3D application could continue functioning even if the 2D browser is closed or has crashed. In addition, the 3D browser application would itself allow for hyperlinks, some of which could be designed to launch the default 2D browser (i.e. the reciprocal case -- IE or Firefox is launched as a result of clicking on a link to a 2D HTML page that exists within a 3D VRML world). I think Flux Player might have been designed with this philosophy in mind (i.e. a standalone application AND a plugin version), though I am not certain.

Since the topic has (sort of) been opened, has anyone thought about the possible networking topologies for a multiuser VRML/X3D chat. By that I mean, for example, the blaxxun/bitmanagement based VRML multiuser chat system (i.e. Cybertown or the blaxxun outer worlds) was arranged to have every client 3D browser (i.e. blaxxun Contact or BS Contact) communicate with a single central server through which all chat events, all avatar position/orientation/gesture change events, and all other shared world events were routed. The topology of this is like the spokes of a bicycle wheel, with the server at the hub and all the clients at the far ends of the spokes. No client talks directly with another and if the server goes down then multiuser chat becomes impossible.
As an alternative example, the Kazaa file sharing system had no real servers and was designed to be P2P (peer to peer), though any client could be configured to be a node that was invisible (i.e. the analog of the blaxxun client -- a true client) or a node that would appear as a file source/repository (i.e. a kind of hybrid client/server node). Visible nodes (if I am understanding the Kazaa system correctly) would share their list of known visible nodes among themselves and with the invisible clients. That way, if a visible node (what I would call a super-node) was unavailable then any client (node or super-node) could just consult its list of last known super-nodes and connect with the next closest online super-node. In that way, no client will become completely disconnected from the vast file sharing network.

IRC (internet relay chat) can be made to operate in the fashion just described, if I'm not mistaken. So, as a theoretical example, any member of the 3D chat community could set their computer to be a super-node if their computer was virtually always online like a server, and most others could just leave the default configuration of their 3D client application to be a normal node. The super-nodes would then handle some extra bandwidth as they intercommunicate with each other to ensure that the list of open worlds, list of online users, avatar updates, shared event updates, and chat text are all kept synchronized to within a second or so. However, each super-node would only have to directly communicate with a small fraction of the online users, since normal nodes would communicate with the "closest" super-node, so I think the increase in bandwidth usage on a super-node would still be less than or equal to the bandwidth usage that was seen by the server in the blaxxun topology. That is, if ten users are online in the blaxxun case, then the blaxxun server (in Germany) must directly communicate with all ten clients in countries all around the world, whereas in the IRC based case it may be that 4 users in Germany communicate with a super-node in Germany, and another 4 users in USA communicate with a super-node in the USA, and the two super-nodes communicate with each other directly (for a total of ten client nodes).
I envision that, in such a system, one might even design three levels of node (normal client, super-node, and dedicated server), and also arrange that the number of normal nodes that connect to a given super-node or server is dependent upon the number of users already communicating through that IRC branch and on the available bandwidth of the super-node/server. The system would then dynamically reroute communication paths towards faster average speed for everyone, which is what I think IRC can already do.

So, I am proposing that the chat/shared-event part of VRML/X3D could be built into a new standalone client application using open source IRC libraries, and the 3D-rendering/file-parsing part could be built into the application using an existing, open source, standalone, 3D browser (e.g. OpenVRML, Xj3D, FreeWRL, etc.). Alternatively, Croquet seems to already have the topology/behavior that I have described and might just need to have a VRML/X3D file parsing routine added.

Any comments?
Any corrections to my (uncertain) claims about IRC, Croquet, etc?
Is this a direction that people would like this forum discussion to explore?