New mapping tools
Fredrik Ramsberg
This is my understanding of the current situation in mapping tools:
* Quite a few people are interested in using them.
* Surprisingly, considering the way the IF community works in general,
there are no good, freeware mapping tools available.
* There are no mapping tools that work on many platforms.
* There is no common map format.
* There are no interpreters with built-in mapping support, neither auto-
mapping nor manual mapping.
I think interpreters with built-in mapping support would be of great value
on PDA:s in particular. I have my doubts about the value of auto-mapping,
but manual mapping support would be nice. The only PDA I use myself is
Palm, and I know task switching is a big hassle there. If a mapping
program is to be useful, it must be integrated with the interpreter.
Another main reason why PDA:s would be the most important platform is the
way they are used for playing IF -- often in locations where it's
impossible or very incovenient to draw a map on paper, or at times when
the possibility to play IF was unexpected, and the player has no means of
aquiring paper and/or a pen.
So, I would suggest a common map format to start with. I'd say make it
text based -- Easier to debug, and people who don't have the necessary
software may still be able to use the map file to some extent. Here's a
first suggestion:
@BEGIN
$Map of Zork Plus: The Underexploited Overgrounds {Sets the map title}
%10;10 {Sets the map size}
#1 {Start of location 1}
$West of House {Name of location}
+Mailbox
++Leaflet | May be a coded message, not sure. {This object has a description}
+Dagger
%5;5 {Map coordinated of location 1}
>SE:2,NE:3 {Exits and which locations they lead to}
&,5.7;5.9|5.9;5.7 {Says that the second exit should pass through these points
#2
$South of House
+Sword | Is this needed to kill the giant?
%6;4
>NW:1
#3
$North of House
>SW:1,D:4|SSE-N|1|Dangerous, you can't get out!
{Down -> #4, draw it as exiting at SSE and entering the destination at N,
with a one way arrow, and associate a comment with the exit.}
#4
$Deep Pit
%6;5
@END
Opinions?
/Fredrik
atholbrose
news:ab01df60.02030...@posting.google.com:
> Hi crowd,
> This is my understanding of the current situation in mapping tools:
[...]
> * Surprisingly, considering the way the IF community works in general,
> there are no good, freeware mapping tools available.
> * There are no mapping tools that work on many platforms.
Well, there's IFM and its tcl-based editing shell.
> * There is no common map format.
True, I suppose.
> * There are no interpreters with built-in mapping support, neither
> auto-mapping nor manual mapping.
Nitfol is a glk-based zcode interpreter that supports automatic mapping,
based on the "location" variable in the game. It takes a little sleuthing
to use, because you never really know which zcode variable is the location
at first. Pretty easy to use, but the maps can get a bit ... bizarre, I
guess is what I'm looking for. Still, it handles expanding bits of the map
to fit in geography quite well -- better than IFM.
> So, I would suggest a common map format to start with. I'd say make it
> text based -- Easier to debug, and people who don't have the necessary
> software may still be able to use the map file to some extent. Here's
> a first suggestion:
[map text deleted]
> Opinions?
To risk sounding like a broken record -- have you looked at the IFM map
format? Not much more complicated than the script you provided but MUCH
easier to read -- and write, I'd suppose -- for humans.
I'm not sure about your main thrust here, though -- mapping on PDAs. As
much as I like playing IF on my Palm, there's just not enough screen real-
estate to show a map as well as the game, which means at least a button
press to flip between map and game. Plus, taking time to write out the map
commands with a stylus, especially with all that punctuation... if I were
using a Palm mapping app, I'd expect to just tap to create a room and drag
lines between them, Graffiti with the cursor in a room to change the room
text, scroll around with the keys, flip to seperate sections with a drop-
down and so on.
Plugh!
Personally, I would like to see an interpreter with automapping and
have considered implementing one, but am snowed under by another
project.
Now, to your proposal
- I like plain Ascii, but some people are going to suggest XML. It may
be more difficult to parse, but it is a very valid suggestion.
- what about multiple maps? E.g, separate maps of the cellars & Crypt
below the monastery, the ground floor, the grounds and the attic. I
think that's how many i-f authors draw them, each on a its own piece
of paper. How would your notation show the map number of each location
and how would it show links to other maps?
- what about dynamically created passages? E.g in colossal cave, there
is is no crystal bridge until you wave the wand.
- what about locations connected only by a magic word?
- could you show an example of a nested room, please?
- hmm, do you want to show the directions as leading to location
numbers, or lcoation names? It probably doesn't make too much
difference, but names would be easier to read. Numbers are acceptable
if the map is only ever considered statically. Names might be better
to reflect a dynamically changing map, especially if you extend the
format to include NCPs & items. But even if only for rooms then, for
instance for vehicles, I'd rather see the car's (which is also a
location) location as a room name than an index.
Ooops. I have to run to a meeting - more later.
I hope that you get some good contributions and that something comes
of this.
Matthew Russotto
Fredrik Ramsberg <f...@mail.com> wrote:
>Hi crowd,
>
>This is my understanding of the current situation in mapping tools:
>
> mapping nor manual mapping.
Nitfol has automapping.
I use a spreadsheet for heavy manual mapping. Maps that are simple
enough to draw as lines and boxes I usually don't need.
--
Matthew T. Russotto mrus...@speakeasy.net
=====
Dmitry is free, but the DMCA survives. DMCA delenda est!
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
Kodrik
simple adventure but not for complex ones:
* Rooms can switch during game but to the player, it is just a change in
environment.
* Rooms are scaled differently for the player but remain the same for the
engine.
* Objects that you focus on can be rooms, eventhough you go to another room
for the engine, you go nowhere when it comes to the player.
* A passage can go one place at one time, then another at another time,
meanwhile the player thinks he goes to the same place all the time.
* complex 3d maps can be extremelly hard to render and be visibly pleasing
or useful.
* A room that seems one square away might be on the other side of the world
for the engine.
There are many more little problems. IF is a lot about illusion, the player
creates the world by his writing as much as with the structure of the data,
so you can't make an accurate map based only on the structure of the data.
The best way to have a good auto-mapping feature would be for the author to
define the map as he is creating the adventure, but how many author will go
through this extra work for this feature? I am curious about an answer.
The problem is not technical at all, it is practical.
Ferlin Scarborough
"Kodrik" <kod...@zc8.net> wrote in message
news:u8i3e6q...@corp.supernews.com...
>
> The best way to have a good auto-mapping feature would be for the author
to
> define the map as he is creating the adventure, but how many author will
go
> through this extra work for this feature? I am curious about an answer.
>
> The problem is not technical at all, it is practical.
>
author defines the map as he goes along, and can drag rooms around and draw
passages between locations. I kind of liked those features my self.
Later.
Ferlin.
Kodrik
> author defines the map as he goes along, and can drag rooms around and
> draw
> passages between locations. I kind of liked those features my self.
Making a map for the author to create his world is no problem. I think that
Plugh's interface to TADs will create it also.
But that is because the map of the author is different than the map to the
players because the author is aware of the tricks he used for this game.
The problem is having an auto-map for the players generated automatically
without additional information entered by the author.
JJKC
The only PDA I use myself is
> Palm, and I know task switching is a big hassle there. If a mapping
> program is to be useful, it must be integrated with the interpreter.
>
FWIW, I have a hack that lets you switch back and forth between two apps
with one swipe of the stylus. If anyone is interested, let me know and
I'll scrounge around until I find out where I got it...
-Jim
Derek F.
to
> define the map as he is creating the adventure, but how many author will
go
> through this extra work for this feature? I am curious about an answer.
I've done it. Last weekend I wrote up a simple automapper for my Glulx
game-in-progress. It was built using GWindow's GDrawImageGrid library,
which allows me to define a map as a series of grids. By default I use a
5x5 grid-space, although it can be zoomed out to 10x10 or 20x20 (although
this has yet to be implemented).
Because the maps are author-definable, I have full control over things like
distance and scale, as a "room" can be drawn to occupy as many grids as I
want (eg. a closet will use one square grid while a gladiator arena might
take up four or six). Further, the automapper -- or "cartographer" -- can
erase certain rooms, redraw passages or even reconfigure the entire map as
new or revised data becomes available to the player. This way, optical
effect or illusions (eg. shifting corridors) can be maintained so long as
the player isn't "aware" of them.
I'm also planning to include map notes either within or near some of the
location grids, such as listing pertinent objects or noting, say, curious
sounds. I'm still working out the details (read: making it up as I go), but
I'd like to give the cartographer a bit of a personality in the notes he
takes. There's certainly room here for nudging the player forward and, most
definatly, amusing him.
I've got a screenshot of the automapper (along with my unfinished GUI) at
www.plover.net/~dfeddon/heraldry/sshot.htm
Derek
Kodrik
> www.plover.net/~dfeddon/heraldry/sshot.htm
The picture link is broken.
Someone else did something with Hugo also.
This discussion has been very interesting and opened new horizons for me:
Each room is associated to 2 coordinate systems, one set of coordinates for
the engine itself (4 coordinates in the case of my engine) and one set of
coordinates for the map (3 coordnates).
Dimensions (and even shapes) can be associated to each rooms for the
map.
The author could also specify what type of passage there are for the map to
represent them by the correct icon on the map (door, stairs...). He can
aslo specify conditions for the passages being closed or open.
Then all the author has to do is:
* associate each one of his room with map coordinates x, y, z
Optional:
* associate each one of his room with dimensions (w, l , h)
* associate each one of his room with a shape type
* associate each shape types with icon
* accossiate each one of his passages with a passage type
* associate each passages type with an icon
* associate each passages with conditions for being closed or open
Now, what is really cool, is that using the data from the map, we could
create NPC movement.
Like you suggested, we could also create a sytem for users to write notes
for each map room (a map room is different than an engine room and it can
regroup multiple engine room).
That is really interesting. I think I'm still a couple months away at the
very minimum before starting to incorporate something like that in my
engine but I hope you will be able to complete your mapping programs for
existing engines. I think there is a lot of potential with it.
I would be very interested in anyone doing this regardless of the engine
and I would help the best I can.
Derek F.
> > I've got a screenshot of the automapper (along with my unfinished GUI)
at
> > www.plover.net/~dfeddon/heraldry/sshot.htm
>
> The picture link is broken.
Oops. It should work now. (Thanks Kodrik!)
> The author could also specify what type of passage there are for the map
to
> represent them by the correct icon on the map (door, stairs...). He can
> aslo specify conditions for the passages being closed or open.
So would your engine provide preset icons? More importantly, would you
allow the use of icons created by the author?
I'm somewhat of a customization phreak -- I've supplied a different
background for each of my five (thus far) maps, and have gone so far as
reskinning the entire GUI when the player enters a new story section
(granite and limestone skin for the underground crypt, wisps of ivy and
foliage for the outside section). I suppose some would consider this
overkill.
> Like you suggested, we could also create a sytem for users to write notes
> for each map room (a map room is different than an engine room and it can
> regroup multiple engine room).
Right now only the cartographer (automapper) inserts notes automatically on
the map. I plan on allowing player-customizable notes as well which can be
accessed by clicking on a grid. However these notes would be listed not on
the map itself but instead in a popup text window. (I haven't investigated
this yet, does anyone know if this possible with Glulx I/O?)
> That is really interesting. I think I'm still a couple months away at the
> very minimum before starting to incorporate something like that in my
> engine but I hope you will be able to complete your mapping programs for
> existing engines. I think there is a lot of potential with it.
I agree. Automapping is sorely lacking in IF. (GWindows also provides for
graphical inventory display, which I think further enhances play.) While
mulling over a particular puzzle or deciding where next to go, I like the
idea of being able to see *all* of the tools at my disposal (inventory and
location relative to the map) without having to recall these things from
memory, most notably during the early stages of play. Recollection of
resources becomes easier once you achieve immersion, but this takes some
time, and I'm sure it poses a roadblock for many players -- especially new
ones. So I don't think such graphical displays are necessarily a crutch;
rather, I think they free the player, and allow him or her to focus on
plot, character and puzzle-solving -- the fiction -- without having to type
"i" everytime you forget what's in the blasted backpack.
>
> I would be very interested in anyone doing this regardless of the engine
> and I would help the best I can.
>
As would I. An automapper can be as simple or complex as the author
wishes -- or the game calls for. There's a lot of room for discussion on
this, how best to represent certain situations. Plus I think they look
really nice.
Derek F.
Kodrik
> allow the use of icons created by the author?
Actually, no, not at first.
It's already a huge work to code a stable fucntional engine, it is another
enormous task to create librairies for it and it might take years to get to
par for existing engines on that aspect.
I am trying to set-up a system to let authors create objects, images,
keys.. and have the option to publish them so other authors can use them.
I used this system for the engine's dictionary. Authors can create words
and their sysnonym as well as suggest words and synonyms for the engine to
use and make available to everyone. This is how the engine's dictionary has
been developing.
As for the icon, authors who double as designers will be the pioneers and
once they create their icons for their games and if they publish the ions
publicly, any other authors can use them.
I have to specify that this engine server based and all data of all
adventures are centrally stored, so making something publicly available is
just clicking a button.
> Right now only the cartographer (automapper) inserts notes automatically
> on the map. I plan on allowing player-customizable notes as well which
> can be accessed by clicking on a grid. However these notes would be
> listed not on
> the map itself but instead in a popup text window. (I haven't
> investigated this yet, does anyone know if this possible with Glulx I/O?)
I agree, if it's not, pop-up it's no big deal as long as you can return to
your gam window without wasting a turn.
> I agree. Automapping is sorely lacking in IF. (GWindows also provides
> for graphical inventory display, which I think further enhances play.)
> While mulling over a particular puzzle or deciding where next to go,
> like the
> idea of being able to see *all* of the tools at my disposal (inventory and
> location relative to the map) without having to recall these things from
> memory, most notably during the early stages of play. Recollection of
> resources becomes easier once you achieve immersion, but this takes some
> time, and I'm sure it poses a roadblock for many players -- especially new
> ones. So I don't think such graphical displays are necessarily a crutch;
> rather, I think they free the player, and allow him or her to focus on
> plot, character and puzzle-solving -- the fiction -- without having to
> type "i" everytime you forget what's in the blasted backpack.]
I foudn that interface very good, maybe not for veteran IF player but
certainly for people new to IF.
We are goign to have to experiment with different layouts for our products
and find a good balance so the information is there but is not too crowded.
Another challenge will be to please the veteran IF players andthe newcomers
who have completelly different standards.
> As would I. An automapper can be as simple or complex as the author
> wishes -- or the game calls for. There's a lot of room for discussion on
> this, how best to represent certain situations. Plus I think they look
> really nice.
Especially if they can help with other features for the game such as even
better NPC AI.
Derek F.
> I foudn that interface very good, maybe not for veteran IF player but
> certainly for people new to IF.
> We are goign to have to experiment with different layouts for our products
> and find a good balance so the information is there but is not too
crowded.
> Another challenge will be to please the veteran IF players andthe
newcomers
> who have completelly different standards.
For those who detest the graphical UI, they need only to type "mode text"
and <poof!> the game will continue in full ASCII glory. Right now the game
can play in either full graphics or text-only mode, but I'll probably supply
a few more options, such as turning off various graphical features, moving
the player input back into the main window, a window providing a textual
list of inventory, etc.
Derek
Plugh!
> define the map as he is creating the adventure,
some property which is not accessible be the player, but which the
interpreter can ... urm, interpret. But only optionally, of course.
Not every interpreter may wish to auto-map.
> but how many author will go
> through this extra work for this feature? I am curious about an answer.
Well, obviously, I have a vested interest in this. So, I would suggest
the easiest way would be to use a tool which automagically generates
the map and the TADS/Inform/etc source code. This would be easy
enough to add to something like http://plugh.cjb.net Mwuhhahahaha!!
> The problem is not technical at all, it is practical.
and, thus, easilly solvable :-)
Plugh!
> SUDS is on authoring system that I recently played around with that the
> author defines the map as he goes along, and can drag rooms around and draw
> passages between locations. I kind of liked those features my self.
A pity that the author has recently announced to this newfroup that he
can/will no longer support SUDS and is looking for someone else to
maintain it.
Plugh!
>
> Making a map for the author to create his world is no problem. I think that
> Plugh's interface to TADs will create it also.
> But that is because the map of the author is different than the map to the
> players because the author is aware of the tricks he used for this game.
post.
> The problem is having an auto-map for the players generated automatically
> without additional information entered by the author.
Yes, this is very hairy - it gets complicated when we get to the
"leave to the north, but don't return by the south" scenario. That's
why it's better that the author define the map (it also gets round
magic words, but we are left with the quandary of how to represent the
Swiss Cheese Room).
Ideally I would like the player to be able to drag the rooms of the
map around as pleases him, but I suppose that this requires what I
just rejected - the interpreter choosing where to place the rooms on
the map.
I'd also like the use to be able to add comments to the map as he goes
along, thus negating the use for endless A4 pads and saving trees,
whales, ozones, etc.
Plugh!
> I've done it. Last weekend I wrote up a simple automapper for my Glulx
> game-in-progress.
This is *excellent*, Derek (a pity that you didn't use HTML TADS,
though ;-)
Can you make it generic, such that other authors can #include it in
their own i-f? This would be a highly desirable project.
Plugh!
coverted here. A lot of "me too" but little practical discussion of a
generic map data format.
OK, the discussion so far implies interpreter specific implementation
and/or perhaps addition of map details by some external tool. What
about usage other than auto-mapping by the interpreter during play? I
can imagine a tool to extract maps from i-f, statically, without
playing the game (though I wouldn't like to implement it). Any other
ideas? By imagining possible usage, we can better define the data
format.
Hey, Kodirk, do you think that Amissville will use auto-mapping ?
Kodrik
> about usage other than auto-mapping by the interpreter during play? I
> can imagine a tool to extract maps from i-f, statically, without
> playing the game (though I wouldn't like to implement it). Any other
> ideas? By imagining possible usage, we can better define the data
> format.
I think I've mentionned in my post (or is it in a private email) the
possibility to use the map to design new NPC ai movemement.
There is indeed more features we can add if we have a "play map"
CardinalT
>> The problem is having an auto-map for the players generated automatically
>> without additional information entered by the author.
> Yes, this is very hairy - it gets complicated when we get to the
> "leave to the north, but don't return by the south" scenario. That's
> why it's better that the author define the map (it also gets round
> magic words, but we are left with the quandary of how to represent the
> Swiss Cheese Room).
There is no way to represent the Swiss Cheese Room. That's why the idea of
a dependable interpreter side mapper is a pipe dream. Unless you can get
authors to stick to the necessary rules when laying out their games,
there's no way you can ever anticipate how you're going to need to draw
something in order to make a reasonable representation of it (the key word
here being "reasonable." An IF system I had in the early '80's called the
Computer Novel Construction Kit had a nice mapping feature included in it.
Problem was, if you had screwy room arrangements, you'd end up with rooms
printed all over the place, to the point where you couldn't even interpret
them anymore. This wasn't so much a shortcoming of the mapper as it was the
nature of the beast).
Moreover, I can't see how in the world you're going to have a universal
mapper that doesn't require extra effort on the part of the author. Either
you read the existing code in its native format--which means your
interpreter has to be specifically programmed to understand Inform code,
TADS code, Hugo code, and all the rest, or you make the author include
special code in the universal format your mapper understands, which is
extra work for him.
Incidentally, I wrote a fairly robust mapping library about five years ago
for Hugo, and it's been sitting at gmd for all that time basically being
ignored. It comprises an automapper, which is very much like the map in
Beyond Zork--it draws your current location and any immediately connected
locations you've visited--and a fullscreen mapper, which draws, from the
center of the screen and centered on your current location, a complete map
of every location you've visited in the game (well, as complete as your
screen size will allow, anyway). The mappers support the eight cardinal
directions, as well as up, down, in, out, and rooms that connect to
themselves. They *do not* support cross connections (the automapper does,
but the fullscreen mapper doesn't), nor "strange" connections--those cases
where A connects to B but B connects back to something other than A, or A
connects to B south, but B connects back to A northeast. (This is all
onscreen stuff, btw, available at any time via the command line, so no
printing is required.)
If you want to read about it, go download automap.zip from
/if-archive/programming/hugo/library/contributions and read automap.doc. It
gives a pretty detailed account of both mappers. If you want to see it in
action, I can email you the necessary files. Just let me know what OS
you're using.
--
--CardinalT
Archbishop of Frith and Funeral Barker to the Stars
Derek F.
"Plugh!" <pl...@subdimension.com> wrote in message
news:98ef019f.02030...@posting.google.com...
> "Derek F." <dfe...@yahoo.com> wrote in message
news:<a6bvpl$d8bvj$1...@ID-124731.news.dfncis.de>...
> > I've done it. Last weekend I wrote up a simple automapper for my Glulx
> > game-in-progress.
>
> their own i-f? This would be a highly desirable project.
Well, at present it's far too crude and rather sloppily hard-coded into my
game. Further, it's not very complex from a design standpoint, as every
icon (representing location grids *and* their corresponding connectors) must
be drawn by hand (eg. in Photoshop). Glulx can draw on its own -- and would
probably be the preferred method of mapping -- but mine is conveniently
built on top of GWindows GDrawImageGrid which takes hand-drawn images
directly from a Blorb resource file.
My code is based on the inv_obj set out in the GWindows manual and the
Balances demo. Dummy locations are added to the map_object and displayed
via the image routine like so:
Object galal_copse "Shady Copse"
class map_obj,
with image [ x y x2 y2 x3 y3 grid_image owl_image;
x=1;
y=3;
my_x=x;
my_y=y;
x2=1;
y2=2;
x3=2;
y3=2;
if (location == Copse)
grid_image=map_galal_copse_on;
else
grid_image=map_galal_copse;
if (owl in good_branch)
owl_image=map_galal_copse_owl;
else owl_image=map_galal_copse_owlx;
DrawGrid(grid_image,x,y); ! draw the grid
DrawGrid(map_ns_1,x2,y2); ! draw the north-south connector
DrawGrid(owl_image,x3,y3); ! note the presence of the owl
];
[ DrawGrid grid_image x y;
gwin_image_draw (mapper.winid, grid_image,
(x+map_x)*mapper.columnwidth,
(y+map_y)*mapper.rowheight,
mapper.columnwidth, mapper.rowheight);
];
GWindows does all of the work, really. I simply specify what images to use.
As you can see *my* code is sloppy, and I'm certain there are a few
extraneous variables in there which the gurus could pick apart.
Hopefully, though, I'll refine the code as I go, and if it becomes "generic"
enough then I'll certainly add it to the archive.
Derek
Fredrik Ramsberg
> - I like plain Ascii, but some people are going to suggest XML. It may
> be more difficult to parse, but it is a very valid suggestion.
It is valid, yes. I just think the IF community generally strives to cut
unnecessary weight. XML would put a lot of extra weight into a map file.
Parsing is actually often simpler using XML, since there are XML parsers
readily available as components.
> - what about multiple maps? E.g, separate maps of the cellars & Crypt
> below the monastery, the ground floor, the grounds and the attic. I
> think that's how many i-f authors draw them, each on a its own piece
> of paper. How would your notation show the map number of each location
> and how would it show links to other maps?
Good point. There should be support for multiple maps. The map file could
start with a section describing the various maps, with titles and dimensions.
> - what about dynamically created passages? E.g in colossal cave, there
> is is no crystal bridge until you wave the wand.
In my original post, there's a one-way passage shown with a one-way arrow.
The one-way arrow would just be one of many different connection types
you could use to symbolize different types of connections. And you could
associate comments with both rooms and connections.
> - what about locations connected only by a magic word?
I personally tend to use a dotted line for all connections that are not
perfectly straight-forward. Whether there's an obstacle in the way, or
you need some magic word to use the passage, you just put a comment
on the connection.
> - could you show an example of a nested room, please?
It would be considered as a normal room, only the connection would get the
word "IN/OUT" on it, and possibly a comment. Not a problem, I think.
> - hmm, do you want to show the directions as leading to location
> numbers, or lcoation names? It probably doesn't make too much
> difference, but names would be easier to read. Numbers are acceptable
> if the map is only ever considered statically. Names might be better
> to reflect a dynamically changing map, especially if you extend the
> format to include NCPs & items. But even if only for rooms then, for
> instance for vehicles, I'd rather see the car's (which is also a
> location) location as a room name than an index.
I don't think the map format would need to specify how the map should be
displayed. I personally prefer maps with room numbers and a list of
rooms on the side, but the map viewer/editor could switch between these
modes at the click of a button.
> Ooops. I have to run to a meeting - more later.
Hope you made it to the meeting! ;)
> I hope that you get some good contributions and that something comes
> of this.
Plenty people seem interested in discussing it. Most of them seem to think
automapping is the only right way to go though. I'm still not convinced
about this. I think mapping is usually an enjoyable activity, which makes
me feel I'm progressing, even if I'm just covering more territory without
solving problems.
I'm not saying automapping is wrong, but I don't think it's the only
option worth discussing.
/Fredrik
Plugh!
> > be more difficult to parse, but it is a very valid suggestion.
>
> It is valid, yes. I just think the IF community generally strives to cut
> unnecessary weight. XML would put a lot of extra weight into a map file.
XML parsers feeely avilable. The question then is only whether we want
the file to be human readable, or only ever accessed by other
sowftware.
> Good point. There should be support for multiple maps. The map file could
> start with a section describing the various maps, with titles and dimensions.
"Dimensions" - this is new. Until now you only proposed describing
room names & connecting passages. Now we are discussing specifying how
to display the rooms. Do we want to open this can of worms?
Should we make such tags preferances only, but overridable if the
displaying s/w 'knows better'? Should we also allow specification of
graphics to represent rooms, whether as file names or simple enums
representing graphic types? Should we allow a specified preferred font
or text colo(u)r for displaying the room name?
> > - what about dynamically created passages? E.g in colossal cave, there
> > is is no crystal bridge until you wave the wand.
>
> In my original post, there's a one-way passage shown with a one-way arrow.
> The one-way arrow would just be one of many different connection types
> you could use to symbolize different types of connections. And you could
> associate comments with both rooms and connections.
Sounds good.
Hmmm, just to clarify. If there are multiple connections between a
pair of rooms, do we specify all? I suppose that some mapping tools
mihgt want to show all and some to show just one.
> > - what about locations connected only by a magic word?
>
> I personally tend to use a dotted line for all connections that are not
> perfectly straight-forward. Whether there's an obstacle in the way, or
> you need some magic word to use the passage, you just put a comment
> on the connection.
Or should we attempt to define possible types of non-standard
connection (magic word, uni-dirctional, random, run-time generated)?
Should be ok, so long as we allow "other".
> > - could you show an example of a nested room, please?
>
> It would be considered as a normal room, only the connection would get the
> word "IN/OUT" on it, and possibly a comment. Not a problem, I think.
No, I guess you're right. Now I am confusing how to represent them in
this specification language and how to display them on the screen (if,
say , there are a group of 3 or 4 smaller rooms within one room, the
mapper author has the choice of connecting them with in/out, or
drawing them within the other room, with connecting passages, or as a
separate map).
> > - hmm, do you want to show the directions as leading to location
> > numbers, or lcoation names? It probably doesn't make too much
> > difference, but names would be easier to read. Numbers are acceptable
> > if the map is only ever considered statically. Names might be better
> > to reflect a dynamically changing map, especially if you extend the
> > format to include NCPs & items. But even if only for rooms then, for
> > instance for vehicles, I'd rather see the car's (which is also a
> > location) location as a room name than an index.
>
> I don't think the map format would need to specify how the map should be
> displayed.
I agree, but we might have contradicted that above. Maybe we can allow
the specification language to "suggest", with the understanding that
its sugegstions are overridable.
> I personally prefer maps with room numbers and a list of
> rooms on the side, but the map viewer/editor could switch between these
> modes at the click of a button.
Sorry, I can't quite visualize that.
> Plenty people seem interested in discussing it. Most of them seem to think
> automapping is the only right way to go though. I'm still not convinced
> about this.
Me neither. It is "a Good Thing", but not the only possible use.
Hmmm, I might just knock up a cut down version of my proggie which
would be a sort of player's notepad, letting him add rooms, items,
comments, etc as he plays. The interpreter could either be run
seperatly or in a window of the tool. If I do it, this one will be in
Java for portability.
> I think mapping is usually an enjoyable activity, which makes
> me feel I'm progressing, even if I'm just covering more territory without
> solving problems.
True. Of course, it might be nice to have a tool to let you draw the
map as you go, add those problems as you encounter them, remove them
when you solve them, etc.
> I'm not saying automapping is wrong, but I don't think it's the only
> option worth discussing.
Agreed. So, how does your spec look now? Just the raw data
reqeuirements, we can discuss later whether to use XML or not.
Kodrik
>> start with a section describing the various maps, with titles and
>> dimensions.
> "Dimensions" - this is new. Until now you only proposed describing
> room names & connecting passages. Now we are discussing specifying how
> to display the rooms. Do we want to open this can of worms?
A fifth dimension? Yes, I agree it is a good idea for the mapping.
> Should we make such tags preferances only, but overridable if the
> displaying s/w 'knows better'? Should we also allow specification of
> graphics to represent rooms, whether as file names or simple enums
> representing graphic types? Should we allow a specified preferred font
> or text colo(u)r for displaying the room name?
As options yes -> Icon, color, font...
> Hmmm, just to clarify. If there are multiple connections between a
> pair of rooms, do we specify all? I suppose that some mapping tools
> mihgt want to show all and some to show just one.
The map has location, and the connections should be made to the locations.
Different rooms can be in the same location, meaning one connection on the
player map.
All connections to locations that the player is aware of should be shown,
>> It would be considered as a normal room, only the connection would get
>> the word "IN/OUT" on it, and possibly a comment. Not a problem, I think.
> No, I guess you're right. Now I am confusing how to represent them in
> this specification language and how to display them on the screen (if,
> say , there are a group of 3 or 4 smaller rooms within one room, the
> mapper author has the choice of connecting them with in/out, or
> drawing them within the other room, with connecting passages, or as a
> separate map).
Wy are we showing nested rooms? They are in the same location and sometimes
are used to focus on an object.
I don't want a telephone or a fridge or a box as a room in my map. I see
them as object in a room even if the engine sees them as nested rooms to
handle them right.
Plugh!
> > "Dimensions" - this is new. Until now you only proposed describing
> > room names & connecting passages. Now we are discussing specifying how
> > to display the rooms. Do we want to open this can of worms?
>
> A fifth dimension? Yes, I agree it is a good idea for the mapping.
erm, I thought that he was meaning "dimensions" like height & width. I
thought that that was not specifying the map so much, as specifying
how it should be represented on the screen.
> > Hmmm, just to clarify. If there are multiple connections between a
> > pair of rooms, do we specify all? I suppose that some mapping tools
> > mihgt want to show all and some to show just one.
>
> The map has location, and the connections should be made to the locations.
> Different rooms can be in the same location, meaning one connection on the
> player map.
"Different rooms can be in the same location" I'm afraid that I don't
agree with this. Are you perhaps describing a room whose name will
change during the course of the game?
> All connections to locations that the player is aware of should be shown,
So, we could have somthing like this on the screen?
---------- in out ----------
| |<-------------->| |
| Room 1 | n s | Room 2 |
| |<-------------->| |
| | up ssw | |
| |<-------------->| |
---------- -----------
That looks messy to me, but I suppose it could be aconfigurable
option.
> Wy are we showing nested rooms? They are in the same location and sometimes
> are used to focus on an object.
Well, we might also be showing NPCs, items, treasures, puzzles, etc on
the map. So, we might want to how the cupboard as well as the library.
Also, there might be a mini-map of several rooms within another room.
I would be strongly against not showing nested rooms.
> I don't want a telephone or a fridge or a box as a room in my map. I see
> them as object in a room even if the engine sees them as nested rooms to
> handle them right.
Ah, I see. What about vehicles? In any case, it would probably be
better to include them in the definition of the map and let the user
optionally choose to notdisplay them. Then we would both be happy :-)
Plugh!
> pl...@subdimension.com (Plugh!) wrote in message news:<98ef019f.02030...@posting.google.com>...
> > - I like plain Ascii, but some people are going to suggest XML. It may
> > be more difficult to parse, but it is a very valid suggestion.
>
> It is valid, yes. I just think the IF community generally strives to cut
> unnecessary weight. XML would put a lot of extra weight into a map file.
When I first begn developing my Magnum opus, I wanted to use a binary
file format for the save file, which would only be read or written by
programs. Then some users persauded me to make it ascii so that they
could make quick changes to typos without firing up the program (which
is eactly what I wanted to avoid by making it a binary format "just a
little change which won't affect anything else").
Anyhoo, I finally settled on the Windows .ini file format. I know
that there is freely avilable C source code to access such file types,
so we could also use it on Un*x and Macs. That would give us
something like:
[status]
current_room=tuxedo junction
current_map=highway 61
[maps]
1_name=teenage wasteland
2_name=suffragette city
3=miles out to sea
4=rivers of baylon
[rooms]
1_name=singabus
1_map=teenage wasteland
1_out=deep in your room
2_name=deep in your room
2_map=teenage wasteland
2_in=singabus
[npcs]
1_name=obi man
1_location=singabus
2_name=pantaloon duck
2_location=singabus
[items]
1=acid gold bar
1_location=singabus
2=message in a bottle
2_location ... well, you get the picture
it's not pretty, but it's human readable & editable, if need be and
there's plenty of software out there to read & write it.
Plugh!
would be the startRoom at compile time, but could be updated
dynamically and reflected in any save file.
Kodrik
> thought that that was not specifying the map so much, as specifying
> how it should be represented on the screen.
I misunderstood you. I sought you were talking about different maps within
a large map. So on top of the location coordinate, you would have a map id.
You are in the house, the map house square size is 10ft.x10ft.
You go outside, you go to the outside map whose squares are 1000ftx1000ft.
For me, the fifth dimension was the map to which the room belongs and
inherints the square (cube) dimensions.
I don't think room dimensions are that important because they have to be to
scale with the rooms next to it.
If you have 10x10 rooms surrounding a room, that room cannot be 100x100. or
the rest of the map doesn't make sense. Rooms larger than a unit of a map
would have to encompass more than one room.
So the map needs a square size associated to it and if we use room size and
shapes, it needs to be within that value.
I think a shape icon would be more helpful, it would give an idea of the
size and exits (like in a hexagone). The exact size is not needed to draw
the map, just the number of map square unit (which I guess is the
dimension, so I am wrong), the associated icon and the coordinates.
> Well, we might also be showing NPCs, items, treasures, puzzles, etc on
> the map. So, we might want to how the cupboard as well as the library.
Yes, but these would be object inside a room, not another room that appears
on the map as a room.
> Also, there might be a mini-map of several rooms within another room.
This I think should be handled with a seperate map, to distinguish between
nested-rooms/objects which are not rooms to the user and nested-room/rooms.
I guess the author will have to specify an extra variable to the room to
tell if its a room or an object for the player's map. The engine sure can't
tell because it's the descripition that makes a difference.
> I would be strongly against not showing nested rooms.
In the case of nested-rooms/rooms I agree.
> Ah, I see. What about vehicles? In any case, it would probably be
> better to include them in the definition of the map and let the user
> optionally choose to notdisplay them. Then we would both be happy :-)
I would make such room/object sub-maps, using the 5h dimension. This way
you can easily show the point of entrance and exits to the car-map
dimension. Or you could go to the car map to easily check all the
directions.
Different dimensions|map|nested-rooms/room could have their own entrance
color or symbol for the maps for easy navigation.
Fredrik Ramsberg
> > Good point. There should be support for multiple maps. The map file could
> > start with a section describing the various maps, with titles and dimensions.
> "Dimensions" - this is new. Until now you only proposed describing
> room names & connecting passages. Now we are discussing specifying how
> to display the rooms. Do we want to open this can of worms?
I meant map size. It would be possible to skip it entirely, but defining
the map sizes at the start of the file may be convenient for programs
that want to read the map files.
> Should we make such tags preferances only, but overridable if the
> displaying s/w 'knows better'? Should we also allow specification of
> graphics to represent rooms, whether as file names or simple enums
> representing graphic types? Should we allow a specified preferred font
> or text colo(u)r for displaying the room name?
None of the above. The idea is not to have the fanciest maps imaginable,
just functional, portable and lightweight maps.
> Hmmm, just to clarify. If there are multiple connections between a
> pair of rooms, do we specify all? I suppose that some mapping tools
> mihgt want to show all and some to show just one.
The person who draws the maps chooses which connections to draw. If it's
an automapping program, I guess it's the person who writes the game.
> > > - what about locations connected only by a magic word?
> >
> > I personally tend to use a dotted line for all connections that are not
> > perfectly straight-forward. Whether there's an obstacle in the way, or
> > you need some magic word to use the passage, you just put a comment
> > on the connection.
> Or should we attempt to define possible types of non-standard
> connection (magic word, uni-dirctional, random, run-time generated)?
> Should be ok, so long as we allow "other".
We may be heading for complications. We'll probably find new connection
types we'd like to include as new games are released. Anyway, I don't
think double-dotted curly line is more clear than a dotted line with the
words "Say XYZZY" written above it.
> > > - could you show an example of a nested room, please?
> >
> > It would be considered as a normal room, only the connection would get the
> > word "IN/OUT" on it, and possibly a comment. Not a problem, I think.
> No, I guess you're right. Now I am confusing how to represent them in
> this specification language and how to display them on the screen (if,
> say , there are a group of 3 or 4 smaller rooms within one room, the
> mapper author has the choice of connecting them with in/out, or
> drawing them within the other room, with connecting passages, or as a
> separate map).
I don't believe in drawing them inside another room. That makes it
difficult for the map viewer to decide how to print text inside a
room and being certain that it will all be visible.
> > > - hmm, do you want to show the directions as leading to location
> > > numbers, or lcoation names? It probably doesn't make too much
> > > difference, but names would be easier to read. Numbers are acceptable
> > > if the map is only ever considered statically. Names might be better
> > > to reflect a dynamically changing map, especially if you extend the
> > > format to include NCPs & items. But even if only for rooms then, for
> > > instance for vehicles, I'd rather see the car's (which is also a
> > > location) location as a room name than an index.
> >
> > I don't think the map format would need to specify how the map should be
> > displayed.
> I agree, but we might have contradicted that above. Maybe we can allow
> the specification language to "suggest", with the understanding that
> its sugegstions are overridable.
There could be data in the file which may safely be ignored. There may even
be data that only one mapping program understands, but which is marked in
such a way that other programs can tell right away that they won't understand
it. Don't know if it's a good idea though.
> > I personally prefer maps with room numbers and a list of
> > rooms on the side, but the map viewer/editor could switch between these
> > modes at the click of a button.
> Sorry, I can't quite visualize that.
___ ___
| | | |
| 2 |-----| 1 |
|___| |___|
1. West of House(mailbox(leaflet))
2. Forest(Troll,Sword)
I think this kind of map makes it easier to get an overview over a large
area, and you can have more text for each room. The formar really
shouldn't care though -- it's up to the user how to display the map
in the map viewer.
> > Plenty people seem interested in discussing it. Most of them seem to think
> > automapping is the only right way to go though. I'm still not convinced
> > about this.
> Me neither. It is "a Good Thing", but not the only possible use.
> Hmmm, I might just knock up a cut down version of my proggie which
> would be a sort of player's notepad, letting him add rooms, items,
> comments, etc as he plays. The interpreter could either be run
> seperatly or in a window of the tool. If I do it, this one will be in
> Java for portability.
Sounds nice. Hope you get around to it.
> > I think mapping is usually an enjoyable activity, which makes
> > me feel I'm progressing, even if I'm just covering more territory without
> > solving problems.
> True. Of course, it might be nice to have a tool to let you draw the
> map as you go, add those problems as you encounter them, remove them
> when you solve them, etc.
Well, probably not remove them, but give them status "solved" perhaps,
somehow marking them as such on the screen.
> > I'm not saying automapping is wrong, but I don't think it's the only
> > option worth discussing.
> Agreed. So, how does your spec look now? Just the raw data
> reqeuirements, we can discuss later whether to use XML or not.
I haven't updated it yet. Let's see if this discussion produces any more
additions or changed first.
/Fredrik
Plugh!
> > Should we make such tags preferances only, but overridable if the
> > displaying s/w 'knows better'? Should we also allow specification of
> > graphics to represent rooms, whether as file names or simple enums
> > representing graphic types? Should we allow a specified preferred font
> > or text colo(u)r for displaying the room name?
>
> None of the above. The idea is not to have the fanciest maps imaginable,
> just functional, portable and lightweight maps.
Hmm, I've always been a fan of throwing in as much information as
possible and letting the 'user' choose what and how to interpret
(where the use is generally a program).
What we get back to here is whether humans will ever read/write this
info, or only programs.
Persoanlly, I'd go for a front end program which lets you store an
incredible amount of data, rather than a plaintext editor (for
instance, this front end proggie could let you draw the map, connect
rooms, place NCPs, indicate objects, puzzles, etc -(my own program at
http://plugh.cjb.net could be easilly altered to do this)). Cram in as
much as you can about the game design and the back end programs can
each choose which subset of the data is important to them.
Of course, you may disagree, so let's try to nail that one down.
> > Hmmm, just to clarify. If there are multiple connections between a
> > pair of rooms, do we specify all? I suppose that some mapping tools
> > mihgt want to show all and some to show just one.
>
> The person who draws the maps chooses which connections to draw. If it's
> an automapping program, I guess it's the person who writes the game.
That seems like a contradiction to me: I read "The person who draws
the maps" as the automapper, rather than the author. What I am driving
at is including as much info as possible (so, 3 connections between
the same 2 rooms) and letting the automapper decide to draw only one
line, to avoid clutter.
> > Or should we attempt to define possible types of non-standard
> > connection (magic word, uni-dirctional, random, run-time generated)?
> > Should be ok, so long as we allow "other".
>
> We may be heading for complications. We'll probably find new connection
> types we'd like to include as new games are released. Anyway, I don't
> think double-dotted curly line is more clear than a dotted line with the
> words "Say XYZZY" written above it.
True, but if the map drawing program lets the user drag rooms around,
the text will ahve to follow the arrow, which is not so easy.
> > > > - could you show an example of a nested room, please?
> I don't believe in drawing them inside another room. That makes it
> difficult for the map viewer to decide how to print text inside a
> room and being certain that it will all be visible.
Me neither, it was just an example of how different back end tools may
choose to represent the data in different ways.
> > > I don't think the map format would need to specify how the map should be
> > > displayed.
> > I agree, but we might have contradicted that above. Maybe we can allow
> > the specification language to "suggest", with the understanding that
> > its sugegstions are overridable.
>
> There could be data in the file which may safely be ignored. There may even
> be data that only one mapping program understands, but which is marked in
> such a way that other programs can tell right away that they won't understand
> it. Don't know if it's a good idea though.
This is pretty standard stuff in telecomms software, if a message
contains a field which the recipient can't/doesn't want to interpret,
it can be skipped (if optional, some 'information elements' are
mandatory) and the rest of the message processed. A similar concept of
tagged data exists in JPEG & most other graphic and, I believe, music
file formats. Hmmm, if you ever standardize this, don't forget to
notify http://www.wotsit.org/
> > > I personally prefer maps with room numbers and a list of
> > > rooms on the side, but the map viewer/editor could switch between these
> > > modes at the click of a button.
> > Sorry, I can't quite visualize that.
>
> ___ ___
> | | | |
> | 2 |-----| 1 |
> |___| |___|
>
> 1. West of House(mailbox(leaflet))
> 2. Forest(Troll,Sword)
Ah, now I see. Personally, I'd rather see the room names in the boxes,
but this might mean splitting the map into several sub-maps to let if
all fit on screen. Still we could always have a tool-tip or right
click option to show room info.
> I think this kind of map makes it easier to get an overview over a large
> area, and you can have more text for each room.
true.
> The formar really
> shouldn't care though -- it's up to the user how to display the map
> in the map viewer.
also true.
> > > Plenty people seem interested in discussing it. Most of them seem to think
> > > automapping is the only right way to go though. I'm still not convinced
> > > about this.
> > Me neither. It is "a Good Thing", but not the only possible use.
> > Hmmm, I might just knock up a cut down version of my proggie which
> > would be a sort of player's notepad, letting him add rooms, items,
> > comments, etc as he plays. The interpreter could either be run
> > seperatly or in a window of the tool. If I do it, this one will be in
> > Java for portability.
>
> Sounds nice. Hope you get around to it.
Well, it's very tempting to drop what I'm doing, which is nearing
beta, but at a tough stage & start on something new. I could do this
on the side, though. Would you prefer a "player's notepad" or an
"author's map drawer"?
> > > I think mapping is usually an enjoyable activity, which makes
> > > me feel I'm progressing, even if I'm just covering more territory without
> > > solving problems.
> > True. Of course, it might be nice to have a tool to let you draw the
> > map as you go, add those problems as you encounter them, remove them
> > when you solve them, etc.
>
> Well, probably not remove them, but give them status "solved" perhaps,
> somehow marking them as such on the screen.
Yes. I was thinking of making little notes ("locked door. look for
key") then removing or updating those as appropriate ("not locked.
Hinges need oiling. Find oil").
> > Agreed. So, how does your spec look now? Just the raw data
> > reqeuirements, we can discuss later whether to use XML or not.
>
> I haven't updated it yet. Let's see if this discussion produces any more
> additions or changed first.
Ok, though we are rather running out of steam.
> /Fredrik
I used to use /Plugh before I graduated to ~Plugh(); this came from
some mainframe or another twenty odd years ago, where the logoff
command was a slash followed by your user name.
~Plugh();
Jason Etheridge
>Hmmm, if you ever standardize this, don't forget to
>notify http://www.wotsit.org/
I thought it kind of funny that there's no IF stuff on
that site. Looks useful though.
L. Ron Hubbard
file format look like?
Plugh!
still working on it, or can we add this one to the "good ideas that
people wandered in to raif & proposed, then walked out again leaving
them to die the death" pile?
Fredrik Ramsberg
When you're on the web, you don't know what is happening to people outside
the screen, in the real world. That's one of the reasons why it's usually
not a good idea to tell people what to do and when.
There was a death in my family a few days ago. I'll be back in a while.
Best regards,
/Fredrik
Plugh!
I'm truly sorry to hear that, Frederick. I certainly didn't, your
bereavement aside, intend to tell you what to do and when; bereavement
aside, as you said, we all have lives outside of this group, so
delivery times can be fluid and no one here "owes" anyone anything.
I had an unfortunate incident last year when I was visiting home and a
close family member died. As de facto head of the family I had to stay
an extra week and organize the funeral. Unfortunately, my elderly
family had no internet access and I couldn't check my mail, leading to
some negative feedback on eBay and some increasingly nasty e-mails.
But you don't want to hear my parttling. As I said, I didn't intend to
sound like I was demanding that you do something. If you want, I would
be happy to summarize what's already been posted here for you. In the
meantime, you have my sympathy.
Plugh
> Best regards,
>
> /Fredrik
Adam Thornton
>> the screen, in the real world. That's one of the reasons why it's usually
>> not a good idea to tell people what to do and when.
>> There was a death in my family a few days ago. I'll be back in a while.
>I'm truly sorry to hear that, Frederick. I certainly didn't, your
>bereavement aside, intend to tell you what to do and when; bereavement
>aside, as you said, we all have lives outside of this group, so
>delivery times can be fluid and no one here "owes" anyone anything.
What he said, and also:
It didn't sound to me like Plugh was demanding anything.
If he'd been demanding something it would have been more like:
Write me a spraypaint can, sucka piss grit fruitcake yourself fuck!
Which it wasn't.
Adam
Fredrik Ramsberg
> As I said, I didn't intend to
> sound like I was demanding that you do something. If you want, I would
> be happy to summarize what's already been posted here for you. In the
> meantime, you have my sympathy.
I can see now that you didn't necessarily mean to demand anything from
me, but I thought you did when I first read your post. No hard feelings.
I've read the thread and intend to get back with a proper reply soon.
TTYL8R,
Fredrik
Plugh!
> pl...@subdimension.com (Plugh!) wrote in message news:<98ef019f.02032...@posting.google.com>...
> > As I said, I didn't intend to
> > sound like I was demanding that you do something. If you want, I would
> > be happy to summarize what's already been posted here for you. In the
> > meantime, you have my sympathy.
>
> I can see now that you didn't necessarily mean to demand anything from
> me, but I thought you did when I first read your post. No hard feelings.
Thanks, Frederick. I'm the sort of shrinking violet who doesn't like
to upset people in any case, but thiking taht I had done so at a time
of bereavement, I was very upset with myself all day yesterday. You
have made me feel better now and I really appreaciate it.
> I've read the thread and intend to get back with a proper reply soon.
Take your time. I'll look forward to your post. I think that a
standard map definition could be a major contribution.
>
> TTYL8R,
>
> Fredrik