ExploreNet is an experimental general-purpose two dimensional graphics-based communications environment. ExploreNet has special features to support simulation-based role-playing games for educational purposes, and cooperative learning of many kinds. The basic philosophy of ExploreNet's creators was to facilitate the creation of cartoon-like networked "virtual worlds" in which the participants are visible to each other as animated figures. ExploreNet was inspired by LucasArts' Habitat system (Morningstar 91.) Educational uses of ExploreNet are proposed and explored in (Moshell 94.) This document focuses on how to set up, use and extend ExploreNet.

The design goals are

1. To make ExploreNet simple enough that it can be useful and entertaining when used by sixth graders (or even adults) within a minute of first encountering it. This goal has largely been achieved.

2. To enable ExploreNet to operate on 486 PCs equipped with Microsoft Windows and Internet addresses. Ultimately we'd like to support a wider variety of platforms, but in June 1995 this is where we are; and

3. Ultimately, to make ExploreNet powerful enough to serve as its own authoring environment, in the spirit of MUSEs[1]. This is not true for the current version.

ExploreNet software and this manual are Copyright (c) 1995 by the University of Central Florida. All rights reserved. We expect to make ExploreNet available without charge for educational use in July of 1995, but will reserve rights to the software to prevent its inappropriate use.

Contents

0. The Nature of this Document

1. Tutorial Introduction to ExploreNet

2. A Network Session

3. Constructing a New World

4. Constructing Behaviors

References

APPENDIX A: Installing ExploreNet

APPENDIX B: Preparing Your Site for Networking ExploreNet

APPENDIX C: Editing Text with the NotePad Text Editor

APPENDIX D: Known Bugs in the Software

APPENDIX E: Error Messages

APPENDIX F: Glossary and Index

APPENDIX G: Behaviors, Action Verbs and Predicates

This project is sponsored by the University of Central Florida. Additional support has been provided by AT&T, AutoDesk, Lotus Development Corp., MicroSoft and Nanyang Technological University of Singapore, for which the authors are most grateful.

0. The Nature of this Document

This manual has four main parts and a collection of Appendices. The first part introduces the user to ExploreNet and guides the user through a simple non-networked scenario. Users should be able to carry out the actions described in this section without any prior computer experience, although setting up ExploreNet on your computer does require some know-how. Appendix A assists in that set-up process.

Part two explains how to join and participate in a networked session with two to four players. This can be done "long distance" in conjunction with a server and players elsewhere, or locally by setting up your own server. Appendix B describes how to set up your computer for accessing ExploreNet remotely. It also explains how to set up your own server so as to conduct networked sessions without accessing UCF. This setup process requires some knowledge of the Internet and networking.

The third part describes how to construct and extend scenarios. Because ExploreNet is a prototype and is far from a buttoned-up, bullet-proof system, a fair amount of computer skill is required for this authoring task. Version 3 does not contain a full suite of built-in authoring tools. It is necessary to use other resources such as Autodesk Animator Pro or Aldus Photoshop to construct graphical actors (called "characters"), props and scenes. One's favorite text editor is used to modify the script files which describe the scenes that make up a world, and to describe the behaviors of characters and props. Appendix C briefly describes how text is edited with the NotePad editor of Microsoft Windows, though any text editor can be used if it can read and write raw text files.

The fourth part is a reference section which describes each of the presently available action classes which can be specified for the characters and props, and also specifies the structure of macro sequences - that is, behaviors you can construct for yourself.

Additional appendices provide lists of known bugs and error messages. Finally, a Glossary and Index assist the reader in figuring out what it all means.

1. A Tutorial Introduction to ExploreNet

The initial demo scenario only provides two characters, and is designed for play by two people. If you're alone, then you will alternate between controlling one, then the other character in one window. This simple introductory scenario is named Zora's World; because DOS only supports 8-letter file names, we abbreviate this as ZWORLD. In this world, you play the role of a nine year old African-American girl named Zora. You explore a world consisting of three scenes; meet another character named Jake, and learn how characters and props work.

'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.

We assume you have ExploreNet installed and ready to run. If not, see Appendix A.

To start ExploreNet on a machine where it's installed:

Run Windows if it's not already running.

Double click the Smalltalk/V Windows icon.

Inside this window you will see a big red V with the words "ExploreNet V3.2a" underneath. (It may say "3.2b" or "3.2c" etc, as versions are developed.) You will see other things, too; ignore them. There might be several red V's; just choose the one that says 3.2 (ignore "client" and "server" versions.)

Double click on the big red 'V'.

It will take about 40 seconds for ExploreNet to load into memory. You will come to a bright green screen, across the top of which are listed five options with "choose-one" buttons:

* No Network * Run History * Network Server * Network Client * Quit

The text below the buttons says" Select running mode by clicking mouse on appropriate button."

For this demonstration, you should click on the "No Network" button.

The green screen disappears for a few seconds. Two possible things could then happen:

- If there is only one world in the WORLDS folder, you will immediately be taken to that world.

- If there are more than one world in the WORLDS folder, you will then see a series of small square pictures with captions. One of them says ZWORLD. The picture over ZWORLD is of a brown dog. You can click on the labels under the pictures to get a description of what's in that world, or click on the pictures to start up the respective worlds.

Click on the dog. This is a signal to load up the ZWORLD demonstration and start it.

It takes perhaps 60 seconds to load the files for ZWORLD on a typical 486. A screen will show you that the scenes, characters and props are loading[2]. Below each scene's name will appear the names of the props being loaded into that scene. At the end of the list, the characters Zora and Jake are loaded.

You should now see a house with a porch, and a small girl (Zora) Across the top of the screen you will see small buttons labelled QUIT, HOUSE, RESTART, REPLAY, and DIALOG, and larger buttons labelled ZORA and JAKE. The meanings of these buttons:

In the left group:

QUIT takes you out of the current virtual world (ZWORLD), back to the green button menu where you can choose whether to enter a networked session, another stand-alone session, or quit altogether.

HOUSE provides background information about this scene. This button always displays the name of the current scene, and provides information about the scene if you click the button.

RESTART resets characters to their initial positions and conditions, and clears out all the stored dialog.

DIALOG provides a script of everything that anyone's "said" (typed) up to this point.

REPLAY displays each action of every character that was initiated on this workstation or which happened while this workstation was watching. (Obviously it won't replay things that weren't seen here.) Pauses, very common in actual interaction, are not reproduced in their full duration; in fact, not at all.

ZORA. Clicking this button selects the Zora character as the one to which your commands will be directed. As the first character, she's initially selected.

JAKE selects Jake the dog. Right now you can't see him, but if you click on his button, the screen display will change to show his current scene. He's sitting in a scene that contains a puddle.

Try that now. Click on JAKE's button. You should see a small brown dog in a blue pond. We'll play with him later. For now, click on ZORA's button again to return to the scene with the red house.

A scene consists of five kinds of things:

* The background; in this case, a red house for Zora and a blue pond for Jake, the dog.

* characters - people, critters, etc. that can serve as symbols for the players in the game ... e. g. Zora and Jake.

* props - e. g. a lantern and other things, to be seen shortly.

* portals (exits) - they're not visible. We'll lead you to them.

* regions - these are rectangular areas, also not visible, where characters are permitted to go. We're not actually using regions right now, but they're useful in structuring more complex story environments.

The background is just a flat picture. It was painted with a paint program.

The Mouse. Most PC mice have two buttons; a few have three. In ExploreNet, all the buttons do the same thing, so we'll just refer to the button from now on.

* Characters (live characters in the story, controlled by your computer)

* Ghosts (characters being controlled by another computer on the net)

* Props (like stage-properties: things to use in the story)

* Exits (ways to leave this scene for some other scene)

The cursor will change into a small symbol, depending on what you're pointing at. A small box with a P in it stands for "Prop"; a small human means you're pointing at a character in the story. A footprint means you've found an exit to another scene.

