Figure 1. A Typical ExploreNet Screen.
Computer Science Department and
Institute for Simulation and Training
University of Central Florida, Orlando,
FL 32816, USA
13 November 1995
Abstract. ExploreNet is an experimental environment for creating and delivering networked "virtual worlds." This system's style of user interaction was inspired by the concept of a "habitat" as first articulated in the LucasFilm's Habitat system. Players enter and interact in a habitat via their animated alter egos, called "avatars." Habitats may be created for many purposes, including social interaction, entertainment and education. Our focus has been to facilitate the creation of habitats in which virtual communities of learners and mentors interact. This paper presents details of the current ExploreNet system, including its user interface, the means it provides for creating complex behaviors, details of its implementation, the outcomes of several experiments using this system, and our plans for its natural migration to a World Wide Web-based system.
Key words: Constructionism -- Distributed interactive simulation -- Distributed objects -- Graphical MUDs -- Object-oriented simulation -- Situated cognition -- Virtual communities -- Virtual worlds
1 Virtual Communities
A virtual world is an interactive computer simulation which lets its participants see, hear, use and even modify the simulated objects in a computer-created world. Participants in a successful virtual world have a deep sense of presence in that world. High performance virtual-world systems induce presence by providing immersion - i. e. by using devices such as head-mounted displays and earphones to monopolize the user's senses. (Pausch 93) Such so-called virtual reality systems raise many technical challenges, and are expected to have an impact on many aspects of human life, from immersive entertainment, to telerobotics, to training and education (Durlach 94.)
Virtual worlds can be designed for single inhabitants, such as a solo flight trainee, or for many, simultaneous participants. When a virtual world supports multiple users, it can give rise to a virtual community. Inhabitants of a virtual community have a heightened sense of presence in this artificial world, since they can communicate with each other in the context of the simulated world (Morningstar 91.) Virtual communities can provide the settings for effective teleconferencing, and for productive, remote cooperative work (Rheingold 94.) This shared presence also greatly enhances the opportunities for effective educational applications (Bricken 91, Hughes 94, Moshell 94.)
One of the lofty goals of virtual world research is to make access to information as easy as looking, and to make control of information as easy as walking and touching. Educational researchers are anxious to begin developing didactic models for using virtual worlds, without waiting for suitable immersive virtual reality systems to become available. The authors created ExploreNet to begin the learning process using technology that can be afforded in today's schools.
2 The Interdisciplinary Nature of Virtual Communities Research
There are many little-understood, complex problems concerning the creation and implementation of virtual worlds and the evolution of virtual communities. In fact, it is likely that most of the good questions have yet to be posed. Technologists are still asking the question, "How and what can we do?", but the important questions may be "How can it be used?", "Should we do it?", "What, in fact, are we doing?" and "What is the impact of what we are doing?"
Some of the issues are clearly technological -- these include advances in computer networking, parallelism, visual displays, and digitized sound. Others are on the cutting edges of research in the computing and physical sciences, involving artificial intelligence and the real-time modeling of physical phenomena (e. g. Li 93.) But many of the unexplored questions lie outside these domains. Ethical issues need to be addressed by philosophers; behavioral issues by psychologists; and applications issues by subject matter experts. Research into virtual communities is interdisciplinary by its very nature.
The design, creation, deployment, evaluation and maintenance of a virtual world require a host of different talents. In the following list, we describe each role in terms of the questions or issues these people must address.
€ Users. (How should these new users, called Guests, experience the world for the first time? What are the criteria for their evolution to more trusted visitors and eventually to the various roles played by world builders?)
€ Subject Matter Experts. (What are we trying to achieve? How can a simulation represent the needed properties and behaviors?)
€ Scenario Designers/Scriptwriters. (How is the story told? How does a user progress through the story?)
€ Graphics Artists. (What does everything look like? What visual effects are needed to achieve the desired emotions and transitions?)
€ Sound specialists. (What sounds should be produced by what actions? How should the sounds be modulated by a user's location and behavior?)
€ Behavior Modelers. (What software needs to be written to achieve the desired interactions and effects? Are some of the desired behaviors beyond the available science and technology?)
€ Cast Members -- if needed. (Are human mentors appropriate for the world? What behaviors can best be achieved by the dynamic involvement of live actors in the simulation?)
€ System Managers. (Does the running of this simulation adversely affect other uses of the delivery environment? What restrictions must be placed on the resulting simulation's use to minimize detrimental effects on existing operations?)
€ Evaluators. (What measures must be taken to investigate the system's effectiveness? Which of these measures must be designed into the virtual world or the underlying simulation software?)
€ Tool Builders. (What tools are available to ease the burdens of others? What new tools, e.g., figure editors, sound effects, software network routers, etc., need to be built?)
Building a shared virtual world that meets real needs is likely to require all the above skills, and more. The ExploreNet project team is evolving as we discover new parts of the problem. A consortium of faculty and students from various academic departments, including computer science, art, education, English, film, industrial engineering, philosophy, psychology and statistics, as well as industrial partners, K-12 teachers and students, and a number of retired individuals from the community are now involved.
3 Goals of the ExploreNet Virtual Communities Project
Our goal is to investigate the applicability of virtual communities to peer mentoring, cooperative learning, and adaptive problem-solving. Using a fully immersive virtual world would require tremendous financial resources, and today's 3d technology would severely constrain the complexity of the worlds to be used. Fortunately, rich social interactions can happen in simple environments such as Habitat (Farmer 94.) In fact, graphics is not even a requirement for social interaction, as is evident from research on interactions in textual role-playing software environments called MUDs (Multi-User Domains). (Curtis 92)
In ExploreNet simulations, the world appears as a collection of background scenes, computer-controlled objects (props), and user-controlled objects (avatars or characters). Each member of the virtual community generally controls a single character, although one player can control several characters from the same workstation. This character becomes the incarnation of the human participant within this world.
The objectives of the project include seeking answers to these questions:
€ How can virtual worlds be used to bring new human assistance to teachers and students? How can older students in other classrooms, industrial partners in their workplaces, or community volunteers, interacting from their home computers, help?
€ Can students learn better by expressing their understanding of complex subjects as simulations and acting roles within them?
€ Can improved teaching techniques such as constructionism (Harel 91) be propagated between schools by means of collaborative world-building projects?
€ What user interface and simulation techniques are best suited to the support of multi-age virtual communities? Where are the technical bottlenecks? What new tools and systems need to be invented and built?
Section 7 below describes experiments underway to address the first three questions. The remainder of this paper (Sections 4-6) describes ExploreNet's technology and discusses the system's evolution.
4 The User's Perspective
ExploreNet worlds appear to be two-dimensional; the actual technique is called 2-1/2 dimensional animation. The third (z) coordinate represents an object's depth into the screen, and is used to decide which object appears in front of another. Displays are generated using an orthographic projection; increasing z (depth) is represented by increasing the object's vertical position in the image. Moving objects have their z value set equal to their y value (which tracks the bottom of the object), so moving object A, whose "feet" are higher than those of moving object B, will appear behind B when they cross. Static props (typically used for scenery) can have z-values assigned independently of their y-values.
ExploreNet can run either stand-alone or networked. The stand-alone option is typically used by a world developer or a novice. In this mode, a single user selects a world from among those available. Available worlds are depicted by a sample scene and a textual description. When the world starts up, the user initially controls one of the world's characters, and then proceeds to alternately control different characters while exploring the selected world.
Running in the networked mode, a user can choose a world and offer it to others on the network, or can join some world already in progress (provided there are characters left to control.) Each user typically controls just one of the world's characters. It is possible to have a single node control more than one character by taking turns -- a useful option when we wish to have two or more users share a single machine.
The simple introductory world depicted in Figure 1 is named EggQuest. This world provides nine characters, and is designed for use by four students (guests) and two to five mentors (cast members.) One of the characters in this world is a nine year old girl named Zora. We will assume that you are controlling Zora's actions (she's your alter ego or character.)
Zora is actually Zora Neale Hurston, an African-American writer from Eatonville, Florida. Stories about her childhood, and African-American folklore she collected, inspired the first virtual worlds that were built in ExploreNet. (Hurston 37, Glassman 91)
Figure 1. A Typical ExploreNet Screen.
The first scene in Zora's world contains a house with a porch. The top of the screen displays a cluster of buttons for global control and inquiry, and larger buttons, one for each of the world's characters. The Zora button is highlighted to indicate that the user is currently controlling this character. Another character is made active by mouse-clicking on its image, provided it is visible in the current scene. The buttons are used to control off-screen or hidden characters. When one of these is selected, the screen image immediately changes to that character's scene.
A scene consists of five kinds of things:
€ the background; in this case, a red house.
€ characters -- people, critters, etc. that can serve as symbols for the players in the game, e.g., Zora, Zeke and Wise.
€ props -- e. g. lanterns, firewood and all sorts of other things that have behaviors.
€ backdrops -- e.g., bushes and trees which have no behaviors, but can temporarily occlude characters and props
€ portals (exits) -- they're not visible, but scenes usually give clues as to their presence.
€ regions -- these are areas within the current scene, also not visible, where characters are permitted to go.
In addition, a scene display contains text which represents the speech
of the characters in that location. Whatever is typed on the computer keyboard
appears in a work-line at the bottom of that user's screen; when the The mouse serves as a kind of browser that allows you to control characters,
props and portals. The cursor's appearance indicates what it's crossing
over. For example, the cursor appears as a footprint when you pass over
a portal. When the cursor appears as an arrow, clicking the mouse (either
with the left or right button) leads your character to that spot. When
a portal is detected, clicking the mouse leads your character there, and
allows it to pass through the portal if the associated conditions associated
with that exit are met. Props and characters are recognized by distinctive
cursor shapes. Clicking on a prop or your own character provides you with
a menu of the object's behaviors. This technique of using only single clicks,
and not differentiating the left and right buttons seems to reduce learning
time for our young users, compared to Windows' left/right mouse conventions
or Macintosh's single and double clicks.
The EggQuest world was designed by a collaboration of elementary school
teachers, high school students, university undergraduates and faculty to
support language arts classes in the 3rd through 5th grade. The immediate
objective of the teachers was to present vocabulary words in the context
of a story in which the children play active roles. At any given time,
four children are guests in the world (only two are visible in Figure 1
above.) Zora and Zeke have a guide character, in the form of the owl named
Wise. This owl is controlled by another, more experienced student, who
might be entering the world from a completely different school. Wise's
action menu includes a command which is used to allow Zora and Zeke to
leave the first scene. The intent is that such movement be blocked until
they have learned the basic skills of how to traverse and interact with
the world.
The quest posed in the world EggQuest is for the students to find and
boil eggs. To do this, they must discover and acquire the implements to
create a fire, a kettle to cook in, and, most importantly the eggs to be
cooked. The mentors act as coaches and guides; other cast members serve
as antagonists. Cooperation among the participants is essential to their
success. For example, stealing eggs from the hens is extremely difficult
for one guest, but is relatively easy for two who are working together.
Figure 2 shows a barn scene at which two of the characters, Zora and
Andy have succeeded in capturing eggs from one of the hens, placing them
in a kettle and boiling them.
Figure 2. The Egg Quest. A typical world contains props beyond those that are strictly needed
for the main action sequence. For instance, the flower that Zora is about
to pick can smile and wilt. Although props have computer-controlled behaviors,
there is no reason that the flower could not be actor-controlled, just
as the cat is managed in both ways in various versions of this world. In
fact, part of the design of a world involves a careful analysis of which
objects' behaviors should be autonomous (programmed) and which should be
actor-controlled. In all cases, however, the action of an object is based
on its current affordances, and these are based on capabilities and the
past history of the world. For example, a kettle can cook eggs only if
the kettle is placed on firewood that is lit.
5 Constructing a World
Since our goal with the current version of ExploreNet was to test ideas
about the educational benefits of participating in virtual communities,
we have not put a great deal of effort into the development of tools for
authoring these worlds. A later section will discuss our intentions of
converting ExploreNet into a Web-based system that can easily take advantage
of existing and evolving authoring tools for Web pages. For now, we will
describe the rather primitive language that one uses to author within the
existing system. Our objective is to use this scripting language as a means
to help identify a minimal set of capabilities required of any subsequent
authoring scheme.
After an ExploreNet world is designed, the first implementation step
is to create, or reuse art work for backgrounds, characters and props.
Backgrounds are just flat two-dimensional images. Characters and props
typically require a number of poses. Simple walking can usually be expressed
in three to ten poses. The flower has eighteen poses, allowing it to smoothly
transition from normal to smiling, and from smiling to wilted.
A world's structure is described in a simple scripting language. The
script specifies which props belong in each scene of the world. The script
also specifies the scenes and characters that comprise the world, and the
initial position (scene and location within the scene) and the attributes
of each character. Simple behaviors like walking (e.g., for a character),
toggling (e.g., for a light switch), cycling (e.g., for a fan), and being
possessible (e.g., for a lantern) are easily specified by declaring that
an object belongs to the corresponding class. Some complex action classes,
like being a sage (a computer-controlled character that can provide guidance
and information) are provided. New behaviors, e.g., a flower that smiles
or a cat that steals unguarded eggs, can be scripted. User-scripted actions
are specified in a simple language to be described below.
The notion of attributes is critical to the operation of ExploreNet
worlds. Each object (character, prop, scene or the entire world) can possess
story-specific attributes. An attribute is represented by an arbitrary
symbolic name and a corresponding strength or value (non-negative integers).
If an attribute is absent, its strength is zero. For instance, the firewood
can have the attribute "ablaze".
All scripted behaviors have four parts:
€ a set of preconditions that must be met for the behavior
to be enabled;
€ a name through which the behavior can be invoked;
€ a sequence of actions that implement the behavior; and
€ a set of attribute changes that result from having performed
this behavior.
The preconditions include tests for the presence or absence of certain
attributes, the presence or absence of certain neighbors in the current
scene, the presence or absence of certain possessions, and the identity
of the character requesting this behavior.
As an example, consider the following behavior that describes when and
how the Wood can be extinguished. Comments are indicated with colons; bold-face
lines are actual commands in the scripting language. Predicates such as
"attributes" refer to the behaving object ("Self' from a Smalltalk viewpoint);
references to other objects' attributes, possessions etc. are referred
to by prefixing the object's identity to the predicate. For instance, Wood.attributes(~ablaze)
would allow another object's method to refer to this object's attribute.
: Precondition is that the Wood is already ablaze.
A slightly more complex behavior is the behavior of Zora (Zeke, Anna
or Andy) to light the Firewood.
: Precondition is that the character can light the Wood.
Actions defined in this fashion have two uses. First, they define action
items that appear in objects' action menus; e. g. "Light Firewood With
Lantern". Second, they define methods that can be invoked in the definition
of other actions. The standard pattern of preconditions, menu item, resulting
action and changes to attributes is used extensively in ExploreNet scripts.
For example, the Redhouse scene has just one portal leading to left along
the path that runs by the house. This portal is used to enter a scene having
a bundle of firewood and a lantern. Guests must travel through this area
before going to the Barn scene.
: Conditions for passing through this portal.
Portals are described by rectangles. This is a bit restrictive in two
ways. First, it doesn't allow for irregularly shaped portals -- a collection
of triangles might be better. Second, it's a two dimensional structure.
This has not proven to be a significant limitation in practice.
Another place where attributes are particularly useful is with non-player
characters (props that look like characters, but are computer-controlled).
Assigning a prop the behavior named "inquirer" results in an "Asks Questions..."
behavior being added to the object's menu of actions. Selecting that action
produces a menu containing a series of questions. Selecting a question
causes the character to ask a question, and then wait. The user must then
provide an answer. Attributes (and thus the course of the story) are changed,
depending on the answers.
Similarly, the behavior called "sage" causes an option titled "Answers
Questions..." to appear in the object's action menu. When this option is
selected, a sub-menu appears and displays a series of topics (questions
that you can ask this character.) You can select any of the listed topics
and receive the corresponding piece of information. Both inquirers and
sages' scripts can contain preconditions, so that the questions and answers
can change as the simulation's state evolves. As a simple example, we could
have designed the owl, Wise, to be a sage, with behaviors like the following.
:------------------------------
:------------------------------
Even though this is not a good example of a patient mentor, the above
example of how to chain together questions and answers shows how you can
chain together causes and effects of all kinds, to 'steer' the player's
experience within an ExploreNet world.
A final example of this scripting shows how a non-player controlled
Cat can be a rather unpleasant antagonist in the EggQuest world. To implement
this automatic behavior we found it useful to include a notion of an "Initialize"
behavior. Specifically, if any object (prop or character) has a behavior
named Initialize, ExploreNet executes this behavior at the very start of
a world's simulation. Our Cat has the following Initialize.
: PRIVATE means that this can never appear in a behavior menu.
The egg stealing behavior, scheduled for every 30 seconds, has a number
of preconditions. In particular, the cat never tries to steal the eggs
from a hot kettle.
: SCHEDULED is an attribute that is set for scheduled events.
The complete syntax of the command language is available from the ExploreNet
User's Manual, which is available at the ExploreNet World Wide Web site
(UCF 95.) Access to this documentation and the associated software is free-of-charge
for non-profit experimental use.
6 Implementation Issues
6.1 Distributed Object Management
ExploreNet is implemented in Digitalk's Smalltalk. The object-oriented
features of Smalltalk provide an excellent platform for developing behavior
hierarchies. Inheritance is used extensively in the case of characters
and props, which have much in common. ExploreNet implements its own distributed
object management system, based on concepts associated with the U. S. military's
distributed interactive simulation (DIS) effort (Blau 93, Orlansky 91)
The Distributed Interactive Simulation (DIS 2.0) Protocol is a military
standard and IEEE draft standard, which provides a model for the task of
linking two virtual worlds together (IST 93.) Central to DIS is the notion
of a single player and many ghost entities associated with each simulation
object. A player entity exists on the network node where the behaviors
of this object are controlled (i. e. where the human "player" is actually
controlling the player entity.) In ExploreNet, this could be the machine
controlling a character such as Zora, or the server which is responsible
for all props. The player entity maintains a precise model of the current
state of the object. Each player entity has an associated ghost entity
on every machine participating in the simulation. Ghosts are approximations
to players. They display themselves on each of the other machines, and
their approximation is good enough with regard to simple movement, but
not necessarily with regard to attribute values. Thus, for instance, decisions
about when an object passes through a portal are never made by ghosts.
Rather, player objects explicitly instruct their ghosts when an exit through
a portal is warranted.
In ExploreNet's class hierarchy, an abstract class called ExploreObject
provides the protocol that is standard for all props and characters. This
class has three children, Avatar, Prop and BackDrop. Avatar, in turn, is
abstract, specifying the common protocol for players and ghosts. Its two
child classes are OwnAvatar and GhostAvatar. A character in a world has
only one associated instantiation of OwnAvatar, but many (one per participating
node) instantiations of GhostAvatar.
Figure 3. Portion of ExploreNet class hierarchy. Keeping with principles established in DIS, we also implement a "self
healing" protocol. For instance, if a movement message is lost, a subsequent
movement will bring the ghosts back in line. This is true even if a portal
was passed through, since movement messages include not only the position
of movement, but also the destination scene and the orientation (frame
and direction) of the object. Messages related to prop manipulations are
equally complete. Moreover, the server node can transmit a resynchronizing
message to any node that requests this service. This provides complete
state information, and is used whenever new users enter the simulated world,
since they must "catch up" with the other participants.
6.2 Client/Server Architecture
The military's DIS paradigm was designed to minimize network traffic.
An additional objective is to optimize user interaction with the dynamic
version (the "player entity") of the principal object. However, military
DIS presupposes a true broadcasting environment in which all nodes can
hear all traffic. A practical Internet-based simulation system like ExploreNet
needs to use point-to-point or multicast communication. At this stage we
have chosen to use point-to-point, assigning an ExploreNet server for a
given world the primary role of redistributing packets sent by player objects.
Clients never send messages directly to other clients. All client initiated
messages go to the server, which orders the messages to provide a consistent
view of the object-space for all participating nodes.
The basic philosophy has been to keep decisions decentralized whenever
possible and to centralize them only when necessary. Certain local
acts such as examining props' current states, or reviewing the dialog,
have no effect on the world's state and so generate no traffic. Movement,
new dialog and attempts to pick up new props do, however, affect all potential
participants in the scene; these actions must be communicated and possibly
arbitrated.
As an example, picking up a prop requires arbitration since more than
one character may attempt to do this simultaneously. After arbitration
the message is sent out to all nodes, even the originating node. In general,
an originating node may have already have executed the action (if it was
an allowable unconditional action) or may only carry it out when this authorizing
message arrives.
6.3 Information Transmission for Distributed Objects
When a client makes a change which should be shared, a message is sent
which includes the client's identity, the name of the receiving object,
the method called and any arguments. All this information is formatted
as a string. Receiving nodes look up the receiver's name in a dictionary,
and issue a method call to the actual Smalltalk object. Since the parameters
are passed as strings; the receiving object must recast them (e. g. by
looking up the name of another object being referred to in the string.)
This technique has made the system easy to extend, as the distributed nature
of objects is maintained by simply adding string names and corresponding
local objects to the dictionary when new objects are introduced.
6.4 Network Management
Network services and message sending in ExploreNet are implemented using
the TCP/IP support provided by Microsoft WinSocket compliant dynamic link
libraries. We have tested our code with several such packages, including
the Microsoft, Chameleon and Trumpet implementations.
Server nodes offer two types of network services. One is a world name
service in which the server offers the name of the world it is running.
The other is a join service through which clients express their intent
to join the world. The server regularly listens for client connections
to these sockets. Client nodes query the network for nodes providing ExploreNet
world name service. At present, each ExploreNet system has a configuration
file that lists the IP addresses, or equivalent names, of potential server
nodes. The client tries to connect to the world name service on each of
these nodes. For each responding node, the client receives a message from
the server, indicating the name of the world.
Once a client chooses to participate in a world, the server provides
the names of available characters. Once the client chooses a character
(provided this character is still available), the server provides current
state information and then keeps this client informed of all subsequent
world activities.
7 The Educational Model of the Virtual Academy
The teaching model we are using is a simple one, resembling the operation
of the Girl Scouts or Boy Scouts. Under the leadership of teachers and
adult volunteers, students learn how to construct virtual worlds that teach
specific (teacher-chosen) concepts to other students. The students themselves
have a large amount of control over the kinds of situations and simulations
that are constructed to convey these concepts. This gives the students
an ownership stake in the work. The overall concept is referred to as The
Virtual Academy.
When a new school first joins the Virtual Academy, groups of students
enter a virtual world as "guests". They might be visiting ancient
Egypt or the human circulatory system. They encounter other live human
beings ("cast members") who play roles needed to make the simulation effective.
After gaining experience as guests, students are promoted to cast members.
They are responsible for learning the appropriate facts and behaviors about
the world they are simulating. Ultimately they are invited to become "world
builders" -- that is, to script and create new worlds in which other kids,
in turn, play the roles of guests and cast members.
Constructionism is a theory of learning which is based on the idea of
students building physical, working systems that embody their understandings
of relationships (Harel 91.) The idealism of the paradigm has been attacked
as difficult to replicate or sustain (Holden 89); there seems to be a strong
dependence on unique charismatic teachers and advocates for change. One
of the Virtual Academy's main goals is provide a mechanism to overcome
this objection.
Specifically, the Virtual Academy's response to this problem is to create
a new social mechanism whereby the necessary teaching and mentoring is
largely provided by peers. The Coalition of Essential Schools is an example
of a highly successful school-change movement based on the principle of
"student as worker" (Sizer 92.) For this reason, we recruited the Coalition
as one of the founding organizations of the Virtual Academy.
8 Initial Experiments
8.1 First Trial of the Guest/Cast Relationship
In the spring of 1995, ExploreNet was tested by approximately 100 students
at Hungerford
Elementary School in Eatonville, Florida. The cast/guest relationship
was the focus of the experiment.
Mentors, represented by animals within the virtual world, were not much
used as sources of information by the Guests. The tendency was to seek
help from available adults rather than on-screen animal guides. This may
be because speech is easier than typing and reading, or because the adults
were available and were not instructed to stay quiet. Some students said
that they want to be able to talk to other characters more easily. Also,
adults, conveniently close by, represent authority in traditional classroom
culture. Sometimes when students asked for help and it wasn't available,
they would simply wait rather than "talk" to the animal guides or observe
others.
The most frequent question was "how do I ..." and was almost always
asked of an adult mentor; occasionally of a student sitting alongside;
and almost never of an on-screen character. This experiment clearly showed
us a number of problems with the user interface, and emphasized the importance
of continuing to refine the communications capabilities of the system.
8.2 A Second Trial of the Guest/Cast Relationship
On 3 November 1995, eight students from the multimedia class at Maitland
(FL) Middle School were exposed to the Egg Quest game. The students are
seventh and eighth graders; their individual maturity levels and backgrounds
vary enough that there is no real differentiation in the two age groups'
behavior or computer skills. Six girls and two boys participated.
Four of the students served as Cast Members, with two of them playing
the roles of the mentors (Jake the Dog, Wise the Owl) and two others playing
the chickens. (In this version of EggQuest the cat behaves automatically.)
No explicit instructions were given with regard to teamwork or individual
pursuit of goals. The Cast Members were instructed on the overall sequence
of the game (though they had never experienced it as Guests) and they were
instructed not to think of themselves as players -- but to guide the experience
of the players. Almost no "how do I..." questions were addressed to the
adult supervisors in this trial, apparently due to better initial training
and the use of older subjects.
The students enjoyed the game and the cast members generally managed
to act as mentors (dog, owl) or as adversaries (the chickens) rather than
breaking the paradigm and playing the game themselves (as happened with
younger students during the Hungerford trials.) However, neither the Cast
Members nor the Guests worked cooperatively among their respective groups.
The students who acquired props were generally unwilling to set them
down for joint use, because they were convinced that other students' characters
would just grab them and run off. It took a substantial amount of luck
and timing to achieve the initial egg-pickup, because four guests and two
cast members (hens) were all sitting right on top of the eggs and nobody
would move away. Similar things happened with the steps necessary to combine
the lantern and firewood to make a fire.
The students preferred to speak out loud to other players rather than
typing messages. On occasion they would shout across from the Cast side
to the Guest side or vice versa. They generally ignored typed messages.
8.3 Observations on Second Trial
When we asked for specific feedback, the students requested a means
of private communication, even though this capability already exists. Initial
instruction should include a demonstration of this built-in feature.
Difficulty in picking up objects was the most annoying aspect of the
system. The real problem appeared to be a lack of cooperation that resulted
in everyone standing on top of the objects. For those of us who have coached
youth soccer, it was reminiscent of hoping for teamwork but getting a wave
of kids all trying to kick the ball at the same time. The innate competitive
urge and the emphasis on individualism in our current teaching model seemed
not to inspire spontaneous cooperation.
The experimenters were careful to say nothing about teamwork, individual
work or whether the game could be "won". Several students retrospectively
commented on how cooperation would have improved their experience of the
quest.
We are anxious to see how physical distance and experience influence
the way students interact. In 1996 we expect to conduct a wider circle
of experiments in schools, including at least one Department of Defense
Dependents' School in Germany. Having Guest and Cast separated so that
direct speech is unavailable, and making the story's development depend
more on Cast Members' actions, are priority items for experimentation.
8.4 World Building.
In the fall of 1995, Coral Springs Middle School (a member of the Coalition
of Essential Schools) and Maitland Middle School are collaborating to develop
world-building concepts and skills. The first months of this process were
devoted to teaching the students in both schools how to build World Wide
Web pages, as the needed skills and tools are quite similar to those used
for building ExploreNet worlds.
As of this writing, each school is building worlds which will be tested
long-distance by the other school in the upcoming months. Coral Springs'
students have elected to build a world concerning the extinction of whole
species of dinosaurs, while Maitland's world involves daily life and individual
survival of dinosaurs. The similar themes allow reuse of animated figures
and scenes, while providing opportunities for contrasting story development.
Simultaneously, a group of university students at UCF are constructing
a world based on Greek mythology. Their world will be tested on Maitland
students in the upcoming weeks. A third group of students at the University
of Texas/Austin, who have already developed textual MUDs embodying their
knowledge of classical Greece and other venues, are demonstrating their
work to UCF and Maitland students, and preparing to build ExploreNet worlds.
Home-bound and hospital-bound students in Orange County Public Schools
are developing Web- and ExploreNet world-building skills in order to serve
as creative consultants to in-school project teams. The home/hospital students
have more time flexibility than in-school students, so they can actually
support in-class activities better than school-bound students can support
their peers. They are highly motivated, and enjoy being given a responsible
task. Communications have thus far been via e-mail and MUDs; new tools
such as Timbuktu (Farallon 1995) are now being added.
9 A Situated-Cognition Experiment
In collaboration with our UCF colleague Dr. Rebecca Parsons, we are
now designing a project involving situated learning (Brown 89). This approach
to curricular design emphasizes the creation of extended meaningful contexts,
in which students must solve various problems embedded in a story line.
ExploreNet extends this paradigm by providing first-person involvement
in the simulated world.
Role modeling through interactive role-playing and remote multi-age
mentoring are essential components of the new project. The context in which
these occur are scenarios inspired by the work of a prominent female geneticist
in the real world. In our simulated genetics laboratory, participating
students will initially play the roles of laboratory assistants. More experienced
students will mentor novices by playing the roles of senior staff members.
The primary goal of this project is to understand the impact of networked
role-playing scenario-based science education on the retention of girls
in science fields. We believe that this approach will make science more
approachable to girls and will facilitate continued interest in science
from girls. The project pursues these goals by focusing on the utility
of science in the real world, by providing visual role models of women
in scientific leadership positions, and by fostering a sense of cooperation
among the participants.
The innovative aspects of this initiative include:
€ The focus on empowerment through personal relationships in
the learning process. This should provide an environment within which girls
will be encouraged and motivated to learn, excel and continue participation.
€ The ability, due to the aliasing effect of ExploreNet, to
test the effect of gender in the role playing environment. A child or adult
of either gender could assume a female character or a male character; the
identity of the actor is hidden from the participants.
€ The use of ExploreNet and other multimedia tools to foster
the development of peer mentoring relationships.
The simulated laboratory itself will include a community of "virtual
creatures" that will be the focus of the genetics experiments. On most
occasions only a few individual creatures at a time are graphically rendered.
The community simulation will have data gathering capabilities to facilitate
students asking questions about various properties of the population, such
as "How many green creatures are there?", or "What is the distribution
of expressed characteristics for this gene?"
10 Lessons Learned and Future Directions
We have been encouraged by the positive response of students and teachers
to the concepts embodied in ExploreNet and the Virtual Academy. The number
of university students and adult community members who volunteer on-line
or in-person mentoring time for the middle school students is steadily
increasing. The discovery of the usefulness and enthusiasm of hospital/home-bound
students has been exhilarating for all concerned. The ExploreNet user interface
is convenient and easily learned. Middle school students can effectively
serve as Cast Members to guide the Guest experiences of other students.
The principal focus for our educational research in 1996 will be to
improve our understanding of world building and multi-school collaboration.
We need to locate free or inexpensive, easily used graphical software tools
-- or build them. In advanced development are sound-effects and speech-output
capabilities, and scripting/authoring tools. These will be deployed in
early 1996 for use in world-building curricular experiments.
The current version (November 1995) of ExploreNet is available for experimental
use by non-profit entities (UCF 95) and is being tested at several sites
in Europe, Asia and the U. S. The next version of ExploreNet will be integrated
with World Wide Web technology and tools. Current HTML standards easily
support our models for initiating new worlds, and finding and joining current
worlds (W3C 1995.) It seems that new classes of behaviors can conveniently
be implemented and distributed through Java (Sun 1995.) However, convenient
ways for children to easily script new composite behaviors from existing
primitives are not so obvious. We will be exploring these and many other
issues n conjunction with the ARPA CAETI Project (Bellman 1995.)
Acknowledgments.
Partial support for this research was provided by the University of
Central Florida's Strategic Planning Initiatives Program, the National
Science Foundation under NSF Grant # CDA-9115281, and the Advanced Research
Project Agency's CAETI Program. Software and hardware have been provided
by AT&T, AutoDesk, Euphonix, IBM, Lotus, ParcPlace-Digitalk and Microsoft.
The active support of UCF's Computer Science Department and Institute for
Simulation and Training, the Orange County Public Schools and the Coalition
of Essential Schools at Brown University has been invaluable. The project's
participants are too numerous to mention, but the particular contributions
of Terry Frederick, Daniel Tan (Nanyang Technological University, Singapore),
Mark Kilby, Don Jones and Homer Whittaker have been outstanding.
References.
Bellman, K. Computer Aided Education and Training Initiative (CAETI).
Advanced Research Projects Agency, Washington, DC. 1995. Available on Web
via URL http://www.csto.arpa.mil/ResearchAreas/CAETI.html.
Blau, B., Moshell, J. M. and McDonald, B. "The DIS (Distributed Interactive
Simulation) Protocols and their Application to Virtual Environments." VR
World 2:1, Meckler Inc., Westport, Conn, 1993.
Bricken, M. "Virtual Reality Learning Environments: Potentials and Challenges."
Computer Graphics, July 1991.
Brown, J. S., Collins, A., and Duguid, P. "Situated cognition and the
culture of learning." Educational Researcher 18:1, 1989, pp. 32-42.
Curtis, P. "Mudding: Social Phenomena in Text-Based Virtual Realities."
Proceedings of DIAC T92, 1992. Available via anonymous ftp from
parcftp.xerox.com/pub/MOO/papers/DIAC92.{ps,
txt}.
Durlach, N. and Mavors, A. S. Virtual Reality: Scientific and Technological
Challenges." National Academy Press, Washington, DC. 1994.
Farallon. Timbuktu. Farallon Computing, Inc., Alameda, CA. 1995.
Farmer, F. Randall. "The Social Dimensions of Habitat's Citizens" in
The Virtual Reality Casebook. C. E. Loeffler and Tim Anderson, ed.
Van Nostrand Rheinhold, New York, 1994, pp. 118-122.
Glassman, S. and Seidel, K. Zora in Florida. University of Central
Florida Press, Orlando, FL, 1991.
Harel, Idit and Papert, Seymour. Constructionism. Ablex Publishing
Corporation, Norwood, NJ. 1991.
Holden, C. "Computers make slow progress in class." Science,
244, pp. 906-909. 1989.
Hughes, C. E. and Moshell, J. M. "ExploreNet" in The Virtual Reality
Casebook. C. E. Loeffler and Tim Anderson, ed. Van Nostrand Rheinhold,
New York, 1994, pp. 118-122.
Hurston, Z. N. Their Eyes Were Watching God. J. B. Lippincort,
Philadelphia, 1937. Republished by Harper & Row, New York, 1990.
IST (Institute for Simulation and Training.) Distributed Interactive
Simulation Operational Concept (2.3). IST-TR-93-25. Orlando, FL. 1993.
Li, X. and Moshell, J. M. "Modeling Soil: Realtime Dynamic Models of
Soil Slippage and Soil Manipulation." Computer Graphics 24:4, 1993.
Morningstar, C. and Farmer, F. Randall. "The Lessons of Lucasfilm's
Habitat" in Cyberspace: First Steps. M. Benedikt, ed. MIT Press,
Cambridge, MA. 1991.
Moshell, J. M. and Hughes, C. E. "The Virtual Academy: Networked Simulation
and the Future of Education." Proceedings of the Imagina Conference,
Monte Carlo, February, 1994.
Orlansky, J. and Thorp, J. "SIMNET - An engagement training system for
tactical warfare." Journal of Defense Research 20:2, 1991.
Pausch, R., Robertson, G. G., Card, S. K., Mackinlay, J. D. and Moshell,
J. M. "Three Views of Virtual Reality." IEEE Computer 26:2, 1993.
Rheingold, H. Virtual Communities. Summit Books (Simon and Schuster),
New York. 1993.
Sizer, Theodore R. Horace's School: Redesigning the American High
School. Houghton Mifflin Co., Boston, MA. 1992.
Stephenson, Neal. Snow Crash. Bantam Books, New York. 1992.
SUN. Java(tm): Programming for the Internet. Sun Microsystems,
Mountain View, CA. 1995. Documentation and software available on Web via
URL http://java.sun.com/.
UCF. ExploreNet(tm). University of Central Florida, Orlando,
FL. 1995. Documentation and software available on Web via URL http://www.cs.ucf.edu/~ExploreNet.
W3C. HyperText Markup Language (HTML). The World Wide Web Consortium,
Boston, MA. 1995. Documentation available on Web via URL http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.html
Correspondence to: Charles E. Hughes
1 The term "avatar" to denote an on-screen animated figure representing
a player was introduced by the authors of the Habitat system [Morningstar
91] and independently in Snow Crash [Stephenson 92.]
attributes (ablaze)
: If the preconditions are met then we can extinguish the fire.
: This is the name of the behavior appearing in the Wood's menu of
: affordances.
Extinguish
: Here's the script that animates the extinguishing of the fire.
: The Firewood goes back to its first pose -- no fire.
restingFrame 1
: The Firewood is no longer ablaze.
~ablaze
: Character must possess the lantern, the Firewood must be in the scene,
: and the Firewood must not be ablaze.
possessions(Lantern) neighbors(Wood) Wood.attributes(~ablaze)
: If the preconditions are met then we can light the fire.
: This is the name of the behavior appearing in the character's menu
of
: affordances.
Light Firewood with Lantern
: Here's the script that animates the lighting of the fire.
: The character walks over to the Firewood and drops the lantern.
walkNearObject Firewood;
drop Lantern;
: The Firewood does whatever is required to make it appear on fire.
Firewood ignite
: There are no changes to the character's attributes.
NONE
: canExplore is an attribute assigned by the owl, Wise.
: This allows a mentor to instruct new guests before letting them
: loose to explore the world.
attributes (canExplore)
: Which scene do you go to?
Field
: Where do you emerge in that scene (x,y)?
900 500
: Capture rectangular zone of portal:
: Upper left (x,y) and (width, height) in pixels:
0 0 100 1000
: There are no consequences of passing through the portal.
NONE
: Condition for utterance 1: I haven't told you this yet and you haven't
: annoyed me by asking too often.
:------------------------------
attributes (~informed ~annoying)
: You can ask me how to move through a portal.
How do I exit this scene?
: This is my answer.
You click a mouse button when the cursor looks like a foot.
:----Note: This means 'the next time you ask me', because
:----we set the 'informed' attribute to show we've been asked once.
informed
: Condition for utterance 2: I've told you this once already.
:------------------------------
attributes (informed ~annoying)
: You can ask me again how to move through a portal.
How do I exit this scene?
: This is my answer.
Remember, you click on the mouse when the cursor looks like a foot.
:----You're one annoying dude. I won't give you this info any more.
annoying
PRIVATE
: Executed at start of world
Initialize
: Schedule an attempt to steal eggs after 30 seconds.
: This behavior is retried every 30 seconds whether or not it succeeds.
scheduleRepeatedAction StealEggs 30
: No attributes are changed
NONE
: It cannot be set by any other means.
SCHEDULED kettle.possessions(egg) kettle.attributes(~hot)
: This action never shows up in a behavior menu.
Steal Egg
: Grab the egg and run
flyNearObject egg; pickUp egg;
flyNearObject bush; drop eggs;
flyToObject bush
: No attributes are changed
NONE
Footnotes:
