Executive Summary

The Virtual World Web® is the next stage in the evolution of the World Wide Web - transforming the web from a collection of web pages into an immersive virtual reality universe of business, education and entertainment. The VWW® operates on proprietary infrastructure from the ground up designed to be secure, flexible and scalable. A single browser enables surfing the web traditionally, in 3D and in Virtual Reality.

By bringing together technologies from the web, video games, mobile devices, social networking and Virtual Reality, the vision for the VWW is to represent a single platform upon which companies, governments, universities and individuals can connect and interact in new, unlimited real and unreal ways.

Product description

The Virtual World Web® is a brand new Internet software layer that integrates video game technology with the traditional web. It opens the door for new forms of rich user interaction within immersive environments, and it simplifies and radically reduces the cost of developing multi-player virtual experiences.

The Virtual World Web builds on Unity's vision of democratizing game development and expands it from just games to encompass all forms of social VR development. Our mission is to build and enable a network of 3D environments hyperlinked together in the same way as web sites on the Internet. The platform offers a toolset for creating interactive multi-player experiences that can be as unique as their creators: online games, entertainment venues, social networks, educational environments, services, shopping or even architectural visualizations.

The Virtual World Web® is a software platform for building and presenting engaging virtual experiences. As such, it isn't purpose built to do specific things, but rather as a protocol to enable the rapid creation of any imaginable type of elaborate virtual reality offerings whether they be: in-house VR experiences, client-driven creations, or all imaginable personal or business virtual worlds made by the general public.

Technology

The Virtual World Web platform software is divided into three conceptual layers. Each layer builds on the more generic functionality of the layer below.

Infrastructure layer

The infrastructure layer is the most technical and most generic. It defines the core software components of the Virtual World Web and the way they communicate with each other. The infrastructure layer is also responsible for browser software delivery and update, as well as hosting resources used by the 3D environments. It defines how the system will represent the virtual world at run-time and allow users to meaningfully consume the online experience, whether through a 3D client viewer, or a 2D web experience. The infrastructure layer also implements a JavaScript based scripting system to allow scenes and objects to expose user-designed behaviors.

System components

The infrastructure layer is broken down into five main components

Root Services provides shared authentication for user logon, message routing between systems, notifications of users’ friends status changes, and various system security features. The Root Service can be thought of much like the DNS Root (IANA), or a PKI root trust provider (such as VeriSign), or a little like Microsoft Passport or Facebook Login when it comes to authentication.

A Service Provider represents a company or project providing service on the Virtual World Web and defining world structure, objects, creatures and hosting various physical servers and virtual experience for user consumption. The Service Provider also hosts the web (http) presence for a given system, providing a 2D web view of worlds, scenes, and of the Service Provider itself.

An Instance Host is a component of a Service Provider’s system that accepts connections from client viewers and hosts instances of scenes in the world. The instance host also provides a JavaScript host to run user-designed scripts which add complex behaviors to objects in the 3D world.

A Viewer or browser is a piece of client software that allows a user of the system to view the 3D world. Our reference browser uses the Unity 3D engine and leverages the .NET framework and Google V8 JavaScript engine to provide a rich user experience. It allows world designers to deliver powerful, scripted UI to compliment the rich worlds they build.

The API (Application Programming Interface) is the Virtual World Web’s connection with the outside world. Through it, third party developers will be able to integrate with our system in various ways. Transacting virtual currency, object brokerages (trading or selling in-world items), and 3rd party system integration with VWW applications are all examples of the functions of the API. Our API endpoints are simple SOAP or REST based web-services and use OAuth based security. These technologies are widely understood by developers and myriad tools already exist to facilitate easy integration with our services.

World structure

The infrastructure layer describes how space is represented in the Virtual World Web and defines URL syntax for referring to a given scene. We also implement mechanisms for creating and describing objects (things) in the world, and for managing the current location of instances of these objects.

Briefly, the Virtual World Web is broken down into Service Providers, much like web sites on the World Wide Web. These systems host worlds, each of which can be considered a container for scenes. Worlds can also be nested so that child worlds inherit configuration and access to resources from their parent. A scene is the basic unit of space in the world and is the target of a VWW URL which follows this pattern:

http://<service provider>/<world>/<childWorld>/<scene>#<startpoint>

Entities

Entities in the Virtual World Web are the actors. If World Structure is the “what” then Entities are the “who”. Accounts, Personas, and Social Groups are the most user-visible kinds of entities.

Objects

Objects are the “things” in the world. Object Types (like blueprints) can be created and instances of them can be put into containers which makes it possible for them to be displayed in a scene. At this layer in the system architecture, objects are a fairly abstract idea of “a thing in a place”; little attention is paid to who owns these things, how they got there, who can move or take them, etc.

3D Document Object Model

The 3D Document Object Model (DOM) represents the runtime layout of a scene in the world. Code in the form of JavaScript can be added to the document to affect its behavior at run-time in much the same way as JavaScript code can be added to an HTML document to affect a web page at run-time. The 3D document is saved as a template or starting point for new run-time instances of a scene. When a new instance (room) is created, the template document is loaded by the instance host and becomes “live”. Changes to the document are seen in real-time by all connected viewers (clients), and are tracked by the server. In cases where an instance is associated with a user or group of users, as in a game room or story adventure for example, the current state of the document can be saved at any time to be restored later so that users can continue their experience.

Workflows

Workflows help to formalize and visualize complicated multi-step processes. Built on the Windows Workflow Foundation libraries, our workflow implementation allows for flexible and extensible logic throughout the virtual world web server software. We create workflows for actions like “User Login” and “User Navigate To Scene”. These workflows can then be extended by software in the Components Layer to add business-model functionality to the system.

Scripting systems

The Virtual World Web is meant to be an active world with objects exhibiting complex behaviors and a customizable user interface. To that end, the Virtual World Web provides two JavaScript environments, one for scripting the Document Object Model which runs on the Instance Hosts, and one for scripting the browser user interface.