Characters are symbols for human players. (The symbols may look like animals, aliens, or anything you wish to "inhabit.") Choose any point on the screen, point at it with the cursor and click the mouse button; the character which you are currently controlling will move to that point in the scene (specifically, you point where you want the character's FEET to be.) Right now the active character is Zora.

Try this now. Click on the door of the house. Zora walks there. She's a bit large for the doorway; but who's perfect?

Point at Zora and click. The menu will list a number of behaviors that Zora can exhibit, including:

Identify

About Face

Kneel Down

Choose "Identify" with a click. The resulting message box tells you a little about the character Zora.

You can also open the action menu of a character by clicking on the character's control button (at the top of the screen).

Scene information is always available. Click on the button at the top of the screen that is marked INFO and learn something about this first scene. This INFO option can be used by the story designer to give hints, or background information of any kind. In this demo it's a straightforward guide through the (very simple) maze.

Let's take that hint. Click on the far left edge of the path displayed on the screen. Zora will walk right off the screen, and a new scene will come into view. She just used a "portal" or an exit, which we'll discuss later.

In this new scene, there's a forked road that leads straight across to the left side. You will see a lantern a bit below Zora's location. It's a prop. Let's explore this lantern.

Props can have any number of behaviors. The simple ones in this world don't have very many behaviors, though. If you Click on this lantern, you will see a list of things it can do. It's pretty boring: all it can do right now is give information about itself. If, however, Zora comes close enough to the lamp (move her closer if necessary, so that her feet are right above the lantern) a second prop-behavior is added to the lamp's menu: "PICK UP".

Select "pick up" from the lamp's menu with a click. The lantern disappears.

Now select Zora's menu with a click. One of her behavioral options is now "Drop Lantern", which if selected, will cause Zora to drop the lantern back into the scene.

Zora's Journey Continues. We're back in the green path scene.

Have Zora walkto the left side of the screen.

An invisible portal there leads to the dog/puddle scene, and we find our friend Jake. If someone else were playing the 'Jake' role on another computer, he would have seen Zora arrive on the left side of his screen. Zora is now going to speak to the dog.

Just start typing a greeting: "Hello, dog!"

At the top of the screen above Zora, the text "Hello, dog!" appears. This text would simultaneously appear on all the computers sharing this world, if they happened to be looking at this screen. Let's now pretend we're playing Jake the dog.

Click on Jake's button to direct actions to him. You can see Zora's words at the top of the screen. Reply to her by pressing the spacebar, then typing "Hello, human. Did you bring lunch?"

More Prop Actions. In this scene, we also see a flower. It's happy to see you there, and will reveal this fact if someone tells it to.

Click on the flower, then select SMILE. You will see the flower change her state to a smiling face. Look at her menu again with a click, and you will see the options BE NORMAL and WEEP. Try either of them.

You've now seen most (but not all) of ExploreNet's main features demonstrated. The variety of behaviors of characters and props is endless, because they're built into each new world by the world's designers. To become a world designer, see section 3 below. Meanwhile, if you are ready to try using ExploreNet on a network, there's always Section 2.

2. A Network Session

This section assumes that your system is set up and ready to work in the networked mode, either locally within your lab or long-distance via the server at the University of Central Florida. To set up for either circumstance, see Appendix B.

If you are not running ExploreNet, start it up by clicking on the ExploreNet icon in the V32WIN folder. If you are running a stand-alone session, go to the "running mode" screen by Clicking the QUIT button. Now select the "Network Client" option.

THE FOLLOWING SECTION IS UNDER REVISION AND MAY NOT CONFORM TO TODAY'S EXPLORENET BEHAVIOR.

Running a Local Session of ExploreNet. Start ExploreNet running on the server machine. Make sure that all clients and the server have the same EXPLORE.NET files in place. Select the option "Run Server" from the green menu. Select the world you want to support. In our tutorial example, we are using ZWORLD. We assume you're running just one server. If not, see the following subsection.

The server will display a white screen that invites you to select the characters to be controlled by this station. Above the screen are buttons which correspond to each character. These are to be used to choose any characters which the server will control.

Now, notify anyone who is to use a client to start their ExploreNet clients by going to the green menu (Quit from any active ExploreNet sessions to get to this menu, or start ExploreNet if it's not running). Have each select the "Run Client" option.

Clients show the same screen as the server. Each client can choose one or more characters to control, except that the server has to have at least one. If its operator hasn't chosen a character when one is left, the server will automatically choose the last one. If a client has gotten no characters by the time the scenario runs, the client returns to the green screen.

As soon as all the characters are chosen by either clients or the server, the world session begins. The white transcript screen will show each scene, prop and character's name as it is loaded. Once all the world's components are loaded, the world begins to operate as described in Section 1 of this manual.

Any client can quit the world by simply clicking on the QUIT button. When this happens, that server's character doesn't do anything more (unless requested by the other players through the character's second-person pop-up action menu.) When the server operator clicks on the QUIT button, the session is over and all clients automatically quit.

Single vs. Multiple Servers. If two or more servers' IP addresses are provided in the Explore.cfg file (see Appendix B), the client application will be given a choice of servers. Each server's description will include its IP address and the name of the world it's currently running. Only those worlds which have corresponding world-files available on the client will be offered. The descriptions are in the green screen's descriptive list. A menu also appears, listing the IP addresses. Choose the one you want to join.

Why didn't we list the worlds, instead of the addresses, in this menu? Well, there may be multiple servers running copies of the same world. We need a more friendly nomenclature than IP addresses, but haven't got it yet.

Running a long-distance Session of ExploreNet. At this early phase of experimentation, we recommend that a phone call be made to the operator of the server to make sure everything is ready. The number at UCF's Digital Media Lab is 407 823 6532. Your collaborator at UCF will tell you when the server is operating and ExploreNet is running, and which world has been selected for use by the server. You can then start your client(s) as described above.

Technically there is no difference between a long distance and an in-lab session, since IP addresses are being used in either case. It's just harder to know if the server is ready, etc. If you try to run a client and the server isn't ready, the client reports that it didn't find a willing server.

3. Constructing a New World

Plug-Ins. We use a handy shareware accessory called Plug-Ins, from Plannet Crafters. This provides a little icon just to the right of the put-away box in a Window, which provides instant access to tools. You can put ExploreNet in this list, and you can get at NotePad and your graphics tools via the plug-in control, even in the midst of an ExploreNet session. ExploreNet won't actually pick up the results of any changes you make until you go back out to the green screen and start another session. That still saves you the time required to re-start the ExploreNet software.

See "Plug-Ins" in the Glossary for addresses and contact information.

Tools. It is convenient to use NotePad (a built-in Windows accessory) for text editing. For quick guidance on how to do this, see Appendix C. We expect that you will use Windows' File Manager for duplicating, renaming and deleting files.

We recommend that you begin by modifying some of the existing files, such as ZWORLD, by slightly changing some behaviors, substituting your own .BMP files, etc. Once you master the basics, you can then get adventurous and build your own worlds.

Creating a background can be done with almost any PC paintbox program that is capable of producing a .bmp (bitmap) file in indexed 8-bit .BMP mode. The background scene should be 640 by 400 pixels and should use the ExploreNet Custom palette. In PhotoShop, this palette can be constructed by taking the System palette, setting the first color (upper leftmost box) to RGB=(0,0,0) and the last color (lower right box) to RGB=(255,255,255). Or, you can 'lift' the standard palette from any ExploreNet scene or object.

Creating objects (props and characters) can also be done with the above tools. The principal constraints are two:

a) Objects should be fairly small, so that they don't overwhelm the scene in which they're acting. Standing human figures should be 144 (high) by approximately 80 (wide) pixels (the exact width depends on the proportions of the character.). Animal characters should be about 72 pixels tall and as wide as needed, proportionately. Props can be any size that is appropriate for humans and animals at the above scale.

b) Objects must be drawn with BLACK backgrounds, so that they will animate properly and not bring along a rectangular surround with them. In particular the background must be of the black we just added to the palette; namely (0,0,0).

Animation Sequences. For both characters and props, you can store a sequence of slightly different poses to achieve animation. For Zora, we have ZORA1.BMP up through ZORA8.BMP devoted to walking, and ZORA9..17 devoted to kneeling. In the World files (extension .WLD) described below you will see how the walking poses are distinguished from others. When a character is initially loaded, it is assumed to be facing to the right. If you subsequently fly it toward the left, the bitmap is automatically reversed so that the character always flies forward.

World files. Figure 1 (at the end of this Manual) is a "road map" to the types of files that describe an ExploreNet world. There are four subdirectories of the EXPLORE.NET directory. The three relevant ones are called OBJECTS, SCENES and WORLDS. We begin with the WORLDS directory, and work our way outward.

The overall structure of a world is stored in a file in the directory C:\EXPLORE.NET\WORLDS. Our example is called ZWORLD.WLD. You can examine and modify it by using the Smalltalk Class Hierarchy Browser File/Open command. "ZWORLD.WLD" looks like this:

ZWORLD.WLD

:scenes in the two-actor demo "ZWORLD"

house pathway puddle

:character pose-counts, and initial positions

zora 8+ 9 100 800 800 house

:Zora has 8 walking poses and 9 others (kneeling)

jake 8 40 800 800 puddle

: -- we see that Jake doesn't appear until the puddle scene.

The lines of text beginning with a colon are comments. The lines in between the comments carry the actual description of the world. The characters are first listed, then their pose-count and initial positions are described. In the case of a character which doesn't make its initial appearance in the first scene, its scene assignment is stated in the character's descriptive line.

Seems reasonable, eh? The scenes are stored in subdirectory named EXPLORE.NET\SCENES, the characters and props are stored in a directory named EXPLORE.NET\OBJECTS.

The data structures cited in the ZWORLD.WLD file shows x, y and z locations, but Explorenet is a 2d system. In fact we're using a "Chinese perspective" trick; motion in the z direction (into the screen) is represented in the display by increasing the object's vertical position in the image. For initialization purposes, we just set z equal to the y value. We haven't yet developed user-driven methods for moving in and out along the z-axis. We'll shortly encounter some uses for the z-coordinate, when placing props for maximum effectiveness.

Now let's see, what information is missing? Aha, props and portals!

In fact, information about props and portals' locations is stored with each scene's descriptive file. So let's go look at one of those. When we open C:\EXPLORE.NET\SCENES, we see the following (among other things):

pathway.bmp <-- the bitmap image of the pathway scene

pathway.inf <--- the file describing the "information" display

pathway.prp <-- the file describing the props for this scene

pathway.xit <-- the file describing the exits for this scene

Here's the file for "pathway.prp."

:prop, number of poses, and its location (x y z)

lantern 1 400 750 750

tree 8 700 600 600

It says that there are 2 props in this scene; the first one is named 'lantern', has 1 pose, and is located at 400, 750, 750 in virtual space. The tree has 8 poses because it can be animated.

A neat trick. What if you want TWO trees? Well, you just give them two names, such as leftOak and rightOak, and you do the following:

:prop, number of poses, and its location (x y z)

leftOak (tree) 8 300 600 600

rightOak (tree) 8 700 600 600

This takes the files for the image and behavior of a tree from the disk files named 'tree', but it makes two copies of them in memory. One copy is called leftOak and another is called rightOak. (Actually it's more complicated than that but you can just imagine two copies of everything.) These two trees will have the same behaviors and user-defined actions, in the files named tree.beh and tree.act. If you did provide a file named leftOak.beh, it would replace the "generic" tree behavior with specific behavior for the leftOak.

This technique of using a (filename) as a source for information about an object can also be used for scenes. In the File Structures illustration at the end of this manual, for instance, you will see that the scene-defining line of the ZWORLD.WLD file looks like

house (redhouse) pathway;

puddle (meadow)

Which means that the 'house' scene is getting its information from the 'redhouse' scene files; the 'pathway' scene is getting its information from 'pathway' files, and the puddle gets its info from the meadow files.

Action Regions. In order to prevent characters from getting into parts of the scene that don't make sense, we can use region files such as the following:

PATHWAY.RGN

:upper left corner; width; height of the only region in the Pathway scene

0 300 1000 700

The coordinate system for an ExploreNet scene, by the way, has the origin in the upper left corner of the screen; 'x' is to the right and 'y' is downward. Both start at 0 (origin) and range up to 999 at the screen's edges farthest from the origin.

This region begins at (0,300); that is, left-justified and 300 units (30%) of the way down from the top to the bottom. Its width is 1000, i. e. the full screen, and its height is 700, i. e. the 70% of the screen remaining after you exclude the top 30% which is the sky. None of this world's characters will be allowed into the sky.

In later versions of ExploreNet we may allow different characters to go to different regions; presently they all follow the same rules. If there were multiple regions, a character can walk about only within the overlapping group of regions in which it finds itself when arriving through a portal. In fact, in version 3, any single movement must begin and end in the same region. For this reason we usually just use one big rectangular region at the present.

There is a default action region in each scene which prevents characters from destroying the dialog text at the top of the screen. We generally don't use regions very in scenarios these days, but they're available.

Exits. Let's see how we can get out of the scene named 'house'. The file 'house.xit' is structured as follows.

:condition for passing through the portal (''ALWAYS'=nothing stops you)

ALWAYS

:which scene do you go to?

pathway

:where do you emerge in that scene (x, y)?

900 500

:upper left (x,y) and (width, height) of the exit in pixels:

0 0 100 1000

:consequences of passing through the portal

NONE

This file's successive lines tell us this story:

- there is only one exit from the scene "House".

- It is always active (no conditions are imposed.)

- It leads to the scene "pathway".

- Your character emerges in "pathway" at x=900, y=500 and the same z position that it had in the "house" scene. If you had only mentioned one number, it would be taken as x and the y value would be inherited from the character's location in the previous scene.

- the exit's upper left corner is located at (0,0), which is the lower left corner of the screen. It is 100 pixels wide and 1000 pixels tall.

- the condition N/A means not-applicable; there is no condition. If your movement ends within the portal, you go to the new scene.

- the consequences. N/A means that no attribute was set when you went through the portal. Attributes are explained in section 4 below.

Constructing Regions and Exits. A special behavior called 'cursor' is available. When you include the word 'cursor' in an object's behavior-file, the option "Tell Where" appears in the Click menu. This option opens a window which reports the current position (x,y) of the bottom center of the character or prop. This can be used to probe around and find the most useful locations for exits, regions, props etc. Then you go and modify the .prp (prop), .rgn (region) or .xit (exit) files associated with the scene.

Also reported are "Extent from Old", which helps to determine the third and fourth numbers in an exit or region. These numbers are relative displacements from the last place you used this feature, which presumably would have been the upper left corner of the exit or region you wish to create.

We also provide an object named Locator which can be used as a cursor character for these purposes. Locator looks like this:

Props and Characters. The only essential differences between props and characters are these:

1) A character may own a window. This window may be on a separate computer or may be a shared window on a single machine. In this case, the character owns the window only if it is the most recently selected character in that window.

2) A character obeys certain commands only when they are sent to it from its own window (and presumably from its 'actor', the human being playing the role represented by the character. Props accept commands from anyone.

Characters and props are both ExploreNet Objects, and any comments henceforth referring to objects are intended both for characters and props.

The behavior of an object is described in a Behavior file, such as TREE.BEH. It's one of our simplest kinds of files, because all it contains is a list of the built-in behavior classes to which this object belongs.

:list of actions

possession turner

This means that, in the action menu of the tree, there will appear two options due to these two classes:

PICK UP

ABOUT FACE

The 'pick up' command only becomes visible when a character is close to the object. The 'about face' command allows the tree to 'face' left and right (which is pretty useless, given the current drawings of the tree.)

The available behaviors are listed in Appendix G.

4. Constructing Actions (User-defined Behaviors)

We expect and hope that the techniques described in Section 3 above will be comprehensible to world-builders who are not programmers. The use of pre-defined behaviors in a simple list of desired behaviors should not be too challenging a concept. However, with this method, the repertoire of possible actions is pretty much limited to the behaviors provided with a given release of ExploreNet.

Two kinds of more complex behaviors can be constructed by world-builders. Questions and answers can be provided by special props, which often appear in the guise of 'autonomous characters' (in D&D terminology, 'non-player characters', NPC.) Compound series of behaviors ("macros") can also be constructed from built-in primitive behaviors. We discuss these two capabilities in the two following sections.

Constructing Actions

For a world-builder to create more complex behaviors without recourse to the tool-builders, it was necessary to define a kind of miniature programming language. We refer to behaviors which the user can define as 'actions'. Before we can explain the structure of macros, we must introduce the notion of attributes.

Attributes. An attribute in ExploreNet is a simple integer variable, which 'belongs' to an object (character or prop.) An attribute can be interpreted as describing part of the state of a prop or character (such as having learned something or acquired a capability.) Attributes are motivated by a similar idea in Dungeons and Dragons, in which properties of players such as courage, strength or wisdom are kept as scores, and incremented and decremented during the game. Attributes in ExploreNet are declared, incremented, decremented, tested, reset and deleted in a very simple fashion.

Attributes are created and given an initial value of 1 by simply mentioning their names. The places where this can occur are

1. In the 'consequences' portion of an exit.

2. In the 'consequences' portion of a user-defined behavior, the same situation applies for the creation of new attributes.

3. In the creation of question-asking and answer-giving autonomous objects, attributes are also used. These uses will be discussed in the section of the manual concerning those capabilites.

The things that can happen to an attribute are each mediated by a one-character symbol, as follows. We use the attribute "strong" as an example.

~strong

If the attribute 'strong' has a nonzero value, this command sets the value to zero (false). Thus the object is now regarded as not being strong.

+strong

This increments the value of the 'strong' attribute by 1. If this attribute was zero or nonexistent, a new attribute is created and given a value of 1.

-strong

This decrements the value of the 'strong' attribute by 1.

strong

This forces the attribute's value to 1, no matter how large it is.

In turn, when attributes appear in conditions, they can appear in several forms.

strong

This means that if the attribute 'strong' has value of 1 or greater, then the conditional action in question occurs.

~strong

This means that the conditional action only occurs if the attribute is not present, or has zero value.

Attributes are always referred to in an attribute predicate, which looks like this:

attributes(strong ~beautiful)

The "predicate" is really attributes() and its "argument list" is the two attribute expressions 'strong' and '~beautiful.'

Object Predicates. There are also some conditions which depend not on attributes, but on what objects are present in the scene.

lantern

This means that the named ExploreNet object (prop or character), such as the lantern, is in the scene and visible on the ground.

~lantern

This means that the named object must NOT be in the scene for this condition be true. The object may be in the possession of a character in the scene; since it's not visible on the ground, this condition would be true.

Possessions are mentioned in a predicate named 'possessions()', which works just like the attributes predicate. For instance

possessions(hammer ~lantern)

would be TRUE only if the person had a hammer and no lantern.

Neighbor Predicates. Another useful class of tests is to tell whether the current object is in the same scene with another object. The predicate 'neighbor (egg hen)' would mean that the current object is in the same scene with both the egg and the hen, at the same time.) You can test for the presence of props or characters with this predicate.

Predicates for Which Object? If you are defining a behavior for Zora, and you just use a predicate like neighbor(cat) to see if she was close to the cat. However if you needed to know that the cat was close to a mouse (while defining Zora's behavior) you could test for Cat.neighbor(mouse).

In general, if you don't name an object, the predicate refers to the object for whom the action is being defined. If you wanted to make this totally clear, you could either say Zora.neighbor(etc...) or self.neighbor. Both these would have the same meaning as neighbor(etc...).

User defined Actions. If an object (e. g. TREE) has a properly constructed action file (TREE.ACT) then it will have some user-defined actions. Here is an example of an action file.

TREE.ACT

:condition for installing action 1

attributes (~grown)

:menu command for action 1

Grow

:the action that occurs

sequence 1 8 1

:the consequence for attributes:

grown

:-----------------

:condition for installing action 2

attributes (grown)

:menu command for action 2

Shrink

:the action that occurs

sequence 8 1 -1

:the consequence for attributes:

~grown

This is fairly self explanatory. There are two actions defined. The first says that if an object with the behavior 'user' has an attribute named 'grown' that has value 0, then

1. Place the command 'Grow' in its action menu, and

2. When that action is selected, execute the command

sequence 1 8 1

Which in fact means to step through the first 8 poses of the character's bit-maps, one pose at a time.

3. When the action is complete, assign to the attribute 'grown' a value of 1.

The complementary action called 'Shrink' is similarly defined.

More complex actions. To this point we've only seen one-piece actions, like "sequence 8 1 -1". To construct a more complex action consisting of several steps, we must separate the steps by semicolons. If they require multiple lines, we must use the back-slash \ as the last character on a line, to extend it.

Consider the following example of a complex action which Zora can perform as part of the 'EggQuest' world.

:This action requires that Zora have a lantern and be near the firewood.

possessions(lantern) neighbors (firewd)

:When those conditions are true, the following appears in Zora's menu

Light Fire with Lantern

:When that menu entry is selected, the following sequence of actions occurs:

flyNearObject firewd; fly 0 10; pause 100; \

firewd.ignite

:No changes are made to Zora's attributes.

NONE

Conditional Actions. The IF command allows you to make PART of an action sequence conditional. The basic syntax is as shown in this example:

if Zora.possessions(lantern) Zeke.possessions(firewood) Fire.ignite

This would check to see if Zora has a lantern and Zeke has the firewood. It that were true, then the fire would be told to ignite. This entire construct would consist of one action in an action sequence.

The only way that conditions can be nested is if you define a new action (such as Fire.ignite) and put conditions inside it.

General Issues about action sequences. ExploreNet3 scripts are not expressed in a general purpose programming language. A major and obvious omission is that there is no way to repeat a section of code. Cunning programmers may decide to try to create recursive actions (those which call themselves.) This won't work, and may cause crashes if we weren't clever enough in detecting your attempts.

The purpose of this system is to tell simple stories in which most of the complex actions are produced by the participants, not by crafty programmers. We expect to build more powerful programming tools into the next version based on the storytelling needs that emerge from this year's experiments.

Questions and Answers

There are two classes of behavior which cause props to be able to ask and answer questions. Assigning an object the behavior named "inquirer" causes a menu item "Ask Player" to appear in the object's action menu, along with any other actions you have provided to that object. Selecting that action produces a menu containing a series of questions. By selecting one of these, you are causing the character to "ask the player" (the human, i. e. yourself) a question. You must then provide an answer. Attributes (and thus the course of the story) are changed, depending on your answers.

Similarly, the behavior called "sage" causes an option titled "Answer Player" to appear in the object's action menu. When this option is selected,

a sub-menu appears and displays a series of topics (questions to be asked by the player.) You can select any of the listed topics (thus "asking the question") and receive the corresponding piece of information. Both inquirers and sages' scripts can contain conditions, so that the questions and answers can change as the simulation's state evolves. Let's look at examples.

Inquirer. The following sample script shows how an inquirer works.

CHIEF.BEH

:list of behaviors

inquirer

This is pretty obvious. Let's move on to the file which specifies the questions and answers.

CHIEF.QA

:condition for this question to appear in the menu

ALWAYS

:question 1 is:

How many cents does it take to buy gum?

:answer 1 is:

2

:consequences of correct answer (changes to attributes of character:)

smart

:----------- second question would follow, if more were used.

We see that the character's 'smart' attribute gets set to 1 when the player successfully answers the question. At present, ExploreNet doesn't accept a very wide range of answers (like '2 cents' or 'two cents'); the answer is a precise template. That is, the exact string of characters provided in the QA file must occur for the answer to be considered correct.

Sages. A sage tells you things. Because all the actual initiative in ExploreNet comes from the players, you actually have to trigger the sage's actions by selecting a topic from the action menu of the sage object. Here's an example of a behavior file.

KING.BEH

:list of actions

sage

The question/answer file in this case is fairly complex. You may want to hop to the commentary below the example.

KING.QA

:-------------- 1 ---------------

:

:condition for utterance 1:

attributes(~friend ~informed ~annoying ~unwilling)

:the topic (question which player may ask)

How much does the gum cost?

:answer

I'll tell you when I get to know you better.

:----note: This means 'the next time you ask me', because

:----we set the 'friend' attribute to show we've been asked once.

:consequences .. in this case, marking the character as a friend

friend

:

:-------------- 2 ---------------

:

:condition for utterance 2:

attributes(friend)

:Topic:

How much does the gum cost?

:answer

Well, since you're a friend, try 2 cents. (Just type 2).

:consequences

~friend informed

:----note: Now 'friend'=0, 'informed'=1.

:

:---------------3-----------------

:

:condition for utterance 3:

attributes(informed) neighbors (~lantern)

: question (topic) to be asked if the player is 'informed' (see 2

: above, but the lantern is NOT in the scene.

How much does the gum cost?

:answer

Hey, I already told you. How about a little gift?

: Commentary: The 'sage' is just a prop, and cannot possess

: a gift. The only way we can give it to him, is to put it down in

: the scene. We only ask this question if it's NOT there yet.

:consequences

N/A

:

:---------------4-----------------

:

:condition for utterance 4:

attributes(informed) possessions(lantern)

:question

How much does the gum cost?

:answer

OK, it's 2 cents. Don't forget it this time.

:consequences

~informed annoying

:

:-----------------5----------------

:

:condition for utterance 5:

attributes(annoying)

:question

How much does the gum cost?

:answer (sage is getting tired of this silly question.)

Not again. You better find somebody else to ask.

:consequences

~annoying unwilling

: commentary: By setting 'unwilling'=1, this sequence

: prevents the whole cycle from starting with utterance 1

: in the future. The sage will never again willingly answer

: this five-ply gum question (during this session.)

:

:---------------6-----------------

:

:condition for utterance 6 (it's unconditional)

ALWAYS

:question

How do I get out of here?

:answer

There's a portal in the front of the hut

:consequences (none: blank line required)

N/A

:-------End of Utterance 6

Notice that in this example, five of the six questions are variants on the same theme, but because of the conditions, only one of the 'gum' questions will actually appear in the menu at a given time.

Also notice that the five gum questions are chained together in such a way as to cause them to occur one after the other, if the player does the right thing. Despite the large apparent number of possible states that can be generated with four attributes, only these five can actually occur (unless some other question/answer or other action starts changing these attributes.)

The above example of how to chain together questions and answers should be regarded as a starting point for how you can chain together causes and effects of all kinds, to 'steer' the player's experience within an ExploreNet world.

References

Curtis, Pavel (1992). "Mudding: Social Phenomena in Text-Based Virtual Realities." Proceedings of DIAC T92. Available via anonymous ftp from parcftp.xerox.com, pub/MOO/papers/DIAC92 in two versions: .{ps, txt}.

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: Networked Simulation and the Future of Education. in Proceedings of the IMAGINA Conference, Monte Carlo, Monaco, 16-18 February 1994.

Stephenson, Neal. Snow Crash. Bantam Books, New York. 1991.

APPENDIX A: Installing ExploreNet

We assume that you have installed Win32 and Smalltalk/V for Win32 on a 486 PC with 8 meg of RAM and a large hard drive, and worked through at least some of the Smalltalk tutorial manual. The Smalltalk system should be stored in a folder named v32win, hanging off the C: root; and should be associated with an icon titled "Smalltalk/V for Win32". This is the configuration you'll have if you used the automatic installation procedure provided with Smalltalk.

Installing ExploreNet is easy. Use the Windows File Manager to do the following things:

1) Save any existing file named V.EXE in the Smalltalk/V directory named C:v32win This is the original Smalltalk image file; you may need it later for activities unrelated to ExploreNet. One way to save it is to rename it VOLD.EXE, or any other name that helps you remember what is in it. You also need to rename the CHANGE.LOG file.

2) From ExploreNet Distribution Disk 1, copy the files V.EXE, V32VM20.dll and WINSOCK.DLL directly into the V32WIN directory. The V32 file is a modified Smalltalk/V library which contains the special cursor objects to display cursors that designate one's own or another's character, prop, and exit.

3) Copy from ExploreNet Distribution Disk 2, the complete directory named Explore.Net and install it directly on the C: drive. If you have any older Explore.Net directory there, rename it first. We don't want to mix the old with the new.

4) There may be a few spare pieces of the scenario back on Disk 1. Re-insert Disk 1. If it contains any directories named OBJECTS, SCENES or WORLDS, copy their contents into the corresponding directories inside C:\EXPLORE.NET.

