A Project Under Development at the
Computer Science Department &
Institute for Simulation and Training
University of Central Florida
Orlando, FL 32816-2362

email: [email protected]email: [email protected]

Charles E. Hughes, J. Michael Moshell
10 December 1995

ExploreNet(tm) is a general-purpose object oriented, distributed two dimensional graphic-based computational environment with special features to support role-playing games for educational purposes, and cooperative learning of many kinds. The design goals are

1. To make ExploreNet simple enough that it can be useful and entertaining for a sixth grader (or even an adult) within a minute of first encountering it;

2. To enable ExploreNet to operate on inexpensive 486 pcs with Internet addresses, and subsequently on Macintosh computers of equivalent power.

3. Ultimately, to construct a networked cooperative work environment for the design, construction and educational deployment of ExploreNet worlds.

After constructing three prototypes between 1992 and 1994, we have largely achieved the first two goals. ExploreNet is a Windows/PC application; in the next implementation cycle we would like to build both Mac and PC versions. The third goal is the subject of intense work in 1995. The convenient authorship of multimedia materials has been revolutionized by the arrival of Mosaic/WorldWideWeb, and our strategy for authoring ExploreNet materials is based on this fact. Efforts in that direction are described in a separate document The Virtual Academy Educational Model

This document briefly describes the user interface and general architecture of ExploreNet. A more detailed description can be found in the ExploreNet User's Manual. In particular, succesive versions differ in small details which are not tracked by this general description; the User's Manual is the only source of this level of information.

Sponsors: We thank UCF, ARPA, AT&T, Microsoft, AutoDesk, ParcPlace DigiTalk, IBM and Lotus Development Corp. for their generous support of ExploreNet and the Virtual Academy. ARPA's sponsorship is as a part of the CAETI (Computer Aided Education and Training Initiative) Project.

ExploreNet(tm) and Virtual Academy(tm) are trademarks of the University of Central Florida.

Other Documents about ExploreNet

The following documents are available.

1. The Virtual Academy Educational Model

Explains why we're building ExploreNet, how we expect it to be used, and the experiments we are conducting to get from here to there. See also item 5 below for general educational background.

2. Hungerford Elementary School Experimental Report

This document describes the first major in-school trials of ExploreNet. We worked for three weeks in third, fourth and fifth grade classes at Hungerford Elementary School, a historic African-American city in Central Florida.

3. ExploreNet Reference Manual

This describes in gory detail the current software. It teaches the user how to construct worlds and interact with them. This is one of the most volatile (rapidly changing) documents in the collection because we are dynamically improving the world-building language and user interface of ExploreNet.

4. How to get ExploreNet

ExploreNet is now available for experimental use for educational or non-profit purposes. We ask that you sign a simple license agreement in which you promise not to use ExploreNet for pornographic or commercial purposes, and FAX that license back to us. We then tell you how to get the software.

5. The Virtual Academy: A Simulated Environment for Constructionist Learning is a paper which will appear in the International Journal of Human-Computer Interaction.

6. Our most recent paper is titled Shared Virtual Worlds for Education: The ExploreNet Experiment and will appear in the ACM Multimedia Journal.

7. We are currently developing tutorials to teach our students at Maitland Middle School and Coral Springs Middle School, how to build ExploreNet worlds. You can watch the tutorials grow and change, week by week.

CONTENTS

1. Purpose of the System

2. User Interface

3. File Structure

4. Communications Techniques

5. Implementation

6. Future Plans

1. Purpose of the System

History. When "virtual reality" came into the public eye in the mid-1980's, one of the first potential applications discussed was education. The idea of providing students with access to experiences that were remote in time, space or scale, or which depended on unavailable laboratory resources, was quite attractive.

However, ten years later, three dimensional immersive virtual environments (VE) remain expensive and difficult to manage. Upon reflection, many of the anticipated advantages of VE could perhaps be achieved with simpler technology. The simulation, interaction and communication aspects of VE in particular seemed amenable to relatively low-tech solutions.

