University of Arkansas – CSCE Department
CSCE 4013 Virtual Worlds – Final Report – Fall 2010
Virtual World Reference Architecture
Christopher Dempewolf, Pate Motter and Abraham Lopez
Abstract
As Virtual Worlds are a new aspect of pervasive computing, the information base for the different platforms is lacking. In order to begin to solve this problem, research and information gathering is required into the many of the lesser-known and/or lesser-used Virtual Worlds. To this end, a team of three was tasked to begin performing this research into three different Virtual Worlds (realXtend, Unity and Open Cobalt). The resultant findings for these three Virtual Worlds were varied, as the stability of each platform was at different stages of completeness, yet sufficient enough to enable at least some final analysis to be stated. Ultimately, each researcher was able to evaluate the high to mid-level state of their respective Virtual World, begin to construct a base vocabulary and architectural definition, and finally to conclude the programming worthiness of using their particular platform for future projects.
1. Problem
As the concept of Virtual Worlds is relatively new in the field of computing, the subsequent documentation, terminology and information concerning Virtual World platforms is mostly lacking. For any commercial, educational or research institution that plans to utilize a Virtual World, this lack of information means the investment of time and resources in not only familiarizing itself with a specific Virtual World, but also evaluating whether the Virtual World has the capabilities required to perform the tasks the institution needs to achieve its end goals.
2. Objective
The objective of our project is to begin the process of establishing viable reference architectures for the Virtual Worlds realXtend, Unity and Open Cobalt. Through this research and information gathering, we can then recommend whether further exploration of one or all of these Virtual Worlds is appropriate for any further projects set forth by the University of Arkansas.
3. Related Work
3.1 Context
Everything is Alive is a concept that describes the evolution of pervasive computing that involves the use of modern and the evolving technologies such as RFID, sensors and wireless communications[1]. With the combination of these technologies a future is envisioned where all objects in real life are “smart” objects. Furthermore, all these objects communicate with each other so as to drastically change the lives of the human population that use them. Rather than manually changing a setting on an individual object, such as a thermostat, the user simply gives the object a command. Beyond even this type of communication, however, these objects are programmed to evaluate a situation and change their setting accordingly, without being instructed to do so by their users.
Though the modern world is rapidly becoming more capable of fulfilling this vision, the full realization of Everything is Alive is not yet possible in the real world. Thus, a substitute world is needed in order to not only visualize what such a world would be like, but also to further innovate and research both the benefits and pitfalls of this concept. Virtual Worlds are just such a substitute, in that they enable their users to create environments where objects, regardless of size, shape or function, can be enabled with “smartness”, and can be vetted while the development of the actual, real world object is produced. In researching the new and relatively lesser-used Virtual Worlds of realXtend, Unity and Open Cobalt, our team can evaluate how appropriate a particular platform would accommodate the perpetuation of the Everything is Alive concept.
3.2 Key Technologies
Our work was much more concept-based and did not rely on any specific technologies, rather it was to study the existing technologies available in virtual worlds and compare and contrast them.
3.3 Related Work
Our primary sources of reference for our project were the wikis and tutorials on our respective platforms and Second Life [3, 4, 5, 6]. If there had been any documentation or work from previous University of Arkansas students in this particular area, we were unaware of it.
3.4 Related EiA Projects
Our projects on Reference Architecture relates (or could relate) to these other EiA projects:
· My Immortal Avatar – In order to determine what platform would be most appropriate to sustain and accommodate an Immortal Avatar, research into the reference architecture is a necessity.
· Stutterbots – In designing a bot that will satisfy the goals of this project, the world must offer scripting, speech processing and object creation that fit its parameters. A reference architecture can help in identifying which Virtual World is the most capable of accommodating this type of project.
· Home Healthcare – In order to design an environment that shows the innovations and benefits of a Home Healthcare system, a reference architecture would be needed to show the suitability or advantages of one Virtual World over another.
· Virtual Campus – As with the Home Healthcare project, a virtual campus layout would be best designed using the Virtual World that is most capable of meeting its requirements. With the use of a reference architecture, choosing between different Virtual Worlds would be made more easily.
· Workflow – Workflow projects would likely need an extensive, robust scripting language and accurate physics simulation among others. A reference architecture would take into account such use cases and see that future virtual world implementations would support workflow applications.
· Ontology – Ontology projects would also likely need a robust scripting language and querying capabilities which would be accounted for in a reference architecture.
· Mirror World application – Mirror world applications would make use of content creation features, scripting capabilities, among others. Again, the former would be accounted for in a reference architecture.
· Augmented Reality – An augmented reality project would benefit from the requirements set forth by a virtual world architecture.
· Smart Object Communication and Soft Controller – An interoperability requirement would take into account smart objects such as smart phones, seeing that virtual world applications run on a variety of hardware/software types.
4. Architecture
4.1 Use Cases or Requirements
Use cases for a reference architecture abound. In essence everything related to virtual worlds would unduly benefit, since, after all, the reference architecture itself takes into account use cases in order to construct an ideal set of requirements for virtual worlds to meet in their architectures. Virtual worlds based on an ideal reference architecture would be more efficient and compatible to end-user needs.
4.2 Tasks
- Our goal was to understand the requirements needed in a Virtual World Reference Architecture and to become familiar with our platforms and virtual world community in general.
- We did so by experimenting in and documenting different virtual world platforms (Pate was assigned to Unity3d, Abraham to Open Cobalt, and Chris to realXtend).
- The design of our project was as follows:
a. We each chose our platform and began getting a feel for it and taking notes on different factors and functionalities that our system offered and how they were implemented, which we we would later use for comparison.
b. Our next goal was to develop a glossary of key terminology commonly used with virtual worlds; however, this was eventually done through crowd sourcing the class.
c. Using Second Life as a baseline, we noted different points of comparison (e.g. terminology, representations for avatars and objects, scripting, etc.) between each platform.
d. The next goal was to develop a modular hierarchy of requirements for the reference architecture by examining the comparisons we made to determine favorable functionalities and use cases. This, however, still remains to be completed sufficiently.
4.2 Architecture/Design
The overall design of the project was for each of us to gain basic understanding of virtual world architectures through the perspective of our respective system versus Second Life and also to determine if another platform would be more suitable than Second Life for various purposes. We were then to compare our findings to gain an even broader perspective. Overall we learned common virtual world terminology, functionalities, and what would be required in a virtual world reference architecture.
Chris was responsible for learning realXtend. He did so by testing out different features offered by the realXtend platform (e.g. basic movements and controls, content creation and scripting, chat, loading meshes, etc.) and studying documents on the platform's design.
Abraham was responsible for learning Open Cobalt. He did so also by testing out its features, documenting them, and comparing/contrasting them to Second Life. He spent much of his time becoming familiar with Squeak, the scripting language that Open Cobalt is written in, and evaluating the functionality and stability of the virtual world's Alpha version.
Pate was responsible for learning Unity 3D. He did so by creating simple, working worlds and learning the syntax of Unity 3 with the overall purpose of determining the feasibility of using the Unity 3D game engine to create one's own worlds for arbitrary use cases as opposed to using a predefined world such as Second Life.
4.4 Testing
As our project did not consist of any hard code or explicit results, the “testing” phase for our project was immaterial in the sense of trial and error or experimental observations; however, we have developed an incomplete and haphazard list of some potential requirements for the virtual world reference architecture which should be reviewed to determine if they should remain, be modified, or to determine what else needs to be accommodated for.
5. Results and Analysis
The results of our project did not yield necessarily palpable results (such as code); rather, the results of our project provide an overview of current virtual world architectures. Analyzing these gives insight into some possible requirements of a virtual world reference architecture.
Functional
· Scalability: A virtual world should be capable of handling any number of objects in the scene from a single entity to mass gatherings; moreover, it should do this without dramatically affecting performance or bandwidth.
· Open source: Open source platforms are favorable in that developers can simply modify the existing code to make any desired changes.
· Standards: A virtual world should have support for all existing standards in messaging, object representations, scripting, audio, etc.
· Interoperability: Ideally a user should be able to seamlessly travel from one virtual world to the next.
Nonfunctional
· Modularity/Extensibility: In a modular virtual world architecture, functionalities can be easily added or overridden to meet end-user desires. That is, each functionality is distinct and has a minimal dependency on other functionalities.
Furthermore, key terminology associated with virtual worlds could be deduced from our findings, but a more comprehensive list was obtained through crowd sourcing the class on the Workshop on Extensible Virtual Worlds (X10) Workshop Summary Report [7].
6. Conclusions
6.1 Summary
Virtual worlds are a new, burgeoning area of computing; thereby, there are relatively few standards in place. Current virtual worlds are often implemented as monolithic pieces of software, which makes them difficult to extend and run arbitrary applications. Through our research this semester we have learned that many current virtual world architectures are implemented very disparately, and that a favorable architecture is one that is robust and extensible. Modularity in the reference architecture would solve these issues, since functionalities implemented as modules would be easier to update and have less dependency on the rest of the system.
The applicability and practicability of virtual worlds is large; they can be used as a social medium, game engine, for remote conferencing, simulations, etc. As they evolve the number of applications will increase. For example their current capability as a Web browser is limited; one would be more inclined to use a standard browser such as Firefox for it's extensions and such. If they are to be adopted for wide-spread purposes, then they will need to conform to a set of standards and be implemented based on an ideal reference architecture.
6.2 Potential Impact
There is now a substantial effort to standardize virtual worlds and develop a working reference architecture. Our work should provide a good starting point for anyone interested in contributing to this effort. We have collected a fair amount of data on our respective platforms which could be used either as a brief overview to each system or be reviewed to determine commonalities among the systems or functionalities that may prove useful for consideration in said architecture (e.g. developing requirements). The end goal is to have more modular, component-based virtual worlds on which arbitrary applications may be implemented and less static, monolithically-built worlds. We hope that our research will provide some contribution, however minor, to this movement.
6.3 Future Work
One could look at research as a sort of dichotomy : research to learn preexisting information (i.e. it produces no new knowledge; only aggregates it from the researcher's perspective) and research that yields novel information or data. The research we have done this semester consists of both, but mostly of the later. We spent our time learning new platforms and comparing them with Second Life as described above. That is, we have compared two sets of preexisting information to produce some novel information (what one can infer from the terminology and concepts of our systems compared to Second Life). We hope that our work will provide a means or incentive to many an end.
We have each compared our systems to Second Life, but have not combined our findings to produce a matrix, so to speak, of comparisons for all of our systems together. This should be a relatively simple task, as the information has already been collected. At this point, one could add dimensions to the vertical or horizontal (platforms vs. dimensions of comparison) axes. Since we have surely not gathered all the possible information on our systems that we could have conceivably gathered, one could add more information to the dimensions of comparison axis (e.g. Chris never successfully created his own user-defined module for realXtend nor successfully got his own Taiga server running); however, it may prove more fruitful if one adds to the “platforms” axis (e.g. OpenWonderland, OpenSimulator, Blue Mars, WoW, etc.). This would give a broader, high-level overview of systems' core functionalities and the way each implements them – useful for reference architecture research.