\documentstyle[a4,epsf,alltt]{article}
\begin{document}


\include{commands}


\title{Creating your own worlds}
\author{Jocelyn Ireson-Paine}
\maketitle


This handout shows you how to construct your own production system
programs. I assume that you've already read the notes on {\it
Introduction to the editor}, and that you know how to run Eden,
including the world-editor.

There are three aspects to creating your own world. These are: defining
new objects; defining new bug senses; and creating new arrangements of
existing objects. The latter is simplest, so I'll talk about it first.


\section{New arrangements of existing objects}

You can do this entirely via the editor. The simplest way to start is by
modifying an existing world. Let's suppose you choose to modify
\verb/psworld2/. Then you would start by giving, from Prolog, the command
\begin{verbatim}
help psworld2
\end{verbatim}
This will give you a display like that of figure~\ref{worlds:psworld2},
below.
\vfigstart
\begin{verbatim}
!  PSWORLD2

pb_objects
        ***********
        *         *
        *  B   S  *
        *         *
        *+     1  *
        ***********

\end{verbatim}
\vfigend{worlds:psworld2}{The contents of {\tt psworld2}}

In this display, the bottom part will already be familiar to you. What
about the rest? The first line is a {\it comment}. This has no function
as far as Eden is concerned, and its only purpose is to convey
information to a human reader. In this case, it just gives the name of
the file, in case I forget while editing. In world definitions, comments
always begin with a \verb/!/, placed right at the start of a line.

The second line is left blank. You can have as many or as few blank
lines as you want: I usually leave one, for readability.

The third line contains the name of the {\it objects file}. This file
contains some small Pop-11 programs defining how objects respond to
various ``forces'', and links the symbols for objects to these programs.
Thus it tells Eden that boulders have the symbol verb/*/, and are
impassable; that food has the symbol \verb/+/, and can be grabbed and
used; and so on.

Finally, the world itself must start on the line below the objects
file's name.

Once you have done the \verb/help/ command and got this display, use
\verb/name/ to make it into one of your own files. Thus you could do
\begin{verbatim}
ENTER name myworld RETURN
\end{verbatim}
to create a world-file called \verb/MYWORLD/. The handout on
{\it Editing your own programs} shows another use for the \verb/name/
command.

You can now edit this file, making changes as described in the next
section. The best plan here is just to change the world itself. If you
are keen, it would be nice to change the first line so it reflects your
own filename, but Eden won't care if you don't. Do not change the third
line. You don't know enough to create your own objects files, so you will
have to stick with those I supply.


\subsection{Making small changes, and saving the world}

The easiest type of change is just --- say --- to add a new piece of
food, or delete a coin. You do this by using the edit keys in the usual
way. You will need to take care to keep objects on the right of your
change lined up, and you may have to add or delete some spaces to do so.

Note: you will see that the original file contains a \verb/B/. This
symbolises the starting position of the bug. You can move this, but you
must have it somewhere inside the world. If not, you won't be allowed to
save the world. Do not have more than one bug! You can't change the
bug's initial direction: Eden assumes it is always facing east.

Once you have made your change, you can then save it. To do so, use the
Ved command \verb/saveworld/. Thus:
\begin{verbatim}
ENTER saveworld RETURN
\end{verbatim}
This will save the new world, in your own directory or work area, under
the name you gave when using the \verb/name/ command.

Then exit the edit, by doing
\begin{verbatim}
ENTER x RETURN
\end{verbatim}
If you don't do this, you will lose the diagram of the world, and will
have to create it again next time.

To run a bug in the new world, just use its name as the second argument
to \verb/eps/. Thus:
\begin{verbatim}
eps( psbug2, myworld ).
\end{verbatim}

Note: you must do a \verb/saveworld/ before running a bug in your world.
Worlds are stored in two forms: as their picture, and as a specially
encoded or ``compiled'' form used by \verb/eps/. When you do the ENTER
\verb/x/ RETURN, it saves the picture. When you do the \verb/saveworld/,
it saves the compiled form. \verb/eps/ needs the latter, because it
can't work directly off the picture.


\subsection{Another world}

You may find it helpful to practice my making another world, this time
from \verb/psworld1/. Remember, the sequence is:
\begin{enumerate}
\item From Prolog, do a \verb/help/, e.g. \verb/help psworld1/. This
displays the original world file which I wrote.

\item Do a \verb/name/, e.g. \verb/ENTER name nextworld RETURN/. This
copies my original into your file.

\item Edit that, leaving the name of the objects file intact. Make sure
your world contains a \verb/B/, to show where the bug starts off. The
bug will be assumed to face east.            

\item Save the world in an \verb/eps/-useable form, i.e. \verb/ENTER
saveworld RETURN/.

\item Save the picture, i.e. \verb/ENTER x RETURN/.

\item Run a bug in the new world, e.g. \verb/eps(psbug2,nextworld)./.
\end{enumerate}


\subsection{Making bigger changes, and using static mode}

These may entail deleting and retyping several lines. If so, you will
find the commands in the TEACH file \verb/ved3/ useful, particularly
mark and delete.

One of the problems I mentioned earlier was that if you add or delete an
object, the objects to its right are pushed out of line. You can avoid
that by putting the editor into {\it static} mode. To do so, give the
Ved command
\begin{verbatim}
ENTER static RETURN
\end{verbatim}
Once you have done this, typing a character will overwrite what's
underneath rather than moving it. This is the same mode that the editor
is in when you use the Eden control command \verb/e/.

It's a good idea to get out of static mode before editing other files.
If you don't, you may get confused. To do so, just give the
\verb/static/ command again. This command is like a toggle-switch: it
turns the mode on, then off, then on, \ldots


\subsection{The drawing commands}

There are two Ved commands you can use to draw lines. They are most
useful for drawing walls of boulders, but you can use them for other
things too.

To demonstrate them, start editing a file. Any file will do; it doesn't
have to be a world file. Move the cursor somewhere, and then give the
command
\begin{verbatim}
ENTER point RETURN
\end{verbatim}

Then move the cursor somewhere else, and give the command
\begin{verbatim}
ENTER draw RETURN
\end{verbatim}
You will see a line of \verb/*/ characters appear. Because of the way
characters are displayed, this works best when the lines are vertical,
horizontal, or at 45 degrees.