5) Use the Windows File Manager to create an icon within the V32WIN folder, and associate it with C:\V32WIN\V.EXE. Name it "ExploreNet 3.1e".

Now you're ready to run.

PROBLEMS

If anything happened that you didn't understand or couldn't fix, delete all the files that have been added to the system and start over with the installation procedure. You may even have to re-install Smalltalk/V, though this level of problem is getting rarer as things settle down.

If that doesn't work, call or write or visit Charlie Hughes (ceh@cs.ucf.edu), 407 823 2341.

APPENDIX B: Installing a Network to support ExploreNet

First, you need to install ExploreNet, according to Appendix A. In addition, from Installation Disk 2's EXPLORE.NET subdirectory, make sure you copied the file Explore.cfg into the EXPLORE.NET directory. If you open this file with a text editor, you will see that it contains a four-byte Internet address. This is the IP numeric address which ExploreNet will use when it attempts to reach the server.

If two or more servers' IP addresses are provided (one per line in the Explore.cfg file) the client application using this Explore.cfg file will be given a choice of servers. Each server's description will include its IP address and the name of the world it's currently running. Only those worlds which have corresponding world-files available on the client will be offered.

If you plan to run a local session, you must determine the IP address of the machine upon which you want to run your server and install it into this file, adding to or replacing the UCF IP number (Make a note of the UCF number for future use, if you remove it!)