In 1990, the authors encountered the Habitat system built by Farmer and Morningstar for LucasFilm (Morningstar 90). Simple cartoon-like animated figures moved through a flat-screen simulated world. They communicated by typed text messages which appeared over the characters' heads. A client program ran on one's own Commodore 64 computer which accessed a commercial on-line information service via modem. The server application supported a database consisting of a complex series of interconnected "rooms" or scenes. Objects could be picked up, moved around and exchanged between players.

The authors immediately realized that this environment offered great opportunities for education, and embarked upon building an educational version. Like many technology projects, our sense of objectives and teaching methodology co-evolved with successive versions since 1991. A broad description of the educational model of the Virtual Academy (as we now view it) is provided in another document. The following paragraph provides a brief glance.

Habitat has now led to the creation of a number of prototypical Web-based entertainment environments; for background information, see Electric Communities

Educational Model. Constructionist and constructivist theories of instructional design have had substantial play in the last decades. Students are believed to learn better thinking skills if they actively build working models of the things being understood. The creation of an internal mental model is apparently enhanced by the concrete activity of building and using ("playing with") external artifacts.

However, initial successes in constructionist experiments have proven hard to replicate in ordinary schools (Times citation.) It is not possible to provide every child with a charismatic, highly talented teacher trained in constructionist methods. Thus we asked ourselves: how can telecommunications help? In particular, if cyberspace is to provide the venue for new societies to emerge, how can we create a kind of constructionist mini-society to provide teachers and students with the guidance they need?

Virtual Theme Parks. To understand the following development, think of ExploreNet as an electronic, distributed simulation of a theme park. Details later, concepts first.

The Virtual Academy concept is based on ideas of peer support and team project development. We differentiate four levels of involvement for students (finer gradations are possible.), to wit: guest, cast member, world builder, tool builder.

* Guest: a group of students initially visits an ExploreNet world by simply "logging in" from their home classroom, as though a virtual field trip was occuring. Guests will adopt a role (an existing character within the scheme of the world they are visiting) but don't have to initially know anything about the character's background or capabilities.

* Cast Member: this group of students has been trained to act the roles of an interactive drama or "quest", for the benefit of the guests. Often the cast members are in character as animals; sometimes they are also prop or special effects managers. Cast members received their initial training in a particular world as guests.

* World Builder: this group of students and older (possibly adult) mentors has learned the necessary design and construction skills to create a specific world, with an educational theme and mission. World builders produce scripts, train cast members, observe the operation of their world and help to measure its educational effectiveness. They then modify the world for future use.

* Tool Builder: this group of students (probably high school and university students) is involved in modifying the basic tools used by World Builders to create worlds and by cast members and guests to act within those worlds.

ExploreNet itself is not a general purpose collaborative work environment. It will, however, be supported within a context of collaborative tools. For instance, IBM's Person to Person collaboration system is being investigated as a possible support system, and Lotus Notes is being investigated by the project. IBM and Lotus have each donated licenses of these products. The WorldWideWeb will also play an important role in the work of the world builders.

With this sketchy introduction we move onward to describing the ExploreNet system.

2. User Interface

ExploreNet was designed as a Microsoft Windows application, and follows most of the conventions of such applications. A two-button mouse is used, but both buttons have identical functionality. ExploreNet is a Client/Server distributed application; every computer in a given ensemble (supporting one world) must have an Internet address.

When a user initially starts up an ExploreNet client, it checks an internal list and then asks each server on that list for information about the worlds currently available. The user is then given a choice of which world to join. Normally you may only join worlds at the beginning of a session, because of the structured-story nature of interaction within a world.

Upon arriving at the initial scene of a world, the user is instructed to select (by a mouse-click on buttons at the top of the screen) one of the characters in this world. The cast members will have already chosen their characters, so the guests may only choose from among the remaining options. Typically there will be three to six cast characters and two to four guests in a world. The cast members may support more than one cast character each, because these characters tend to be active for only part of a given scenario.

The two basic classes of objects are characters and props. A character is an animated figure that can serve as the 'avatar' (local representative) of a live human, called the actor. Props, even though they may look like a human or an animal, are not normally capable of independent motion or speech. (This assumption can be overridden.)