These scripting systems provide a rich toolset for developers to leverage in extending the world’s behavior.

Software Delivery & Update

The infrastructure layer is responsible for delivering the client viewer software as well as incremental updates as required.

Components layer

The components layer organizes and focuses the infrastructure layer into functional systems that can be leveraged to build a business. The components (or server plugins) here should be thought of as building blocks. They will be the configurable, white-label, flexible, and well documented “features” of the virtual world web platform.

Following are some examples of components that have been already developed:

Creature manager

Is a component responsible for defining the look of avatars in one or another world. Each world can use its own set of creatures, unique with their own animations, body type configurations, end so on.

A set of tools allows world creators to also define things like special titles, entrance effects and chat colors per user group.

Human avatars

If a world designer wishes to use humanoid creatures, they can install this component that offers a set of ready-to-use characters with a set of base animations. Tools for configuring avatar actions is also included.

Virtual currency system

The core of many of our revenue models, this system provides a secure mechanism for the exchange of virtual currency between users for anything and everything from paying for service membership plans with a service provider to buying a property or virtual good, to contracting a service from another member.

Membership component

Is a set of tools for creating and configuring membership types available in a given world. Certain world functionality can be made available to users, who purchased a membership.

World Builder

Provides end user UI for a property marketplace where users can design and market new property types, buy and sell properties, rent properties to each other or from the system, and manage the permissions on their properties.

It also provides a back-end tool for listing things for sale in the Object Mall, configuring store categories, setting prices for individual items.

The Object Mall also provides viewer UI for a virtual goods marketplace.

World moderation

This component offers a set of tools for community moderators, including incident reporting, removing of trouble makers from certain world regions or banning them from the system.

Scene Creation Tools

This component provides UI to help a user work with a scene in design mode. Through it, a user can place objects they’ve purchased in their property and attach scripts to their rooms to give them interesting behaviors. They can also work with environmental effects like light, water and weather.

Clothing designer

Is a tool that can be used for end users for creating new clothing items and offering them for sale to other users. A back-end for this component offers some tools for configuring catalog categories, adding new designs and setting up prices.

Game cloud

Is a set of tools enabling a world designer to write custom mini-games.

Business layer

The business layer is more conceptual than technical. It represents the various enterprises on the VWW. Each organization that wishes to build a presence on the VWW will host a Service Provider, or contract the services of an existing one, within which they will build their world from the components available.

We expect to be able to support gaming, education, entertainment and government applications, and will work to diversify the available components over time to support these models as richly as possible.

Distinguishing Highlights

Given this background on the nature of the platform, some of the highlights that distinguish the VWW from other VR offerings include:

MMOVR

Although solo and small-group virtual reality experiences have their place, the social and commercial nature of VR demands that applications accommodate large numbers of concurrent users. Imagine VR shopping malls, trade-shows, lectures or even concerts – all of these require large, even enormous crowds of people in order to be commercially viable.

The VWW has developed and patented the only successful methods ever deployed to enable large numbers of users to engage with each other and their virtual environment simultaneously. This technology has been successfully used to host the largest Virtual Conventions ever held - almost 20,000 users.

No other VR company has ever come close to delivering these kinds of numbers, as even the most aggressive efforts have allowed only about 100 VR users to be in the same virtual venue at the same time. In addition to unlocking the ability to host large-scale VR regions, our MMOVR technology turns the problem of overcrowding into benefit.

The problem of overcrowded VR regions really presents itself in two different forms. In the first form, computers using any system other than ours will run into problems handling and exchanging the data necessary to create and render the VR scene. This will cause the scene to slow down, lag and ultimately crash. All of these outcomes are bad, and they likely will also cause the user to get a case of VR-sickness.

The other form of VR overcrowding is something that competitors have never even been able to encounter, since it requires solving and implementing a solution to the prior one. This second form is similar to overcrowding in the real world: too many avatars in too small a space leaves insufficient room for everyone. In virtual spaces, it is theoretically possible to cram an unlimited number of users into a location – but this causes all kinds of problems.

Our protected solutions not only solve this form of VR overcrowding, but the solutions result in added value for users.

The VWW platform allows Service Providers to use our Instancing tools to set occupancy caps to their regions. In the most basic form, a region will be set with a “soft” cap and a “hard” cap such that when the number of users reaches the soft cap, a new instance of the region is automatically spawned – and new entrants to the region begin to populate the new instance. Users can still transport into a “full” instance (for example, to visit their friends) until the instance reaches the “hard” cap, at which point no new users can enter unless another user leaves.

In more advanced implementations, other instancing modes can be developed to spawn in accordance to any preference by the Service Provider or end users. The most common examples of this type of Instancing (which is know by users as “Dimensions”) is based on language preference – so English speakers enter an “English Dimension” and Spanish speakers go to a “Spanish Dimension.”

The advantage to this kind of management of overpopulated regions is obvious – users can communicate natively in a language they understand.

Further and alternate kinds of criteria can also be set to spawn or populate alternate Dimensions. For example, to separate: users who wish to abide by real-world laws of physics from those who wish to be able to fly; enjoy non-human avatar forms (like faeries, cars or dragons) from more reality preferring users; or users who are single and looking from those who are not. They can also be set for very practical purposes like putting friends into Dimensions where more of their friends are located or where other people from their real-world geography are present.

The VWW platform has the potential to host large numbers of simultaneous users in what we call a “Massively Multiuser Online VR” (MMOVR) experience. Without this technology, no company can compete in the social VR space; and without Smart Instancing, VR overcrowding would make social VR a miserable experience anyway.

The Curio VR Browser

With a single application, users can connect to billions of web pages. That was the disruptive concept behind the World Wide Web and Mosaic, the first practical web browser.