Now return to Section 2 for a walk-through of a networked session.

APPENDIX C: Editing Files with NotePad

It's a simple process, folks. NotePad follows all the Windows conventions for handling documents. The main thing to know about is that you can use the Associate feature of the File Manager to set things up so that whenever you click on a file that is displayed in the File Manager, its associated application opens. We want to create associations from files with the following extensions:

.wld

.inf

.beh

.act

.xit

.rgn

.qa

.cfg

to Notepad. Do this before you start running ExploreNet. To do this, open Windows' File Manager. Open its FILE menu; select Associate. Specify the desired extension, and select NotePad as the application. Do this for each of the above file types. Now, it is very easy to jump back and forth between ExploreNet (at the world-selection window, where you see all the little square pictures and choose a world) and File Manager; double click on the file you want to change; change it, save it and resume working with ExploreNet.

We use the PlugIn shareware desk accessory, which makes it possible to "hop" right out of an ExploreNet session and access the File Manager. Press (alt-tab); that is, hold down the alt key and press tab, and you find yourself in the general Windows screen you had before you started ExploreNet. Then pull down the PlugIn icon, select File Manger.

Alternatively if you don't use NotePad, you can arrange your Windows desk-top so that File Manager is easy to get to. In fact it might be kept open, if you have enough RAM space.

