Scene Creation on the Client
Background on NVEsTechnically speaking, an NVE is a computer-based artificial world of 3D spaces, visited by geographically dispersed users who interact and collaborate with each other and with objects/entities local to the world. The world's 3D spaces and their objects may be maintained/hosted by numerous computers spread around the network. In other words, it's an online place to hang out, to be seen, and to fight to the death with swords and laser cannons. The NVE is a descendant of the Multiple-User Dungeons (MUDs), text-based role-playing adventure games that achieved enormous popularity from the mid-1970s onward. In the 1990s, MUDs object oriented (MOOs) started to use object-oriented programming techniques to implement their worlds, 2D and 3D chat environments appeared, and the first multiplayer games were released. The current in-vogue gaming acronyms are MMORPG (Massively Multiplayer Online Role-Playing Game), MMOG, and MMO (both standing for Massive Multiplayer Online Game), typified by EverQuest, Asheron's Call, Ultima Online, and a growing list of others. Some sites maintain lists, news, FAQs, and reviews:
Aside from the game-playing potential for NVEs, they're the subject of much academic research. In the 1990s, DARPA's SIMNET project developed the Distributed Interactive Simulation (DIS) protocol for modeling real-world scenarios (usually military-related but also complex, distributed applications such as Air Traffic Control systems). DIS has greatly influenced the communication protocols utilized in NVEs and the utilization of real-time within the worlds. A follow-up to DIS is the High Level Architecture (HLA), focusing on support for simulations composed from multiple distributed components (see https://www.dmso.mil/public/transition/hla/). The HLA offers federation rules to govern the interactions between components, and numerous management tools, called Run-Time Infrastructure (RTI) services. These include time management (e.g., federated clocks), data distribution management (e.g., to filter user messages), and object ownership tools. Another source of ideas comes from Collaborative Virtual Environments (CVEs), which emphasize human interaction in collaborative working frameworks when the users are at different physical locations. The Elements of an NVEThe most immediately noticeable elements of an NVE are spaces, users, objects, and views. Less evident are the notions of consistency, real-time, dead reckoning, security, and scalability.
SpacesThe 3D spaces in an NVE define the world's topology. A space may be a large common area (a landscape, playground, street), a smaller private space for select groups (e.g., a conference room, gym, hall), or a place for individual interactions (an office, a kitchen). Spaces may be unchanging, or privileged users may be able to reconfigure them, delete them, or create new ones. Each space has a set of attributes, privileges, and/or security features (e.g., passwords) that govern who can use it and in what ways. The largest granularity of spaces are often known as zones and play an important role in the underlying implementation of the NVE. In Ultima Online and EverQuest, zones are supported by different servers, so a user who moves between zones will move between servers. This approach lends itself to load balancing, though a popular zone will still cause overloading. In Asheron's Call, portal storming is a mechanism for "teleporting" users away from a high-traffic zone to a randomly selected destination. Zones make message filtering easier since users only need to receive information related to their current zone. Zones may be duplicated to deal with the popularity of a particular space (e.g., the chat area, the dragon's lair), with duplicates known as shards. Duplication may make the overall system more fault-tolerant since users can be moved from a failed shard to another copy. A drawback is that friends may believe themselves to be in the same game space, but they won't meet since they're located in different shards of that space. UsersUsers in an NVE are visually represented by avatars, created by users when they first join the world. At the implementation level, a user may be denoted by two kinds of avatara local avatar present on the player's own machine, and a ghost avatar employed on all the other machines connected to the world. The avatars look the same on the screen; the differences lie at the communication layer. A local avatar may be controlled directly by the user without the overhead of the communication passing through a server first. A ghost avatar will require its state and behavior updates to be delivered over the network, which introduces the issue of latency. NVEs frequently distinguish between different groups of users (e.g., novices, gurus, farmers) with corresponding differences in their abilities to affect spaces, objects, and other users. Differing abilities lead to users forming groups to collaborate on common tasks. A task may be a CVE-style activity such as report writing, or a gaming-style objective such as treasure seeking. Collaboration usually requires a richer communications protocol to support forms of interaction such as negotiation, brokering, bargaining, contracts, task division, and result combination. ObjectsObjects in a space can be classified in various ways. Some objects may never change, such as buildings, signposts, and street fittings, and others may be mobile but still passive (e.g., coins, maps). Movement in the world may require a corresponding implementation level movement of the object's representation between machines. Objects may react when a user "triggers" themfor example, a door opening when a user touches it. A dynamic object will have its own behavior, often AI-based, allowing richer interactions with users, which may be initiated by the object. Objects are one of the ways that users communicate. This is done by giving objects to each other, by making copies for others, or by dividing a single object into smaller pieces. ViewsViews govern how a client sees a space, objects, or other users. Most multiplayer games are first-person-oriented, so the player sees little of his own avatar. However, each user will be able to employ several views into the space, which can be dynamically adjusted. Views may be abstractions, as with maps showing player activities or a list of objects currently being carried by the player. Interest management permits a player to subscribe and unsubscribe to the reception of messages concerning other users, objects, or spaces. For example, when a user changes position, all the subscribed players will be notified. IP multicasting is often utilized to implement this mechanism, though the large number of users and objects in a world may mean that the number of available multicast groups is exhausted. Zone-based notification schemes are more viable due to the relatively small number of zones in a world. Only users currently in the zone will receive updates when something changes in that zone. ConsistencyConsistency states that all users should see the same sequence of events in the same order. For instance, if user X walks through a door and user Y shoots a gun, then X, Y, and all the other users in the vicinity should see that same sequence. The problem is that the events may have occurred on geographically separated machines and that event details must be sent between the player's machines by message passing. The presentation of these events to every user in the same order implies that they can be temporally ordered. This means timestamping the events on different machines with clocks that are synchronized. Fortunately, not all users require the same level of consistency. In the above example, only users close to X and Y require complete consistency. Other users will receive the events, but their ordering may not be so critical. Real-timeReal-time requirements mean that when an event occurs at time t for one user, other users should see that event at time t as well. This assumes a globally consistent logical clock, usually implemented using synchronized local clocks on each machine. Real-time requires assumptions about typical network latency and reliability. For example, bucket synchronization relies on the setting of a suitable playback delay, derived from the network latency. If the latency increases above 100 ms, as it will over larger networks, the delay will need to be increased. This will further retard event processing, including events initiated by users on their own machine. The increased delay will degrade the application's apparent response time and will become unacceptable to the user. Another aspect of the problem is the likelihood of packet loss when utilizing UDP transmission. Moving to TCP is often ruled out since its guaranteed delivery can affect latency time severely. Dead reckoningA popular solution to the problems with real-time support is to combine UDP, timestamping, and related algorithms with dead reckoning (also known as predictive modeling). The basic idea is that each client runs simulations of the other clients in the NVE. When it comes time to update the global state on the machine, any missing data from other clients will be replaced by extrapolations taken from the simulations of those clients. Therefore, delays caused by latency and lost data are hidden. The client may run a simulation of itself and regularly compare its actual state with the one generated by the simulation. When the differences between them become too great, it can send a state update message to its peers and ask them to correct their details for the client. Consequently, state messages will probably need to be sent out less often, reducing network congestion. Dead reckoning was first introduced in DARPA's SIMNET project and was mostly concerned with updating the position of entities. For instance, the current position of an object (e.g., a tank) could be extrapolated by using its last known position and velocity or by using position, velocity, and acceleration information. Other dead reckoning algorithms take the orientation of the entity (i.e., its roll, pitch, heading) into account, and handle moving subparts. A recent DARPA initiative, the Advanced Distributed Simulation (ADS) architecture, introduced predictive contracts, which encourage extrapolations using non-physics-based equations and a wider range of object attributes. The drawback with mathematical complex algorithms is the increased cost of their calculation. A fundamental problem with dead reckoning is its assumption that an entity's state change (e.g., its movement) is predictable. This is often false for user avatars in an NVE. Another issue is deciding when a simulated state and actual state are sufficiently different to warrant the sending of update messages. If the difference threshold is too large, then the client's ghost avatar may undergo a noticeable change in position (or other attribute) when the update message is processed. If the threshold is too small, then unnecessary messages will be sent out contributing to network congestion. The means by which a simulated state is changed to the correct value is called convergence. The simplest technique is to change the state in a single step, causing the avatar to jump, jitter, or snap to a new state. Other approaches rest on the idea of gradually interpolating between the simulated state and new one. SecurityNVE security takes many forms. Within the world, security determines how users behave with each other and how they interact with spaces and objects. Active objects must be monitored since they have their own behavior and may be able to move between client and server machines. Security is usually distributed. Typically, there's a connection manager that new users must deal with before they enter the world. Internal world security is handled by the servers responsible for each zone, and/or by the client software. The drawback with delegating security to the client is the possibility that it may be circumvented by hackers. ScalabilityNVE scalability is a complex problem since an increase in world size often makes implementations based upon a single server inadequate. The typical solution used by pay-for-play models, such as EverQuest and Ultima Online, is to use multiple servers, each managing a zone, and to use a connection manager to supervise user admission. The zoning metaphor allows issues like consistency management, message volumes, and sharing to be kept under control. Zones may be duplicated across several servers to improve load balancing, dissuade some forms of hacker attack, and act as backups if a server fails. Multiple servers can be geographically dispersed to help reduce latency since international packets transfer times can easily extend beyond 200 ms. Systems may utilize peer-to-peer communication for aspects of the game that don't need monitoring (e.g., chatting). |
EAN: 2147483647
Pages: 340