mapping - open source software
Plugh!
docmentation) when I saw that it uses an open source package from ATT
called GraphViz to draw the relationship beetwen classes in source
code. But the example pictures on the homepage at
http://www.research.att.com/sw/tools/graphviz/ look just like what I
draw when I am mapping on papaer.
I am rather busy at the moment, but I am sure that this would make an
excellent start point for someone who wants to produce a mappoing
program.
Sam Denton
Well, yes and no. Every automatic graphing program I've ever looked
at doesn't give you any control over which side of the node the lines
come out of, nor where the nodes lie in relation to each other. Both
of these are is pretty important for us IFers who want to see that the
north exit of this passage connects to the south exit of that room.
What you need are nodes that have mutiple connection points in at
least the eight planar compass directions, and a program that then
lays out the graph appropriately.
Branko Collin
I use the open source program Dia for mapping.
(<http://www.lysator.liu.se/~alla/dia/>)
--
branko
ik schrijf woorden achterstevoren
Plugh!
Some good points there. However, since it's open source it can be
tweaked and it saves a significant amount of development work to use
it as a start point.
As for the eight planar compass directions, I am never sure. On the
one hand, most modern i-f tends towards such realism - but it fails
the Colossal Cave test.
Daniel Barkalow
> As for the eight planar compass directions, I am never sure. On the
> one hand, most modern i-f tends towards such realism - but it fails
> the Colossal Cave test.
Adventure does have the exits leaving the rooms in the eight planar
compass directions (aside from special directions and up and down, of
course); it's just that the connections then enter other rooms at
different (still compass direction) angles.
-Iabervon
*This .sig unintentionally changed*
Plugh!
Although that was not your point, I realize, some folks object even to
that in maping. They want to have only mirror image passges - go
north, return south, etc.
From memory, you can go SW from the Hall of the Mountain King in
Colossal Cave, though I can't rember where it gets you - if there is a
treasure there, then you can't get a perfect score without going SW.
In any case, you can't map CC in 8 planar directions.
I thiok you can go weird directions too from the Swiss Cheese Room
(and maybe bedquilt), but those are in any case difficult to
represent.
I hope that I don't sound too pedantic. It's just that modern i-f is
so conservative, but when trying to design a mapping tool the gold
standard IMO has to be CC.
Quintin Stone
> > Adventure does have the exits leaving the rooms in the eight planar
> > compass directions (aside from special directions and up and down, of
> > course); it's just that the connections then enter other rooms at
> > different (still compass direction) angles.
>
> Although that was not your point, I realize, some folks object even to
> that in maping. They want to have only mirror image passges - go north,
> return south, etc.
I can see objecting to it in the game itself... but in mapping software?
How else are you supposed to map a game where exits do not reciprocate?
Any decent mapping software *must* support the idea of
go-south-return-east, otherwise it is simply not adequate for those
uncommon but very real occurrences in various games.
/====================================================================\
|| Quintin Stone O- > "You speak of necessary evil? One ||
|| Code Monkey < of those necessities is that if ||
|| Rebel Programmers Society > innocents must suffer, the guilty must ||
|| st...@rps.net < suffer more." -- Mackenzie Calhoun ||
|| http://www.rps.net/QS/ > "Once Burned" by Peter David ||
\====================================================================/
Daniel Barkalow
> Daniel Barkalow <iabe...@iabervon.org> wrote in message news:<Pine.LNX.4.21.031230...@iabervon.org>...
> > On 29 Dec 2003, Plugh! wrote:
> >
> > > As for the eight planar compass directions, I am never sure. On the
> > > one hand, most modern i-f tends towards such realism - but it fails
> > > the Colossal Cave test.
> >
> > Adventure does have the exits leaving the rooms in the eight planar
> > compass directions (aside from special directions and up and down, of
> > course); it's just that the connections then enter other rooms at
> > different (still compass direction) angles.
>
> Although that was not your point, I realize, some folks object even to
> that in maping. They want to have only mirror image passges - go
> north, return south, etc.
I think people generally don't mind too much if they can tell from the
text which way they entered every room they enter. I think
"go SE, return N" is pretty common for halls with multiple doors in the
same wall.
> From memory, you can go SW from the Hall of the Mountain King in
> Colossal Cave, though I can't rember where it gets you - if there is a
> treasure there, then you can't get a perfect score without going SW.
> In any case, you can't map CC in 8 planar directions.
>
> I thiok you can go weird directions too from the Swiss Cheese Room
> (and maybe bedquilt), but those are in any case difficult to
> represent.
SW from the Hall of the Mountain King is a secret E/W canyon, but you
often just crawl around in circles if you try to go that way. That exit,
swiss cheese, and bedquilt are examples of a single direction with
multiple destinations (where the result is randomly chosen). They're still
normal planar directions, though. (There are other examples, as well)
You certainly need more than planar directions to map CC, since you need
up and down (which you obviously need in many games), as well as two magic
words, at least one (and more for completeness) room name.
> I hope that I don't sound too pedantic. It's just that modern i-f is
> so conservative, but when trying to design a mapping tool the gold
> standard IMO has to be CC.
Certainly; no other game has been able to have that complex a map, because
they've all put more effort into things like plot and puzzles instead of
almost exclusively map. Adventure also manages to be playable despite the
complex map in part due to its extreme realism, being derived from a real
place with a complex map. About the only other place that would be
sufficiently interesting to set such a game in would probably be the
London Underground (which would be fun; in the Underground, directions
follow the standard subway map; outside, they follow geography, which is
often quite contradictory).
In any case, mapping software will probably have to support multiple
pages, such that it can do something sensible with maps that would
otherwise be non-planar (in the sense of planar involving edges crossing
each other). But this is probably true of most maps, even currently,
assuming that they have parts that go under other parts.
Sam Denton
> SW from the Hall of the Mountain King is a secret E/W canyon, but you
> often just crawl around in circles if you try to go that way. That exit,
> swiss cheese, and bedquilt are examples of a single direction with
> multiple destinations (where the result is randomly chosen). They're still
> normal planar directions, though. (There are other examples, as well)
> Adventure also manages to be playable despite the
> complex map in part due to its extreme realism, being derived from a real
> place with a complex map.
> In any case, mapping software will probably have to support multiple
> pages, such that it can do something sensible with maps that would
> otherwise be non-planar (in the sense of planar involving edges crossing
> each other). But this is probably true of most maps, even currently,
> assuming that they have parts that go under other parts.
I first played CC back in 1981 (the version written in Fortran on an
IBM mainframe over a 300 baud dial-up line). I was also a spelunker
at the time, and had no trouble with the plausibility of the map, as
the game would often say things like "you crawl through a long twisty
passage before arriving at...". So, it made perfect sense that any
direction out of a room could connect to any direction in the
destination. I've never played Graham Nelson's re-creation, but the
original version had a "back" verb, that would always return you to
the previous room, even if the trip back would normally go through one
of the random passages mentioned. (There were a few one-way passages
where "back" wouldn't work, but they were clearly indicated before you
entered them. On the other hand, it did work in the mazes, which made
the job of mapping them a wee bit easier.)
For some reason, the "save" command didn't work on that version, so I
tended to play in marathon sessions. I got to know the main section
of the cave pretty well, from going through it so many times. I
probably drew and redrew my maps a dozen times, refining the relative
positions of the rooms with each other.
Anyway, on one of those trips through CC, I finally noticed that all
of the rooms containing falling water could be lined up vertically
with each other and with the slot on the surface, so I created my
Magnus Opus, a 3-D map consisting of several pieces of paper and not a
few soda straws, showing exactly where the various levels were in
relation to each other. It wasn't really that useful, but I was even
more impressed by how well everything fit together. Of course, at the
time I didn't realize that CC was based on part of the Flint Ridge
system.
Plugh!
> On 2 Jan 2004, Plugh! wrote:
>
> > > Adventure does have the exits leaving the rooms in the eight planar
> > > compass directions (aside from special directions and up and down, of
> > > course); it's just that the connections then enter other rooms at
> > > different (still compass direction) angles.
> >
> > Although that was not your point, I realize, some folks object even to
> > that in maping. They want to have only mirror image passges - go north,
> > return south, etc.
>
> I can see objecting to it in the game itself... but in mapping software?
> How else are you supposed to map a game where exits do not reciprocate?
> Any decent mapping software *must* support the idea of
> go-south-return-east, otherwise it is simply not adequate for those
> uncommon but very real occurrences in various games.
>
Sorry. Once again I fail to get my point across (I'm not very good at
putting things in writing). For fear of offending aprevious poster, I
may have suuggested that certain practises are acceptable...
Personally, I believe that nothing short of full flexibility is
acceptable. Thst means
in/out/shakeitallabout/up/down/turnaround/eenymeenymeinie/youareit
Please visit http://plugh.info and have a look at how my mapping
works. If you have any suggestions, I welcome them most greatfully...
Plugh!
> > Colossal Cave, though I can't rember where it gets you - if there is a
> > treasure there, then you can't get a perfect score without going SW.
> > In any case, you can't map CC in 8 planar directions.
> >
> > I thiok you can go weird directions too from the Swiss Cheese Room
> > (and maybe bedquilt), but those are in any case difficult to
> > represent.
>
> SW from the Hall of the Mountain King is a secret E/W canyon, but you
> often just crawl around in circles if you try to go that way. That exit,
> swiss cheese, and bedquilt are examples of a single direction with
> multiple destinations (where the result is randomly chosen). They're still
> normal planar directions, though. (There are other examples, as well)
SSW to get to the priates chest? I forget what the orignal discussion
was about - maybe needing only 8 directions?
> You certainly need more than planar directions to map CC, since you need
> up and down (which you obviously need in many games), as well as two magic
> words, at least one (and more for completeness) room name.
Do you have any ideas about how to represent one way passages, magic
words and random direction passages? Please look at http://plugh.info
and offer me some advice on my mapping.
> > I hope that I don't sound too pedantic. It's just that modern i-f is
> > so conservative, but when trying to design a mapping tool the gold
> > standard IMO has to be CC.
>
> Certainly; no other game has been able to have that complex a map, because
> they've all put more effort into things like plot and puzzles instead of
> almost exclusively map.
Granted - but a program such as mine has to be flexible enough to
handle CC and even CC II if anyone is ambitious enough to contamplate
it.
> Adventure also manages to be playable despite the
> complex map in part due to its extreme realism, being derived from a real
> place with a complex map. About the only other place that would be
> sufficiently interesting to set such a game in would probably be the
> London Underground (which would be fun; in the Underground, directions
> follow the standard subway map; outside, they follow geography, which is
> often quite contradictory).
I did once contemplate that. CC does remain the touchstone, the gold
standard, against which I measure all others (including my own, which
is why none see the light of public day).
>
> In any case, mapping software will probably have to support multiple
> pages,
Agreed - do I handle the loinks between pages acceptably ?
> such that it can do something sensible with maps that would
> otherwise be non-planar (in the sense of planar involving edges crossing
> each other). But this is probably true of most maps, even currently,
> assuming that they have parts that go under other parts.
IMO, multi maps don't just need to handle 'levels', they are also
useful for dividing up very large maps which are on a single level.
Daniel Dawson
written by Plugh! <pl...@plugh.info>. It says:
>Do you have any ideas about how to represent one way passages, magic
>words and random direction passages? Please look at http://plugh.info
>and offer me some advice on my mapping.
Okay. Well, one-way passages, I think, are obvious: just use one-way arrows!
Hmm, looking at one screenshot I'm confused: it looks like there's a 'beach'
room to the south of a 'startroom', but the tooltip on 'beach' says
'south=startroom'. startroom should be below beach!
Also closely related, an exit in a given (normal) direction should be on that
side of the map node *and* initially in that direction; e.g. a SE exit should
have a line coming out of the SE corner of the box *and* going in the SE
direction; if the destination is elsewhere on the map, it will be necessary to
add curves or corners to the line. Well, that's my belief about mapping,
anyway.
As for magic words and random directions, I don't know.
>IMO, multi maps don't just need to handle 'levels', they are also
>useful for dividing up very large maps which are on a single level.
Or, say, buildings where there are only a few locations outside and many
inside. (Take the house in Zork I, for example. Well, not a very extreme
example, but I still like to separate the outside and inside of the house.)
--
| Email: Daniel Dawson <ddawson at icehouse.net> ifMUD: DanDawson |
| Web: http://www.icehouse.net/ddawson/ PGP key: 'about' on web site |
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Adrien Beau
>
> Do you have any ideas about how to represent one way passages,
> magic words and random direction passages? Please look at
> http://plugh.info and offer me some advice on my mapping.
One thing I've "discovered" when mapping Anchorhead last year is
that you can vastly improve the clarity of a map when you stop
trying to connect everything. The two mazes (at the top-left and
bottom-right of the map) are prime examples of this.
You can add a lot of meaning with some conventions on the drawing
(I used triangle/plain arrows to mean one-way paths, dashed lines
to mean a change of level such as up or down, and curved lines
when a path was not leading where expected.)
Textual annotations can bring a lot, and I think I would use them
for magic words (just an arrow with the text "SAY XYZZY" next to
it) or for random directions (several arrows starting from the
same point, with the word "random" crossing the arrows).
Of course, all this is more easily said than done, and more easily
hand-done than programmed.
Oh, the map is here, don't click if you don't want to be spoiled:
http://boa13.free.fr/anchorhead.png
(.eps, .ps, and .svg also available, just change the extension).
--
spam....@free.fr
You have my name and my hostname: you can mail me.
(Put a period between my first and last names).
Graham Holden
skip this message....
On 4 Jan 2004 06:21:54 -0800, dda...@nospam-icehouse.net (Daniel
Dawson) wrote:
>You pick up and read article <68bd0e8.04010...@posting.google.com>,
>written by Plugh! <pl...@plugh.info>. It says:
>>Do you have any ideas about how to represent one way passages, magic
>>words and random direction passages? Please look at http://plugh.info
>>and offer me some advice on my mapping.
>
>Okay. Well, one-way passages, I think, are obvious: just use one-way arrows!
That's what I've always done on paper; an added advantage is that
because there's no reverse direction, the arrow can hit the
destination room at any convenient point, rather than trying to make
it hit at the "reverse" location.
>Also closely related, an exit in a given (normal) direction should be on that
>side of the map node *and* initially in that direction; e.g. a SE exit should
>have a line coming out of the SE corner of the box *and* going in the SE
>direction; if the destination is elsewhere on the map, it will be necessary to
>add curves or corners to the line. Well, that's my belief about mapping,
>anyway.
Seconded, e.g.:
/-----\
/ \
+---------+ +---------+
|Some Room| |Another |
| | |Room |
+---------+ +---------+
(i.e. NE from 'Some Room' leads to 'Another Room'; NW leads back).
>As for magic words and random directions, I don't know.
Magic words/non-standard directions (e.g. 'enter vortex') I've usually
handled by labelling the link:
+---------+ +----------+
|First |"Plugh" |Another |
|Room |----------->|Room |
| | | |
+---------+ +----------+
Which side of the room such links come out of doesn't really matter;
usually it's whichever is easiest given the existing topology.
(If a magic word worked from a lot of locations, trying to put a link
from every one to the room in question would probably overly clutter
the map, in which case I would probably either (a) have stub-links
coming from each room [cf. "sections" below], or (b) mark each room in
some way (maybe an asterisk in the corner) and have a note on the map,
or (c) (if the topology permits) put something like a dashed line
around all affected rooms together with a note about the magic word).
I also occasionally use this "labelled link" if it's not convenient to
have a normal direction leave from the "correct" edge of the room:
+---------+ +----------+
|First |SW |Another |
|Room |------------|Room |
| | | |
+---------+ +----------+
I.e. SW takes you from 'First Room' to 'Another Room', W would take
you back again. In this example, I would only use the above technique
where other factors would prevent the more representational:
+---------+
|First |
|Room |
| |
+---------+
/
/
| +---------+
| |Another |
+--|Room |
| |
+---------+
Random directions (one exit leads to one of three rooms) would
generally be something like:
+---------+
|First |
--|Random |
/ |Room |
/ +---------+
/
+---------+ / +---------+
|First | / |Second |
|Room |------o-------|Random |
| | \ |Room |
+---------+ \ +---------+
\
\ +---------+
\ |Third |
--|Random |
|Room |
+---------+
(i.e. E from 'First Room' leads to one of the three rooms on the
right; W from all of them returns to 'First Room'.
>>IMO, multi maps don't just need to handle 'levels', they are also
>>useful for dividing up very large maps which are on a single level.
>
>Or, say, buildings where there are only a few locations outside and many
>inside. (Take the house in Zork I, for example. Well, not a very extreme
>example, but I still like to separate the outside and inside of the house.)
Again, second the need for a mapper to have 'levels' not just to
handle, say, floors of a tall building; I also second the
inside/outside as commonly the "correct" place to partition a map
(often because the "rooms" outside represent larger areas than a room
inside, and so a map that tried to accommodate both could look weird.
Sometimes going UP/DOWN is a natural call to switch to another
map/section of map which is conceptually on top of/below the current
map. Other times, an occasional up/down "obviously" belongs on the
same page, and the map sections are governed by other splits.
To handle such map-sections on paper, I generally have a link
(emerging correctly where possible) labelled to where it leads. If
the target is on the same sheet of paper (to avoid a long snaking
line) then I normally just use the room name; if it's on another
sheet, then I'd label it with the Sheet Name and the Room Name, e.g.:
+--------+ +--------+
|Living | |Entrance| Sheet 2
|Room |-------|Hall |<----->Outside
| | | | House
+--------+ +--------+
\D
\
\---> Cellar
and on Sheet 2 I would have:
+--------+
Sheet 1 |Outside |
Entrance <----->|House |
Hall | |
+--------+
Assuming a moderately-sane gameworld, a "good" set of map sheets would
only have very few such "off-page" links, and they should generally
occur at "logical" breaks in the game. I.e. you spend a while faffing
around inside a house; you get everything you need together, and then
leave to enter the big, wide world -- the story proceeds to the next
"stage", and the map continues on the next "sheet".
I say "sheet" because depending on the size of paper, I might have two
or three "logical" sheets on the same physical piece of paper, e.g.:
+-------------------------------------------------------+
| | |
| | |
| | |
| Area 1 | Area 2 |
| | |
| | |
| | |
| |---------------+---------------|
| | |
| | |
| | Area 3 |
| | |
| | |
+-------------------------------------------------------+
Other general mapping points:
I _generally_ favour keeping all "rooms" on a map the same size, but
will sometimes have a larger room where it assists the layout or it's
overwhelmingly "natural" to do so.
None of the ideas above should be taken as "rules", only guidelines;
the art of good map-making is knowing when and where to partition the
map, and when and where to break the "rules" to aid clarity.
Just my 2p-worth.
--
Regards,
Graham Holden
g DASH holden AT dircon DOT co DOT uk
(to reply by email, replace DASH, AT and DOT as appropriate).
There are 10 types of people in the world;
those that understand binary and those that don't.
Daniel Barkalow
> > > From memory, you can go SW from the Hall of the Mountain King in
> > > Colossal Cave, though I can't rember where it gets you - if there is a
> > > treasure there, then you can't get a perfect score without going SW.
> > > In any case, you can't map CC in 8 planar directions.
> > >
> > > I thiok you can go weird directions too from the Swiss Cheese Room
> > > (and maybe bedquilt), but those are in any case difficult to
> > > represent.
> >
> > SW from the Hall of the Mountain King is a secret E/W canyon, but you
> > often just crawl around in circles if you try to go that way. That exit,
> > swiss cheese, and bedquilt are examples of a single direction with
> > multiple destinations (where the result is randomly chosen). They're still
> > normal planar directions, though. (There are other examples, as well)
> Again, from memory, there is at least one 'weird' direction - maybe
> SSW to get to the priates chest? I forget what the orignal discussion
> was about - maybe needing only 8 directions?
I believe the pirate's chest was a normal direction from the room it was
connected to. It was just tricky to get there.
> > You certainly need more than planar directions to map CC, since you need
> > up and down (which you obviously need in many games), as well as two magic
> > words, at least one (and more for completeness) room name.
> Do you have any ideas about how to represent one way passages, magic
> words and random direction passages? Please look at http://plugh.info
> and offer me some advice on my mapping.
I didn't find a specific part that discussed mapping, so I may be missing
something (I did find that your page closes the html tag before the body
tag, which turned up a bug in my browser).
I think that the map should either support a "landscape map", where you
draw how you want the world to be arranged, tack the rooms to spots on it,
and connect them, or the connections should be determined mostly by the
program, with it shifting rooms and passages to make the map tidy.
One way passages get an arrowhead at the far end (or no arrowhead at the
near end, depending on how you're doing two-way passages). Magic words,
up, down, and special directions get a label on the near end saying how
you do it. Random destinations are handled with multiple lines coming out
of the same point on the near end.
> > > I hope that I don't sound too pedantic. It's just that modern i-f is
> > > so conservative, but when trying to design a mapping tool the gold
> > > standard IMO has to be CC.
> >
> > Certainly; no other game has been able to have that complex a map, because
> > they've all put more effort into things like plot and puzzles instead of
> > almost exclusively map.
> Granted - but a program such as mine has to be flexible enough to
> handle CC and even CC II if anyone is ambitious enough to contamplate
> it.
I think that there isn't particularly much to make the map of CC
technically difficult. It's mainly very extensive, which means the player
has to form some understanding of it, but a computer program wouldn't
encounter any special issues. Using software to design something like CC
is probably impossible, because what you really need to design something
of the sort is a real cave system.
> > Adventure also manages to be playable despite the
> > complex map in part due to its extreme realism, being derived from a real
> > place with a complex map. About the only other place that would be
> > sufficiently interesting to set such a game in would probably be the
> > London Underground (which would be fun; in the Underground, directions
> > follow the standard subway map; outside, they follow geography, which is
> > often quite contradictory).
> I did once contemplate that. CC does remain the touchstone, the gold
> standard, against which I measure all others (including my own, which
> is why none see the light of public day).
Perhaps you ought to compare your work to CC on other factors than the
map. I don't think a game could have as elaborate a map as CC without
being as plotless, because it would be impossible to keep the player
involved in a plot while they were lost or exploring.
> > In any case, mapping software will probably have to support multiple
> > pages,
> Agreed - do I handle the loinks between pages acceptably ?
Arrow to a label, which matches the other end on the other page.
> > such that it can do something sensible with maps that would
> > otherwise be non-planar (in the sense of planar involving edges crossing
> > each other). But this is probably true of most maps, even currently,
> > assuming that they have parts that go under other parts.
> IMO, multi maps don't just need to handle 'levels', they are also
> useful for dividing up very large maps which are on a single level.
Certainly; I just meant that they only become necessary (to prevent
non-intersecting passages from crossing on the map) if a passage or room
is over another. They are generally desirable for a number of other
reasons.
Plugh!
> room to the south of a 'startroom', but the tooltip on 'beach' says
> 'south=startroom'. startroom should be below beach!
often. Those who produce 'modern' i-f with all directions conventional
would like me to auto arrange the map.
That would be a major, major effort, so I weasel out of it by saying
that it wouldn't be flexible enough to accomodate CC, so it is the
responsibility of the programmer to lay out his map.
I may eventually get around to that, but it is a major effort and
there is much to do besides - like importing existing TADS files,
running the TADS compielr form within the program , etc.
As an aside, I am contemplating generating code for the map (just
extend the room class with a few extra properties) and getting hold
iof the source code of a TADS interprter and tweaking it to show the
map as the player explores. But that is also a fairly major project.
The final word on this particular screenshot is that it was an
Australian beach ;-)
> Also closely related, an exit in a given (normal) direction should be on that
> side of the map node *and* initially in that direction; e.g. a SE exit should
> have a line coming out of the SE corner of the box *and* going in the SE
> direction; if the destination is elsewhere on the map, it will be necessary to
> add curves or corners to the line. Well, that's my belief about mapping,
> anyway.
I agree - in principle - but I still need to know how to represent
oddball directions like SSW and what to do with in/out/up/down/magic
words. So, I have something with which we can live for the time being
and when I have prodcuded v1.0 I will revisit this topic.
(btw - implemetation detail. Teh arrow which I am currently using can
only attach itself to a corner or middle of a side of a box)
> As for magic words and random directions, I don't know.
Different line properties on the arrows - dashed or dotted,
colo(u)red, etc - but if I have 'literal' directions, which
corner/side should radom passages and magic words atatch to (perhaps
somewhere inside the box)?
Thanks very much for the feedback.
Plugh!
> I didn't find a specific part that discussed mapping, so I may be missing
> something (I did find that your page closes the html tag before the body
> tag, which turned up a bug in my browser).
Taht's MAcromedia DreamWeaver for you! I'll look into it. Thanks.
> I think that the map should either support a "landscape map", where you
> draw how you want the world to be arranged, tack the rooms to spots on it,
> and connect them, or the connections should be determined mostly by the
> program, with it shifting rooms and passages to make the map tidy.
I think the former is as I have implemented it and the latter is as
some folks wouldf like it (of course, those are folks who don't
realize the effort involved to implement this. However, it gets asked
often enough that I really have to consider it - and, when I do, the
purists will insist on complete control, so I will have to support
both simultaneously).
> One way passages get an arrowhead at the far end (or no arrowhead at the
> near end, depending on how you're doing two-way passages).
Clear enough.
> Magic words,
> up, down, and special directions get a label on the near end saying how
> you do it.
I could - I suppose then you don't care which corner they enamate
form?
> Random destinations are handled with multiple lines coming out
> of the same point on the near end.
You mean I start a single arrow from teh source and then fork it half
way to multiple destinations?
> I think that there isn't particularly much to make the map of CC
> technically difficult. It's mainly very extensive, which means the player
> has to form some understanding of it, but a computer program wouldn't
> encounter any special issues. Using software to design something like CC
> is probably impossible, because what you really need to design something
> of the sort is a real cave system.
Good point. But people will still want to try, so I have to try to
support it. For sure, if I made it auto-layout only the purists here
would shoot it down.
> > > Adventure also manages to be playable despite the
> > > complex map in part due to its extreme realism, being derived from a real
> > > place with a complex map. About the only other place that would be
> > > sufficiently interesting to set such a game in would probably be the
> > > London Underground (which would be fun; in the Underground, directions
> > > follow the standard subway map; outside, they follow geography, which is
> > > often quite contradictory).
> > I did once contemplate that. CC does remain the touchstone, the gold
> > standard, against which I measure all others (including my own, which
> > is why none see the light of public day).
>
> Perhaps you ought to compare your work to CC on other factors than the
> map. I don't think a game could have as elaborate a map as CC without
> being as plotless, because it would be impossible to keep the player
> involved in a plot while they were lost or exploring.
What other factors do you have in mind? Btw, there are still
regularly i-f ecplorathons produced (I like them).
> > > In any case, mapping software will probably have to support multiple
> > > pages,
> > Agreed - do I handle the links between pages acceptably ?
>
> Arrow to a label, which matches the other end on the other page.
That's what I do.
> > > such that it can do something sensible with maps that would
> > > otherwise be non-planar (in the sense of planar involving edges crossing
> > > each other). But this is probably true of most maps, even currently,
> > > assuming that they have parts that go under other parts.
> > IMO, multi maps don't just need to handle 'levels', they are also
> > useful for dividing up very large maps which are on a single level.
>
> Certainly; I just meant that they only become necessary (to prevent
> non-intersecting passages from crossing on the map) if a passage or room
> is over another.
Particularly on auto-mapping.
> They are generally desirable for a number of other
> reasons.
Agreed.
thanks for the input.
Plugh!
> On Samedi 3 Janvier 2004 14:24, Plugh! wrote:
> >
> One thing I've "discovered" when mapping Anchorhead last year is
> that you can vastly improve the clarity of a map when you stop
> trying to connect everything.
D'oh! I never, ever thought of that. It just seemed obvious that you
have to. I will think about this. Thanks.
> You can add a lot of meaning with some conventions on the drawing
> (I used triangle/plain arrows to mean one-way paths, dashed lines
> to mean a change of level such as up or down,
Good idea. Up/down doesn't always lead to another map.
> and curved lines
> when a path was not leading where expected.)
But you don't mark the actual direction on the map?
> Textual annotations can bring a lot, and I think I would use them
> for magic words (just an arrow with the text "SAY XYZZY" next to
> it) or for random directions (several arrows starting from the
> same point, with the word "random" crossing the arrows).
Sounds good - especially the random part (lets just hope that we don't
have multiple random passages from teh same room).
> Of course, all this is more easily said than done, and more easily
> hand-done than programmed.
Aye, there's the rub! I also have to judge how much effort to put
into each part of the program, and things like auto-map/logical layout
and snap to grid are tough to do
> Oh, the map is here, don't click if you don't want to be spoiled:
> http://boa13.free.fr/anchorhead.png
> (.eps, .ps, and .svg also available, just change the extension).
Well done. Anything larger would need multiple maps, though.
Thanks very much for your comments.
Evin Robertson
>> One thing I've "discovered" when mapping Anchorhead last year is
>> that you can vastly improve the clarity of a map when you stop
>> trying to connect everything.
Anchorhead is less difficult to map connectedly than some IF games. For
example, the maze in the lower-right of your (rather nice) map could be
drawn like <http://members.cox.net/erobertson10/anchorhead.pdf>.
This map was algorithmically generated with a small amount of manual
guidance. Most of the bent connections were drawn simply by adding an
extra dummy room in the path. But some of the cycles in the map are
impossible to draw without using doubly-bent connections, the adding of
which I did by intuition rather than method.
>> Of course, all this is more easily said than done, and more easily
>> hand-done than programmed.
To which Plugh! exclaimed:
> Aye, there's the rub! I also have to judge how much effort to put
> into each part of the program, and things like auto-map/logical layout
> and snap to grid are tough to do
Indeed. I'm very certain that drawing maps in the style that I linked
to is NP-complete. I'm currently investigating whether various
approximations (such as lines not perfectly at 90 or 45 degrees) are of
any use, or whether there are heuristics which will improve the running
time in the common case of the maps of most existing IF games. If
you're interested, <http://members.cox.net/erobertson10/np.pdf> has a
few more details. I'll report back if I make more progress.
Rick Clark
> Different line properties on the arrows - dashed or dotted,
> colo(u)red, etc - but if I have 'literal' directions, which
> corner/side should radom passages and magic words atatch to (perhaps
> somewhere inside the box)?
I have been playing around with your program, and I have to say it is quite
nice. As you say, it has a way to go, but it is a very nice start.
I have thought about mapping myself (I have considered creating my own
mapping program), and it does pose some challenges. The compass directions
are not that hard to deal with as long as you create a point of reference,
i.e., the top of the form is North. Creating rooms based on compass
directions then would fall naturally into a "grid" system by treating a
compass direction as an offset to the reference point.
In my view, up and down should lead to a new page (new level in the grid, so
to speak) with hot-links that allow you to "travel" from one page to
another. For example, Room 1 has a down direction that ends in a small tag
that when clicked takes you to a new page that has the "down" room.
Personally, I like this as it creates a layered map that is easier to
visualize by placing detail into its proper relationship.
I am not sure what the concept of random and magic directions are, but if
they lead to existing structures within the same map, then using (clickable)
iconic identifiers could be the way to go. If they lead to different layers
within a map, then they could be handled the same as up and down.
The concept of in/out could be mapped to compass directions, or a subset of
them, I would think. The games I have played where you use in and out, I
could map them as I would a compass direction, by taking into account where
I was and where I ended up. I tagged them as in or out, but mapped them as
if I was going east, for example. Not having played a great number of games,
I am not sure this is valid in all cases.
Well, just some thoughts, worth about $.02. :)
--
Rick Clark
http://www.rickclark.org
Adrien Beau
>
> Anchorhead is less difficult to map connectedly than some IF
> games. For example, the maze in the lower-right of your (rather
> nice) map could be drawn like
> <http://members.cox.net/erobertson10/anchorhead.pdf>.
>
> This map was algorithmically generated with a small amount of
> manual guidance. Most of the bent connections were drawn simply
> by adding an extra dummy room in the path. But some of the
> cycles in the map are impossible to draw without using
> doubly-bent connections, the adding of which I did by intuition
> rather than method.
It certainly looks clearer than my initial attempt at mapping that
maze! For some reason I can't remember, I used only one-way
arrows, that is twice as many lines as needed.
http://boa13.free.fr/anchor-map.png
(Hey, isn't there a sort of demonic shape amidst all these
lines? ;)
Daniel Dawson
written by Plugh! <pl...@plugh.info>. It says:
>Different line properties on the arrows - dashed or dotted,
>colo(u)red, etc - but if I have 'literal' directions, which
>corner/side should radom passages and magic words atatch to (perhaps
>somewhere inside the box)?
I liked some of the suggestions from others about random directions.
Personally, I would be inclined to draw a single line and split it with a
diamond, to borrow the branch symbol from flowcharts and such. (Yes, I know
flowcharts are not used that much in software design these days.)
Daniel Dawson
>In my view, up and down should lead to a new page (new level in the grid, so
>to speak) with hot-links that allow you to "travel" from one page to
>another. For example, Room 1 has a down direction that ends in a small tag
>that when clicked takes you to a new page that has the "down" room.
>Personally, I like this as it creates a layered map that is easier to
>visualize by placing detail into its proper relationship.
Fine, as long as it is not strictly enforced: you don't want to waste a whole
page on a single room that happens to be connected vertically.
>The concept of in/out could be mapped to compass directions, or a subset of
>them, I would think. The games I have played where you use in and out, I
>could map them as I would a compass direction, by taking into account where
>I was and where I ended up. I tagged them as in or out, but mapped them as
>if I was going east, for example. Not having played a great number of games,
>I am not sure this is valid in all cases.
Sure. You have to go somewhere, do whatever works. Conceptually, of course, in
and out are not always in any compass direction from the starting room;
something like a booth in the middle of a room or a gazebo, for instance, i.e.
anything that is not on one side or corner, does not really fit this model. Yet
the normal mapping conventions require such a room to be elsewhere on the map.
I can think of two ways to avoid that: either break the convention and draw it
inside the node for the enclosing room, or don't draw it at all (it's may not
be a 'real' room anyway as far as the world model is concerned).
Daniel Barkalow
> Daniel Barkalow <iabe...@iabervon.org> wrote in message news:<Pine.LNX.4.21.040106...@iabervon.org>...
>
> > I think that the map should either support a "landscape map", where you
> > draw how you want the world to be arranged, tack the rooms to spots on it,
> > and connect them, or the connections should be determined mostly by the
> > program, with it shifting rooms and passages to make the map tidy.
> I think the former is as I have implemented it and the latter is as
> some folks wouldf like it (of course, those are folks who don't
> realize the effort involved to implement this. However, it gets asked
> often enough that I really have to consider it - and, when I do, the
> purists will insist on complete control, so I will have to support
> both simultaneously).
I think you'll have to support one at a time (that is, each map will
either be arranged by the user or arranged by the system, not a
combination). I think what you've implemented is missing a feature that I
think would make it more helpful: you ought to be able to draw in the
background, and then stick rooms to it, so you can first do a space-based
map (as a drawing), and then do a room-based map for actually writing the
IF. Just having a plain background behind the rooms and passages doesn't
really help much in guiding the map design.
> > Magic words,
> > up, down, and special directions get a label on the near end saying how
> > you do it.
> I could - I suppose then you don't care which corner they enamate
> form?
Nope, although it might be nice to have "up" and "down" opposite each
other when they're both on the same room, with "up" on the top side of the
room somewhere. Beyond that, arrange them to minimize tangling.
> > Random destinations are handled with multiple lines coming out
> > of the same point on the near end.
> You mean I start a single arrow from teh source and then fork it half
> way to multiple destinations?
Right. Of course, my conception of the lines is with splines instead of
straight lines, with two control points to make passages leave from the
right corner in the right direction, one (for a one-way passage) so it
reaches the right destination, and additional ones to guide the path
around other rooms. With that sort of look, you can just have multiple
paths that leave together but bend differently to reach different
destinations. (If this doesn't make sense to you, I can generate an
example when I'm at home)
> > I think that there isn't particularly much to make the map of CC
> > technically difficult. It's mainly very extensive, which means the player
> > has to form some understanding of it, but a computer program wouldn't
> > encounter any special issues. Using software to design something like CC
> > is probably impossible, because what you really need to design something
> > of the sort is a real cave system.
> Good point. But people will still want to try, so I have to try to
> support it. For sure, if I made it auto-layout only the purists here
> would shoot it down.
Actually, I'd bet that anyone trying to do a real cave system in IF would
want to place their own rooms, simply because they have a real-world
understanding of where things are relative to each other that they want to
preserve.
> > Perhaps you ought to compare your work to CC on other factors than the
> > map. I don't think a game could have as elaborate a map as CC without
> > being as plotless, because it would be impossible to keep the player
> > involved in a plot while they were lost or exploring.
> What other factors do you have in mind? Btw, there are still
> regularly i-f ecplorathons produced (I like them).
Story, interesting mechanics and devices, and so forth. All adventure
really has going for it is the map, which it does extremely well, and the
map was found (occurring naturally) rather than designed.
(in response to a different post)
I think getting the optimal layout for a map laid out from the graph
connections probably is NP complete. But getting a reasonable
approximation is probably not that inefficient, particularly for the sorts
of graphs that actually turn up in IF. The main trick is defining a good
fitness function, and then you should be able to do "as well as a human
would" with a hill-climbing algorithm. If you give people the option of
dragging things around, after which it will go towards the local maximum,
you'll probably essentially solve the problem as well as anyone can tell.
Uli Kusterer
pl...@plugh.info (Plugh!) wrote:
> Do you have any ideas about how to represent one way passages, magic
> words and random direction passages? Please look at http://plugh.info
> and offer me some advice on my mapping.
I'd also go for an arrow at the end of one way passage lines. Or if you
want to get fancy, a little graphic of a "one way" street sign.
If you don't want to label magic words (or, if you have magnification,
if you only want to label them at a higher magnification), I'd just
display a little icon next to the line. Like a mage's pointy hat, or a
magic wand with some sparkly stars around one tip, or something like
that.
For random ones, You'd probably want to draw the line in all the
directions it can go. Maybe you could draw those lines dashed or grey as
well, which would mark nicely that they are transitive.
In general, I think road traffic signs would be a great metaphor to use
as icons next to exits to indicate e.g. blocked exits that exist in the
game but show an error message, etc.
> Granted - but a program such as mine has to be flexible enough to
> handle CC and even CC II if anyone is ambitious enough to contamplate
> it.
Don't get too caught up in the details. Remember, this is the first time
someone's gotten this far in developing a graphical IF builder of this
kind. Start small. Even if it fails the colossal cave test, it will
still be a very valuable tool.
So, what I'd suggest is: Make it work with the standard compass
directions (the eight ones). Make it also work with up/down, which could
default to NE and SW, but just end up somewhere else if those are
already taken. That way, you're making it easy for the most commonly
needed things. People who are creating an advanced map will expect to
have some manual massaging of the map.
As long as Plugh allows manually re-arranging items on the map and
allows changing for each room where the line for a particular direction
comes out, most people will be more than happy with that. You can always
revisit this for version 2.0 or so. But right now, it's much more
important to just get a version 1.0 out. Make it work, *then* make it
pretty. :-D
Cheers,
-- M. Uli Kusterer
http://www.zathras.de
Uli Kusterer
> Good point. But people will still want to try, so I have to try to
> support it. For sure, if I made it auto-layout only the purists here
> would shoot it down.
Could you keep around a flag with each exit that specifies what is to
happen? Have one for each compass direction that you can have a line
coming out from/going in, and an additional ninth direction called
"automatic".
Then when an item is moved, all automatic exits would be adjusted, while
those where the user specified an actual direction would stay the way
they were.
Just a thought,
Uli Kusterer
> I agree - in principle - but I still need to know how to represent
> oddball directions like SSW and what to do with in/out/up/down/magic
> words. So, I have something with which we can live for the time being
> and when I have prodcuded v1.0 I will revisit this topic.
I personally just try to make things look like they would in an
isometric perspective drawing. I.e. lines that go backwards out of the
box ("depth") are drawn at a 45 degree angle. I'd do something similar
with the map, just with the difference that the map is obviously seen
from the top, so "up" and "down" would go out at 45 degree angles.
> (btw - implemetation detail. Teh arrow which I am currently using can
> only attach itself to a corner or middle of a side of a box)
Pity. I was just suggesting that, to indicate "up" you could also have
the line start in the middle of the box, then going out the upper right
edge. That would look like a straight line coming out the top
> > As for magic words and random directions, I don't know.
I'd personally keep colors for the user. Let the user set colors for
markers and lines and rooms to let them label what they do. Use dashed,
dotted lines and different line thicknesses for stuff the program does.
As to where magic words and random directions should come out: I'd
probably use some rarely used directions, and of these the one in the
direction of the room it leads to. If that direction is already taken,
use the one next to it. And of course, that would only be done for
directions which aren't already taken by a better fit (e.g. the sw
corner would be given to the SE exit preferentially, and would only be
given to "down" in the case where there is no SE exit.
HTH,
Sam Denton
> In my view, up and down should lead to a new page (new level in the grid, so
> to speak) with hot-links that allow you to "travel" from one page to
> another. For example, Room 1 has a down direction that ends in a small tag
> that when clicked takes you to a new page that has the "down" room.
> Personally, I like this as it creates a layered map that is easier to
> visualize by placing detail into its proper relationship.
In DM4, "Gareth Rees persuasively advocates writing this sort of
transcript, of an ideal sequence of play, first, and worrying about
how to code up the design afterwards. Other designers prefer to build
from the bottom up, crafting the objects one at a time and finally
bringing them together into the narrative."
I've gone with Rees' idea. First, I wrote a transcript, then I wrote
a Perl script that turns transcripts into Inform source code. So,
something like this:
>n
West Wing
You are in the West Wing of the White House. You see a desk and, on
it, a red telephone.
>x large wooden desk
It has a heavy paperweight on it.
>x paperweight
It says "The buck stops here."
>x red telephone
It's red, without a dial.
>w
Rose Garden
generates something like this:
Room West_Wing "West Wing"
with
description "You are in the West Wing of the White House. You
see a desk and, on it, a red telephone.",
w_to Rose_Garden;
Prop -> large_wooden_desk_00 "large wooden desk"
with
name 'large' 'wooden' 'desk'
description "It has a paperweight on it."
Prop -> paperweight_00 "paperweight"
with
name 'paperweight'
description "It says ~The buck stops here.~"
Prop -> red_telephone_00 "red telephone"
with
name 'red' 'telephone'
description "It's red, without a dial."
Props are numbered, so multiple rooms could contain, for example,
large wooden desks. Note that anything described is assumed to be a
child of the room, so you still have a bit of fixing up to do (both
the paperweight and the telephone, in this instance). Also, note that
I assume the existance of classes named Room and Prop. Right now, I
use the script to generate a file that I then include in my main
Inform source, as both the transcript and the Perl script are still in
a bit of flux.
My next goal is to add a mapping component, which will likely spit out
gnuplot instructions to draw a crude map of just the rooms. You just
pretend that the eight "primary" links between rooms are elastic, and
figure out a layout that keeps the links at their minimal lengths.
Simple iterative physics-based modeling.
I think I can also divide a map into layers by using some coloring
algorithms. It's easy if the only connections between layers are 'up'
and 'down', but I think that by using weighted averaging, I can decide
which connections are important and which just lead to sunken living
rooms and the like.
Evin Robertson
[...]
> My next goal is to add a mapping component, which will likely spit out
> gnuplot instructions to draw a crude map of just the rooms. You just
> pretend that the eight "primary" links between rooms are elastic, and
> figure out a layout that keeps the links at their minimal lengths.
> Simple iterative physics-based modeling.
If the links are straight, then solving for an initial map with the
given directional constraints is, as I posted before, NP-complete, even
ignoring trying to minimize the lengths (which is a separate NP-complete
problem).
If the links are bendable, then you can easily get an initial map, but
trying to do the iterative moving about would seem difficult, as things
will need to hop over each other to make things better (which will often
make things look worse in the short-term). But if you have some more
detailed ideas, or pointers to references which discuss this, I'd be
very interested.
Sam Denton
> Sam Denton wrote:
> [...]
> > My next goal is to add a mapping component, which will likely spit out
> > gnuplot instructions to draw a crude map of just the rooms. You just
> > pretend that the eight "primary" links between rooms are elastic, and
> > figure out a layout that keeps the links at their minimal lengths.
> > Simple iterative physics-based modeling.
>
> If the links are straight, then solving for an initial map with the
> given directional constraints is, as I posted before, NP-complete, even
> ignoring trying to minimize the lengths (which is a separate NP-complete
> problem).
Well, I've got the map-creation part of the code semi-working, and
it's been an educational experience. First was the debugging of my
code ("Hey, why are the rooms moving away from each other with
increasing speed?"). But I was quickly able to get things stable and
start producing maps of some usefulness. The problem may or may not
be NP-complete, but that doesn't mean that we can't brute-force an
approximate solution. I'm pretending that each node has eight
connection points, each one unit away from the node's center. I give
the nodes random starting locations, and then figure out the forces
generated if the connection points are connected by perfect springs.
I then move every node an amount proportional to the force, and start
over again. Everything settles down in about a dozen iterations, and
I plot my map.
Interesting discoveries. My IF locations are two floors of a hotel
and the surrounding city. My code only considers the horizontal
directions and since the only path connecting the floors was "up" and
"down", it happily created two sub-maps which overlapped one another.
So for now, I moved the second floor to a different file. The second
problem is that from the lobby, you can move east to the street, south
to an intersection, west to a park, and north to an alley. My code
cheerfully overlaps the lobby and the alley. So I again split the
input file into interior and exterior locations. Now I'm getting
useful maps, but at the cost of managing several input files.
But, the maps *are* useful. For starters, I immediately discovered
two areas where my compass directions are messed up. (I'm modeling a
real city whose streets don't run north-south and east-west. For ease
of play, I'm rotating everything 45 degrees, but there are still
irregularities where I wasn't consistent in my conversion.)
Next, I want to recombine the input files. I think I'll add a
repulsive force between nodes proportional to their separation, so in
the example above, the lobby and the alley will push each other away
with a force of 4. While I'm figuring out separtions, I think I can
also divide things into levels, and generate multiple images.
BTW, please note that my tools aren't trying to do everything. For
example, they have no knowlege of doors. Instead, I'm trying to
automate maybe 2/3rds of the effort, and still use vi for the "hard"
parts. My maps aren't interactive, but they do show you areas that
are "messed up". And since they run off of transcript files, you
could use them to map out (or even reverse engineer) someone else's
world.
Plugh!
My first reaction is that this is an icredibly cool thing. Please
continue to develop it.
> Props are numbered, so multiple rooms could contain, for example,
> large wooden desks. Note that anything described is assumed to be a
> child of the room, so you still have a bit of fixing up to do (both
> the paperweight and the telephone, in this instance). Also, note that
> I assume the existance of classes named Room and Prop. Right now, I
> use the script to generate a file that I then include in my main
> Inform source, as both the transcript and the Perl script are still in
> a bit of flux.
Of course, you will eventually want to autogenerate everything, or at
least put complete code into one file + that needing tweaking into
another.
What heppens when the user has tweaked + then wants to update the
transcript + run your program again?
> My next goal is to add a mapping component, which will likely spit out
> gnuplot instructions to draw a crude map of just the rooms. You just
> pretend that the eight "primary" links between rooms are elastic, and
> figure out a layout that keeps the links at their minimal lengths.
> Simple iterative physics-based modeling.
I like that 'simple' :-) Just wait till someone demands more than 8
directions. Again, however, very neat.
(for what it's worth, my experience with incremental programming has
probably added at least a year to my project. If you want my advice,
at least consider the most complex imaginable case before implementing
the straightforward stuff. Otherwise, rework is innevitable).