You can change the text files that define an ExploreNet world, then go back out to the green menu (via the QUIT button) and select the world again. This causes the files to be re-loaded into RAM, and thus you see the results of your changes. This is only feasible when you're not running networked, because you would have to find a way to send your changes to the other sites, in networked mode.

A final hint: When you first use the OPEN option, select "All file types". Now as long as you are working with Notepad (and not closing/re-opening it) you will see all the .wld, .beh etc. files. If you don't do this, it'll continually revert to trying to display only the .txt files, which is a nuisance.

We're working on it!

APPENDIX D: Known Bugs in the Software

As of 6/28/95 these are no known bugs.

APPENDIX E: Error Messages

These are the most common error messages that result from errors in world-building. Any other error messages you encounter are probably due to system failures and should be reported to Charlie Hughes at the address above.

<We need to trigger some errors so as to populate this section. It has been a while since we've done that and most of the errors in previous manuals are now handled appropriately.>

APPENDIX F: Glossary cum Index

Act File. A file with the extension .act which specifies user-defined behaviors for objects. Section 4.

Action Verb: These are the building blocks from which you construct user-defined behaviors, in Act files. See Appendix G or Section 4.

Action Menu: if you point the mouse cursor at any object and press the right button, you will see a list of choices for what the object will do. A click selects an action. Click outside the menu to select no action.

