Virtual Environment System Layered Object Model Manuel Oliveira
3rd Author
University College London 3rd author's affiliation Department Computer Science 1st line of address Gower Street. WC1E 6BT London, UK 2nd line of address +442076793876 Telephone number, incl. country code
[email protected]
ABSTRACT The current development trend concerning online games and virtual environments has and continues to yield monolithic solutions, which are responsible for the wide proliferation of system implementations. However, there is much overlap of functionality, but the adopted design principles make reusability unfeasible, representing a significant waste of resources. This paper presents an alternative novel approach based on a layered object model, addressing the pitfalls associated to the existing systems. The approach relies on object-oriented methodology coupled with component layered design to system architectures. The aim is to design and implement systems that promote reusability and flexibility, thus allowing system construction based on smaller building blocks.
3rd E-mail
renowned hallmarks. For the purpose of this paper, Cyberspace implies the creation and maintenance of an alternate reality where people are able to come together to work or/and play. When considering the factors contributing to Cyberspace, one may associate the problem domain to the three tiered framework illustrated in Figure 1. The first tier represents the network that is responsible for providing the global connectivity according to a particular service model, thus connecting any system to the rest of the world. The second tier corresponds to the system responsible for creating a shared experience that engages the user’s senses. Finally, the last tier is the user, who forms their internal mental model taking into account both the input/output signals of their senses. This paper focuses on the second tier, namely the system, but taking into account the other two tiers as necessary.
The proposed methodology revolves around a four layered object model consisting of a universal platform, networking, middleware and application. This paper presents a solution for the universal platform – Java Adaptive Dynamic Environment.
Categories and Subject Descriptors D.2.11 [Software Engineering]: Software Architectures – data abstraction, domain specific architectures, patterns Figure 1 - Overview of the infrastructure architecture
General Terms Design
Keywords Virtual Environments, online games, component frameworks, cyberspace.
1. INTRODUCTION There are many interpretations with regards to what the vision of Cyberspace represents, but the majority will agree upon its essence and relate to the rich imagery conjured by cyberpunk literature of which Neuromancer [4] and Snow Crash [11] are Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ACE’04, June 3–5, 2004, Singapore. (c) 2004 ACM 1-58113-882-2/04/0006 5.00…$5.00.
The paper is divided into seven sections. The next section will discuss the difference between the online games development process and the research involved in virtual environment (VE) systems. In section 3, the paper discusses two case studies concerning shortcomings in system development, one from the games industry and the other from the research community. The study of the pitfalls concerning the current trend of system development is described in section 4. This paper presents in section 5 an alternative approach to develop systems based upon layered object model. The paper imparts in section 6 the core of the layered object model and some of the design principles for the remainder of a VE system. Finally, section 7 draws some conclusions.
2. GAMES VERSUS RESEARCH Within the games industry, the development of online games is relatively recent and evolved from the single player experience to multiplayer with the advent of the Internet phenomenon. The age of games developed in the garage with just a team of three developers is no longer a common practice. Nowadays, the process normally involves larger teams with a budget in the region
of a few million dollars. The team consists mostly of content developers, with just a few developers to implement the game engine. The game development normally involves projects during a twoyear period. No matter how carefully the project is planned, it is not unexpected for milestones to be forwarded thereby delaying the initial time to market. The challenge of online game developers is not only to meet the milestones and resource constraints, but also to release a product that meets the expectations of potential customers. However, it is not possible to predict the behaviour of a user, thus imposing unexpected stress upon the game engines that reveals all the pitfalls and errors in the implementation. The process begins with the delineation of a set of functional features to implement what is necessary for a game. The cost involved in developing a custom game engine from scratch has fomented the trend to seek alternative paths, such as: •
•
License of game engine. This solution is quite common, but has the pitfall that the set of requirements supported by the game engine does not address all the features of the game design. The need to maximise performance results in an implementation that is highly coupled to the data structures and functionality. Thus, the developers either compromise the initial design or develop a new system. The latter is the usual outcome, but although there is no code reuse, the process benefits from the experience and lessons learnt. A similar situation occurs when using an in-house game engine from a previous product. In those few cases where the team does not compromise the game design and uses unaltered an existing game engine, the result is what is considered a ‘clone’ where only the development effort focuses on the content creation. Middleware. This solution is progressively being sought by game developers, but the middleware relates only to wellconfined subsystems within the game engine, such as the component responsible for physics and artificial intelligence (AI). However, the adoption of middleware imposes design constraints because of the data model dependencies.
This paper focuses mainly on two genres of online games, namely First Person Shooters (FPS) and Massive Online Role Playing Game (MORPG). The former is session based, thus participants come together in an alternate reality for a limited period of time, whilst the latter supports persistency even when no users are playing. The continual time availability of a MORPG is fundamental to promote the emergence of sustainable cybercommunities, but the system suffers greater stress from the players. The research community concerning VEs evolved from the single experience made possible by virtual reality. The development process revolves around a small core team of researchers, if not a single individual, that starts with a research concept or idea. The longevity of a system is either tightly coupled with a particular project or its development team. The former implies a well delineated period whilst the latter corresponds to an ongoing project. This implies in both cases, that the associated budget is significantly smaller than the one for online games.
Unlike MORPG, VEs are purely session based and the user’s expectations are not as demanding as the players of online games. Although many VE systems have adopted object-oriented development methodology, the results continue to be monolithic architectures. The MAVERIK [6] system consists of a small kernel with an elegant callback mechanism, thus allowing the decoupling from a particular internal data structure. MAVERIK itself focuses on a framework, which provides the developer with great flexibility at the cost of productivity. However, to aid the development of a VE system a set of existing base Modules are provided for the purposes of rendering, spatial management, navigation and device integration. Another system where reusability was an important design aim is the VRJuggler platform [1]. This consists of a toolkit to build VE systems that are portable, flexible and configurable at runtime. The core of the toolkit is the Virtual Platform, which alleviates the developer of considering low-level details regarding the management of system resources such as devices and processes. This allows the developer to build a system disregarding the target configuration of the hardware and expect the applications to work. However, both systems epitomize that applying sound software engineering principles does not ensure reusability since both are tightly coupled to the initial functionality aims. Although FPS and MORPG are more engaging than the majority of existing VE systems, the latter consists of more sophisticated solutions. In fact, much of the research carried out in VE systems have been adopted and improved by game developers. For the remainder of the paper, the focus will be on virtual environment systems. However, both game engines and VE systems seem to neglect the lessons learnt from the networked multimedia community and the knowledge garnered from experiments such as Habitat [8].
3. TWO CASE STUDIES This section of the paper will present two case studies that are representative of the problems that occur with the traditional VE systems.
3.1 Virtual Environment Community The case study in [10] provides a system centric analysis of transatlantic collaborative haptic experiment. The objective of the experiment was to assess the impact of collaborative haptics on the user’s sense of presence and co-presence. Therefore an experiment was designed in two stages involving a task that required joint manipulation of a common object between two users. The stage differentiation was the inclusion of the haptic device as the input device for the user. The task would involve carrying a stretcher with some objects from outside a simple building and taking the same stretcher inside, following a well-defined path. The subjects of the experiment were timed for completion of the task with a threshold of 8 minutes. However, several problems emerged from the monolithic nature of the chosen system that compromised the initial design of the experiment. The first stage raised several technical challenges that required significant changes to the chosen system – Distributed Interactive Virtual Environment (DIVE) [5]. The result was an instantiation
of the system tightly coupled to the experiment to address the problems. However, the serious stumbling block was when the experiment proceeded into the second stage, which involved the same task but using haptics. The DIVE system demonstrated incapable of supporting collaborative haptics due to the tight coupled nature of the graphics subsystems with all the remainder subsystems. Since there is no use of multi-threading, it is the rendering process that determines the processing speed, which is typically two orders of magnitude inferior to the 1KHz sampling rate of the haptic device. The careful design of network protocols and of a physics model did nothing to ameliorate the difference. Consequently, DIVE was discarded for the second stage of the experiment. Due to the limitations experienced by DIVE, a multi-threaded simple prototype was developed to carry out a transatlantic collaborative haptic experiment. However, this involved a new experiment design with a simpler task that would accommodate the coarse functionality of the prototype.
modified, a new system would emerge with some rehash of the existing codebase. The refinement of the systems, which survived their first generation of existence, improved considerably the design. The immediate effect was the emergence of internal modularity that resulted in the definition of rudimentary boundaries between the various subsystems, thus some improvement concerning the flexibility of the system. This is conceptually shown in (B) of Figure 2, where the subsystems are adjacent to each other although some overlap continues to persists. Therefore, a new set of requirements does not initiate the development of a new system, provided that the desired functionality is along the same lines as with the existent capabilities. However, the result continues to be monolithic systems that are either adopted or rejected as a whole.
3.2 Online Games Industry The case study reported in [7] is representative of the lack of understanding of the Internet as a global network infrastructure. The study reports on why game developers consider the Internet intractable with serious impact on the complexity in the system design and implementation. The game discussed is a variant of the FPS, but with an associated storyline. The core of the problem resided with the fact that the development team did the implementation of the game engine within a control environment on a Local Area Network (LAN). To study and accommodate the shortcomings of the Internet, artificial delay was added to evaluate the impact on the consistency held by the server and the response times to the clients. The game engine was finely tuned to a particular threshold that would be extremely lenient to the network problems regarding transmission delays. Unfortunately, the self-similar traffic [3] of the Internet played havoc upon the designed system model and disrupted the illusion of an alternate reality even without exceeding the established delay threshold. This result clearly evidences the lack of understanding towards the network by the game developers and the design is still dominated by the graphics subsystem.
Figure 2 - The impact caused by the adoption of software engineering in the development of virtual environment systems. The system is represented by the black line encompassing five subsystems (A) System subsystems muddled together. (B) System subsystems well-de The promise of reusability given by the application of software engineering has attracted many developers within the field of VEs, but the result continues to be monolithic systems, albeit with good internal modularity and improved customization to adapt to new requirements. Although complexity reigns as the core reason for the design and technical pitfalls of the current development trend, there are many human factors that contribute to the monolithic nature of VE systems, namely: •
No Communication. Mailing lists have been established in the attempt of discussing the development of VE systems. Although each VE developer has lively internal discussions, the external mailing lists are either defunct or with noneexistent traffic.
•
Not Invented Here. It is not unusual for a developer to improve or modify parts of a VE system. However, due to the monolithic nature of VE systems, the usual result is a new system. This is common in the gaming industry, where most game projects result in new VE systems albeit most begin with a licensed system.
•
Reinventing the Wheel. It will always be the case that some developers will want to push the envelope and/or investigate novel approaches to known problems. Unfortunately, it is not possible to make localized changes without having an impact on the remainder system. It is common for the local changes to propagate, resulting in a new system.
4. CURRENT APPROACH When assessing the current trend in the VE community concerning system development, one finds that the culprit for the constant reimplementation of VE systems is the complexity involved. In fact, each time a new set of requirements are specified, a new VE system is designed and implemented. The longevity of the systems is tightly coupled with a particular research lab, with a particular project or product cycle in the case of an online game. The initial systems supporting VEs had a tightly coupled internal architecture without any internal modularity. The result was monolithic systems that were highly inflexible and could only meet the initial set of requirements defined before the development process. This is conceptually shown by the (A) diagram of Figure 2, where the subsystems are muddled together and intersect each other. Each time the set of requirements were
system developers to build high quality components that have been tested exhaustively. Ideally, each component should be self-contained, but that is not a prerogative and consequently some components may have dependencies amongst themselves that will impose constraints on the overall design and choices made by the system developer.
5. NOVEL APPROACH The problem resides in the high complexity of the problem domain concerning VE systems, which results in an immeasurable number of different solutions albeit their partial overlaps. The traditional approach has been always to tackle the entire problem domain as a whole, thus application of software engineering methodology and principles has only yielded some internal modularity. However, the increase of flexibility is not sufficient and does not offset the other problems such as the high resource expenditure associated to system development and the resulting monolithic nature of the systems. An alternative approach, which is the primary topic of this thesis, is the Virtual Environment System Layered Object Model (VESLOM), as illustrated in Figure 3.
•
Application. This layer represents the final VE system that the user interacts with and it contains all the remainder components that are tightly coupled with the specific functionality and instantiation of the VE.
6. UNIVERSAL PLATFORM As illustrated in Figure 3, it is fundamental to determine the core layer corresponding to the Universal Platform (UP). The design challenge is to devise a solution that is common to any conceivable VE system, thus avoiding the monolithic nature of existing solutions. The Java Adapative Dynamic Environment (JADE) is a proposal for UP, where the functionality is decomposed into four main building blocks that are necessary to any VE system: Namespace, Resource Locator, Compiler and Event Management. As illustrated in Figure 4, these blocks support the dynamic runtime management of all components and resources of a VE system.
Figure 3 - Virtual Environment System Layered Object Model The approach underlying VESLOM is to reduce the scope of the problem domain by peeling away the complexity into different layers, each following component framework design methodology. The fundamental problem is to determine the minimal set of requirements that is common and necessary to any VE system independently of the particular functionality to be supported. The determination of this core functionality yields the Universal Platform, a highly flexible micro-kernel that manages resources at runtime and with guidelines that promote code interoperability, thus laying the foundations for middleware. Contrary to the current trend, there is no need to adopt an entire system but only the Universal Platform and select the appropriate components, or build new ones, to build the VE system. The remainder layers are: •
Networking. Although the Universal Platform has basic networking capabilities to retrieve resources from across the network, it is the responsibility of this layer to manage all functionality pertaining networking and the associated protocols.
•
Middleware. This layer encompasses all the components that are necessary to build a VE. There is no pre-determined number or combination of components, thus a VE system may consist of a single middleware component, or a few hundred. However, the purpose of the layer is to allow
Figure 4 - Universal Platform and its main building blocks The core of JADE is a light-weight cross-platform micro-kernel responsible for management of Modules. The initial design was similar to the Bamboo [12] initiative, but the current design has evolved and matured through several projects, such as the development of simple games, a VE editor and a graphical MUD with highly flexible interaction model. Although most of the key concepts survived all iterations, both the architecture and reference implementation suffered drastic modifications. It is important to stress that the JADE framework is independent of the reference implementation using the Java programming language. This particular choice of programming language permitted the focus to be on the design of the framework and its functionality, rather than any concern with implementation. The VE developer may implement the UP using an alternate programming language. The word Modules will be mentioned throughout the subsequent subsections, but only in 6.5 will a detailed description be given.
Figure 6 - INamespace interface
6.1 Namespaces In any VE system, there are numerous resources with a wide and diverse nature, ranging from a simple image as a texture to a complex mathematical model encoded in specific programming language. It is necessary for the VE system to retrieve at any given instance a particular resource. Therefore, one of the main building blocks of the UP is Namespaces. An overview of the UML class diagram of the jade.namespace package is illustrated in Figure 5. The package consists mainly of interfaces along with some reference implementations of namespaces.
The interface INamespace is illustrated in Figure 6. This interface is maintained simple and all encompassing of many forms of namespaces, such as tuplespaces, registry and databases. The (…) represents the different possible signatures of a particular method. The implementation details are delegated to the VE developer, but JADE provides a reference implementation in the object Registry and SQL database based on object/relational mapping. In Figure 7, the INamespace indicates that each resource has different states according to the state diagram of Figure 7.
Figure 7 - Resource state diagram The state cycle depends on two different interfaces: Figure 5 - Simplified UML class diagram of the jade.namespace package
•
BirthCycle. This interface consists of three state transitions, create, initialize and shutdown. When a resource is instantiated, it finds itself in the Void state and the only state transition available is create. After a resource is created, the initialize state transition can be invoked making the resource Ready. The motivation for the two states is that the creation process is time consuming, but only occurs once. However, initialization may take place several times and should be performance sensitive. The final state transition is shutdown.
•
LifeCycle. This interface consists of activate and deactivate. The LifeCycle does not extend the BirthCycle interface to allow maximum flexibility by their decoupling and to avoid possible ambiguity when using polymorphism.
At the heart of the namespace is the process by which the system uniquely identifies each resource. Therefore it is necessary for each and every resource to have some form of identity, which can be categorized into: •
•
SystemIdentity. Any resource within the system has a SystemIdentity. Associated to this identity is a global unique SystemID, which consists of a tuple with the current absolute time in milliseconds (with counter modifications to ensure uniqueness) and the local IP of the host machine if connected to the network. The SystemID of any resource is accessible, but cannot at any given instance be altered. Identity. A SystemID is unmanageable for the developer, thus the Identity provides a handle for developers and content modelers. The identity is based on a name and a logical ID. However, the responsibility of managing resources based on their Identity belongs to the developer, so the system is exempt from any ambiguity that arises from using the same ID for different resources. public Identity get(…); public SystemIdentity getSystem(…); public void add(Identity resource); public void add(SystemIdentity resource); public SystemIdentity remove(…); public void initialize(…); public void shutdown(…); public Iterator elements();
6.2 Event Management The UP may support any number of Modules, but most likely their operation is not isolated from one another. Therefore it is necessary to provide some means for data to be exchange between Modules and for events to be triggered. All the existing mechanisms have their advantages and disadvantages. The choice of which mechanism to adopt is delegated to the VE system developer. The simplest and most efficient form of communication is direct accessibility to a Module. This is possible since each Module is retrievable via the Namespace managed by the JADE kernel. However, this approach requires prior knowledge of the target Module or to use reflection to determine the interface at run-time. The adoption of this method is discouraged since it produces Modules that are tightly coupled to one another.
The JADE framework provides two other forms for communication between Modules, both based on the Subscriber/Publisher pattern using events. An overview of the event package is depicted in the UML class diagram of Figure 8.
Upon subscribing, it is possible for the subscriber to denote if the interest is blocking or non-blocking by using EventBarriers. In the case of blocking, the subscriber is blocked until the event occurs once and only once. While in the non-blocking case, the subscriber is notified each time the event occurs or a particular source generates an event. In this case, it is necessary to explicitly deregister when there is no more interest in receiving events. It is possible to create dispatchers and event queues as necessary, but by default the JADE kernel provides three with varying degrees of priority (high, normal, low).
6.3 Resource Locator The ResourceLocator is an important to the UP. It is responsible for retrieving a resource from a given source and dispatching it to the appropriate sink as illustrated by Figure 9. The ResourceLocator may manage any type of resource provided the appropriate Retriever and Handler exist:
Figure 8 - Simplified UML class diagram of the jade.event.package. Only immediate relationships to classes in other packages are illustrated
•
Retriever. The role of this element is to retrieve a resource from its location. By default, there exist three retrievers: local hard disk, Hyper Text Transfer Protocol (HTTP) and the Jini service.
•
Handler. Once a resource is retrieved, the Retriever delegates it to the respective Handler. The type defined in the resource descriptor determines which handler to evoke. There exist handlers for native system libraries, Modules and Classes.
The base SystemEvent indicates the source, type of event and any arguments necessary to be processed by the target subscribers. However, unless the developer keeps track of the SystemID to each resource, the Event class is more appropriate to the developer since it also uses the Identity to track the source. Any Module (or code within the system) may generate events. The way in which an event is disseminated characterizes the corresponding event model being used, either distributed or central. It is possible to use both models simultaneously.
6.2.1 Distributed Event Model Each Module may accept the direct registration of a subscriber’s interest. Whenever an event is generated, the Module informs each of the subscribers that belong to the set of listeners. While this approach is more robust than a central architecture, it requires that a subscriber retrieves the reference of the desired resource to register their interest. Another disadvantage is the impossibility of a subscriber just indicating their interest in just a particular type of an event independently of its source.
6.2.2 Central Event Model This approach relies on the existence of a central event manager responsible for dispatching events. Whenever an event is generated, it is posted to the event manager, which places it into the appropriate dispatch queue according to its type, priority and source. Any subscriber interested in receiving events is required to register their interest with the event manager, indicating their interest either in a source or particular type of event independent of its origin.
Figure 9 - ResourceLocator with sources/sinks The process of locating a resource begins by the ResourceLocator receiving a resource descriptor. A caching mechanism is used to validate if the resource has been previously retrieved. This may be overridden when necessary by setting a flag. The retrieval process is determined by the protocol defined in the URL of the resource. If no protocol is identified, then it is assumed that the resource is located on a file system, either local or remote and the system variables for paths are used. Once the resource has been retrieved, it is delegated to the appropriate Handler based on its nature (Module, Library, Class or any content specific resource such as textures, X3D, etc). In the case of a Module or a Java class, the ResourceLocator resolves the associated classfile and dynamically links it into the system. The class resolution verifies any dependencies and retrieves all the other necessary classes from the either the local classpath or the same URL of the initial class/Module.
The handling of libraries via the Java Native Interface (JNI) allows the integration of native code (C/C++, Pascal, Assembly, LISP, etc). However, this option will compromise the portability of the VE system, requiring the existence of a different library for each system.
6.4 Compiler One of the design principles of a VE system is to support many alternate realities by incorporating a mechanism that decouples the content from the codebase. This allows for the user to use the same system for different VE, depending on a file that contains the content along with its structure. The mechanism that makes this feasible is the Compiler and it is the final building block that is part of the JADE proposal for UP. The Compiler is composed of two sub-blocks, a parser and a morphemic interpreter. The former is responsible for the syntax parsing of the input file, whilst the latter is responsible for the semantic processing of the output from the syntax parser. Each of the sub-blocks is flexible to support numerous simultaneous syntax subparsers and semantic interpreters. The JADE reference implementation provides a system parser with a morphemic interpreter that allows the configuration of a stack of different compilers as illustrated in Figure 10.
… jade.compiler.sax.ParserBlockSAX TW jadex.treaclewell.compiler.TWMorphemicInterpreter jadex.treaclewell.compiler.ConnectorSAX jadex.treaclewell.compiler.ClassifierSAX jadex.treaclewell.compiler.AnchorSAX jadex.treaclewell.compiler.LinkConnectorClassifierSAX jadex.treaclewell.compiler.LinkClassifierFlowSAX jadex.treaclewell.compiler.FlowSAX jadex.treaclewell.compiler.FactorySAX
… Figure 10 - XML excerpt for configuration of the Compiler The concept is that there exist one syntax parser per language definition, but many interpreters. This is evidenced in the XML description of the Figure, which illustrates how the compiler for TreacleWell [9] is built.
6.5 Module Management The core of the JADE component framework is the kernel, which brings together the building blocks Resource Management, Compiler, Event Management and Compiler. The design of the kernel is highly flexible, allowing for the developer to provide proprietary implementations to replace one or all of the default internal functional blocks. This may be done at runtime or whilst the system is initializing by providing the appropriate configuration file. Since it is necessary to assure easy accessibility to the JADE kernel from any place in the system, the singleton [2] pattern was adopted. As a result, only one microkernel per Java Virtual Machine (JVM) exists.
6.5.1 Module One of the cornerstones of the JADE framework is the Module, which uses the Policy pattern to delegate to the VE developer the
implementation of the details. This approach allows the kernel to manage the various Modules that are part of a system without concern of their particular functionality. The granularity of a Module is entirely the responsibility of the developer. One may encapsulate an entire system within a single Module, or may break down each minimal operation into separate Modules. The developer should aim at a design with balanced flexibility and performance. protected void buildMetaData(); protected void createModule(); protected void initialiseModule(); protected void activateModule(); protected void deactivateModule(); protected void shutdownModule(); protected void absorbModuleState(Module source); Figure 11 - Core of the Module interface Every Module developed is required to implement the policy interface denoted in Figure 11. The buildMetaData is where the developer instantiates the meta data discriminating the particular instance of the Module, this information may be used for both security and reload mechanisms of the kernel. As illustrated in the absorbModuleState method, the developer is responsible for implementing the state transition of one Module instance to another of the same type. The execution of a Module is passive within its owner’s context. However, should it be necessary for it to be concurrent, there exists the ModuleRunnable that is contained within a thread context of its own.
6.5.2 ModuleManager A ModuleManager is a specialized Module that is a container of other Modules and is responsible for their management. Since each Module has a unique ID that identifies it, the resulting namespace in the VE system has a hierarchical nature. The JADE kernel is a derived ModuleManager with additional functionality to management. The operations available are summarized in Figure 11, where (…) contains either the unique ID of the target Module or the pair (owner, module). public void activate(…); public void deactivate(…); public void shutdown(…); public void initialize(…); public void loadModule(…); public void reloadModule(…); public void unloadModule(…); public void unloadAll(); protected Module getModule(…); protected abstract void buildReloadPolicy(); protected abstract void buildSecurityPolicy(); Figure 12 - Core of the ModuleManager class The accessibility of the getModule method is intentionally protected, thereby delegating to the derived subclasses the responsibility of exposing the contents of the ModuleManager.
The JADE kernel provides such a method retrieveModule(…), which may be either blocking or non-blocking.
the data models remains consistent across the different versions of the rendering Module.
In Figure 12, three protected methods exist to enforce the existence of a ReloadPolicy, SecurityPolicy and a Namespace in case none are provided by access methods:
The VESLOM approach does not dictate how to build a VE system, delegating to the VE developer the number of Modules along with their granularity. This foments the emergence of specialised middleware that can be distributed across the Internet.
•
•
ReloadPolicy. This policy is used to determine how a Module is reloaded. By default the JADE micro-kernel validates version numbers of the Modules, choosing the most recent.
The design principles of VESLOM permeate the various Modules developed: •
TreacleWell. This Module [10] corresponds to networking layer and consists of a three-tiered component framework, where developers may build their protocol stacks from micro-protocols. TreacleWell provides a small library of protocols that support reliability, ordering, timeliness, etc.
•
Meta Interest Management (MIM). This Module provides a framework for management of receiver interest independent of the interest policy. MIM provides policies for static spatial interest and for aura based interest. MIM uses TreacleWell for the different communication architectures associated to the various interest models.
•
Meta Unified Datamodel (MUD). The MUD framework is built upon the Model-View-Controller pattern, resulting in Node-Visual-Behavior. The resulting Module embodies the datamodel of a VE application and manages the data.
SecurityPolicy. This policy is invoked preceding any operation of a Module and determines its execution.
7. CONCLUSIONS The current development trend of online games and VE systems share common pitfalls that result in a wide proliferation of solutions. The developed solutions yield monolithic architectures that are strongly constrained by the initial functional requirements. The main problem resides in the significant complexity involved in developing VE systems, independently if done within the research community or online games industry. It is not feasible to devise an ideal solution to meet the entire design space, thus an alternative methodology is necessary. This paper presented the Virtual Environment System Layered Object Model (VESLOM) as a novel methodology to develop VE systems. The approach is based on strong object-oriented principles combined with a layered component design, which contributes in reducing the daunting complexity involved with VE system design. The core of VESLOM is the Universal Platform (UP), which needs to be common denominator across all the VE systems, becoming part of the fabric of Cyberspace. This paper focused in the exposition of the principles involved in the design of the Java Adaptive Dynamic Environment (JADE), which is the proposed solution for UP. The JADE framework is based on the four foundational building blocks that are common to any VE system. However, an application requires JADE and the composition of one or more Modules. The main advantages of using JADE are reusability and code interoperability. However, JADE also makes it feasible to support runtime extensibility, such as the transitions of the demo depicted in Figure 13.
Although reference implementations exist to all the components readily available, including the high semantic Modules for rendering in 3D and 2D, the emphasis is on the respective frameworks.
8. ACKNOWLEDGMENTS This research was partially funded by Alfamicro. The author wishes to thank the discussion and contributions of Mel Slater, Jon Crowcroft and Anthony Steed..
9. REFERENCES [1] Bierbam, A., Just, C., Hartling, P., Meinert, K., Baker, and Cruz-Neira, C., “VR Juggler: A Virtual Platform for Virtual Reality Application Development”, Proc. IEEE VR’2001, Yokahama, March, 2001 [2] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P. and Stal, M., “A System of Patterns”, John Wiley & Sons, 1998 [3] Crovella, M. and Bestavros, A., “Self-Similarity in World Wide Web Traffic: Evidence and Possible Causes”, IEEE/ACM Transactions on Networking, Vol.5, N.6, December 1997 [4] Gibson, W., “Neuromancer”, Ace Books, New York, 1984
Figure 13 - Demo prototpye using JADE The figure illustrates the gradual transition between three different rendering Modules, starting with a simple polygon graphics, followed by a shaded polygon and finally a fully textured based rendering engine. The user does not need to interrupt their game, but careful consideration needs to be taken into account so that
[5] Hagsand, O., “Interactive Multiuser VEs in the DIVE System”, IEEE Multimedia, spring, 1996 [6] Hubbold, R., Cook, J., Kaetes, M., Gibson, S., Howard, T., Murta, A., West, A. and Pettifer, S., “GNU/MAVERIK A Micro-Kernel for Large-Scale Virtual Environments”, Proc. VRST’99, London, December, 1999
[7] Lincroft, P., “The Internet Sucks: Or What I Learned Coding X-Wing vs TIE Fighter”, Proc. Game Developer’s Conference, ,1999 [8] Morningstar, C. and Farmer, F., “The Lessons of Lucasfilm’s Habitat”, Proceedings 1st Annual International Conference on Cyberspace, 1990 [9] Oliveira, M., Crowcroft, J. and Slater, M., “TreacleWell: Unraveling the Magic "Black Box" of the Network”, Proc. SCI’02, Orlando, July, 2002
Systems: A Case Study”, Proc. 2nd International Conference ADCOG, Hong Kong, January, 2003 [11] Stephenson, N, “Snow Crash”, Roc (Penguin Books), New York, 1992 [12] Watsen, K. and Zyda, M., “Bamboo – A Portable System for Dynamically Extensible, Real-Time, Networked, Virtual Environments”, Proc. IEEE Virtual Reality Annual International Symposium (VRAIS’98), Atlanta, March 1998
[10] Oliveira, M., Jordan, J., Mortensen, J., Steed, A. and Slater, M., “Considerations in the Design of Virtual Environment
Columns on Last Page Should Be Made As Close As Possible to Equal Length