Today, the VR landscape is a hodgepodge of stand-alone applications which each require effort to learn and use – and which each only offer a single kind of VR experience. Curio is changing all of that – recreating the browser revolution that ignited the Internet.

The primary purpose of a web browser is to bring information resources to the user ("retrieval" or "fetching"), allowing them to view the information ("display", "rendering"), and then access other information ("navigation", "following links"). - Wikipedia

The aim of any modern browser furthermore, is to provide a dependable set of standards on which developers can build applications that provide useful or entertaining services to users.

By definition, a browser does not “come with” content or attempt to influence its appearance; however, when it comes to virtual reality experiences, good looking content can require enormous files that can take a long time to download and install. Because the VWW is a system that operates both the platform and the browser, we have the opportunity to manage downloads and files in extraordinary ways that result in radical efficiencies and a much better end-user experiences.

The first main hurdle that any massive VR system must overcome is delivering content to users quickly. VR files, such as texture files and animations, can be huge. In a social VR setting, where hundreds of avatars may be using thousands of simultaneous animations and wearing hundreds of thousands of items requires a download management system and a recourse serving system, along with a prioritization schema and, ideally, various level of details for each item. Without a well-architected set-up, each VR region could take minutes or even hours to display.

Asset files within the system are generally replicated into multiple Levels Of Detail (LOD’s). This means that each file may have a small, medium, large and maximum resolution; and the system determines which of these LOD’s to display to the end user based on a multiplicity of possible settings. So, for example, a user may see a low LOD clothing texture on an avatar that is far away, and the LOD may change to better clarity as the avatar moves closer. An avatar may appear in a simplified form of a glowing particle effect when the user first enters a new region, but after all the pieces are loaded, the character appears and gets displayed in full detail.

Curio employs a vast set of additional techniques for presenting users with the optimal browsing experience. Optimized rendering minimizes the system requirements by eliminating needless objects from the render pipeline (hidden or obscured objects for example). Cached textures and background file streaming also contribute to the efficiency of the browser.

With all of this happening under the hood, Curio presents a simple and functional User Interface (UI) to its users. In an instantly familiar way, people can engage Curio to see a URL (navigation) bar, a back button and Landmarks menu of their flagged destinations.

Installed components (or server plugins) can add additional interfaces to the screen and virtual world. For example, “mousing” over an interactive element of the scene will transform the cursor into an appropriate graphic, and elements can be clicked and right-clicked to engage functions or bring up menus. Additionally, walking into certain elements (like a door, for example) can engage a function (such as porting the avatar to a new scene).

Viewable area is the premium feature, and therefore, the UI is displayed in an optimized manner, and it can be further adjusted by the end-user to suit their general preferences, or their preference in the moment. Windows can be moved, minimized or resized.

A host of quick-navigation elements allow one-click and intuitive access to the most important functions; and many features that are not typically considered part of a web browser are accessible right in Curio. Many of these features are actually part of the larger VWW system, and thus their functions, or even their display, can be changed based on the preference of the particular Service Provider that is presenting the content.

An entire object creation software package is available, and with a single click, any user can begin to craft items and objects. A similar offering gives users access to a clothing design package that allows them to create new clothing items, or retexture existing clothes (so, users can very easily turn a picture into a T-shirt for their avatar, for example; or advanced users can be virtual fashion designers – all without the need of any additional software).

Users may be presented with a simple “Avatar doll” in the corner of their display, which allows them one-click access to change their appearance; and there are similarly quick clicks to get to: user’s closet, user’s Property Manager, Action options, Settings/Preferences, object malls (to purchase items) and catalogues. The main account information, including account name and the balance held in the users’ eWallet, can also be displayed. (eWallet amounts are denominated in the network’s virtual currency). Optionally a quick bar can be displayed where currently available script actions are easily accessed; and where users can create their own favorite collection of actions.

Although Curio enjoys a special status as the VWW platform browser, it also performs all the straight-forward functions that a state-of-the-art VR application offers. It provides powerful rendering features, programmability, input device handling and a simple navigation process, and ultimately lets the content developer take over the browser frame.

In this spirit the Curio browser implements several powerful areas of functionality which can be leveraged by a service provider’s content (game resources and scripts) to create amazing experiences for end users:

• Software Install and Update: The Curio user experience begins with a simple install process and an automatic software update (patching) facility to ensure users are always enjoying the latest advancements in our technology. This also ensures service providers that their latest features can be enjoyed by our entire installed user base.
• Browser User Interface: Curio provides an address bar for type-in navigation, UI for authentication to the network, a “Landmarks” system for storing links to users’ favorite locations, and settings UI for tuning various browser features.
• VWW Protocol Implementation: Using the VWW Core Libraries Curio is able to navigate to vww:// URLs, connect to VWW instance hosts, and participate in shared virtual reality experiences. Curio also implements a fully optimized and cached streaming resource acquisition system.
• Unity 3D Rendering Engine: As a Unity application, Curio brings the powerful next-generation rendering capabilities of the Unity engine to online virtual world developers. Once connected to a VWW server, the shared views delivered by the server are translated into Unity game objects, appropriate resources are acquired, and the scene is displayed by the Unity rendering engine. Standard Unity file types such as unity scene files, asset bundles, OBJ mesh files, and PNG and JPG texture files are supported out-of-the-box which makes the design pipeline familiar to game developers used to working with Unity.
• V8 JavaScript based UI: With the exception of authentication, and the address bar, all user interface elements encountered by users are delivered in the form of UI script packages by service providers’ instance hosts. A JSON based UI markup language pairs with JavaScript files and resources to create a programmable, styleable, user interface. UI packages are sent by components installed on a service provider’s instance hosts, and so are selectable, interchangeable, and extensible.
• VR Hardware Support: Through Unity, Curio supports the latest VR hardware including the Oculus and HTC Vive headsets, as well as several motion-tracking input controllers and other hardware for interacting in a VR environment. Curio provides simple mechanisms for navigating in VR space as well as for manipulating objects, scene design tools, and more.
• Vivox Voice services: Curio implements the Vivox VOIP voice communication system that, if enabled on a service provider, allows connected users to communicate hands-free, which is especially useful for VR, presentation, teaching, and collaboration scenarios.
• Rich Media Support: Curio can present various cutting edge media embedded in the virtual worlds it connects to. In addition to the beautiful scenes, objects, materials, lighting, camera effects, particle effects and so on enabled by the Unity rendering engine, Curio also enables:
  • Audio in the form of clips or streams can be played into scenes with or without 3D positioning.
  • Video can be streamed into scenes as video materials which can be placed onto 3D objects like video screens.
  • Web content can be projected onto 3D surfaces and remains fully interactive.
  • VR Video can be played back like a VR cutscene, allowing the user to enjoy a wide range of pre-recorded VR content.
