This is the second part of a three-part post that examines potential aspects of a future Virtual Web experience. Part 2: Virtual druthers: social union of games and Web discusses asset management, sourcing and standards, and offers a list of 15 salient aspects and why I feel each is something to be considered for a successful offering. Part 1: Reshaping the ego for the Virtual Web makes the case for the essentials of self and a review of the current phenomena of the Social Web to conjecture what might take shape and work well in any virtual successor. Part 3: Virtual contenders is a list of some of the major virtual words, current and future, and how I feel they stack up against the former arguments.
Notions for a Virtual Web
What makes for an ideal virtual web? I think whether there will even be a sole Virtual Web near future or ever is debatable. Certainly virtual worlds have really captured the imagination and press recently. But if product history for web clients hold true, it is more likely at this state that a number of virtual worlds will come to market and co-exist, carving out various niches in their activity zones with committed clientele. But I couldn't help thinking about what aspects might take shape in such a phenomena as would constitute the Virtual Web. We are standing at a very exciting time, near to the big bang of explosive virtual growth. Even if several worlds ultimately evolve to co-exist, I think there will always be a push to bring them together into a comprehensive or mutually intelligible format. For that reason, I think that a lot of people are thinking about the potential Virtual Web, seeing in the manifest crop of current simulations the promise of the most significant change to potentially impact social networking since the onset of the Web itself.
It is not hard to begin a feature list of something that is itself an extension, abstraction and recreation of an existing highly successful system. The current Web offers us proven qualities that recommend themselves by default: open distribution, platform independence, open source structure and maintenance, extendibility, indexing, interaction, anonymity, customization, security (relative), persistence, lack of censorship (relative), and free access.
I would argue that each of these aspects has led to the success of the Web and has made the Web as much a mainstay of social interaction and commerce as has the telephone for some, a growth pattern that will only continue. Yet, as we shall see in Part 3, most, if not all, of the offerings examined will be seen to have departed in one or more significant points from the model offered by the existing Web. Even if one does not accept the points model as I've presented it as being the most accurate rendition, there is still clearly a strong deviation in those simulations that preclude them from being a satisfactory extension of the Web experience in virtual form. If one accepts that these aforementioned qualities are proven, why would anyone consider deviating from them as a baseline moving forward to a new form? - Well, I have come to believe that such is the wrong question to ask.
Though there are some few virtual world products that have either aspirations or at least some small hope of their virtual world being the basis of the next Web, for the most, there seems to be no attempt to recreate or to capture the Web experience. What we are seeing in this rush to market is not the competition to recreate the success of the Web, but to stake out a market share in the virtual world collective medium. If such virtual colonies are successful, I believe that the thinking is probably that expansion can come thereafter. But for the time being, it is such a new medium, that exploration, exploitation, and engagement are the most important factors.
So the question, imho, should be not which virtual world could be the basis of a future Virtual Web, but how might a Virtual Web evolve from such competing closed systems? And then how might successful aspects of these spaces fold over into a more communal offering, preparing and raising expectations in terms of behaviors, access, persistence, and use?
I have posed that the existing Social Web can provide a clear roadmap to successful interaction on some levels and should factor in the overall goals for any standards body or intelligent vendor. But there are those aspects of the virtual experience that not only recommend themselves, they are germane to why virtualization is so much more engaging for some than the existing Web. If a Virtual Web is to come about, these newer features, some possibly that have yet to be discovered or displayed, will likely suggest themselves from the most successful of the virtual worlds that will thrive and prosper over their counterparts. To try and predict, plan and be prepared, to react to such a manifestation, I suggest it is best to start thinking outside of the box that is the web browser. Consider that a common yet mistaken assumption that all such virtual worlds are "games" still realizes a fundamental truth: that the other parent model to study is that of social gaming.
Collectively, social games are the most popular form of virtual world currently in existence. The most successful of these, in terms of revenue and active use, are fully realized three-dimensional spaces known as MMOs (MMO comes from Massive Multiplayer Online). In MMOs the game activity is paramount, but most offer varying levels of social activity as a by-product, often unplanned. These games offer us another model that deals with visual and aural manifestation: three-dimensional space, avatars, interactive physics (between avatars and the avatars and environment), inventory (items carried by and used by the avatar), group association and organization, avatar and group communication, persistence of space, both ambient and reactive sound and music, game engines and graphics rendering, and, for some, personal space and/or the customization of space and avatar.
Clearly, in trying to reimagine the Web into a visual format, we have clear working examples. Though such games might be proprietary, they still offer excellent proofs-of-concept. And since we have a large number of working examples, a list that compounds each quarter, a qualitative assessment can be done to decide on what features of each work best, which don't, and which ultimately might suggest themselves to a comprehensive solution that seeks to bridge the visual and interactive environment of social games to the broader use of the Social Web.
Mixing the models
The Web is mostly open, interlinked. It has evolved to include mechanisms and standards so that it can be managed, adapted, and transformed by the uses put to it. Growth is organic and ongoing. The Web is accessible on most levels by nearly all computers. MMOs are exclusive, closed systems. They are software applications where change must be managed, and with more limited resources, requirements assessed against many demands: user satisfaction, technology changes, time to market, and competing products' features. Growth is therefore more structured and scheduled. Because of their technology requirements, MMOs cater to select target markets, some more exclusive than others. Not everyone has satisfactory access.
So if we wish combine the extendibility, user control, and open standards of the Web with the sensory richness and sophistication of the MMOs, how might such an experience come to be, given the different requirements of each?
Probably the biggest hurdle in visualizing such a system are the requirements put forth by graphics rendering and scripted interaction. As we shall see in Part 3, most vendors choose to accommodate these by controlling the number of choices, essentially using MMOs' concepts of fixed asset libraries and animation rethought of in non-game terms, or supra-game terms when considering hybrid models. These work because these are closed systems, with all that such entails. Second Life is currently the only virtual world to offer the ability for users to interject their own creations into the environment (HiPiHi has stated its intention to offer same). There is only a limited fixed library. But though these user-created objects are not the sole cause of performance problems, they are a contributing factor and Second Life suffers for it. Second Life has much poorer performance and currently no ability to scale well for users in any numbers in a given area. Though an outdated graphics engine is partly to blame, one can see where bloated scripts and excessively complex object models can slow rendering to a crawl or even crash the server, harking back to when bloated nested tables and excessive JavaScript could slow the rendering of web pages in the early Web.
Any solution for a Virtual Web that presupposes both state of the art graphics and extensibility, if both parent models are valid conceptual ancestors, must need have the ability to at least offer the option for a rich immersive experience, and yet have the ability to allow for user-created objects and spaces as part of its makeup - and both with an acceptable level of performance. The solution I propose is to to apply an adaptive model that borrows from each parent. It is not necessarily the most likely model. I see several ways this might come about. It is simply a hypothesis that I find attractive.
First need is that a common baseline set of standards, which would govern not only behaviors, but script, visuals, rendering engines requirements, and a visual reference language, would need to be monitored and maintained by an open standards body, much as HTML/XML are by the W3C and JavaScript is by the ECMA. Such a body would provide a neutral platform for change and it is a proven concept already in use. A Virtual Web browser would need to include a graphics engine, like games do. The graphics engine might change over time, or different vendors might prefer different versions of it in their own products, but as long as the requirements are set for in open standards, everyone knows the minimum requirements that will be tasked to any such engine.
To achieve efficient quality, I suggest the solution also needs to follow one of two tracks: the markup model or the library model.
The markup model is an exception to my argument as it excludes the game ancestor and reimagines virtuality based on a markup language, something akin to VRML (virtual reality markup language), X3D, or a scripting language, like ActionScript. This would be rendered in a web browser using a plug-in and would be akin to a more robust version of the Shockwave/Flash player. There is much that is very attractive about this. One of the biggest virtual worlds existing is based on Shockwave technology. It is a closed system but it is not hard to imagine a similar product that is open to user generated content based on a rendered language. The overhead of such would be a lot less than managing user created objects amalgamated through scripts and graphic textures of various file sizes. And objects could be linked rather than uploaded. Though existing Shockwave virtual worlds have a rather cartoony look one often sees in vectored animation, that is more typical of their market (mostly teens and children) than an indication of the limits of the technology. Even if Shockwave is not the channel for this sort of effort, one can imagine something similar coming to market. And though I see much promise in this avenue of approach, the current crop seems more focused on game-like offerings which use or seem to use embedded library objects.
The library model would borrow from the methods used by games. Games achieve much of their performance by maintaining almost all of the objects, textures, and sound that comprise the visual elements on the host system, either directly on a drive or kept on a CD or DVD, to be accessed as needed. For MMO games, the game engine needs to then rerender the scene based not only on the actions of the local player, but on the actions of those around the player as well as the game AI, all transmitted via network connections. But having the bulkiest files kept locally in asset libraries means that the amount of information that need be passed through the network pipeline would be much smaller, and the time to render much faster, than it would be had everything needed to be downloaded.
Static local libraries vs dynamic linked rendering
For the library model to achieve customizable quality, we need to find a correlation that equates media elements to both HTML and XML, and that makes use of the built-in understanding of the former, along with the extensible open-ended application of the latter. HTML is preconfigured to render in such a way because it is governed by a standards body. Anyone seeking to build a browser, be it Explorer, Firefox, Opera or Safari, knows how to build their application to render the markup correctly because these standards are open and available. Hence the "understanding" for HTML is built into browsers, and even though they include references to conforming DTDs, such are not utilized for the sake of performance and speed. There's no need to when expectations have already been set.
If builders of virtual worlds know which visual and media elements have been downloaded to any user's computer via the browser, they can use such knowledge to craft their worlds. Virtual world builders would have a hopefully large and updated library of assets they know they could call upon, at minimal impact to bandwidth. So, for the sake of virtual argument, if one takes the preconfigured asset library of a game as potentially being the same as a virtual HTML, assets hosted not on the collective Web to be downloaded and rendered dynamically, but on the host systems as part of the "browser" installation, then one understands the correlation between the two models. This creates for a very rich experience, providing visual, aural, and scripted building blocks which are then reconfigured according to instructions coming in via the Web. Everyone experiences them the same because they are the same on everyone's system.
Therefore, the default or baseline Virtual Web, like a closed game system, will have a finite number of choices available. And like a closed system that seeks to keep its users engaged, textures, objects, scripts might be corrected, modified, replaced over time, and the choices extended with care. Stored assets would obviously be faster to load. But how to expand the experience to be open-ended? Two ways: optional library downloads and linked dynamic objects. These would be akin to our visual XML. The former might even have conformance instructions, like DTDs or Schema. The latter would be self-describing. For this hypothesis, assume that all objects, standard or optional, library or dynamic, have a fixed reference number to call upon.
Optional library downloads would be like the initial library installed as part of the viewer, added to the local asset files to be potentially called upon by builders, using provided documentation indicating reference calls. Such stored assets could be based on themes or uses. They could be provided by the standards body as optional files to help extend the experience of the Virtizen, or could be offered as part of product promotions or activity vendors, such as game providers who want to ensure a specific graphical look or style to their activity zone. To keep file size down, the challenge for library extensions would be to not recreate objects and textures already installed as part of another library but only include those aspects different from the baseline, including ones that might be imagined to be better. For "open" extended libraries, anyone could use the assets in their building calls, and the call details would be provided in library documentation. But some vendors might also offer "closed" libraries, where the assets are provided for download for efficiency, but which could only be used in specific contexts - say on a specific server.
Much like current Web users are sometimes prompted to download a specific font, sound file, or browser plug-in, to optimize their Web surfing experience on a specific site, users entering into activity zones that required new library assets would be notified and asked if they cared to download them. Opting out would force the objects to render to a baseline texture provided in the default library, or render certain scripted objects inoperable. Breaking libraries into specific families of use or themes would help keep the initial browser download smaller and ensure that virtizens only downloaded files that they actively needed to by way of their own use activities. And the impact of exploration could be spread out over more time. Virtizens content with the experience in the main entry zone would never need download anything further except for those files provided as updates or extensions as part of browser upgrades based on new standards. And, as standards updated and older textures and scripts were replaced or embellished by newer offerings, one could see that the more useful and popular public domain open library assets might be added to the official libraries as part of standards maintenance. Optional library sets maintained by the standards body could include highly complex and useful common objects: vehicles, avatar hair, plants and rocks, scripted animals, or theme libraries, such as science fiction, Renaissance, Moghul India, etc. Where optional libraries included the same optional elements, including more than one library would only update the object or item in question if it was older.
Not all objects would recommend themselves as candidates for installation into the local library assets. This might be because the creator did not wish the item to be installed on someone else's computer. But most of the time, user creations would not suggest themselves for such because, not coming from a "trusted" source such as a standards body or activity zone vendor, or because they are limited to only a few files, they are just not candidates for such. And in those instances, objects would be rendered dynamically, based on instructions carried by the object itself when downloaded from the objects' or owners' servers. Such objects would render somewhat slower since the information for their construction, including all baseline textures and scripts, would need to be downloaded to memory and/or cache and then rendered, much like what is currently done in Second Life. The difference between this solution and Second Life's is hopefully that by sharing the load between stored and downloaded files, with the understanding that hopefully the most graphically intensive and complex are likely to be local, helps create a more efficient render and allow for richer objects than one currently has in Second Life.
Typical dynamic objects would likely relate to avatar embellishment: clothes, hair, skins, vehicles, etc. Probably avatar or other dynamic objects acquired would include a local download copy so one can see one's own avatar render as quickly as possible. The "browser" would first check to see if the dynamic object had a local copy kept in the asset library and if it did not find such, would then proceed to follow the rendering instructions. Dynamic objects would be self-describing, carrying their own scripts, textures, and rendering instructions as part of their object package. Dynamic object creators, for the most part, would probably like to see their objects added to local libraries, not to use per se, but at least to speed up viewing. With a hopefully good metadata system in place, users might be able to right-click/ctrl-click an appealing object and download its makeup to the local library so that it rendered faster, and as well find out how to secure their own copy, if such options were possible. (I suspect though that given the desire for unique appearance, that there should be a user option to not let others view avatar or owned-object details). The most popular objects might even make their way into asset libraries at some points.
World builders or virtual site builders would not be limited to using the static library elements, but rendering efficiency, like like in the current Web, would put pressure on builders to use methods that ensured a satisfactory visit or be willing, to put up with smaller crowds. But just like when creating complex scripting or heavy structuring in the current Web, the choice is always up to the user.
Of course, packaging efficiency, graphics processing power, and transmission speeds might someday soon render such methods obsolete, in which case all objects could be rendered dynamically, just as they are in Second Life. As equipment improves and bandwidth becomes less of an issue, asset libraries could be removed over time. But until that day, in the quest to serve as many users, the final trait inherited from the games parent for this mixed model would be a graceful de-evolution of graphics intensity, so that users not blessed with cutting-edge systems could still make use and function within the Virtual Web. Either textures could be provided in differing levels of quality, such as base, midline or high. Or the graphics processor could be set to have different levels of graphics rendering, allowing for the most pleasurable experience at the cost of processing power or functional pleasing use for most systems.
Protocols and growth
Finally, we're back to the Web ancestor. How to manage an interlinked distributed system of virtual sites like the Web? Though the application I'm sure is complex, the answer is simple: grow the Web. Virtual worlds would just be another type of access point and in the spirit of convergence, having a Virtual Web browser being the same application as a Web 2.0 browser makes sense, especially given tabbed browsing now available in nearly every Web browser. The Virtual World just becomes another layer of interaction in the existing Web, not a replacement as some have posed.
What would be needed is a protocol to take the stateless experience of HTTP to a new method of bidirectional stateful communication. One's browser isn't simply a passive recipient, it actively injects you - all right, the collection of dynamic objects that constitute your avatar - into a distant server and you are able to function and effect that space just as it and other visitors effects your alter-ego.
And yet, that same protocol might give you access to sensitive personal information retained in your browser, but not allow access to same by the owners of the server you are visiting until you actively choose to offer such to enable transactions.
I cannot speak to the state of stateful Web services, but essentially that is what is required. I know that WebSphere, among others, are working on stateful applications. One can see that one of the keen benefits of a Virtual Web, as opposed to the feudal baronies of closed competing virtual fiefs, is all the rampant growth in infrastructure that a Virtual Web would create were it to take off as projected. I suspect that existing protocols wouldn't allow for a lot of avatar/packet injection resulting in a somewhat low user ceiling, ala Second Life. But that would change in time and demands for more powerful servers and new software to host and manage traffic would ramp up. Businesses poised to sell servers, software, and routers could really see a long-term windfall that would spill over to other support industries as the means to populate this new endless Virtual Web created new job opportunities.
None of this would happen to anything like the same degree if the virtual world collective remains disjointed and disconnected. That I think is both the challenge and incentive to realizing a universal Virtual Web.
Druthers in 15 points
Combining the arguments for ego, asset management, standards and extendability, my ideal for the Virtual Web would address the following points in its construction:
Notions for a Virtual Web
What makes for an ideal virtual web? I think whether there will even be a sole Virtual Web near future or ever is debatable. Certainly virtual worlds have really captured the imagination and press recently. But if product history for web clients hold true, it is more likely at this state that a number of virtual worlds will come to market and co-exist, carving out various niches in their activity zones with committed clientele. But I couldn't help thinking about what aspects might take shape in such a phenomena as would constitute the Virtual Web. We are standing at a very exciting time, near to the big bang of explosive virtual growth. Even if several worlds ultimately evolve to co-exist, I think there will always be a push to bring them together into a comprehensive or mutually intelligible format. For that reason, I think that a lot of people are thinking about the potential Virtual Web, seeing in the manifest crop of current simulations the promise of the most significant change to potentially impact social networking since the onset of the Web itself.
It is not hard to begin a feature list of something that is itself an extension, abstraction and recreation of an existing highly successful system. The current Web offers us proven qualities that recommend themselves by default: open distribution, platform independence, open source structure and maintenance, extendibility, indexing, interaction, anonymity, customization, security (relative), persistence, lack of censorship (relative), and free access.
I would argue that each of these aspects has led to the success of the Web and has made the Web as much a mainstay of social interaction and commerce as has the telephone for some, a growth pattern that will only continue. Yet, as we shall see in Part 3, most, if not all, of the offerings examined will be seen to have departed in one or more significant points from the model offered by the existing Web. Even if one does not accept the points model as I've presented it as being the most accurate rendition, there is still clearly a strong deviation in those simulations that preclude them from being a satisfactory extension of the Web experience in virtual form. If one accepts that these aforementioned qualities are proven, why would anyone consider deviating from them as a baseline moving forward to a new form? - Well, I have come to believe that such is the wrong question to ask.
Though there are some few virtual world products that have either aspirations or at least some small hope of their virtual world being the basis of the next Web, for the most, there seems to be no attempt to recreate or to capture the Web experience. What we are seeing in this rush to market is not the competition to recreate the success of the Web, but to stake out a market share in the virtual world collective medium. If such virtual colonies are successful, I believe that the thinking is probably that expansion can come thereafter. But for the time being, it is such a new medium, that exploration, exploitation, and engagement are the most important factors.
So the question, imho, should be not which virtual world could be the basis of a future Virtual Web, but how might a Virtual Web evolve from such competing closed systems? And then how might successful aspects of these spaces fold over into a more communal offering, preparing and raising expectations in terms of behaviors, access, persistence, and use?
I have posed that the existing Social Web can provide a clear roadmap to successful interaction on some levels and should factor in the overall goals for any standards body or intelligent vendor. But there are those aspects of the virtual experience that not only recommend themselves, they are germane to why virtualization is so much more engaging for some than the existing Web. If a Virtual Web is to come about, these newer features, some possibly that have yet to be discovered or displayed, will likely suggest themselves from the most successful of the virtual worlds that will thrive and prosper over their counterparts. To try and predict, plan and be prepared, to react to such a manifestation, I suggest it is best to start thinking outside of the box that is the web browser. Consider that a common yet mistaken assumption that all such virtual worlds are "games" still realizes a fundamental truth: that the other parent model to study is that of social gaming.
Collectively, social games are the most popular form of virtual world currently in existence. The most successful of these, in terms of revenue and active use, are fully realized three-dimensional spaces known as MMOs (MMO comes from Massive Multiplayer Online). In MMOs the game activity is paramount, but most offer varying levels of social activity as a by-product, often unplanned. These games offer us another model that deals with visual and aural manifestation: three-dimensional space, avatars, interactive physics (between avatars and the avatars and environment), inventory (items carried by and used by the avatar), group association and organization, avatar and group communication, persistence of space, both ambient and reactive sound and music, game engines and graphics rendering, and, for some, personal space and/or the customization of space and avatar.
Clearly, in trying to reimagine the Web into a visual format, we have clear working examples. Though such games might be proprietary, they still offer excellent proofs-of-concept. And since we have a large number of working examples, a list that compounds each quarter, a qualitative assessment can be done to decide on what features of each work best, which don't, and which ultimately might suggest themselves to a comprehensive solution that seeks to bridge the visual and interactive environment of social games to the broader use of the Social Web.
Mixing the models
The Web is mostly open, interlinked. It has evolved to include mechanisms and standards so that it can be managed, adapted, and transformed by the uses put to it. Growth is organic and ongoing. The Web is accessible on most levels by nearly all computers. MMOs are exclusive, closed systems. They are software applications where change must be managed, and with more limited resources, requirements assessed against many demands: user satisfaction, technology changes, time to market, and competing products' features. Growth is therefore more structured and scheduled. Because of their technology requirements, MMOs cater to select target markets, some more exclusive than others. Not everyone has satisfactory access.
So if we wish combine the extendibility, user control, and open standards of the Web with the sensory richness and sophistication of the MMOs, how might such an experience come to be, given the different requirements of each?
Probably the biggest hurdle in visualizing such a system are the requirements put forth by graphics rendering and scripted interaction. As we shall see in Part 3, most vendors choose to accommodate these by controlling the number of choices, essentially using MMOs' concepts of fixed asset libraries and animation rethought of in non-game terms, or supra-game terms when considering hybrid models. These work because these are closed systems, with all that such entails. Second Life is currently the only virtual world to offer the ability for users to interject their own creations into the environment (HiPiHi has stated its intention to offer same). There is only a limited fixed library. But though these user-created objects are not the sole cause of performance problems, they are a contributing factor and Second Life suffers for it. Second Life has much poorer performance and currently no ability to scale well for users in any numbers in a given area. Though an outdated graphics engine is partly to blame, one can see where bloated scripts and excessively complex object models can slow rendering to a crawl or even crash the server, harking back to when bloated nested tables and excessive JavaScript could slow the rendering of web pages in the early Web.
Any solution for a Virtual Web that presupposes both state of the art graphics and extensibility, if both parent models are valid conceptual ancestors, must need have the ability to at least offer the option for a rich immersive experience, and yet have the ability to allow for user-created objects and spaces as part of its makeup - and both with an acceptable level of performance. The solution I propose is to to apply an adaptive model that borrows from each parent. It is not necessarily the most likely model. I see several ways this might come about. It is simply a hypothesis that I find attractive.
First need is that a common baseline set of standards, which would govern not only behaviors, but script, visuals, rendering engines requirements, and a visual reference language, would need to be monitored and maintained by an open standards body, much as HTML/XML are by the W3C and JavaScript is by the ECMA. Such a body would provide a neutral platform for change and it is a proven concept already in use. A Virtual Web browser would need to include a graphics engine, like games do. The graphics engine might change over time, or different vendors might prefer different versions of it in their own products, but as long as the requirements are set for in open standards, everyone knows the minimum requirements that will be tasked to any such engine.
To achieve efficient quality, I suggest the solution also needs to follow one of two tracks: the markup model or the library model.
The markup model is an exception to my argument as it excludes the game ancestor and reimagines virtuality based on a markup language, something akin to VRML (virtual reality markup language), X3D, or a scripting language, like ActionScript. This would be rendered in a web browser using a plug-in and would be akin to a more robust version of the Shockwave/Flash player. There is much that is very attractive about this. One of the biggest virtual worlds existing is based on Shockwave technology. It is a closed system but it is not hard to imagine a similar product that is open to user generated content based on a rendered language. The overhead of such would be a lot less than managing user created objects amalgamated through scripts and graphic textures of various file sizes. And objects could be linked rather than uploaded. Though existing Shockwave virtual worlds have a rather cartoony look one often sees in vectored animation, that is more typical of their market (mostly teens and children) than an indication of the limits of the technology. Even if Shockwave is not the channel for this sort of effort, one can imagine something similar coming to market. And though I see much promise in this avenue of approach, the current crop seems more focused on game-like offerings which use or seem to use embedded library objects.
The library model would borrow from the methods used by games. Games achieve much of their performance by maintaining almost all of the objects, textures, and sound that comprise the visual elements on the host system, either directly on a drive or kept on a CD or DVD, to be accessed as needed. For MMO games, the game engine needs to then rerender the scene based not only on the actions of the local player, but on the actions of those around the player as well as the game AI, all transmitted via network connections. But having the bulkiest files kept locally in asset libraries means that the amount of information that need be passed through the network pipeline would be much smaller, and the time to render much faster, than it would be had everything needed to be downloaded.
Static local libraries vs dynamic linked rendering
For the library model to achieve customizable quality, we need to find a correlation that equates media elements to both HTML and XML, and that makes use of the built-in understanding of the former, along with the extensible open-ended application of the latter. HTML is preconfigured to render in such a way because it is governed by a standards body. Anyone seeking to build a browser, be it Explorer, Firefox, Opera or Safari, knows how to build their application to render the markup correctly because these standards are open and available. Hence the "understanding" for HTML is built into browsers, and even though they include references to conforming DTDs, such are not utilized for the sake of performance and speed. There's no need to when expectations have already been set.
If builders of virtual worlds know which visual and media elements have been downloaded to any user's computer via the browser, they can use such knowledge to craft their worlds. Virtual world builders would have a hopefully large and updated library of assets they know they could call upon, at minimal impact to bandwidth. So, for the sake of virtual argument, if one takes the preconfigured asset library of a game as potentially being the same as a virtual HTML, assets hosted not on the collective Web to be downloaded and rendered dynamically, but on the host systems as part of the "browser" installation, then one understands the correlation between the two models. This creates for a very rich experience, providing visual, aural, and scripted building blocks which are then reconfigured according to instructions coming in via the Web. Everyone experiences them the same because they are the same on everyone's system.
Therefore, the default or baseline Virtual Web, like a closed game system, will have a finite number of choices available. And like a closed system that seeks to keep its users engaged, textures, objects, scripts might be corrected, modified, replaced over time, and the choices extended with care. Stored assets would obviously be faster to load. But how to expand the experience to be open-ended? Two ways: optional library downloads and linked dynamic objects. These would be akin to our visual XML. The former might even have conformance instructions, like DTDs or Schema. The latter would be self-describing. For this hypothesis, assume that all objects, standard or optional, library or dynamic, have a fixed reference number to call upon.
Optional library downloads would be like the initial library installed as part of the viewer, added to the local asset files to be potentially called upon by builders, using provided documentation indicating reference calls. Such stored assets could be based on themes or uses. They could be provided by the standards body as optional files to help extend the experience of the Virtizen, or could be offered as part of product promotions or activity vendors, such as game providers who want to ensure a specific graphical look or style to their activity zone. To keep file size down, the challenge for library extensions would be to not recreate objects and textures already installed as part of another library but only include those aspects different from the baseline, including ones that might be imagined to be better. For "open" extended libraries, anyone could use the assets in their building calls, and the call details would be provided in library documentation. But some vendors might also offer "closed" libraries, where the assets are provided for download for efficiency, but which could only be used in specific contexts - say on a specific server.
Much like current Web users are sometimes prompted to download a specific font, sound file, or browser plug-in, to optimize their Web surfing experience on a specific site, users entering into activity zones that required new library assets would be notified and asked if they cared to download them. Opting out would force the objects to render to a baseline texture provided in the default library, or render certain scripted objects inoperable. Breaking libraries into specific families of use or themes would help keep the initial browser download smaller and ensure that virtizens only downloaded files that they actively needed to by way of their own use activities. And the impact of exploration could be spread out over more time. Virtizens content with the experience in the main entry zone would never need download anything further except for those files provided as updates or extensions as part of browser upgrades based on new standards. And, as standards updated and older textures and scripts were replaced or embellished by newer offerings, one could see that the more useful and popular public domain open library assets might be added to the official libraries as part of standards maintenance. Optional library sets maintained by the standards body could include highly complex and useful common objects: vehicles, avatar hair, plants and rocks, scripted animals, or theme libraries, such as science fiction, Renaissance, Moghul India, etc. Where optional libraries included the same optional elements, including more than one library would only update the object or item in question if it was older.
Not all objects would recommend themselves as candidates for installation into the local library assets. This might be because the creator did not wish the item to be installed on someone else's computer. But most of the time, user creations would not suggest themselves for such because, not coming from a "trusted" source such as a standards body or activity zone vendor, or because they are limited to only a few files, they are just not candidates for such. And in those instances, objects would be rendered dynamically, based on instructions carried by the object itself when downloaded from the objects' or owners' servers. Such objects would render somewhat slower since the information for their construction, including all baseline textures and scripts, would need to be downloaded to memory and/or cache and then rendered, much like what is currently done in Second Life. The difference between this solution and Second Life's is hopefully that by sharing the load between stored and downloaded files, with the understanding that hopefully the most graphically intensive and complex are likely to be local, helps create a more efficient render and allow for richer objects than one currently has in Second Life.
Typical dynamic objects would likely relate to avatar embellishment: clothes, hair, skins, vehicles, etc. Probably avatar or other dynamic objects acquired would include a local download copy so one can see one's own avatar render as quickly as possible. The "browser" would first check to see if the dynamic object had a local copy kept in the asset library and if it did not find such, would then proceed to follow the rendering instructions. Dynamic objects would be self-describing, carrying their own scripts, textures, and rendering instructions as part of their object package. Dynamic object creators, for the most part, would probably like to see their objects added to local libraries, not to use per se, but at least to speed up viewing. With a hopefully good metadata system in place, users might be able to right-click/ctrl-click an appealing object and download its makeup to the local library so that it rendered faster, and as well find out how to secure their own copy, if such options were possible. (I suspect though that given the desire for unique appearance, that there should be a user option to not let others view avatar or owned-object details). The most popular objects might even make their way into asset libraries at some points.
World builders or virtual site builders would not be limited to using the static library elements, but rendering efficiency, like like in the current Web, would put pressure on builders to use methods that ensured a satisfactory visit or be willing, to put up with smaller crowds. But just like when creating complex scripting or heavy structuring in the current Web, the choice is always up to the user.
Of course, packaging efficiency, graphics processing power, and transmission speeds might someday soon render such methods obsolete, in which case all objects could be rendered dynamically, just as they are in Second Life. As equipment improves and bandwidth becomes less of an issue, asset libraries could be removed over time. But until that day, in the quest to serve as many users, the final trait inherited from the games parent for this mixed model would be a graceful de-evolution of graphics intensity, so that users not blessed with cutting-edge systems could still make use and function within the Virtual Web. Either textures could be provided in differing levels of quality, such as base, midline or high. Or the graphics processor could be set to have different levels of graphics rendering, allowing for the most pleasurable experience at the cost of processing power or functional pleasing use for most systems.
Protocols and growth
Finally, we're back to the Web ancestor. How to manage an interlinked distributed system of virtual sites like the Web? Though the application I'm sure is complex, the answer is simple: grow the Web. Virtual worlds would just be another type of access point and in the spirit of convergence, having a Virtual Web browser being the same application as a Web 2.0 browser makes sense, especially given tabbed browsing now available in nearly every Web browser. The Virtual World just becomes another layer of interaction in the existing Web, not a replacement as some have posed.
What would be needed is a protocol to take the stateless experience of HTTP to a new method of bidirectional stateful communication. One's browser isn't simply a passive recipient, it actively injects you - all right, the collection of dynamic objects that constitute your avatar - into a distant server and you are able to function and effect that space just as it and other visitors effects your alter-ego.
And yet, that same protocol might give you access to sensitive personal information retained in your browser, but not allow access to same by the owners of the server you are visiting until you actively choose to offer such to enable transactions.
I cannot speak to the state of stateful Web services, but essentially that is what is required. I know that WebSphere, among others, are working on stateful applications. One can see that one of the keen benefits of a Virtual Web, as opposed to the feudal baronies of closed competing virtual fiefs, is all the rampant growth in infrastructure that a Virtual Web would create were it to take off as projected. I suspect that existing protocols wouldn't allow for a lot of avatar/packet injection resulting in a somewhat low user ceiling, ala Second Life. But that would change in time and demands for more powerful servers and new software to host and manage traffic would ramp up. Businesses poised to sell servers, software, and routers could really see a long-term windfall that would spill over to other support industries as the means to populate this new endless Virtual Web created new job opportunities.
None of this would happen to anything like the same degree if the virtual world collective remains disjointed and disconnected. That I think is both the challenge and incentive to realizing a universal Virtual Web.
Druthers in 15 points
Combining the arguments for ego, asset management, standards and extendability, my ideal for the Virtual Web would address the following points in its construction:
In the concluding third part to the original post, I will examine a number of current and future virtual worlds, organize them into types, pose them against my arguments, and conjecture what sorts of perceived strengths and weaknesses they offer.1. It must be distributed, allowing one's avatar to move from server to server and yet retain basic visual and functional integrity. (a)
2. It should either allow for multiple avatars or an infinitely malleable avatar whose visible identity is distinct from an absolute verification identity. (b)
3. It must be platform independent.
4. It must be based on an open-sourced, scalable, and extendable language and asset library, such as a series of common media libraries (that are download with all viewers) and user-defined (optional download or linked) media libraries. (c)
5. It must allow users to upload their own content and define their own activities and own their own creations.
6. There must be a way for all activities and content to be typed with metadata to let search and indexing function properly. (d)
7. Though governed by standards designed to regulate its structure so that everyone has a common reference when building (like the W3 to HTML or ECMA to JavaScript) – it must be unregulated in terms of content – leaving regulation to the users and to governments to enforce.
8. It must be fully linkable with existing web-based content and existing technologies, being able to direct traffic and information to web sites and web services and vice versa; as well being able to embed web-based and media content where it makes sense to do so.
9. It must integrate high-quality multi-channel voice client, allowing people to communicate in teams or groups (useful for business and games).
10. The social space should act as an umbrella through which one enters into business, activity, and educational spaces. The social space must remain distinct but linked, so that avatars can move back and forth, from activity to activity, using the social space as the bridge. (e)
11. Activity spaces should be "zoned" or demarcated in some fashion to help indexing, search, and access (or avoidance, for areas inappropriate or offensive) to certain users of the social space (e.g. children). (f)
12. There should be social controls should that extend down to the user level. (g)
13. It must be secure.
14. It must persist.
15. It must be free of cost (h)(a) This to allow for the full growth of the system and also the ability to host one's own offering and yet have it tied into the "grid." And in this way, market forces would come to bear, allowing for cheaper alternatives and richer experiences. Some systems might require avatar changes and restrictions based on themes, for example a fantasy game space like World of Warcraft, should it be linked – but the avatar should retain it's basic form preferences and revert upon leaving that kind of space back into the common social area. One should not discount the appeal of avatar persistence and embellishment as a form of ego extension.
(b) In the former case, I suggest an unlimited amount, but that there should be a fee (nominal but enough to discourage willy-nilly avatar escalation ($15 U.S?)). Validation, though sub-surface respective to appearance, allows anyone's avatar access to methods for payment or access confirmation when needed. Yes, people can just change their avatar at will but not always their avatar name. OR – make the exposed name itself malleable to allow for those people who want to disappear into the virtual throng without being recognized. Then no need for multiple avatars (again, "true" identity being linked to the hidden validation mechanisms). Any system really needs to account for somewhat diametrically opposed needs and function of avatars: ones that require anonymity and permutation, and ones that require authentication and fixed identity link. If we disconnect the displayed name and appearance from the latter, then we can have both. – I cannot overstate this strongly enough, part of the strength and appeal of these environments is the ability to level the social field of perception and allow everyone the ability to either appear as they wish to, regardless of social, ethnic, class, gender, wealth, religious, orientation, cultural or other conventions.
(c) Common libraries installed on system as part of the application viewer will help efficiency, reduce load times, reduce bandwidth usage, help offer high-quality graphical objects for free to help encourage building and use and help maintain the appeal of the space. This is basically taking the idea of common tagging and extending it to graphical and scripting elements. A common library lets users build say a brick edifice and have comfort in knowing that it will appear as intended. One possible use for this user-defined libraries would be to let vendors who are selling a certain "look" for avatars to use in their proprietary space have access to those textures and media files only within and while the avatar is in the vendor activity area. Avatars leaving that area, if they lack the vendor's permissions to retain the look or objects, would have such become inoperable and textures would render to a default common value or the avatar would need to "change clothes" so to speak. Like any media files, library elements could be linked for download to user system (faster loading) vs linked to load off of owners' servers (helping guard ownership and restrict unauthorized reuse). Activity vendors might also use avatar embellishment as a marketing tool to encourage subscription, such as the ability to show off a hard-won item used for the activity in the social space. ("were u git kewl rabit ears?") - Another option, is as stated, to use markup solely for rendering. But I think markup married to embedded graphical elements still allows for the best experience.
(d) Such typing should be encouraged, though users will learn this necessity themselves once better search methods come to being. This is key since objects and services are unlimited.
(e) Though social spaces are just their own activity zone, and though there should be an option to enter from a "homepage" like the Web, offering a one or more likely several communal entry points helps bring a focus and discovery point for new objects. I suspect that should such a proposed Virtual Web come about, one good way to think of this is to realize search sites like Google and Yahoo as social zones. There might be many and we'd each not have the same ones, but each would provide ready access to new features. Probably many spaces might try to attract people to "home" there and therefore be exposed to other host branded offerings on the way to doing whatever one does in virtual worlds. And I think one way to help this is to require that avatar's be "homed" somewhere - be it communal social spaces hosted by the standards body or search engines (Google, Yahoo, Microsoft), private offers that include advertising and access to fun activites (Games for Windows, Sony Home, AWOMO, Gamespot), personal worlds hosted on a home server, or even corporate or information sites (Apple, IBM, Guardian Unlimited, NY Times).
Keeping social space and its economy in real dollars distinct from activity spaces insulates the social/business space from the effects of "gold farming" and other manipulative techniques already affecting game economies. It also protects vendors doing business from dealing with inflation or devaluation of the game currency when trying to convert back to real dollars. IF game vendors want to link their game economies directly with the overall space, they will have to be the ones who pay for money taken from game to social space and account for such in their subscription fees. A good working example of games sitting within or under the social framework can be found in Second Life's Dark Life game – where "gold pieces" the game currency are tracked by the HUD given to control the game and in no way are translatable to objects or services outside the game. In other words, one cannot take gold and purchase anything outside of the game. Gold remains strictly to buy items in the game. Conversely, one cannot take Linden dollars and buy game objects – one needs gold for that. However, there is nothing to prevent people from making side deals to sell game items for minimal gold in return for a side transaction of Linden dollars, or to just sell gold themselves, all to help elevate one's game avatar abilities faster than the game designers probably would wish. But this is just the same as the issue of real money being used to purchase game items in online games, like World of Warcraft, which his the basis of the "gold farming" service industry. I suggest that game designers either decide to get into that business, as Sony did for EverQuest, make items non-transferable, instill a game tax for in-game transactions, or some other such controls.
(f) A way to enforce this "zoning" through a common media library (point 11) is to always require a "safe" baseline texture for any object so that moving back into the social space, certain types of media textures or objects would simply not render in the transition but would be replaced by a default unless the avatar user remembered to adjust. That way, there would be no way for a character to leave a game space (say a Star Wars franchise) wearing their game kit if the game vendors did not want that stuff used outside the space (or perhaps required for a separate purchase) or say, if an avatar left an adult-zoned area, there would be no danger of offensive avatar embellishments being exposed after the avatar reset to baseline (Again, all custom or user-defined textures would require or come with a default common texture, certain objects would just disappear). Also, zoning, in combination with some sort of verification, could be used to keep children out of adult-only areas and vice versa.
(g) And by inference to any and all avatar permutations. I think, borrowing from game conventions, the ability to self-edit one's own experience is key to keeping enjoyment level high. Unlike the real world, we do have the ability to filter out unwanted intrusions into our experience and I think an intelligent system should account for such. Say for example, typical of many games, if I see someone spouting nonsense that I find offensive I can simply ignore them. But is that enough? How far should it go? Let's extend that further to be more informative. Say a given decision to ignore someone is temporary and times out but a warning e-mail/IM is fired off to the person letting them know that they had some sort of social filter applied against them. That person can then decide if the action or dialogue that precipitated this is worth the cost of alienation or that the person(s) was just too thin-skinned. Or, a person can even make that ignorance of the other person permanent (reversible of course but only through the application interface). "Property" owners could use such controls to ban or warn persons abusing (in their opinion) their offerings or spaces; such is already is done in Second Life. Such social controls should permeate all the way down to the user level so that a person simply can't fashion a new avatar and then go back to the same venue or activity as if nothing had happened. I think even more powerful would be to turn off collision-detection and visibility for the mutually offended parties, and have any aspect of an unwanted user's avatars made invisible and unable to interact with the banning person or location – basically as if they weren't there. – Though I think there is a highly questionable issue of social sterility to such a solution, it would be a very powerful and appealing tool. The amount of trouble and effort it could save might justify social stagnation. Though my gut-feeling is that maybe to allow for some "in your face" "griefing" as a necessary part of any life, real or virtual. People who do not face such at some point fail to learn to the tools to maturely handle such situations. One of the strengths of virtual worlds, imho, is to be able to interact in a safer environment.
(h) ...for end users.
No comments:
Post a Comment