When the action menu of a character is being used by a character's actor, it contains all possible actions. If it is being used by a "second person" (someone other than the actor) a smaller set of actions is possible; they are usually requests to the character, rather than "direct orders". The FOLLOW request is an example of one of the actions you can request of someone else's character.

Section 1, 3,4.

Action Region: a rectangular area of a scene. When used, action regions are the only areas where characters can move. They are used to prevent characters from doing implausible or undesirable things. There is a default action region in each scene which prevents characters from destroying the dialog text at the top of the screen. Section 3.

Avatar. In Indian religious thought, an avatar is a manifestation on earth of a deity or spiritual being. In the Habitat system (Morningstar 91) the term denotes what we refer to in Explorenet as a "Character" (q. v.) Independently of the Habitat system, Neal Stephenson coined an equivalent useage in the delightful novel Snow Crash (Stephenson 92.)

Background: a flat colored image, usually 640 x 400 pixels. This serves as the foundation for a scene (q. v.).Sections 1, 3.

Behavior: One of the built-in kinds of things that objects can do. See Appendix G for a list of all the behaviors currently provided, or Section 3 for discussion.

Behavior File: a file with the extension .beh which accompanies any object that has non-trivial behaviors. Section 3.

Character: a cartoon figure within the ExploreNet system, which is controlled by a live human being called the actor for this character. An actor can control more than one character, by alternating between them (or perhaps by using two computers at the same time.) When a character passes through a portal to another scene, the scene on the computer changes to follow the character. Section 1.

Client: a program which is being used by an individual or a group of users sitting in front of a single computer. The client is communicating via another program called the server with other client programs. Sections 1, 2, appendix B.

Cursor: a behavior. Section 3.

Cycler: a behavior. Section 3.

Dialog: This main control button provides a script of everything that anyone's "said" (typed) up to this point. This should be in a scrollable box, but it isn't yet in V3.1e. To make the box go away, press the Enter key. Section 1.

Exit: a region in a scene which, when entered by a character, causes a change of scene. Exits may have conditions attached to them. Sections 1, 3.

Flyer: a behavior. Section 3.

Follow: This is an action that can be requested of someone else's character, or in fact of a prop. If the actor agrees, the character follows "you" (your character) wherever it goes. To make an object capable of becoming a follower, put the "follower" behavior into its behavior file.

Follower: a behavior. Section 3.

Identify: this option is in the action menu of every object (character and prop.) It produces a small screen with textual information about the object. Sections 1, 3.

Info: This main control button provides background information about the current scene. Section 1.

Inquirer: a behavior. Section 3.

Invisibility: see vanisher. Section 3.

Plug-Ins. A neat screen management accessory which is "share-ware"; you can get it for free and try it out. If you like it, you then send the maker a specified fee. Plug-Ins is available from

Plannet Crafters Inc.

P. O. Box 450

Alpharetta, Ga. 30239-0450

FAX 404 740 9821

73040.334@compuserv.com

AOL: DMANDELL 1

Genie: D.MANDELL1

Prodigy: VSFB48A

Their bulletin board is located at 404 740 8543.

Portal: another word for Exit, q. v. Section 1.

Possession: a behavior. Section 3.

Props: objects in a world which can be manipulated, but which do not normally serve as an animated "person". Section 1.

Quit: This main control button takes you out of the current virtual world (ZWORLD), back to the green button menu where you can choose whether to enter a networked session, another stand-alone session, or quit altogether. Section 1.

Replay: ExploreNet can replay the actions that have taken place so far. Just press the REPLAY button; but if you've been playing for a while, the replay may also take a while. Section 1.

Region: a rectangular area, not visible, where characters are permitted to go. We're not actually using regions right now, but they're useful in structuring more complex story environments. Section 3.