• Embedded Web Browser: Curio is also able to display web content in tabs alongside 3D content for various purposes via it’s embedded Coherent browser (an implementation of Google’s Chromium).

World Creation and Management Tools

The web was revolutionary, not because a handful of tech wizards built a few amazing destinations, but because everyone was enabled to create web sites using simple tools – and then to have those sites accessible by anyone else with a web browser.

The VWW platform contains tools designed specifically to enable anyone to create professional virtual worlds and VR experiences. Depending on the level of access, tools can be aimed at Service providers (World Creators), Developers (Content Contributors) or End users.

Service provider tools

This is the most advanced set, giving world creators direct access to the platform’s low-level functionality.

A Service Provider represents a company or project providing services on the Virtual World Web network and defining world structure, objects, personas; and hosting various physical servers and virtual experience for user consumption.

Businesses and organizations can extend their online presence by creating 3D versions of their web sites that people can visit as avatars. A special toolset allows them to develop virtual experiences complete with their own content, rules, animations and creatures. As an example, instead of putting lectures on a web site, educational institutions can bring their students into 3D classrooms to participate in discussions and pose questions via voice chat, or even present reports to the entire class live, in real time.

Licensed developers will be able to develop custom applications, interface components, 3d assets and scripts that then can be offered for sale to world creators through our central app store.

Although not yet offered to outside parties, the tools for uploading assets (that are used to build a virtual world), defining characters and animation controllers, developing custom user interfaces and server plugins, as well as writing custom scripts to make their world interactive – all will be packaged in a Service Provider SDK.

The aim is to make the Virtual World Web server software a turnkey solution for companies or individuals. Interested parties will deploy our software as a cloud service, register their service provider on the network with our central licensing and authentication provider, and begin building their worlds.

Service provider installations will then be further customized by selecting components – a kind of server plugin or extension – from our online central app store. These components add features to the platform, providing the building blocks of real products and services.

Some examples of server components we have already developed include: a detailed end-user Avatar customization process; a clothing design system; a virtual-property rental, purchase and management system; an object/item inventory system; and an object placement and scene editing system.

Beyond these (and many more) obviously required tools, we have also built tools for more advanced commercial and social applications. An example of such tools is the system for permitting or denying entry of a person/Avatar into a location. This advanced user-management tool has application in a wide range of areas. World creators may wish to make areas public or private. They may wish to limit access to regions based on all kinds of criteria (whether the person is enrolled as a student to attend a class; whether a person has purchased a ticked to the show; whether the person is a VIP…). And each type of criteria may have contingencies (for example, even with a purchased ticked, a user may not be allowed in to a venue until a set time; or they may need to be kicked out of a venue after a certain time).

Just learning all of the tools that would be nice to have for a MMOVR platform has taken many years of operations. Building those tools and thereby expanding the commercial viability of the offering has been and continues to be a tremendous development effort.

(This section has only discussed a few examples of the tools that are required and that have been developed for the VWW platform. A complete discussion could take hundreds of pages, though a few of the most essential components will be discussed in separate sections below).

Scripting system

In VR, people, areas and objects need to feel “alive.” In order to achieve this, programed “scripts” must be allowed to act on people, places and things. Enabling this kind of scripting, however, poses risks at many levels – from the user experience all the way to the network itself.

The VWW platform is architected so that the various scripting environments are secured to the maximum possible level, while still allowing the widest range of use. Presently, the scripting system only permits in-house and trusted third-party developers to create and upload scripts, but those scripts can be made available to external development community when appropriate.

Examples of scripts can range from the simple, like enabling a chair to be sat on by an Avatar and allowing an Avatar to buy a drink from a bartender to the much more advanced scripts that change the User Interface itself when an Avatar moves into a different region, or which enable users keep virtual pets that behave like real ones.

Characters

The VWW platform has been designed with the concept that future iterations will need to support all kinds of avatars and environment styles. This means that the system is expecting to host virtual worlds ranging from those in which everything looks like a Disney cartoon to worlds where users resemble photo-realistic versions of Lord of the Rings creatures. The current version of Curio is primarily directed to providing a fairly realistic rendering of real-world-looking scenes and people.

The base avatars are scaled down forms of extremely high-poly count models. The full-resolution models are suitable for staging still frames, but their staggering realism comes at the cost of their files being much too large to animate in a real-time MMOVR environment. Therefore, we have lowered the poly-count to the maximum resolution that is suitable to be rendered.

Service Providers will be able to give their users character customization tools that can be developed to be presented however the creator wishes.

Other existing service provider tools

Each of these items could be discussed for several pages in similar detail as those already described. For expediency of this document, they are simply identified below.

Web Admin interfaces for:

• Persona, Group, Account management
• World space management
• Permissions
• Components install system
• Chat configuration
• Client scripts management
• Redirects system
• Translations
• API management
• Web assets management

Components:

• Billing
• Clothing
• Creature Manager
• Game cloud
• Human Avatars
• Membership
• Vivox (voice chat)
• World Builder
• World Operations (moderation)

