A Project No Longer in Development 
Computer Science Department 
University of Central Florida

Horizontal red line.

mailbox email: ceh@cs.ucf.edu    mailbox email: moshell@cs.ucf.edu

horizontal red line

Charles E. Hughes, J. Michael Moshell

Latest News

2 July 1997. The last relaese of ExploreNet, affectionately called V3.5-014, is now available at http://www.cs.ucf.edu/~ExploreNet/ExploreNet.zip.

15 February 1997. Several of our third grade test sites in Germany have now had successful excursions through AutoLand. Apparently, these third graders are quick enough to acquire all the needed raw material, bring this to refineries, and haul all the refined products to Detroit so that they complete an entire car in 15 to 20 minutes. Our congratulations go to the children and our sincerest thanks go to their patient, creative teachers.

Barn with two chickens on nest, nine year old Zora standing in front.

ExploreNet(tm) is a general-purpose object oriented, distributed two dimensional graphic-based computational environment with 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 PCs (25MHz 486's) with Internet addresses.

3. Ultimately, to construct a platform-independent 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. The current version of ExploreNet is a Windows/PC application written in the Smalltalk language; we are now building a platform independent version in pure Java. The convenient authorship of multimedia materials has been revolutionized by the arrival of Java-enabled WorldWide Web browsers, and our strategy for authoring ExploreNet materials is based on this fact. the principles behind that effort are described in a separate document The Virtual Academy Educational Model.

This document briefly describes the user interface and general architecture of the current released version 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, DARPA, AT&T, AutoDesk, Microsoft, ParcPlace (the DigiTalk group), and IBM. for their generous support of ExploreNet and the Virtual Academy. DARPA's support was as a part of the CAETI (Computer Aided Education and Training Initiative) Project.

ExploreNettm and Virtual Academytm 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 appeared 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 have also developed tutorials that were used to teach our students at Maitland Middle School and Coral Springs Middle School, how to build ExploreNet worlds


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, over a decade 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, widely available solutions.

In 1990, the authors encountered the Habitatsystem 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. 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 yet a general purpose collaborative work environment. It can, however, be supported within a context of stand-alone collaborative tools. The Java version under development will provide an integrated set of these tools.

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 join worlds at the beginning of a session, because of the structured-story nature of interaction within a world, although the software does not preclude late entry to a world.

Red old-Florida-style frame house with palm tree to left, Zora and Zeke and the owl on the front porch.

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 there is no restriction on movement.

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 all the world's scenes. 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.

Backdrop files are just like prop files, except they use the xtension .drp and can have a scene depth independent of their scene height. In contrast, all props and characters have their depth tied to their screen height, just like in ancient Chinese art.

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 one directory for each world, and a HISTORY. Each world directory's name is the corresponding world name. These directories contain two subdirectories titled OBJECTS, SCENES. Each world's description file and an optional preview image reside in the world's subdirectory. The object files for a given world (characters and props) reside in the OBJECTS directory for that world. 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 Paint Shop Pro and occasionally AutoDesk Animator Pro for creating animated figures and background scenes. Sometimes we also make use of PhotoShop for cleaning up and reorganizing figures. We use WordPad 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 server option is selected, the user gets to choose among the worlds that are available. Commonly, the user then selects one or more characters and then for clients to arrive, who will then select the other characters. Alternatively, the user running the server can initially select all the characters, and then dole some subset of these out for later arriving clients.

If the client option is selected, the file EXPLORE.CFG is consulted for the Internet addresses of any available servers. If this file starts with a line containing just a question mark (?), then the next line contains a default server IP address. The user is asked to confirm use of this address. If the file contains just one address, this is automatically chosen, provided it's running ExploreNet in server mode. When multiple addresses are specified, ExploreNet sends messages to each of 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

All releases of ExploreNet Version 3 are written in Smalltalk/V win32. We chose this language because of its rich object-oriented 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 is possible to share ExploreNet 's object files without requiring 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 are now constructing ExploreNet Version 4 in Java. We plan to make its source available to others when appropriate.

6. Future Plans

The principal business of the Virtual Communities Project for the rest of 1997 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 (hopefully by an automatic tool) to migrate them to the new system.


Hughes, Charles E. and Moshell, J. Michael. "Shared Virtual Worlds for Education: The ExploreNet Experiment," ACM Multimedia 1997.

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

Moshell, J. Michael and Hughes, Charles E. "The Virtual Academy: A Simulated Environment for Constructionist Learning," International Journal of Human-Computer Interaction 8(1), pp. 95-110, 1996.

Horizontal red line

Charles E. Hughes, ceh@cs.ucf.edu