You can use \verb/draw/ commands one after the other. Move the cursor to
yet another place and type ENTER \verb/draw/ RETURN again. This will
draw another line from the end of the first one. You can continue doing
this for as long as you want. If you want to change the starting point,
you can always do another \verb/point/.

To draw lines of some other character, put a different symbol after
\verb/draw/. Thus
\begin{verbatim}
draw +
\end{verbatim}
will draw a line of \verb/+/ characters.


\section{Defining new objects}

This can be done, but not by you, since it requires knowledge of the
Pop-11 programming language and of how Eden works. If you want to
experiment with different objects, ask me, and I'll be able to define
them fairly quickly.

There are a lot of suggestions below, but they're all quite rough. Some
worlds are better for investigating AI in than others, but current
Departmental resources don't allow me to do any further work on this. 

Here are some possibilities:
\begin{itemize}

\item Some objects allow the bug to share a square with them, others
don't. You can regard the first type as impassable, such as boulders.
I usually think of the second type as objects which are small enough to
be walked over or past, such as keys and food.

You could have an object which is impassable unless the bug is carrying
some object. It might require the bug to use this object first, as doors
do a key; or it might just be passable if the bug is holding something
which gives it access. You could also have objects which react to some
other characteristic of the bug, such as its energy; or which remain
impassable for a given number of moves and then vanish; or which remain
passable for a given number of moves and then become impassable (shrubs
growing into trees, perhaps).

You could also have an object which is {\it passable} unless the bug is
carrying something, such as the ``narrows'' mentioned in the table at
the end of {\it How to run Eden}.

\item Some objects can be picked up, others can't. Usually, those that
can't are the impassable ones, but this doesn't have to be so.

It is possible to make objects which when picked up, would leave another
one behind. I'm not sure what use this would be.

\item Most objects you've seen are static, and don't move unless the bug
touches them. However, it's possible to have autonomous objects, such as
``mice'' that move away from a persuing bug. If there's time, I may be
able to define such things.                 