Content pipelines:

• Asset uploads (scenes, objects, characters, clothing, effects)
• Animation System and Motion Capture
• Multimedia Integration (VR Video, music streaming)

Developer and content creation tools

Creative members of the community are offered a set of tools that allows them to upload their creations into the system and offer them for sale or personal use to other users.

At the moment we have two systems that support user-created content:

• Clothing Designer
• Object Workshop

The system was developed with the expectation that tools will be added that eventually allow the uploading of user-created scenes, deco layouts, clothing meshes, animations and eventually scripts.

End-user features

Character Customization

A core concept of Social VR is that users do not see real people in the same way that they do on a video call. In other words, participants see other users’ Avatars, which is very different from seeing the people themselves. For one thing, the actual people are wearing VR headsets. They’re also not making realistic movements that can translate into the virtual world (for example, people take much smaller steps, they fiddle with their hand controllers, they step over and around cables…)

Because everyone is viewed as, and views others as avatars, Social VR requires an extensive system to allow individuals to create, modify and clothe the various avatars they use to when they engage their various VR activities. Once it was enabled, this system opened up an entire industry that communities have formed around at every conceivable level, and which already provides value to all the beta-users in the community (and generates considerable commerce and real-world revenues.)

On top of allowing end users to customize their avatar, Service Providers can give their users access to a set of tools for creating clothing and accessories for personal use or for sale. Fashion designers can upload clothing, jewelry, tattoos or other accessories to the system via a special tool, which can be made available to all end users or selected groups, depending on the Service Provider’s business model.

Clothing items can be created and designed by users of the system now, but clothing meshes are only added by authorized staff. Minor development is still required to automate the pipeline to allow uploads of user-created clothing meshes to the system. The pipeline will perform and facilitate many functions including: 3D model will be first authenticated and the file size assessed; disallowed types and sizes will be rejected. Approved objects will then be ready for further configuration and customization (such as adding textures, normal maps and other types of materials; specifying textures for each part of the clothing piece: for example, jacket, shirt and tie; uploading model and texture qualities for each Level of Detail).

From there catalog setting can be configured: the quantity they are making available, the price, who can obtain their objects (friends, VIP customers, the general public…), and whether the object can be modified or packaged with other objects to be sold by stores or other designers (this would allow a shirt from one designer to become part of a 3-piece suit made by one or more other designers, which could be put together by a fashion consultant with a store, who might then sell the whole ensemble together, with each designer getting their royalty share).

The object-pipeline is one of the plugins that extend the functionality of the VWW platform, and it is designed to encourage collaborative and complex commerce and offerings for VWW users and entrepreneurs. Most of the value is hidden out of obvious sight, with only simple user interface front-ends and sales report back-ends ever being visible to end-users.

The final step of the clothing object pipeline, as far as users are concerned, is getting the clothing they want into their accounts and onto their avatars. Different ways to present objects to end-users for their consideration and use can be developed by the Service Providers.

Within closets represented as a part of a GUI, users may then be able to customize the arrangement and view format of their search results, with objects that are of interest easily displayed as fully rendered 3D objects in mini-viewer (almost like a hologram within the catalogue). With a simple click, users will be able to purchase available items.

For users who wish to shop for their clothing and similar virtual possessions by going to stores or a mall, those experiences can be built to look and function as a world creator wishes.

Once clothing items are purchased, they are immediately made available to the user in their personal Closet. Users’ Closets can be made available to be organized in accordance with the custom desires of each user. Users can sort, filter and search their own items in almost unlimited ways; and to make virtual clothing and items even more fun, they can save their own ensembles for easy future use. In this way, users can dress themselves with custom skin, hair, tattoos, earrings, jewelry, shoes and clothing – and then use the outfit immediately or save the “outfit” for future use (or both).

One final note about users’ Closets is that unlike real-world clothes, virtual clothes don’t wear-out (unless they are designed to do so). Users will retain every item of clothing they ever purchase (unless they delete it), which not only adds value to virtual clothes shopping (imagine her being able to check if the top she is considering buying matches the shoes that she got last month), but it also adds a “stickiness” to the network – since purchases retain permanent future value, but only to the extent that the user remains a member of the VWW.

Portals and Transportation

Navigating an avatar around a virtual reality environment can be tedious – especially when the size of the virtual world is not only big, but potentially limitless.

Whereas today’s VR spaces are typically so small in size that a user can navigate the entire experience simply by walking around; an entirely different system for getting around is required if users are going to be able to enjoy a vast VR landscape. The VWW platform not only solves all of these navigation problems, but it provides innovative opportunities for advertising and revenue generation alongside improved user experiences.

Using a system of hyperlinks and location landmarks, users of Curio can portal from one location to another simply by clicking a linked door (or transport object). With the powerful scripting system, however, the simple VR teleportation system has the potential to do much more.

Under the VWW’s proprietary and IP protected systems, virtual doors and portals can be designed to allow smart teleportation. This means, for example, that a single door may port different people to different places, or it could port the same person to different places depending on any of a multiplicity of factors such as: the time of day, the last place they went, what friends they have online, what shows they’ve purchased tickets to, or even what unit of the virtual building does the system know they’re going to (like their personal apartment).

These kinds of features would be at the core of any possible VR search-engine. Moreover, they are essential in order to enable functions that are as rudimentary as a virtual elevator or as sophisticated as a dynamic pop-up store front that shows a different store to different people in the region depending on things such as: their gender, their age, their virtual currency account size, or their prior purchases and expressed interests. The features would even allow a store to A/B test different “showrooms” and “offers” by transporting different users who share similar characteristics to different versions of their same virtual store.

Transport object clicks will be tracked and associated with audience metrics and demographic analytic tools to display reports for world creators and advertisers; and they can be made to generate things like invoices (if advertising traffic is being purchased on a per-click basis).

Social features