Restart: this main control button resets characters to their initial positions and conditions, and clears out all the stored dialog. Section 1.

Sage: a behavior. Section 3.

Scene: The basic component of an ExploreNet World, a scene consists of a background, props, characters, exits and regions. Section 1.

Server: a program which gathers together information from client programs and broadcasts information to them. Sections 1, 2, appendix B.

Talker: a behavior. Section 3.

User: a special behavior, which announces that there are user-defined actions associated with this object. Sections 3, 4.

Vanisher: a behavior. Section 3.

Zoomer: a behavior. Section 3.

Appendix G: Behaviors, Action Verbs and Predicates

BEHAVIORS

While most of these built-in behaviors will ultimately be usable with all objects, in this version most of them only apply to props. Those which can be used with props are marked with P; those that be used with characters are marked with (C). The square-bracketed commands are used in the creation of user-defined actions. They are more fully explained in the following section.

cursor (C) - this causes the current (x,y) location of the bottom center of the active character to be reported. Also reported is the change since the last report. This is useful for measuring a scene to construct exits and activity regions. [cursor]. Puts TELL WHERE into the user's menu.

cycler (P) - continuously animates through all poses. This could be used for a ceiling fan, a flashing lightning bolt or neon sign, or any kind of prop that you want to use to liven up the scene.[cycle, stopCycling]

flyer (P) - shuttles back and forth from left to right screen edges until you tell it to quit. Puts FLY in the menu. [flyAround]

follower (C,P) - follows the character around until you tell it to quit. Puts FOLLOW into the object's menu; then STOP FOLLOWING once activated. [follow]

inquirer (C,P) - makes an object into a question-asker, which will present your character with a list of questions. See section on 'questions and answers' below. An additional .qa (question/answer) file is needed.

possession (P) - makes a prop eligible for being picked up and carried off by a character. Puts PICK UP into the object's menu. [canBePossessed, cannotBePossessed, drop objName, pickUp objName]

sage (C,P) - makes a prop into a question-answerer, something like the opposite of an inquirer. See the section on 'questions and answers' below.

toggler (P) - puts TOGGLE in the menu. This will cause the next pose of an n-pose object to be displayed. If there are only two poses, you really do get a toggling effect. This is very similar to 'zoomer.' [toggle]

turner (P) - puts About Face into the menu of a prop. (Characters already have this command.)

vanisher (C) - causes the character to become invisible on all screens except the one which owns (controls) it. Puts "Become Invisible" in the menu. An invisible character shows "Make Visible" in its menu. [becomeInvisible, becomeVisible]

zoomer (P) - cycles an object between pose 1 and pose 2, which we assume is an enlarged image. Puts ZOOM in the menu; when something is zoomed, it puts UNZOOM in the menu. [zoom, unZoom]

ACTION VERBS

Items in <angle brackets> are positive numbers. Items in double angle brackets <<>> can be positive or negative numbers (but not zero.) Square brackets mean that the item is optional.

Action verbs can all be directed at specific objects; for instance, in the definition of a method for Zora to pick flowers, the following might be included:

Flower.becomeInvisible

This would direct the flower to disappear when she picks it. If, however, her script had instead included the instruction

becomeInvisible

or its equivalent expression

self.becomeInvisible

then Zora herself would have become invisible (on everybody's screen except that of the person controlling her.)

The [object] in the following list is just a reminder that an optional object can be named at that point as the one to do the requested action. The 'objName' which is occasionally seen is a reference to another object; for instance, Zora might have an action sequence which includes

Zeke.pickUp lantern

In this case, Zeke would be induced to pick up the lantern, when this compound action in Zora's repertoire was being executed.

The * denotes that this action verb works for props but not for characters.

[object.]becomeInvisible - see Vanisher in the Behavior section

[object.]becomeVisible - see Vanisher in the Behavior section

* [object.]canBePossessed - makes object into a Possession

* [object.]cannotBePossessed - makes object not be a Possession

* [object.]cycle - see Cycler in the Behavior section

[object.]drop objName - causes the object to be un-

possessed & to become visible.

* [object.]flyAround - see Flyer in the Behavior section

[object.]fly <<x y>> - walk (cycle) while moving a distance (x,y) [object.]flyToPosition <x y> - walk (cycle) while moving to (x,y)

[object.]flyToObject objName - walk (cycle) and go to the obj.

[object.]flyNearObject objName - walk (cycle) and go near obj.

[object.]pause <milliseconds> - entire system pauses that long.

[object.]pickUp objName - active object picks up named object

[object.]rollOver - object appears upside down. do again -> rightside up.

[object.]say text - the object will speak.

[object.]sequence <start> [<stop> [<interval> [<repeat>]]]

* [object.]stopCycling - see Cycler in the Behavior section.

* [object.]stopFlying - see Flyer in the Behavior section.

* [object.]toggle - see Toggler in the Behavior section.

* [object.]unZoom - see Zoomer in the Behavior section.

* [object.]zoom - likewise -

In addition, you can use any behavior that is defined for any object. If the object is Jake and its action's menu name is, for instance, Go Jump in Lake, you would issue the command

Jake.GoJumpInLake

Obviously you have to take the spaces out of the menu name, to create the action name.

Conditional Actions. These tools allow you to make PART of an action sequence conditional. The basic syntax is as shown in this example:

if Zora.possessions(lantern) Zeke.possessions(firewood) Fire.ignite

This would check to see if Zora has a lantern and Zeke has the firewood. It that were true, then the fire would be told to ignite. This entire construct would consist of one action in an action sequence.

The only way that conditions can be nested is if you define a new action (such as Fire.ignite) and put conditions inside it.

PREDICATES

The following are items which have values of TRUE or FALSE. These are the only things that can appear in the conditional line of a portal or an .act file action description.

Curly brackets {} mean "a list of one or more"

ALWAYS or PRIVATE

These refer to the object to whom the action belongs:

attributes ({attribute names and ~attribute names})

neighbors({object names and ~object names})

possessions( ... ) : object names and ~object names

These refer to some other object. If you want to be explicit about defining a self-referential object, replace 'object' with the word 'self'. If you want to check on Jake's attributes, you would use Jake.attributes(brave) or whatever.

object.attributes({attribute names and ~attribute names})

object.neighbors( ... ) : object names and ~object names

object.possessions( ... ) : object names and ~object names