Cursor Identification. The cursor of the system changes its appearance to inform the user what kind of object is currently being pointed at: character, prop, exit.

Eliciting actions from objects. Both props and characters have lists of actions they can perform. Each object has at least one action called "Identify", which displays a brief text description of the object. This display also describes any attributes the object may currently have. Attributes are described below.

Action menus are opened by pointing the cursor at the object and pressing the mouse button. Actions within a menu are selected by pointing at the desired action and pressing the mouse button again. The actions within a menu can change depending on the current state of the world or the object.

The actions that can be included in an object's behavior script (which defines the menu's contents) include motion, talking (emitting pre-stored strings of text.), interacting with other objects, or changing one's own appearance. Complex sequences of behavior can be defined in a scripting language and added to the menu. The specific basic actions that can be included in menus or used to build complex behaviors are described in the ExploreNet User's Manual.

Controlling a character. The mouse button controls character motion. Pointing at a screen location that is not occupied by an object and clicking causes youe currently active character to travel there (walk, run or fly depending on the character's personal script.) It is not possible to move directly on top of another character using the mouse, because a mouse-click with the cursor on an object opens that object's menu. However, the cursor keys also control character's movement, so a character can in fact go anywhere it is permitted to go. Certain fixed objects (called "backdrops", even if they are used as foreground scenery) do not respond to the cursor, and thus a character can walk behind them to hide.

Characters can also pick up, move and put down those props that are designated as possessible. To do so, they must move close to the prop. The command PICK UP then appears in the prop's menu. When selected, the prop becomes one of the character's possessions. Assume a character has just picked up a lantern .When the character's menu is opened , the option DROP LANTERN appears at the top of the character's menu, with the obvious effect - the object is dropped at the feet of the character in the scene.

Scenes. A scene contains characters and props, as well as two kinds of invisible rectangular regions: exits and action regions.

An exit leads to another scene (or even to a different location within the current scene.) Exits define the overall geography of a simulated world. Whenever a character makes a movement that ends in an exit and meets any other conditions that might be required, the actor's screen display changes to show the new scene where the character has gone.

An action region delimits the portion of the screen that can be used. By default an action region exists which protects a band of space across the top of the screen from visits by characters or props. This region is used for text which is produced when characters "speak".

Speech. At the bottom of the screen is an input line for the user to type messages. At the end of a line of input, the Enter key is pressed. The sentence then appears above the character's head. Successive utterances cause older words to scroll upward; three lines of text are visible at any time. Buttons are also found here with which one can YELL or PAGE. Yelling simply produces speech loud enough to be heard in any adjacent scene (but not in scenes which aren't directly connected to this one.) PAGE allows you to privately communicate with another character, wherever they are.

Speech remains with the scene where it occurred. Late arrivals to the scene do not see speech that occurred before they arrived (just as in real life.) Likewise, when you move to another scene, you do not take your prior speech with you.

Attributes. Characters can have any number of attributes such as "strength" or "magician". Attributes have positive integer values, which can be changed by carrying out various user defined actions or passing through exits. Actions can be made conditional on the presence and value of a given attribute. For instance, a character might have to pass through one exit before receiving the attribute "traveler", after which point a new behavior (such as SHOW YOUR SLIDES) might appear in its action menu.

We now describe the organization of files that represent an ExploreNet world.

3. File Structure

ExploreNet uses a rather large collection of very simple files to represent a world. Background scenes, props and characters are represented by eight bit bitmap images (.bmp files). A standard palette is provided and should be used for all ExploreNet bitmaps (though in fact, as long as the palette is consistent among all the bitmaps of a given world, any palette could be used.) Everything else about a world is conveyed in text files of various sorts. We describe the file types in use in the following paragraphs. The precise syntax of their contents can be found in the ExploreNet User's Manual.

World File. This file names the scenes of a world, the characters to appear in this world, and describes the characters' initial locations in the scenes. In essence the world file is the root of a tree of files, as will be seen.

Scenes are represented by several different kinds of files, all having the same file name (for instance REDHOUSE) and various three-character extensions. The extension .bmp defines the image for this scene. The other options are now explained.