An entirely different mechanic for getting around the VWW’s massive social VR environment centers on user relationships.

In addition to wanting to transport to a multiplicity of possible virtual world destinations, users of social VR worlds demand the ability to locate and transport to friends, people and groups. A sophisticated social-relationship tracker must be built into the foundation of any platform that holds itself out to be a social VR environment.

The first step for users to begin their Virtual World Web experience, once they’ve installed Curio, is to set up and customize their first avatar. This avatar will not only get its appearance crafted by the user, but it will also become a vehicle for the user to interact with their first virtual community. In so doing, users begin to develop their social relations and online persona. A single persona, however, can very quickly prove to be too constraining to be used for multiple social VR experiences. After all, VR is wonderful as a communications tool to hang out with real-world friends and family; but it may not be desirable to give the entire family the ability to follow your every virtual move. Some personas may be useful for school, others for social settings and still others for business, adventure or recreation.

The VWW platform was designed to enable individual users to obtain and maintain multiple avatars; and it can accommodate data separation or sharing between and among those “sub-accounts.” Thus for example, clothing may, or may not, be permitted to be shared by multiple sub-accounts of a single user. Similarly, friend relationships (and “ignore” relationships) may or may not be applied across sub-accounts. The ability to enable and manage sub-accounts by the system gives users the freedom to explore the entire VWW without fear of being virtually stalked, judged or tainted. Even so, because these accounts are all connected by the root server, the VWW network is able to apply conduct and permissions to every appropriate sub-account. This gives the best of both network and user security, and user freedom and optional anonymity.

Critically for a social VR platform, the system accounts for and manages multiple tiers of relationship connections. Relationships can be tied to the root-account of the user or, even more fundamentally, at the global network level; while other relationships can be established at the level of the embodied avatar. Relationships can also be bound to groups, locations or Dimensions.

When a user is browsing with Curio, they will encounter other avatars. A simple click on an avatar brings up a menu of possible interactions that can be performed. One fundamental function is to request that a friendship relationship be established. As with all similar interaction requests, a dialogue box will appear on the screen of the other party asking them to accept, deny or “consider later” the request. Acceptance results in the establishment of a two-way relationship. This will put the new friend’s name onto the “Friends” list. It allows the user to see when the friend is online (if not hidden), where the friend is (the current region within the VWW), and it allows the users to transport to each other’s location with a single click. As with most lists on the network, the Friends list is a quick-item for setting permissions such as who is allowed to enter your virtual properties, who may view your posts and pictures, or who may send you messages.

In diametric contrast, users will encounter avatars that they find obnoxious, and with whom they do not wish any interaction. Through the same mechanism, uses can opt to “ignore” another avatar. This adds the avatar to the user’s personal ignore list (which can be managed through the simple interface, so this action can be undone). Once on the ignore list, the avatar will no longer be visible to the user, nor will their chat be presented to the user. Account-level ignores will prevent the ignored person from contacting the user in any manner whatsoever through the system (so, no web-messages, no offline gifts, no sub-account contacts…). This simple but powerful tool gives the power of first-line grief management to the individual users and the local community. Disruptive users are quickly shunned and ignored by everyone in their region, and thus the disruptive behavior is generally stopped (and the user typically learns that they do not get attention from their activities and modify future behavior or simply leave the platform).

Communication is at the heart of any social platform, and the VWW platform contains a powerful real-time chat engine specifically architected to suit the needs of a massive Virtual World Web network.

The primary chat display usually shows the public conversations from all avatars that are located in the same location as the user (who are not on the user’s Ignore list). In addition, chat design can be extended to allow people with certain permissions be placed into the display (for example, the chat from a Performer appears to local chat displays in all Instances of a region – even if they are on stage in a different Instance; chat from a Moderator or Staff member, or global announcements, may appear in the local chat window). The chat windows may additionally be enabled to allow posting of hyperlinks, pictures, videos or other meta-media content. User’s names are typically clickable in chat, enabling users to quickly bring up interaction menus.

Chat windows maintain a history of the chat during an active session, so even if the user is multitasking, they can scroll back in time to view missed chat.

In addition to the local chat, users can send private messages and have private conversations to other users and groups of users. A minimally intrusive flashing notification alerts users to the arrival of a new message or private message (PM). Whereas the local chat window is tethered to the specific current Region and Instance of the user, private conversations can take place with two or more users, regardless of their locations. The VWW network routing protocols govern the rules for allow messaging within a single Service Provider’s network and across networks. Therefore, when permitted, users can create or join group chats; and those chats can persist even as the avatars move around the VWW.

The VWW platform is an ongoing product of more than 13 years of development, with an average of about 40 full-time staff dedicated to its realization. There are so many features and systems, particularly in the areas of community and social functions, that a comprehensive description would take volumes. The remainder of this section, therefore, will just touch on several of the more prominent system offerings in this area:

Voice chat: While text chat is a very useful feature for a social VR platform, voice communication has some very specific uses and advantages. Curio offers VOIP in which users can enable VOIP to listen and talk to the users in the local Region and Instance.

Names and Name tags: In an MMOVR environment, users will not always know the other avatars by sight. The platform allows for the display of avatars’ names above their heads for easy identification. In addition, the names can be accompanied by graphics and/or name tags that are earned or assigned to avatars. Badges (and the name’s color and any graphics) can be used to indicate the status of a user, such as whether the user is a standard user, an owner or employee of the local Region, a staff member of the Company, or an upgraded user who has purchased, earned or won upgraded status.

Web View: A web-based social center was a prominent feature of the prior version of our virtual world software. The plan for the new platform is to use a web-based component as a link between the virtual world network and the Internet. Indexed and searchable by traditional web browsers, so-called Web Views will be a representation of the virtual environments on a web page. They can display any information the Service Provider decides to share: a list of people currently online at a certain virtual location, a calendar of events at that location (or their entire world), and so on. The idea is to advertise a virtual place on the web and offer a simple way to join the experience in VR.