\item Most of the objects also have no internal state, meaning they
react the same way every time something happens. But again, this need
not be so. For example, it's possible to make a slot machine which
counts the coins put into it and only dispenses food when a certain
total is reached. As another example, one of my worlds contains a
``factory'' object which dispenses a coin after the bug has used it a
certain number of times. I use this in conjunction with the slot
machine; if the bug can't find food or coins, then it has to work for
its living.

\item Objects could disappear, generate new objects, or change into new
objects, either spontaneously or when touched.

\item It's not possible directly to have objects with internal parts.
However, this can be imitated. For example, the bug could be set a task
of gathering the parts of a ``key of power''. When it puts these in
adjacent squares and uses one of them, the parts disappear and are
replaced by the key. This kind of setup can be used in a number of
planning puzzles.

\item Objects can affect the bug in various ways. For example, they
could kill it or reduce its energy: either when it just passes near
them, or when it enters the same square, or when it does something with
them.

\item Objects need not be deterministic. Their effect could depend on a
random-number generator. For example, the slot machine does not need to
drop its food in the same place each time. Non-deterministic objects are
a good way of demonstrating how flexible various AI techniques are.

\item Objects can affect the way the bug moves. For example, you could
have a ``teleporter'' which transports the bug to a distant location.
This location might depend on what the bug is carrying, or on its last
action. You can also have ``roads'' or ``tracks'' which confine the bug
to move along them until it reaches a junction. This is a good way to
experiment with path-finding techniques. In this connection, see also
the comment about new actions, below.        

\end{itemize}


\section{Defining new bugs}

The existing bug has one sense, vision. It's possible to define new
senses, and to make them depend on the objects. For example, one can
have a sense of smell. This might just give the general direction ---
rigght, left, forward or back --- of the nearest piece of food, or of
all the pieces of food. If the latter, then it could just give the
average direction, or it could give a list of directions, one for each
piece.

A sense of hearing could be added, so that the bug hears a ```bang''
when an object explodes, or squeaks from the mouse.

The sense of vision could be changed by making it less precise, or by
increasing its range.

As well as senses, one can alter the bug's ``physiology''. For example,
one can give the bug a measure of energy. As it moves, this energy
steadily decreases; it is replenished whenever the bug eats a piece of
food.

More interesting is to have competing physiological requirements which
force the bug to choose between goals. For an example of this, try
\begin{verbatim}
eps( psbug3, psworld3 ).
\end{verbatim}
\verb/psworld3/ defines a bug which has an energy which decreases with
each turn but increases when it feeds. The bug also has a thirst, which
increases exponentially with time. Finally, the bug can smell food
around it, as a list of directions, one for each piece of food. These
three quantities are given in the \verb/ETS/ part of the second status
line, on the right of the display.

The rules in \verb/psbug3/ are a simple attempt at dealing with these
requirements. Two of these rules involve {\it variables} --- the
\verb/T/ in \verb/thirst(T)/) yet. Each condition makes sure that the
rule isn't triggered unless the bug's thirst is greater than 20.
However, these rules also have higher priorities than the other three
rules, meaning that resolution-by-priority will choose them in
preference. So once the bug does realise that it needs to find water, it
will do so immediately, without breaking for food.

The world contains water objects, \verb/w/. The bug can get over these,
and then use them. This is drinking and reduces the thirst.


\section{Defining new actions}

It's also possible to give the bug a wider repertoire of actions. As it
stands, Eden has one general-purpose manipulate action, ``use''.
However, one could add more specific actions.

As one example, there could be a special ``jump'' action, which is used
when the bug enters a teleporter. The bug would have to supply an
auxiliary piece of data giving its desired destination.

As another example, it's possible to associate other sensory qualities
with objects. For example, one piece of food might have the colour red,
and another the colour yellow. These would not (unlike the symbol
\verb/+/) be sensed automatically by the bug's vision. Instead, it would
have to direct its attention to a specific place in its visual field,
and issue an \verb/examine/ action. This would then dump the colour
into some kind of short-term memory.


\end{document}
