Chapter 32. A Networked Virtual Environment
This chapter utilizes the threaded client/server model, which first appeared in the multiplayer chat system in Chapter 30 and now appears in the service of a networked virtual environment (NVE).
Figure 32-1 shows the
application being run by two clients. Each window is the clients' view of the shared world, represented by a
Figure 32-1. Two visitors to the NetTour3D world
Key features demonstrated include:
A simplification in the application is that sprites cannot communicate with each other. However, adding a multiplayer chat component to NetTour3D would be easy. NetTour3D is a simple NVE, so I'll begin by describing NVEs. Information on NVEs coded in Java and Java 3D are given at the end of the chapter.
Background on NVEs
Technically speaking, an NVE is a computer-based artificial world of 3D spaces, visited by
The NVE is a descendant of the Multiple-
The current in-
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-
A follow-up to DIS is the High Level Architecture (HLA), focusing on support for simulations
Another source of ideas comes from Collaborative Virtual Environments (CVEs), which
The Elements of an NVE
The 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.
The 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
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,
Zones may be
Users 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
Objects in a space can be
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.
Views 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
Consistency 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-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
Another aspect of the problem is the
A popular solution to the problems with real-time support is to combine UDP, timestamping, and related algorithms with dead reckoning (also known as
). 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
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
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
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
The means by which a simulated state is changed to the correct value is called
. The simplest technique is to change the state in a single step,
NVE 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
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.
NVE scalability is a complex problem since an increase in world
The zoning metaphor allows issues like consistency management, message