Virtual Currency: With the traditional web, eCommerce was slow to be adopted and to mature into a vital component. Even still, online payment systems are largely designed for obtaining payments from customers to merchants, with peer-to-peer payments still not fully adopted. This can be attributed to the basic nature of the web as a one-to-many experience, with group experiences only really taking a form of non-real-time social networking sites. Real-time group interactions are available, but they are a small component of most people’s web browsing.

In environments where people interact with one-another as a primary activity, easy commerce is always essential. The demand for simple and universally available transactions requires any MMOVR platform to have an extensive eCommerce system.

The VWW platform was architected with a ubiquitous eCommerce system in mind as a fundamental feature. Every user has immediate access to a virtual wallet into which they are credited with virtual currency when it is earned or received, and from which they can send virtual payments if their account is authorized with the necessary permissions.

Currently, the platform uses a global world-currency called, “Rays.” Rays® are created and destroyed according to a Central Banking system that is operated by the Company. The Central Bank has the ability to set a price at which users can purchase Rays directly from the Company’s system account. This system-account is supplied with Rays that are generated from the Company’s activities in operating the platform such as: rental commissions from virtual properties; sales commissions resulting from purchases through the clothing system and object malls; the purchase of web and world gifts from and to users; business and sales licenses obtained from the Company by users; and other similarly municipal and operational virtual payments by various aspects of the user base.

Similar to the charter of real-world central banks, the Central Bank system allows the virtual economy to be tuned using an array of tools designed to maintain a stable value of the currency, maintain an appropriate money supply, and ensure the overall health of the virtual economy is maintained. Generally, the front-line tool is the online Virtual Currency Exchange where users buy and sell Rays to one-another.

The Exchange can be viewed by any member of the network, but only validated users have the necessary permissions to conduct transactions. Currently, members can obtain the permission to purchase Rays from the Exchange simply by establishing an account and validating that account with authenticated payment methods that pass multiple levels of security (accounts must pass our internal system checks, and a third-party anti-fraud scrub).

Once the member’s account is validated and approved, they can purchase virtual credits for their Trader Account. Trader Accounts are simply denominated at one-credit for every one-dollar (US) that is spent. These Trader Account credits can be purchased using any of the approved payment methods up to certain daily and periodic limits (which can be increased by a customer support agent on a per-account basis to allow more trusted accounts to transact larger amounts or with greater frequency).

Once a user has a confirmed balance of credits, they can then place a bid to purchase Rays on the Exchange.

Users enter the number of Rays they wish to buy and the price that they are willing to pay. If the bid is at or above the lowest “asking” price, the order is partially or fully filled as appropriate. Rays are transferred from the System Escrow account to the buyer’s “Bank” Account (this is the user’s account that is denominated in Rays); and credits are transferred from the System Escrow account to the seller’s Trader Account (after the Exchange fees are deducted and sent to the Company’s system account).

If a bid is made that is below the lowest asking price, the bid is entered onto the Exchange at the bottom of a stack that is ordered primarily from highest to lowest offer, and secondarily from oldest to newest offer. Regardless of whether the bid is immediately filled or not, the necessary credits to fill the bid are immediately deducted from the buyer’s Trader account and placed in escrow with the Company to ensure the funds are available if and when the bid is filled. Selling Rays essentially works using the reverse of the process, with offers being filled when the bid price matches the ask prices, and credits and Rays being moved to and from the System escrow accounts to the appropriate account of the seller.

Additional features of the Exchange have been created to minimize potential fraud, follow the distribution of Rays from buyer’s accounts into the community, set the spread, prevent price swings or market crashes, and to automate many of the daily processes undertaken by the Central Bank.

The system supports custom and proprietary anti-fraud programs that alert our World Operations department to suspicious flows of Rays between accounts. Patterns of transactions between accounts are indicative of fraud, and user accounts may be frozen and investigated using the Support Admin. The system is designed to prevent excessive amounts of Rays from being listed on the exchange by any individual user over set time-periods. (Amounts larger than these limits can be manually exchanged for approved accounts by support staff).

The Exchange is currently operated with a Spread of 0.005 Trader Credits per Ray. Users can bypass the Exchange and purchase Rays directly from the Company account at a Spread currently set at 0.01 Trader Credits. The Central Bank system currently uses the credits received from these transactions to purchase Rays from the Exchange. This serves the function of maintaining a constant level of money-supply in the economy. The 0.01 Trader Credit per Ray translates into a roughly 14% profit in real-money terms, and that profit is booked.

With this understanding of how a process of obtaining and managing a network-wide virtual currency is handled, we can explore some of the more extended features of the currency system.

A network-wide virtual currency is carefully managed to ensure a stable value and the overall health of the virtual economy. While there is a clear need for this universal VC; but there are other needs that local regions of the VWW have which are not well served by such a universal VC. Local regions may wish to offer rewards to their users for performing actions or otherwise participating, and they may want to allow users to redeem those rewards for virtual goods and services within the local region; but they may not wish to (nor would it often make sense to) purchase Rays for these purposes.

By establishing a wide-ranging virtual currency system that operates in a secure manner and that is extensible and system-wide, the VWW is designed to allow developers to produce a wide range of offerings. World creators that use the platform could use the VC system to offer users things like loyalty-rewards points, store-specific to region-wide gift cards, casino chips, tokens, experience points or game money to be used within their own local environment; along with more universal VC’s that can be used more widely across the network.

Virtual Properties

One of the server components that can be installed by a Service Provider is a World Builder – a set of tools that introduces an idea of virtual property ownership into a virtual world. This is a primary component of the Company’s own current offerings, and thus it has been developed and operated for our own in-house use as a beta-testing Service Provider.

