Home / Research / Books / Chapter 32 of Killer Game programming in Java

Chapter 32 of Killer Game programming in Java

Summary of Chapter 32 of Killer Game programming in Java

Background on NVE

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).

The current in-vogue gaming acronyms are MMORPG (Massively Multiplayer Online Role-Playing Game), MMOG, and MMO (both standing for Massive Multiplayer Online Game).

In Ultima Online and EverQuest, zones are supported by different servers, so a user who moves between zones will move between servers.

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.

Interest management permits a player to subscribe and unsubscribe to the reception of messages concerning other users, objects, or spaces … IP multicasting is often utilized to implement this mechanism, … Zone-based notification schemes are more viable due to the relatively small number of zones in a world.

assumes a globally consistent logical clock, usually implemented using synchronized local clocks on each machine.

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.

A 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).

Dead reckoning was first introduced in DARPA’s SIMNET project and was mostly concerned with updating the position of entities.

the Advanced Distributed Simulation (ADS) architecture, introduced predictive contracts,

EverQuest and Ultima Online, use multiple servers, each managing a zone, and to use a connection manager to supervise user admission

An Overview of NetTour3D

WrapNetTour3D sends messages to the server, and the monitoring of messages coming from the server is delegated to a TourWatcher object.

TourServer creates a TourServerHandler thread for each client who connects to it and stores information about the connections in a shared TourGroup object in an ArrayList of TouristInfo objects.

A TCP/IP client/server communication model is employed in NetTour3D, whereas a more realistic approach would include UDP multicasting and peer-to-peer elements and deploy some kind of connection manager.

makeContact( ) sets up an input and output stream to the server and passes the input stream to TourWatcher to monitor. TourWatcher creates distributed sprites when requested by the server, and so must know about the obstacles present in the world

The TourSprite object is passed a reference to the output stream going to the server. The object can then notify the server of its creation, and when it moves or rotates.

About Mohammad Khazab

Leave a Reply

%d bloggers like this: