The Internet is undeniably a global infrastructure that brings people together by toppling geographic and time barriers. The current network applications are prominently hypertext systems that allow the integration of various media into a web page. Therefore, the fundamental application operational paradigm is information retrieval from content servers to client browsers.
The integration of real-time services poses interesting challenges for Virtual Environments (VE) and online games, aiming at leveraging the global network infrastructure. The previous existing networked multimedia applications focused on data streaming, namely of audio and video. The main requirement of any other data communication was reliability, rather than actual real-time responsiveness. In addition, the number of users involved in a session would be confined to a small number, thus the scalability of a system was not an overbearing concern. Consequently, both the VE and games community have initiated a slow and painstakingly apprenticeship as old and new lessons are learnt.
This paper presents the motivation behind VE and online games, along with the main approaches to network architectures within both communities. The Mayhem project aims to address the existing shortcomings by pooling together the knowledge from the network, VE and gaming community. Towards this end, the paper describes the VE system prototype based on hybrid architecture with client nodes for real-time interactivity and servers for offline services, such as content distribution. The paper provides some detail of the system by describing its core building blocks, which are based on layered component frameworks.
Keywords
Virtual Environments, online games, component frameworks, java, distributed architectures, multicast, multi-user and multimedia.
Approximate word count (without references): 7000
"Hiro is approaching the Street. It is the Broadway, the Champs Elysees of the Metaverse. It is brilliantly lit boulevard that can be seen, miniaturized and backward, reflected in the lenses of his goggles. It does not really exist. But right now, millions of people are walking up and down it."
"Developers can build their own small streets feeding off the main one. They can build buildings, parks, signs, as well as things that do not exist in Reality, such as vast hovering overhead light shows, special neighbourhoods where the rules of three-dimensional spacetime are ignored, and free-combat zones where people can go hunt and kill each other." [35]
The Internet has come a long way since its genesis as the ARPANET project and the emergence of Transmission Control Protocol (TCP) [30]. However, it is not the networking technology that is directly responsible for the current success of the Internet, but rather the existence of the World Wide Web (WWW) which empowers end-users with browsers to navigate, share and browse data independently of the geographic location. The exponential growth remains unabated, with the forecast of 320 million users to be achieved by 2002 [6].
The prime objective of the Internet was and continues to be the provision of an infrastructure for users to communicate and share experiences. It seemed natural to most that the next step would be enable the client browsers to provide a third dimension to the user interface as described in the excerpts above. Although most people within the field of Virtual Environments (VE) invoke Neuromancer [18] and Snowcrash [34] as motivation and inspirational vision for more than a decade, the 3D revolution on the Internet has been slow with little or irrelevant impact on its overall growth.
To promote and standardize 3D technologies for the Internet, a nonprofit organization came into existence in late 1998, the Web3D Consortium. This organization has close ties with both the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF) to guarantee that any adopted solutions are integrated into existing technologies and operate within the network infrastructure for the foreseeable future.
In analogy with W3C, the Web3D recognized the importance of interchangeable content. The genesis of the idea was presented at the first World Wide Web conference [28] in 1994, where the Labyrinth prototype application was demonstrated as proof of concept. However, the focus became the file format to describe 3D scenes to be parsed by dedicated browsers, thus in similarity to the Hyper Text Markup Language (HTML) and its successor, the eXtensible Markup Language (XML), the Virtual Reality Modeling Language (VRML) [37] was created. In VRML 1.0, the objective was to create and support static geometry scenes. Although interesting, the users quickly clamored their disappointment with the static and thus VRML'97 emerged with additional features such as behaviors. The current iteration of the language is known as the X3D and aims to leverage the benefits brought forth by XML and the componentization of the language.
The definition of Virtual Environments (VEs) that may only be navigated by a single user proves to be a lonesome experience. As a result, various solutions, such as [7, 13, 29], have and continue to emerge to address the issue of multiple users sharing a common experience in a VE. Although VRML/X3D is considered as the file format for 3D on the web, online games and VE systems continue to have dedicated file formats for describing their 3D content.
The VRML/X3D standards only focus on content without defining the technologies required to support multi-user capabilities. This task is part of the charter of various working groups within the Web3D consortium, such as dis-java-vrml, to add multi-user capability by VRML extensions. However, as with other non-VRML initiatives, such as games and VE, there is a proliferation of different solutions. This clearly points out the pioneering stage of exploring the problem domain associated to VE network infrastructure.
The Mayhem project pools together the knowledge from the VE, online games and networking communities to implement a VE that experiments with new technologies. Since one of the drawbacks that affects innovation in VE system development is lack of reusability of the experienced garnered, a strong component methodology is used in the design the system. The result is a layered set of different functional building blocks with different levels of adoption, where flexibility is exchanged for productivity. This paper will describe the core framework and some of the other building blocks that are used in the Mayhem project.
The remainder of this paper will be partitioned into 4 additional sections. An overview of the main differences between traditional online development and VE research is given in Section 2. The following section 3 provides a brief summary of the core building blocks used in the Mayhem project. In Section 4, an overview of the Mayhem system architecture is provided along with descriptions of interest regarding the server and client applications. Finally some conclusions are given in section 5, along with directions of future work.
As pointed out in [27], one of the core lessons learnt from the Habitat experiment was that cyberspace was about people and their interactions. The sense of sharing the same space with other people is significantly more important than other features, such as engaging graphics [32]. In fact, social interaction and the creation of a cyber identity are the foundation of any cybercommunity [31].
Any VE, ranging from an online game to a military simulation, requires careful consideration regarding the underlying architecture since it is the cornerstone of creating the illusion of shared virtual spaces. At the moment, the most common approach is based on the classic client/server model, but such solutions are plagued with several problems, namely scalability. A wider range of solutions exists in the VE research community and military simulations.
Most, if not all, online games rely upon pure client/server architectures. This approach centralises the world database at the server, which is responsible for distributing the state to every single client. To achieve this, the server must keep track of clients and according to their awareness [19] of the world, compute their state and update the respective clients. Therefore, it is the server that determines what a client perceives in the world; consequently, the client hosts may be regarded as mere dumb terminals to display a viewport into the VE and collect input from the user.
The main advantages of this approach are the centralised management of the VE datamodel; a simplified programming model and ease of deployment. However, there are a significant number of disadvantages associated with the architecture.
The centralised nature of the architecture renders the server as a bottleneck in terms of service being provided. It is always necessary to determine the maximum threshold of simultaneous participants that are allowed at any given time, or risk partial/total disruptions in the service as the server strains with overload. This holds true independently even if the server (The word server is used in singular, but it may represent a single or cluster of machines) is over provisioned in terms of computational power and network resources.
Disregarding the issue of the server being a bottleneck, there would always be the problem regarding latency in playability. Every event that occurs on a client suffers from significant delay since it must be sent via the server before reaching the remote clients. There exist some approaches to attenuate the impact of this lag. For example in RING [17], the fact that the VE corresponds to an enclosed space with high occlusion accommodates for the latency introduced by round trip times (rtt) of the data packets to the server. So, the system may support mechanisms to account for the lag introduced by the server. With online games, some of the game logic has been delegated to the clients allowing prediction [4] of immediate actions. This approach may introduce inconsistencies once the state from the server is received and does not match the current predicted state of the client.
The interaction model between the user and system also plays an important role. In the case of MORPG with an isometric view, the navigation is based on high-level semantics with the user indicating (via clicking) the destination, and the application performs path finding to get their avatar there. This interaction model has very relaxed real-time requirements. However, with the First Person Shooters (FPS) genre, the interaction model is based on the user controlling the avatar at every instance in time. Therefore the requirements are very close to real-time and any lag introduced has significant impact of the playability of the users. Consequently, the network distance of the server may in some instances result in the exclusion of some users from a game session.
In addition to these problems, the fact that a centralised architecture introduces a single point of failure requires the infrastructure to explicitly provide robustness mechanisms to avoid service disruption. These are some of the problems that plague current online games, for which the preferred countermeasure has been to increase the budget involved in overprovisioning the server infrastructure.
The VE research community has explored a wider range of architectures beyond client/server, where the world data model may either be totally/partially replicated or distributed across the client hosts, such as DIVE [20], MASSIVE [19], NPSNET [25], RING [17], SPLINE [1] and VLNET [10]. While these approaches may solve most of the shortcomings of a centralised architecture, a different set of problems arise, such as consistency [mauve] of the world state and object ownership [36]. Various solutions exist, each with their specific strengths and weaknesses.
An ideal system does not exist, thus it would be ideal to combine the best elements from different systems towards a customised solution addressing each specific set of requirements. Unfortunately, code interoperability and composability is unfeasible with current systems. This impediment results from their monolithic nature, independently if the design of the systems is one block of code, modular or even object based. A possible answer may be found in the adoption of component design and methodology, which has not been adopted in the VE community.
The lack of interoperability, while influential, is not the sole reason why alternative approaches to client/server have not been adopted by the online games community. Most non-centralised infrastructures require the distribution of data using multicast, which is not widely available on the Internet [15], in particular towards the edges of the network. However, the network community is strongly promoting multicast and addressing its deployment problems in a practical manner. This is demonstrated by the adoption of the Single Source Multicast (SSM) [21] by network carriers. While other companies have begun to provide multicast services at the application level based upon active networking premises.
In addition, one of the main design premises of online games is "Never Trust The Client" [24]. This means that nothing should be placed at the clients, since the users will have access to the code and through perseverance modify it to suit their own purposes. The impact of cheating on single user games is irrelevant; with multiple users the impact on playability and enjoyment of the remainder user community may ultimately be disastrous. However, the impact of cheating is more damaging on the business of online gaming [14].
With any distributed architecture, it is necessary to place some trust in the clients, since they collectively share the responsibility for management of the world. However, this approach implies the integration of distributed security mechanisms, including authentication. With very few exceptions, the VE community has tended to overlook security requirements. The reason for this trend is mainly due to the fact that the application domain is traditionally within a trusted environment. However, recent research [3] in the networking community has begun to delve into the problems of security mechanisms to counter cheating with distributed system VE architectures.
An understanding of the network and its volatile nature continues to be close to nonexistent in both the VE and online game community. The network is viewed as a "blackbox" that the systems interfaces via a simple interface of send and receive messages. When reliable communication is sought, then TCP is used even though its scalability properties and flow/congestion control mechanisms do not make it appropriate for real-time interactivity in large groups of users. The other alternative is to build protocols based on the User Data Protocol (UDP), where the data flows are tailored to the needs of the application. However, it is not feasible to take a "black box" approach as if the Internet is not a shared resource. For example, if a data packet loss occurs, the resolution may not simply consist of resending the packet since the particular path of the network may be congested. When congestion is detected, it is necessary for protocols to demonstrate TCP friendliness and reduce transmission rate to avoid a network collapse [16]. Unfortunately, most VE systems and online games are developed within a controlled environment of a dedicated network, such as a LAN, which does not take into account the behavior of the Internet at large.
In the game industry, it is unusual to find a game benefiting from the reuse of existing technology. In those few cases where an existing game engine is adopted as the core, it is still necessary to undergo significant re-implementation, which ultimately results in discarding the initial engine. In the VE community the situation repeats itself, each time a new idea or concept requires validation by implementation then the likelihood is for a new system to be created.
The progress in both communities regarding building networked applications with real-time interactivity is slow without major breakthroughs. The main cause behind this situation is the lack of reusability of developed technology, which leads to resource expenditure on re-development of existing solutions.
The Virtual Reality Transport Protocol (vrtp) [8] provides guidelines to a layered component framework for VE. The proposal provides insight into the classes of components that are part of a VE system and their relationships. The proposed components are aggregated into three layers of flexibility as illustrated in Fig. 1:
The Java Adaptive Dynamic Environment (JADE) addresses the infrastructure layer of the VRTP framework as a viable solution to the Universal Platform. It consists of a component framework, which permits dynamic runtime management of all components and resources of a VE system. The operation of the JADE framework revolves around a light-weight cross-platform micro-kernel.
The cornerstone of the JADE framework is the Module, which requires the minimal interface illustrated in Fig. 2 to be implemented.
protected void buildMetaData(); protected void initialiseModule(); protected void activateModule(); protected void deactivateModule(); protected void shutdownModule(); protected void absorbModuleState(Module source);
The JADE micro-kernel requires the most elementary component to implement the Module interface, which reflects their life cycle: active, inactive, loaded and destroyed. While in the active or inactive state, it is possible for a Module to be reloaded, although due to security restriction the operation is only permissible to the owner of the Module. To assist the reload operation, a Module contains a description that encapsulates its name, version and relevant urls.
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.
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.
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 operations available are summarized in Fig. 3, 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();
The getModule method is intentionally protected, which delegates to the derived subclasses the responsibility of exposing the contents of the ModuleManager. The JADE micro-kernel is a derived subclass of the ModuleManager and provides such a method retrieveModule(***).
The JADE micro-kernel contains several helper objects that provide the additional support to meet the requirements of the Universal Platform:
The reference implementation provides default implementations for these helper objects, but it is possible to replace them by customized code. The replacement may be done either at setup time (preferable) or at run-time.
Considering that the JADE micro-kernel corresponds to the core of any VE system and its resources, the singleton pattern [9] is used to promote easy access. This implies that only one JADE exists per Java Virtual Machine (JVM).
The JADE component framework promotes the existence of multiple components, each a self-contained role. However, a Module may not operate totally in isolation except if it is the only one in existence, thus JADE provides three different methods for intra-Module communication.
The simplest and most efficient intra-module communication is direct accessibility to a Module. This is possible since every Module is retrievable due to its unique ID. 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 other two forms of intra-module communication are based on event models:
All mechanisms have their advantages and disadvantages. The choice of which mechanism to adopt is the responsibility of the VE system developer. However, the central event model is the recommended approach.
The ResourceLocator is the fundamental helper class of the JADE kernel and deserves some explanation. It is responsible for retrieving a resource from various possible sources and dispatching it to the appropriate sink as illustrated by Fig. 4.
The ResourceLocator may manage any type of resource provided the appropriate Retriever and Handler exist:
The process of locating a resource begins by the ResourceLocator receiving a resource descriptor. The first phase consists of investigating if the resource exists on locally on the system. If there is a cache miss, then the associated file is retrieved. The entire 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 or Class). 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.
The library of JADE extension Modules provides a networking Module called TreacleWell (TW), which adopts some design principles derived from the Application Level Framing (ALF) [11]. Consequently, the abstraction barrier between the network code and the remainder of the system is removed, allowing an application to access the state of the network and adapt accordingly.
Although TW is a networking Module, there does not exist the concept of a data packet. Instead, the Message abstraction was adopted to represent data while it is handled by the system. These Messages arrive from the network at the bottom of the well and travel upstream towards the remainder of the system (or downstream when the direction is from the application towards the network).
The main part of the Message interface is depicted in Fig. 5, where the token <primitive> should be replaced by byte, short, int, long and string.
public void write<primitive>(<primitive> data); public void writeBytes(byte []data); public <primitive> read<primitive>(); public byte[] readBytes(); public <primitive> peek<primitive>(); public byte[] peekBytes();
All operations are executed in a linear fashion. For non-linear access it is necessary to use a specialisation of the Message interface - AdvancedMessage.
No assumptions are made regarding what is the best data structure to support the Message. Therefore it is necessary to provide an implementation. In the current implementation of TW, a ByteMessage is available with a byte array being used as the supporting data structure.
The protocol processing architecture for each flow in TW is based on the model that consists of three cooperating entities:
To achieve maximum parallelism, all three entities should operate concurrently. However, this does not necessarily imply an explosion of thread usage. In fact, an optional alternative is provided based on the use of the observer pattern coupled with timers to obtain the similar results. The choice of which approach is taken is delegating to the system developer.
The TW operational framework is 3-tiered, as the simplified block diagram of Fig. 6 illustrates.
This provides to the remainder tiers a network device abstraction. The minimal parameters are an IP address and port number encapsulated by the CommPort class.
The Connector represents the network endpoint and it may keep track of the remote endpoint(s). Therefore a different Connector exists for each type of network device. By default the following are available: TCPUnicastConnector, UDPUnicastConnector, MulticastConnector and SMConnector. The SMConnector is a Connector supporting Simple Multicast [2], which resorts to native code via the Java Native Interface (JNI).
The Connector itself merely holds information regarding the network endpoints, ignoring how to extract or dispatch messages to the associated network device. The role of handling the particularities of the network device to send or receive belongs to the ConnectorAdaptor; so for TCP the Message is copied onto the socket stream by means of a buffer, while in UDP the Message is copied to a datagram packet.
public void setConnector(Connector connector); public void setClassifier(Classifier classifier); public void read(); public abstract dispatchMessage(Message message); public abstract Message extractMessage();
The ConnectorAdaptor interface is illustrated in Fig. 7. Even though the ConnectorAdaptor is the link between a Connector and the associated Classifier, it is a CommReader that does the retrieval of Messages. Consequently, the ConnectorAdaptor is required to implement the Receiver interface (the read() method).
The only time a ConnectorAdaptor does not link a Connector to a Classifier, is when considering using TCP on the server side. In this particular case, when the TCPServiceConnectorAdaptor does a read, it passes the connection to be handled by the associated ServiceHandler.
ClassifiersThe Classifiers reside in the middle tier of the framework. They are used to forward incoming Messages from the ConnectorAdaptors to the appropriate Flows according to a classifying policy.
A Classifier may be used by more than one ConnectionAdaptor and may have more than one Flow to forward the Messages. This flexibility allows TW to delegate to the system how the tier connectivity is established. By means of classifiers, the system may share a common Connector between different data flows or it is possible to share multiple Connectors to a single flow.
The structural links between Classifiers, ConnectorAdaptors and Flows are not necessarily static and the system may modify them dynamically at runtime.
At the moment, TW has by default the following classifiers:
The Anchors have a similar role to the Classifiers. However, they are used in the downstream path. Their role consists of delivering Messages from the Flows to the appropriate Connector.
FlowsThe Flow is effectively where protocol processing of Messages occurs. Each Flow has an associated MessageBuffer and a set of FlowElements that are connected together to form the protocol graph as illustrated in Fig. 8.
The MessageBuffer is where the Classifiers place the Messages that are destined for the particular Flow. The current implementation of TW includes a simple round-based buffer and a time bucket synchronisation buffer.
Although Fig. 8 depicts a Flow with all the FlowElements connected sequentially, it is possible to have a more elaborate graph with branches, by resorting to containers. Thus, a FlowElement may either be a protocol or a container of more FlowElements. Each Flow has associated a base FlowContainer where all the FlowElements are placed.
The currently supported FlowContainers are illustrated in Fig. 9 and each affects the protocol process in different ways:
To ease the development effort of how Flows are built and interconnected with the remainder TreacleWellElements, a template is provided denominate FlowBase.
public abstract void activate(); public abstract void deactivate(); public abstract void shutdown(); protected abstract Flow createFlow(); protected abstract void link(); protected abstract void buildConnector(); protected abstract void buildBuffer(); protected abstract void buildClassifier(); protected abstract void assembleFlow();
The FlowBase mainly creates a Flow but as Fig. 10 illustrates, delegates to the application how the Flow is actually implemented.
The ConnectorAdaptor, Classifier, Flow and all the FlowElements, are derived from the TreacleWellElement, which possesses a unique system identification number. This allows TW the possibility of immediate access to any element within it.
The fact that TW aggregates together all the Flows provides an implicit namespace for the system regarding Messages. Due to the container/element pattern, the namespace is hierarchical.
The TW namespace provides additional flexibility regarding protocol processing since it is not mandatory for a Message to originate at the network and be processed upstream (nor originate at the application and be processed downstream); Thus it is possible for any FlowElement to originate a Message.
The namespace also allows the Message processing not to be confined to a single Flow, thus allowing transversal between different Flows.
The motivation for MUD is to provide a framework for the datamodel so it is possible for data to be shared across different variants of the same application. The framework essentially consists of a set of Nodes and a set of Graphs. The Graphs may connect any number of Nodes according to a specific semantic objective, such as visibility culling (k-d, BSD or oct-trees). The underlying design goal of MUD is to provide a meta structure for the datamodel, thereby promoting coexistence with existing rendering technologies. So even if a system with an in-built scenegraph is used, such as Java3D, MUD provides a uniform manner in which the traditional parallel structure is maintained.
Figure 11 The core of the datamodel based on the Model-View-Controller pattern
Towards this goal, the Model-View-Control pattern was applied as the foundation of the framework as illustrated in Fig.11. Every element in the datamodel, independently of whether it defines space, an object or an entity, is derived from a Node.
Using this approach, it is possible to give a game (or VE) view independence, such that the client viewing modality may differ from each host, meaning that some may support 3D, while others may be restricted to 2D or even text. However, all instances of the client use and interact with a common datamodel, with specific extensions to support the corresponding view.
The MUD framework is implemented as one of the middleware Modules, where the interface provides the management of the set of Nodes and Graphs available. To provide maximum flexibility, the MUD Module provides an abstraction to the data repository, thus decoupling the datamodel from its physical existence. By resorting to a well-defined interface, it is possible to have the data residing (The current implementation provides these mappings. However, these may be extended to accommodate for customized ones) in memory, file or in a database.
The Mayhem project consists of a prototype of a Massive Online Role Playing Game (MORPG) based on the traditional Dungeons and Dragons (D&D) theme. The setting is the medieval ages where mysticism is a fact of life, allowing for the existence of deities and permitting the usage of magic.
Similar to other MORPGs, Mayhem adopts an open model regarding playability, thus the users decide how to interact and relate to their environment, including other users. Each user adopts a character and enacts a particular role that ultimately defines their identity within the VE. However, the player types have been characterised into four widely accepted major categories [23]: explorers, achievers, socializers and killers.
Contrary to the current trend where the architecture is solely client/server, in Mayhem different approaches are explored.
There is no dominant architecture in Mayhem. Instead, the architecture of the game differs according to the role of the system towards the end user:
The TW Module is extensively used by all the remainder Modules that require networking capabilities, with the sole exception (Java provides efficient and easy resource retrieval based on HTTP by means of the URL class)of resource retrieval based on Hyper Text Transfer Protocol (HTTP), which is delegated to the ResourceLocator.
The server represents a well-known "portal" to access the game, where clients may connect. The fundamental role of the server is the management of the VE content and the profiles of registered users.
The server is based on the JADE kernel, consequently it is possible to evolve the system without necessarily shutting down the service.
When a client logs on, the server validates the identity of the user before allowing access to the offline services available. Naturally, if the validation process fails, the server allows the user to create a new profile and associate to it at least one avatar. After the user has entered the VE for the first time, it is not possible to modify the chosen character represented by the avatar.
All the offline services are supported by TCP/IP, with the clients maintaining a connection throughout the duration of each transaction. The TCP/IP flows are also used to support heavyweight dataflows [8], namely the download of resources, such as images, sounds, models, network information, etc. The server is responsible for content distribution.
Eventually, the user selects to enter the VE, which requires the JADE client to build the application. This is achieved by the server providing a configuration file indicating which Modules are to be included and where to retrieve them. This file is encrypted to according to a private/public key pair, thereby avoiding trivial tampering. This process allows the system to distribute the workload by placing trusted Modules on the clients. With regards to persistent data, none is maintained at the client. So once the session is ended a final upload is done to the server. This avoids any attempts of the client tampering with the data by analysing it when not in an active game session. Considering that the server manages both the data and code, it is possible for both to change between game sessions of a user.
This approach results in a slight modification to the golden rule of online game development: "Do not trust the client, except if the code was placed there by a trusted source"
The client is also based on the JADE kernel, which initially has a simple configuration file to build the offline version. This application resembles a dumb terminal, consisting mainly of a GUI to the various offline services provided by the server. However, once the user decides to begin a game session, the client receives a new configuration file to replace the former one and the client's interface becomes as illustrated in Fig. 12.
The current version of the Mayhem client is based on a 2D tile based engine. To modify the rendering engine it is necessary to update the nodes with the appropriate VisualHandler.
The scalability of large number of participants is achieved by integrating into the client application the Area Of Interest Management (AOIM). The AOIM controls the Connectors of the TW, thus it is transparent to the data flows where and how the data is sent or received. In the prototype, a static approach [25] is taken where the VE is partitioned into sectors, each associated to two multicast groups. This approach is taken due to the different flow requirements between control and game data. However, with TW it is possible to modify this by combining both flows together and introducing a MuxContainer to distinguish between both.
The current online games do not perform satisfactorily when the network experiences problems although various several integrated mechanisms, such as lag compensation [4]. Another significant problem is the issue of scale where the number of users is limited to the computational and network resources available at the server, which represents the bottleneck of the system. Although some VE systems provide alternate network architectures with better scaling properties, the problem remains regarding the inadequacy of existing solutions to successfully achieve the goals of the Metaverse [34].
The wide proliferation of different solutions illustrates the pioneering stages of research in the area of VE. Unfortunately, there is no reusability of existing technologies, which ultimately hinders any progress. Therefore, the adoption of component methodology and design has been explored by some in the VE community, such as Maverick [22], Bamboo [38], VRJuggler [5]. These solutions address the problem of reusability of technologies within a single user system.
The Mayhem project aims to address the limitations of existing online games and VE systems. The project revolves around a prototype of a MORPG based on a set of layered component frameworks. The departure from traditional client/server to a hybrid solution with distributed workload may represent some concern regarding cheating and tampering. The JADE framework provides the necessary counter mechanisms to make it difficult to customise the client application with non-standard features. However, the setup time may be considerable even with the Module preloading functionality available. The possibility of permitting cacheable Modules is being investigated, using checksum of the corresponding class files to verify any tampering.
The current version of the client application is based on a 2D tile engine. However, a 3D version based on Java3D [33] is being developed. The co-existence of both views is permissible due to the benefits provided by the MUD module based on the Model-View-Controller pattern. Consequently, it is possible for a user with a PDA, consisting of a low-end graphic client, to interact with another user immersed with a CAVE [12] using a rich 3D interface.
A major concern of online games and VE systems is the lack of protocols adequate to address their real-time interactivity requirements, which may vary according to application domain. Towards this end, the TW Module will provide a set of micro-protocols that may be composed into customized solutions.
This work is sponsored by the Portuguese Foundation for Science and Technology. The work has benefited from the useful and insightful comments from Dr. Anthony Steed, Prof. Mel Slater and Prof. Jon Crowcroft.