Although the implementations discussed can be modified to suit the needs of other Service Providers, in our own use, users are presented with a Property Catalog that allows them to obtain pre-fabricated regions, and to build those regions out into fully-functioning VR destinations. These destinations can be relatively simple, as suitable for personal use; or they can be extremely elaborate and detailed at a level suited for governments, universities and Fortune 500 companies.

Depending on the business model, property rights can be purchased and a recurring fee can be charged; or some or all properties may be offered free of charge.

The back-end manager allows the creators of properties to assign prices and to set other limitations and criteria (such as whether the property is a limited release, available to only a pre-set number of buyers for example, or unlimited and available to anyone). A royalty rate can be set by the Service Provider so that a portion of the purchase price and ongoing rent is paid to the property designer, with the remainder going to the SP.

The Property Manager back-end allows for the system to automatically bill the user on a periodic basis, and it can ‘lock’ the property if the rent is not paid.

Users can be presented with a range of permissions and settings that they can employ to control who can visit, and, critically, who can make changes to the property. In the short-term, the Company plans to develop another server component - the Decorator System, which will enable the cottage industry of virtual world “Decorators” to build out VR properties in a similar way to how webmasters can be hired to construct a web page for a third-party. In this way, companies can source professional world-builders right from the VWW community and bypass the need to hire and train in-house talent – though that is always an option.

The collaborative construction will allow the property renter to give a variety of types and levels of permissions to decorators. Decorators will be able to use their own objects or those of the renter, depending on the ownership and rights held by the various parties in the various objects. Multiple decorators may be permitted to work on the same property, and multiple versions of the same property may be created and saved.

Properties can be assembled together to form larger environments and even entire virtual worlds. Various points within the various properties can be actuated to form “start-points” where users enter the region, or to transport users from one property to another (as when walking through a door or into an elevator).

The security environment ensures that the owner of each level of object is tracked and properly compensated. Thus, regions can only be built from objects that have been acquired or made available to the builder, and only in the quantities that are permissioned. Decorators without the appropriate level of permission may be prohibited from changing certain core aspects of the virtual space; and Decorators with sufficiently high permissions will be able to delegate tasks by granting appropriate permissions to their underlings.

Other examples of large user-facing sets of features (which are developed and already deployed, and which could similarly fill many pages) include:

• Virtual Shopping System
• Scene Editing tools

Platform Comparisons

The Virtual World Web is unlike any stand-alone VR experience. It is also very distinct from game engines or other VR development tools or service offerings. This section discusses these distinctions.

Compared with a game engine

It is important not to confuse the Virtual World Web as a platform, with a specific memorable game or VR experience, or with the game engines they are based on. Game engines such as Unity, Unreal, Source, etc. are a set of code libraries and usually some kind of integrated development environment used to render 3D environments, special effects, and animated characters. They also often provide helpful art pipeline tools, code templates, and pre-implemented logic (patterns) to make game development easier.

In the VWW context these technologies make up only the presentation layer of the client part of the system. In other words, a VWW client uses -- or is built on – a game engine to render its view of the scene or user experience it’s participating in. In the case of our reference VWW browser implementation, Curio, the Unity game engine is being used for 3D and 2D UI rendering.

As a rule, “networking” is an after-thought in most game engines, as they are focused on rendering technology. At best, most include some kind of wrapped sockets implementation, sometimes with simple LAN or server-based “multi-player” modules to help game developers implement FPS or RTS style tournament modes. This means that game logic is integrated into the client application which cannot be trusted from a security point of view.

The VWW on the other hand provides an always-on virtual world hosting platform to which client applications can connect to engage with “instances” (scenes, game areas, or other shared experiences). The platform is fully programmable both through scripts which run in instances, or through components that extend the server’s core functionality. Service providers can develop full-scale MMO-style products that leverage the VWW’s extensive networking capabilities, built-in security, data storage facilities, and other well developed features.

Compared with existing MMO back-ends

There are several successful MMO games on the market, all of which have custom server infrastructures and backend software that coordinates their gaming experiences. While many of these systems are impressive, they are all purpose-built, meaning that they are designed to do one thing. You could not use the World of Warcraft client to connect to The Sims, or Star Wars: The Old Republic, or any other game world because they all speak different protocol languages, represent the worldspace differently, handle security differently and so on.

The Virtual World Web server software is designed to be extended by a world creator to implement game or experience specific logic, while leveraging a powerful “Core” set of networking, security and scripting features that are consistent across all worlds. This approach makes it possible for a VWW browser (such as our reference browser Curio) to connect to and consume the content of many service providers.

Compared with game server hosts (Photon, etc.)

There are service offerings that claim to provide “drop in” networking services to game developers, and while these services may look impressive at first glance, they are generally just glorified packet relays. In other words, they provide you with a “server” that your game can connect with and use to exchange data such as game state, audio, chat and so on. But these services do not provide you with a programmable or extensible backend. The server your game client connects to is essentially a dumb relay.

While these services can certainly be used to build simple traditional First Person Shooter (FPS), or Real Time Strategy (RTS) games, they fall far short of the kind of programmability required to build truly shared experiences that persist beyond a single “game” or skirmish. For users to build, collaborate, share, shop, and more, you need cloud services such as data storage, scripting, server extensibility through components, permissions systems, and many others.

As a compliment to Unity

From the beginning the Virtual World Web has been a spiritual cousin of the Unity 3D game development system. Indeed, we chose Unity as the foundation on which to build Curio because it is cross-platform, powerful, feature-rich, and has a thriving developer community already familiar with its art asset pipeline.

Unity’s stated mission is “To Democratize Game Development”. They aim to abstract away the complexities of targeting different end-user platforms and let developers focus on building great games. Similarly, the Virtual World Web aims to abstract away the complexities of building massively multiplayer networks, handling network security and encryption, scaling to meet product growth demands, and more. Thus a service provider or game developer can focus on building great content, and scripting engaging experiences, rather than the nitty-gritty of low level network protocols, security systems, and data storage.