Prop files have the scene's name and an extension .prp. The prop file itemizes the props to be found in a given scene and specifies their initial positions within the scene. For each prop, in turn, there is a collection of files sharing the prop's name and having different extensions. One group of them will be .bmp files with names like LOG1.bmp, LOG2.bmp, LOG3.bmp which collectively represent the various appearances of the log.

Information Files provide the contents for any Information requests about a scene or object.

Behavior Files belong to props or characters and define the contents of the action menu. A behavior file can express behaviors in terms of built-in behaviors or user defined behaviors.

Characters are described in the same way as props - by families of .bmp, .inf and .beh files.

File Organization.

The EXPLORE.NET directory contains two subdirectories titled CODE and UNIVERSE. The UNIVERSE directory in turn contains three subdirectories titled OBJECTS, SCENES and WORLDS. The World description files reside in the WORLDS subdirectory. The object files (characters and props) reside in the OBJECTS directory. The scene descriptions obviously reside in the SCENES subdirectory.

In addition, one file named EXPLORE.CFG resides directly in the EXPLORE.NET directory. Its use concerns the Internet addresses of servers, and is discussed in the next section.

Building Worlds. ExploreNet worlds are built and modified using tools external to the system itself. (Thus, you cannot modify an ExploreNet world while "inside" it, except in the simple manner of moving props around.) Any convenient bitmap editor can be used to construct scenes and objects. We use AutoDesk Animator Pro for creating animated figures and background scenes. On occasion we also make use of PhotoShop for cleaning up and reorganizing figures. We use NotePad or any other convenient text editor to operate on the various text files that define the structure of a world.

The construction of worlds by teams distributed across multiple locations has not yet begun. The beginnings of this effort is now underway; watch this space for further developments.

4. Communications Techniques

ExploreNet uses WinSock, a public domain communications resource, to access InterNet communications. When ExploreNet starts up the user is offered a choice of running the program without networking, as a client or as a server. If the server option is selected, the file EXPLORE.CFG is consulted for the Internet addresses of any available servers. ExploreNet then sends messages to these computers and inquires if an ExploreNet server is operating at that site and is available.

When this is determined for each available address, the client then offers a choice of servers to join, reporting the world being offered by each server.

Once the client has established contact with a server, the server informs the client which characters are still available for the client. As long as characters remain available, any client may request them. The server must control at least one character, and so if the server's operator has not requested one by the time only one remains, it is automatically assigned to the server.

The system then begins to operate. Actions initiated at any client node are transmitted to the server and thence to all the clients. The simulation itself (in particular, any conditional actions) is normally mediated at the client, and thus is actually carried out simultaneously at all sites. One exception concerns the possession of props. To avoid conflicts in which two characters both believe they possess a prop, this is managed at the server.

5. Implementation

ExploreNet Version 3 is written in Smalltalk/Vwin32. We chose this language because of its rich class structure and the rapid development advantages of an interpreted language. Smalltalk/V produces object files which can be freely distributed and executed, and so it will be possible to share ExploreNet 's object files without requiring the users to know anything about Smalltalk or to own Smalltalk/V.

We will not distribute the source code for ExploreNet, because the burden of adequately documenting it to make it useful to others is substantial. We plan to construct ExploreNet 4 in the next six months and will document its structure as we go along, so that we can make its source available to others when appropriate.

6. Future Plans

The principal business of the Virtual Communities Project for the rest of 1995 consists of two components:

* to steadily develop the educational model and the external support environment for distributed world building;

* to construct ExploreNet 4 based on lessons learned with ExploreNet 3.

We expect to incorporate ExploreNet 4 into the educational component of the project at some point in the late fall. ExploreNet 4 will use a different data structure for representing worlds than ExploreNet 3, and so old worlds will have to be reformulated (probably by an automatic tool) to migrate them to the new system.

References

Morningstar, Chip and Farmer, F. Randall. "The Lessons of Lucasfilm's Habitat" in Cyberspace: First Steps. Michael Benedikt, ed. MIT Press, Cambridge, MA. 1991.

This page has been visitedtimes since March 13, 1996