Open Community Example: Playing baseball

This example demonstrates how some key pieces of the Open Community architecture fit together.

Two users meet in the ballpark region of a virtual world to play baseball. One elects to be the batter, the other the pitcher/fielder. Once both players are there, waiting for the pitch, these objects are in the shared world model:

OWNER CLASS NAME COMMENT
app spRegion BallparkRegion region of virtual space
app spThing TheBallpark ballpark object
app spVisualDefinition BallparkModel URL of VRML 2.0 model
app spVisualDefinition BaseballModel URL of VRML 2.0 model
app spBeacon HomePlate marks the spot for the batter
app spBeacon Mound marks the spot for the pitcher
app spClass Batter avatar implementation
app spClass Pitcher avatar implementation
app spClass Baseball simulation engine implementation
batter spVisualDefinition BatterModel URL of VRML 2.0 model
batter Batter TheBatter batter object
pitcher spVisualDefinition PitcherModel URL of VRML 2.0 model
pitcher Pitcher ThePitcher pitcher implementation
pitcher Baseball TheBall ball object


Java Class and Object Descriptions

For a complete description of the built-in classes, see the Java Open Community API specification.

BallparkRegion is an spRegion, a class defined by the UW API that has the network addresses needed to communicate with other clients connected to the BallparkRegion, and a URL pointing to a file containing a specification of the shape and location of this region of shared space. It has no visual appearance of its own.

BallparkModel, BaseballModel, BatterModel and PitcherModel are instances of spVisualDefinition, a class defined by the UW core API. It is a subclass of spLink, and contains a URL that names a VRML 2.0 file.

spThing is a class defined by the UW core API. It has a parent, and a transform specifying its position, orientation and scale with respect to its parent. It also has a reference to an spVisualDefinition. TheBallpark is an spThing.

spBeacons implement a name service in the virtual world. Each one contains a tag which marks the object in a way that permits it to be found by any client of the same shared world, regardless of which region contains the beacon or how far away that is from the client's current focus of attention. The world author has marked home plate and the pitcher's mound with well-known beacons so that the clients can find their way to the ball park and to their places within it.

spClass is a class defined by the UW core API. It is a subclass of spLink, and has a URL that names a file containing a Java class. Batter, Pitcher and Baseball are the Java classes that implement all of the dynamics of the game; the batter and pitcher clients each load these three Java classes. These classes are subclasses of spThing.

How it works

In this example, Open Community is being used to implement a distributed simulation, where control of an object is passed from one computer to another as the simulation progresses. The pitcher is going to throw the ball, the batter is going to try to hit it, and if he succeeds the pitcher will try to field it. While this is happening, ownership of the ball will pass from the pitcher's client to the batter's client, and back again.

The ownership model in Open Community is that the shared state of an object can only be changed by the object's current owner. In addition to what it inherits from spThing, TheBall has shared state to indicate its mode (whether it is under the direct control of its owner-either TheBatter or ThePitcher-or is a deterministic, ballistic missile), and enough information to do an accurate physical simulation of the ball's trajectory when it is under the control of the laws of physics, rather than a user. For example,

Where an instance of one of these classes is owned by the local client (e.g. as our scenario begins, TheBall is owned by the pitcher's client), that client makes changes to the object to reflect what is happening. Very soon after those changes are made, the underlying network mechanisms in an Open Community implementation arrange for those changes to be communicated where they are needed.

For this application, we can hide some latency by playing a couple of application specific tricks. At some point before the actual release of the ball, the version of ThePitcher running in the pitcher's client can go ahead and predict when and how the ball will be released, and change the state of the ball to reflect that prediction. The pitcher's client retains ownership of the ball until the actual moment the pitcher's avatar releases the ball on his client (thus retaining the ability to make last minute course corrections), and then marks the ball as being ballistic and relinquishes ownership. Meanwhile, the version of ThePitcher and TheBall running on the batter's client have been receiving these occasional state change messages and rendering something that approximates what was intended, and that will converge in the ball arriving at the same place and time in both clients.

While the ball is in the air there is time for the batter's client to take over ownership of TheBall, which allows all of the processing to determine if and how the batter's swing affects the ball to happen locally in the batter's client, with very low latency. A trick similar to that used for pitching can be used to hide some of the latency involved in communicating how the ball is struck by the bat. And once again, after it is hit and the ball is in the air, its ownership can be transferred to the pitcher's client so that his attempt to field it only involves local operations, with minimal latency.

Object Relationships

The objects used in this example are related as shown in Figure 13, which depicts all of the objects in the shared world model and their types. The arrows indicate parent-child relationships, in terms of the world model. All of these objects are descendants of the BallparkRegion, which implies that they are communicated to every client connected to that Region, and need not be communicated to anyone else.

In general it is good programming practice in Open Community for an object to carry around with it, as its children, those spLink objects it refers to. For example, in the Figure 13 TheBatter has the class which implements its behaviors as well as its visual model attached to it. This ensures that if TheBatter travels to another region (for an away game?) it will take with it those objects that will need to be communicated to the clients connected to that other region.



Michael Casey
Last modified: Sun Dec 15 14:09:55 EST