From: Garrett Mitchener <wgm2@acpub.duke.edu>
  To  : 
  Date: 28 Apr 1999 11:28:46 -0400

Re: A note about graphs

I got this reply:

the way our graphnodes work is
like this:

Box myPosition = whatever; /* Box extends GraphNode*/

if the user requests moving north, you could say:

if (myPosition.north != null) myPosition = myPosition.north;

this makes movement very natural and simple, or so we thought.

you say:

>etc. all through your code, then you need to fix it up, so that you
>can say this kind of thing instead:
>
>Enumeration e = gn.getConnections();
>
>while( e.hasMoreElements() )
>{
 > ((Connection)e.getNextElement()).doSomething();
>}

i don't see how you can pick which direction you are moving here.  you're
telling every connection in order to doSomething- what is doSomething()?
does it move the player?  i'm not sure i understand.  if you have a minute,
could you clarify?  thanks very much- i really appreciate your help!

--------------

What I was hinting at is that your directions are hard-coded.  You
have no way to add up, down, ne, se, nw, sw, and three teleporters to
a given room.  You have five directions (n,s,e,w,t) and to determine
what a player is allowed to do, you must test if there is a room in
each of those five directions.

You're right in the sense that it is a fairly intuitive way to move,
at least on a plane.  But depending on how you decide to extend your
game, it could be a limitation.  Suppose we want a large dining room
in a castle with two doors on the north wall?  What if we're on a
donut-shaped space station and you can walk all the way around in a
circle and come back to where you started?  And what if someone got
really sadistic and wrote a game on a Mobius strip?  (This is where if
you go off one side of the board you come back on the other side, but
flipped over.)

Those extensions may not be something you want to worry about.  It's
up to you how flexible your program is.  If you have a truly general
graph class, none of those extensions is a problem, whereas some of
them are going to be a bit strange or impossible if you maintain your
n,s,e,w,t kind of graph.  Removing those limitations would improve
your design and probably improve your grade, but I can't say for sure
that leaving them in will lower your grade unless I see more of your
code.

If you put a list of connection objects in each room, you can give
them methods like getDirection() or tryToOpen().  You might for
example have a bunch of buttons, N,S,E,W, that are initally disabled.
You have them in a map from direction names to buttons or control
objects that each have a button, etc.  Then, you iterate over all
possible connections in a room, and enable the appropriate buttons and
feed them the connection object.  When the user pushes a button, you
go through the connection object.  Alternatively, suppose each room
has a list of doors perhaps not corresponding to directions and you
just have a list widget or other kind of menu of doors.  That ought to
be easy to build from a list, and you can have as many doors in as
many directions as you want.  Plus teleporters are possible, etc.

At any rate, this is a design decision that your group will have to
make.

	-- The Phantom of the Opera