world, and kaleidoscope world, all of which
could be placed on any flat surface in a larger VRML 2 world), I found my own
creative concept which I was interested in implementing. I decided to build a virtual world that
would require and emphasize collaborative and competitive behavior and provide
both as alternating goals for a participant. The world would be available for
placement on any flat object such as a table or floor. I defined the following
critical success factors for the world:
·
Demonstrate
collaborative behavior and contrast it with competitive behavior
·
Demonstrate
an appropriate use of mixing VRML and Java technologies over the internet
·
Provide
an enjoyable experience to attract prolonged attendance in the world
·
Provide
component parts that could be put together by participants in unexpected ways
·
Demonstrate
the attributes of a complex system
This chapter provides an overview of my motives behind each critical
success factor and then presents the design high points of the world.
1. Demonstrate collaborative
behavior and contrast it with competitive behavior.
I understand why people have such a difficult time defining collaboration. Everyone has a different
image in their mind when they think of the word collaborate. I wanted to
create a world that provided alternating reward structures: first for
competitive goal reaching, second for team work, and third for collaborative
goal reaching. I hoped that the different objectives would make participants
behave differently. Those different behaviors would be called competitive,
teaming and collaborative. By participating, a participant would be able to
experience the three behaviors and, hopefully, as a result have more insight
into all three.
I experimented with ways to create such a reward structure. I decided
to model the goal structure after an organization attempting to gain market
share. In an emerging market, there are at least three ways to gain absolute
market share (the number of customers) for a producer. The first way to gain
market share is by taking customers away from other organizations
(competitive). A second is by working with another producer to jointly grow
their market share (team). A third way to gain market share is by promoting the
whole industry to grow the absolute size of the market yet maintain the same
relative share (collaborative).
Much has been said and written about the merits of competition in
securing market share for a producer. Less has been documented about the merits
of collaboration. Innovation in the hamburger industry and car industry can
appear to be somewhat collaborative when each key producer adds new features to
the basic product that drives up the demand for the product as a whole (versus
other foods or forms of transportation). Collaboration can also be more direct.
For example, in a collaborative manner, the organizational members of an
industry can work together to increase the demand for their product or service.
For example, the national dairy council promotes milk for all producers of milk
through their “Got Milk?” campaign.
Of all the industries I considered, the oil industry maps more directly
to the structure of my world than others I explored. In the late 1800s, four
large oil conglomerates (called trusts at the time), dominated oil production
in the world (Standard Oil in the US, the Rothchilds in Europe, the Nobels in
Europe, and a group of Russian producers). Another participant, Royal Dutch,
joined the battle shortly thereafter as the Russian producers began losing
market share. There was much direct competition and joint ventures between two
producers were formed from time to time, yet the whole oil industry worked
together to promote oil over other forms of energy [22].
For a high-tech product or service, the marketplace may not be aware of
a new product or service. Once they become aware, they still may not understand
why they would be interested. In fact, even the venture capitalists who are
raising money to support the product or service may not be convinced of its
viability. In those cases, collaboratively building awareness of the product or
service by the producers provides a great return down the road. Taken a step
further, such collaborative gain can include standardizing the technology in
order that it works with other technologies already available to and owned by
the market. VRML is a technology following that path through the efforts of the
VRML Consortium [23]. The venture capitalists have provided funds for VRML
development with strings attached. If the market is not grown to a certain
level by a certain date, no additional funds will be forthcoming. So, there is
much interest in standardizing VRML by the technology providers.
My world gets people to think about how to collaborate in the extreme:
with people they neither know nor have ever seen. I figure such ability to
collaborate would be extremely useful if the Web is to be used effectively for
its new, unique ability of connecting any computer in the world with any other
computer at any time.
So, in my world, a participant competes to reach certain physical
locations in the world before others get there. These goals are represented by
charcoal gray filled circles which lie flat at random locations on a board.
During a competitive round, a participant attempts to win market share by
reaching the goals first. Yet, in the next round of participation in the world,
participants succeed by working together collaboratively and by attempting to
get at least one participant to each location in the shortest period of time.
If there are enough participants, a third situation can be added where
participants work as teams to confront other teams. If there are not enough
participants, computer simulated participants could be added to provide
competition or collaborative partners. Team competition is a behavior required
by many board or card games such as bridge. My world appears similar to a game,
but abstractly represents all virtual worlds that attempt to build a community
through each individual’s actions.
2. Demonstrate an
appropriate use of mixing VRML and Java technologies over the internet
In order for my world to meet the basic environmental constraints of
the technology I wish to use, I needed to create a communication system that
could overcome the latency of the internet where reliable service is not
guaranteed. I would also need to implement a solution that kept up a reasonable
frame rate. By keeping my world to a standard implementation of VRML and the
Java External Authoring Interface (EAI), I was assured certain inefficiencies
in local processing within the Web browser. Yet, I believed it was important
for me to use standard VRML in order that my world could participate as a part
of a larger virtual universe at any time. In fact, I believed that my world
could easily be put into a room of a larger environment such as the virtual 3D
chat environments I comment on in Chapter 3.
I believe that the documented constraints of client/server applications
that use VRML on the internet are not limiting in many cases. So, to prove
that, I wanted my world to be completely realized as a VRML world with Java
scripting and internet message passing using the hypertext transport protocol
(http). In my world, the latency of the internet would actually be incorporated
into the design. I believe there are many useful multi-user applications where
the response to a participant’s actions need not immediately take effect. For
example, in simulating market dynamics, a delay is quite realistic. When an
organization puts a market strategy into effect, it may take weeks or months
until the market begins to react. Many games of thought also do not require
immediacy in terms of relaying moves from a mover to all other participants. To
learn the technologies of VRML, Java scripting, and client/server
communications, I created both a Chinese checkers world and virtual billiards
table which in no way required a rapid response mechanism. Both Chinese
checkers and billiard table worlds implement a turn-taking protocol which is
consistent with their real world protocol.
Instead, the server that connects participants in my world need only be
able to conservatively estimate a latency that is a worst possible scenario and
then add a certain amount of time to it to find the least acceptable latency
for the world. The server then need only assure participants that they have not
chosen a latency that is shorter than the least acceptable latency. I intended
to build that logic into my world server. Should the minimal set latency ever
be violated, the server would simply stop the simulation until any latent
messages could be delivered.
Of course, each event that needs to be coordinated between participants
must be assured to take place at the exact same frame of the simulation. My
world has an event queue built into its design to make sure each event is
enacted at the same point of the simulation (though not at the same absolute
time). Since all other actions are encoded within the physics of the world
itself, and since each participant has that code loaded locally within their
Web browser, only the events that are queued could possibly cause the different
worlds to get out of synch.
All messages that get passed between participants in the world during
an active simulation contain a future framestamp (a term I use to refer to the
specific frame number in a simulation in which a certain state change becomes
active). By not enacting a message until every participant had received it
locally (before the agreed upon worst-case-plus latency), I would assure that
the world state would always be the same for each participant.
3. Provide an enjoyable
experience to attract prolonged attendance in the world
By prolonged attendance, I mean keeping each participant’s interest
during each session as well as an interest in returning to the world time after
time. For me, keeping a participant active in a current session until the
session was over was very important. I expect participants would be
disappointed if they lost the other participants in the simulation during the
experience. Although I envision someday having an automatic process replace the
expiring participant, I had no doubt that that would be a less desired state if
a sense of community surrounded my world. Unless, of course, the participant
was detrimentally and purposely disrupting the natural tranquillity of the
world. In any case, the basic experience in the world had to be an attractive
one.
To keep participants coming back, I figured I would need to provide a
potentially changing experience in order that a participant was never
experiencing the exact same experience each time. I also believed that I could
create a sense of community where participants would come to reunite with
participants they had enjoyed participating with in the past.
During my readings on complex systems, I realized that I would only
need to provide a few different components in the experience that changed
between visits to make the experience seem significantly different. I thought
about how different two separate games of chess become, just by altering the
first couple of moves. Participants would be making moves in my world. Yet, I
wanted to go a step further and allow the rules to change between visits. With
changing rules that could be defined and agreed upon by the participants, I
wanted my world to be flexible enough to provide a wide range of experiences.
As I document in Chapter 6, I intended to test a hypothesis about
prolonging interest in my world. My world would have enough flexibility that
participants could build the world themselves and change the rules often during
their participation. My hypothesis is that participants will be more interested
in a world where they create the design and choose the rules.
Whether or not my hypothesis is true, I wanted to build a world which
had the flexibility to change often should participants desire variability. In
the extreme, I envisioned participants emailing me with new design objects,
physics, and rules which I could make available in the world with a quick
turnaround. For those who preferred to participate in a certain fixed
configuration, I envisioned creating a library of successful variables which
any group could agree to use in a particular simulation. In other words, my
world would cater to both types of participants. Given my world architecture,
it would be easy to store and access successful combinations of design, rules,
and events.
4. Provide component parts
that could be put together by participants in unexpected ways
I wanted my world to follow a serendipitous evolution of its own. I
would provide objects and actions for the world and the participants would work
to use them in ways I could not have anticipated. By providing much power in
the hands of each participant, each participant’s thought process would be
reflected in the experience in the world. Even the component rules would be
able to be added, eliminated, or altered upon participating in the world.
Since my component parts worked so well with an object oriented
programming style and, since I would be using Java (an object-oriented
programming language) to tie together the actions of the objects in the world,
I figured I could provide individual encapsulated objects (visual, behavioral,
and rules-based) that could interact well with each other. The physics of each
visual object would be embedded within that object. There would be little that
was pre-determined about how the world played out. My world would enact the
same kind of collaboration among its code objects that it would be asking from
its participants.
Since each participant would make independent decisions about what to
do in the world and each participant would not be able to see what others were
doing until they did it, I expected to find a strong independent behavior set
coming from each participant.
5. Demonstrate the
attributes of a complex system
With all the interesting thinking I had done as a result of reading
about complexity and chaos, I wanted participants to get the same sense of
amazement about complexity as well, but not as a frustration. Hopefully, my
world would contain what looked like a manageable number of variables and a
minimal number of participants in order that a participant would feel quite
powerful in his or her ability to influence the world and others. Yet, by participating, a participant would
soon realize how complex the environment was because others were independently
trying to effect the outcome of the world at the same time as the participant.
The lessons from my world would be lessons about life. In many cases,
we are not in control of how things turn out. We are only in control of our
attempt. It can be fun to try even if the results are not what is expected. A
virtual world should be able to be a place to learn and have fun without the
goals needing to dominate the experience. I want the world learning to be about
complex systems and an individual’s ability to control his or her environment. Even in a complete and best collaborative
effort (if there is such a thing), a group is not assured of reaching a goal.
Yet the experience of being part of a group can be quite fulfilling.
Computer simulated worlds have a great benefit over physical worlds in
that they can easily be made self-documenting. As part of the experience of
building this world, I hoped to be able to save certain worlds and their events
that best demonstrated emerging behaviors that were being experienced in the
world. I hoped I could categorize certain people’s behavior and find a way to
illustrate collaborative behavior to people who were struggling to define it
for themselves. A shared world could be experienced by another group of
participants even if it were designed by a different group. A new group could
try to outperform a previous group with the same world conditions.
Design
Overview
With these goals in mind, I began coding my world. Much has been
discussed about the architecture of virtual worlds in technical papers and at
virtual reality conferences. My world would not need to address many of the
issues of world architecture as I decided that my world would be a flexible
world which could exist within the confines of a larger virtual world. My world
could exist in a room of a virtual castle, office building, or shopping mall.
Given the structure of VMRL, my world could easily be put into any other
virtual environment.
All the popular 3D multi-user worlds I reviewed in Chapter 3 provide a
large, organized world for multiple participants to explore. Yet, those worlds
lack things to do while in the world. My world is a world which could be placed
in any one of those larger worlds to provide a flexible context in which
participants can share an experience. Although I provide specific objects and
objectives for my world, it is the desire to produce a flexible and interactive
design environment that has driven my work.
Figure 5.1 A Screen Shot of Marbles World
My world does have a context which is outlined in detail in Appendix A.
A screen shot of my world in action is presented in Figure 5.1. I provide a
quick summary of how my world behaves here. A participant in my world first
clicks on check boxes to negotiate the rules for the world session with the
other participants. The rules cover how certain objects on the screen behave,
determine values for the overall physics such as a gravity coefficient and the
mass of the marbles, and decide what constitutes success (including the
competitive v. team v. collaborative decision). Once the server delivers the visual
goals for the next round, participants together design the board on which their
marbles will roll. Participants design the board by taking turns in dragging
and dropping available design objects. After they design the board, they choose
from a palette of available effects to add to their arsenal for the active
simulation round. Then, the marbles begin to roll and the world comes to life.
Participants click on the board to effect the slant of the board which dictates
the direction the marbles move. Participants also click on the effects in their
arsenal to control their marbles within the embedded physics of the world. The
active simulation continues until the agreed upon condition for ending is
triggered (for example, all goals have been reached by at least one
participant). Then, the rules setting starts again. The session continues for a
fixed number of rounds.
To code for such a world, I had a lot of architectural decisions to
make. Client/Server architecture provides great flexibility in placing
functionality at either end of a socket connection. I experimented with placing
different functions at both ends. Over time I settled on an architecture that
worked well enough to keep the frame rate acceptable on each client yet also
kept the participating clients in synch. My client/server architecture appears
as seen in Figure 5.2.
Figure 5.2 - My Client/Server Architecture
Basically, with the architecture in Figure 5.2, the client is burdened
with most of the processing. The client manages the geometry of each visual
object in the world, drives the behavior of each object from its embedded
physics, provides event handling routines for each event triggered by the
participant, calculates and presents the animation of all objects that move and
collide with other objects, and maintains a constant speed for each animation
frame loop.
In comparison, the server’s processing load is light. The server
receives messages from clients and passes them through to the other clients
involved in the simulation. The server also randomizes the placement of any
goals for the simulation and forwards their location to each client. The server
keeps its own timer to make sure participants are responding within any
established time limits. The server enforces any rules established by the
actions of the clients, effectively dropping certain client messages that go
against the established rules. The server also receives timing reports from
each client and changes the animation frame loop time for clients that are
running faster or slower than the average. The server is responsible for
keeping each client simulation in synch.
Client
My world is basically a coordinated effort between various extendible
classes which connect to a standard VRML 2 file through a standard Java External
Authoring Interface. I present an overview of the key Java client classes and
their responsibilities in Table 5.1.
Table 5.1 Alphabetical List of Project Major Classes
|
Class Name |
Functionality |
|
Animator |
The Animator class runs
the frame loop which drives the simulation. The Animator class handles
messaging between all other objects in the world by performing update and
collision management given the current state of the Rules class. |
|
Effects |
The Effects class defines
special abilities of marbles which participants can use to direct their
marbles during the active phase of the simulation. For example, the effects
class defines an anti-gravity effect a participant can use to move her marble
against the pull of gravity. The Effects class can add new effects to itself
easily at any time. The current state of an Effects object determines which
effects are made available to the participants in the world. |
|
MainWindow |
The MainWindow class
contains a question text box, answer text box, and 10 checkbox/label pairs
that can be used to ask questions to and accept answers from participants.
The answers from these questions change the state of the Rules object. The
MainWindow class can easily add new questions to itself at any time. The
current state of a MainWindow object determines which question, if any, is
currently being asked. |
|
Marbles |
The Marbles class,
inherited from the Applet class, sets up and maintains the connection between
the VRML 2 viewer and the Java virtual machine. The Marbles class also starts
the Timer, PortToServer, and Animator threads. |
|
Physics |
The Physics class defines
the behavior of the pieces that can are used during the active phase
(post-design) of the simulation. For example, the physics class contains the
behavioral logic for a pendulum. The Physics class can add new physics to
itself for pieces easily at any time. The current state of a Physics object
determines when and how objects can move during an active session of the
world. |
|
Pieces |
The Pieces class defines
the 3D geometry of the pieces that can be used during the design phase of the
simulation. For example, the pieces class contains the geometry for a
vertical barrier. Participants can add one or more vertical barriers to the
world during design. The Pieces class can add new pieces to itself easily at
any time. The current state of a Pieces object determines which visual
objects are made available to the participants in the world. |
|
PortToServer |
The PortToServer class
connects a client to the world connection server and handles incoming
messages from the server. The PortToServer class can easily add new message
handlers at any time. The current state of a PortToServer object determines
the effect incoming messages have on the world. |
|
Rules |
The Rules class contains
key attributes which define how the world behaves. Rules can be changed by
participants in the world. For example, the Rules class defines how the slant
queue loads its slants (randomly, through participant turn taking, or through
participant first come, first serve). The rules class can quickly be extended
at any time to add new rules to the world. The current state of a Rules
object dictates how the Animation class behaves during a simulation. The
Rules object changes its state based on how participants answer questions
asked by the MainWindow object. |
|
Ticker |
The Ticker class controls
the speed of the Animation thread by setting a sleep variable based on
feedback from the server. The animation then sleeps for the appropriate
period once per animation loop. |
There are also smaller classes that perform very particular roles such
as the Ball, Obstacle, Goal, Player, Arsenal, EventQueue, and SlantQueue
classes. The Ball and Obstacle classes keep track of the objects that interact
during the active phase of the simulation. The Goal class keeps track of each
goal active in the simulation. The Player class manages the scoring for each
participant. The Arsenal class manages the effects a participant has chosen for
the next round. The EventQueue class manages upcoming effects and passes them
to the Animator when the time arrives for an effect to become active. The
SlantQueue class manages the upcoming slant orientations of the world’s board
and passes them to the Animator when the time arrives for a slant to become
active.
The
Server
With my client design falling into place, I figured my world server,
written in Java, would be as simple as possible. I decided to start with a
simple message passing server that would do nothing more than pass messages
from one participant to another. The server would have no understanding of the
messages it passed and all incoming and outgoing message logic would be
contained at each client. As I worked with my design though, I found it better
that the server be aware of the speed of each participants simulation, be
responsible for creating the physical goal locations for each simulation, and
keep track of which participant was which marble. Given all possible
configurations, my server was relatively simple. I started with base classes
that handled socket creation and maintenance and added code specific to my
world. Yet, the code I added would be appropriate for many other shared virtual
worlds. In all, the server Java file contains two classes which together
connect all the participants together in a shared 3D world simulation.
Appendix A contains a primer I created that new users can use to
acclimate themselves to how the world operates. Appendix B contains my client
code as it existed during my pilot test outlined in the next chapter (Chapter
6). Appendix C contains my server code as it existed during my pilot test.
Appendix D contains my VRML world.