Hello! & Automapping in HTML TADS (Long)

3 views
Skip to first unread message

Mark Hatfield

unread,
Apr 22, 2000, 3:00:00 AM4/22/00
to
Greetings,

I'm a newbie to this newsgroup so forgive me if this has alrdy come up.

Has anyone attempted or considered implementing an automapping feature in
their HTML TADS games? Better yet, a library module devoted to the task
would be great to see. I have no experience with HTML and have yet to
release my first TADS game, and it's not a job I'm willing to tackle for my
current project. Down the road however...

IMHO, automapping is functionality that is sorely needed and long overdue.
I realise there are mapping programs available that act as virtual paper on
which to map as you play. But the burden of mapping is still squarely on
the player, and this often becomes a tedious chore, which both distracts and
bores the player, as well as often infringing on the pace of play. If I'm
playing a game and am in an action scene (say I'm being chased by someone),
my natural inclination is keep moving, even though I know real-time has no
bearing. Having to map really infringes on the suspension of disbelief in
such scenes.

Player-friendliness is, or at least should be, a primary concern in any type
of game. We take great pains to make the parser as player friendly as
possible, which ultimately is a losing battle anyway due to the nature of
the beast. Even the most elaborately coded world, full of synonyms for all
the objects, descriptions of even the most mundane objects, and
implementation of a large number of actions, will STILL be easily foiled and
made to look quite stupid by a novice player. As veteran IF'ers we have
realistic expectations of the parser and are knowledgeable enough to be
gratified by small advances. But even a novice would be gratified by
automapping capability. There is no adjustment of expectation here, at
least at this point, because automapping remains an untapped resource in
text adventures. I believe I recall seeing it in a couple of commercial
releases (a later Zork?) but have yet to see it in an Inform or TADS game.

Why is that? I'm not talking about a complex graphical display, it could be
done easily enough as text. Before I stumbled on TADS I was writing a game
in QBASIC. The parser was admittedly lame compared to TADS, but it did have
an Automap feature that I had fully implemented and worked fine. When the
player gave the Map command the screen cleared and a 1-screen, full-screen
map came up, with the rooms they had visited so far visible. The output was
done completely with text and print statements, but it looked pretty good
IIDSSM. The algorithm that did the automapping was fairly simple and
straightforward:
The map subroutine went through a loop once for each location in the
game. If the location was flagged as having been seen by the player, it
called another subroutine which drew a box at the appropriate spot on the
screen for that room and printed the name of the room. The name of each
room and the screen position it should be drawn at were held in array
variables.

This sort of thing wouldn't even require HTML or any type of graphic
formats, but since those are available with HTML TADS it seems a natural
progression to employ them in an automapping module. Forget illustrations -
I can visualize my surroundings in my head. If you want to do something
graphically snazzy and _useful_ at the same time, give me automapping!

OK, I digress now. Anyone have any thoughts on this?

Mark.H...@axom.com

Evin Robertson

unread,
Apr 23, 2000, 3:00:00 AM4/23/00
to
In article <39025071$0$26036@unknown>,
"Mark Hatfield" <Mark.H...@axom.com> wrote:
[snip]

> Why is that? I'm not talking about a complex graphical display, it
> could be done easily enough as text. Before I stumbled on TADS I
> was writing a game in QBASIC. The parser was admittedly lame
> compared to TADS, but it did have an Automap feature that I had
> fully implemented and worked fine. When the player gave the Map
> command the screen cleared and a 1-screen, full-screen map came up,
> with the rooms they had visited so far visible. The output was done
> completely with text and print statements, but it looked pretty good
> IIDSSM. The algorithm that did the automapping was fairly simple
> and straightforward:
> The map subroutine went through a loop once for each
> location in the game. If the location was flagged as having been
> seen by the player, it called another subroutine which drew a box at
> the appropriate spot on the screen for that room and printed the
> name of the room. The name of each room and the screen position it
> should be drawn at were held in array variables.

Nitfol, my Z-machine interpreter, has the ability to automap most
Infocom and Inform games. It uses a lot of trickery and a little help
from the user. But it messes up a lot.

Calculating the 'appropriate spot' is the hard part. In most IF
games, the distance between adjacent rooms is not always the same.
For simple geographies (up to the complexity of the map of
_Enchanter_), nitfol works great, but even only moderately complex
worlds (_AnchorHead_, for example) currently confuse it, to say
nothing of the strangeness found in _Zork 1_.

Nitfol currently just outputs a text map on a side of the screen, with
your position indicated on it. Lacking a good intuitive sense of
directions and locations of places, I find it very useful even though
it doesn't always work quite right.

Supposedly calculating the best (values of best include smallest and
fewest overlapping paths) picture for a graph takes exponential time,
which is bad, even if you only have thirty rooms. So we have to come
up with ways to make good guesses.


Sent via Deja.com http://www.deja.com/
Before you buy.

Kevin Forchione

unread,
Apr 23, 2000, 3:00:00 AM4/23/00
to
"Mark Hatfield" <Mark.H...@axom.com> wrote in message
news:39025071$0$26036@unknown...

> The map subroutine went through a loop once for each location in
the
> game. If the location was flagged as having been seen by the player, it
> called another subroutine which drew a box at the appropriate spot on the
> screen for that room and printed the name of the room. The name of each
> room and the screen position it should be drawn at were held in array
> variables.
>
> This sort of thing wouldn't even require HTML or any type of
graphic
> formats, but since those are available with HTML TADS it seems a natural
> progression to employ them in an automapping module. Forget
illustrations -
> I can visualize my surroundings in my head. If you want to do something
> graphically snazzy and _useful_ at the same time, give me automapping!

It's easy enough to loop through every room and darkroom and determine if
they've been seen or not. The preinit() function could be used to create a
table of room names and screen positions, but there are some problems I can
foresee with this:

a. TADS doesn't display based on screen position, it uses text streams.
b. Some algorithm for converting the relativity of north, south, east,
west, etc, into xy-coordinates would have to be devised.
c. Some rooms may exit with a twist, or have greater distances between
their exits than others. In order to draw a neat map even the "virtual
paper" approach requires shuffling rooms around. In fact, these are the same
problems faced by the "virtual paper" map developers, such as the author of
Guemap, etc.

It poses an interesting problem (as computer programmers like to say.)

--Kevin

Sneed the Sort of Crazy

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to
> OK, I digress now. Anyone have any thoughts on this?

Yeah. Too bad you don't use Hugo. I, Cardinal T, wrote library routines for
this fully two years ago, which are freely available at gmd.de. If you would
care to see them in action (since they can be tricky to code into a game
until you know what you're doing), drop me a line at jn...@pacbell.net.
Otherwise, go download them and have a look-see. Well, go download them and
have a look-see anyway :)

Following is an excerpt from AUTOMAP.DOC, which accompanies the automap
header file, to give you an idea of what they do and how they work.

<begin excerpt>

WHAT THEY ARE:

Map() and FullMap() are both routines that implement on-screen mapping for
games written with Hugo v2.3. Map() is a routine that draws a small,
localized map centered around a specified location, usually in the upper
right corner of the screen and in reverse video. FullMap(), on the other
hand, draws a full-screen map radiating from a specified location, which
location is always positioned at center-screen. FullMap's scope includes
every game location that is connected to the central one and will fit
on the screen, and it is drawn in normal video rather than reverse.

HOW THEY WORK:

Both Map() and FullMap() work by reading the return values of the "dir_to"
properties of room objects. In the case of Map(), a single iteration is
performed outward from the central room of the map, revealing the position
and exits of its immediate (visited) neighbors. In the case of FullMap(),
a branching algorithm is employed which iterates outward through every
connected location. When a location is reached that has more than one exit,
the first one is chosen and that branch is followed. This process is
repeated
until the end of a branch is reached, at which point the routine backs up
one
room and tries any other existing exits, following them in turn to their
ends.
(A loop barrier is employed to prevent maps with circular paths from putting
the routine into an infinite loop.) This continues on until the routine has
backed up to the original central location and has no more paths left to
follow, at which point it returns to the routine that called it.

HOW TO USE THEM:

The Map() routine takes two arguments, although one of these should not be
supplied directly by the programmer. The first argument (called "from" in
the
code) indicates the location the map should center around. Typically, this
will be the player's current location, and when this is the case no argument
need be supplied, as the player's location is assumed by default. The
second argument (called "full" in the code) is a switch that tells Map()
whether it should display the map in full-screen mode or not. In full-screen
mode, the screen is cleared of all existing text before the draw begins, so
that the player is left with only a map and the normal command prompt at the
end. Consequently, this mode is not appropriate for "real-time" mapping of
the kind seen in games like Beyond Zork, and for this reason, unless the
programmer has some specific need to employ full-screen mode with Map(),
the second argument should be omitted and ignored completely.

FullMap() takes only one argument, the location to be mapped from. Since
FullMap() is not a stand-alone routine, but rather engages Map() to do its
heavy lifting, it takes care of calling Map() with the "full" parameter set
to true automatically.

In essence, then, both Map() and FullMap() are called in one of the
following
two ways:

Map() FullMap()
or
Map(some_location) FullMap(some_location)

When called without an argument, both routines will assume that the location
to be mapped from is the player's current location. Otherwise, they will map
from the location specified in the call. Note that any attempt to map from
an object that is not a location (i.e. not an object of type "room") will
result in the player's current location being substituted instead. Moreover,
any attempt to map from an unvisited or dark room will result in the map
being refused. In this latter case, nothing will be drawn and an error
message ("You wish") will be issued to the player.

IS THERE ANYTHING SPECIAL I NEED TO KNOW ABOUT THEM?

Well, funny you should ask. Since both Map() and FullMap() function by
reading the "dir_to" properties of rooms, it will no longer be possible to
put printable text into those properties. This is because "reading the
return values" involves actually running the property routines.
Consequently,
every time those properties are read (which in the mapping routines is quite
often), all the code within them will execute and any text output you've
included there will display to (weird areas of) the screen. To deal with
this problem, a PreParse routine is supplied along with the mappers that
allows the programmer to code movement conditions, printable text, and so
on in a location's "before" property instead. Here's how a typical movement
condition might be coded now:

room white_house "White House"
{
...
before { location DoGo { if object = n_obj
{
if hillary in self
{
"The sight of Hillary and her shotgun
changes your mind."
}
else
return false
}
}
}
n_to { return north_lawn }
}

In this example, if the hillary object is in the white house, any attempt to
move north is met with the message about the shotgun. Otherwise, the before
routine is returned from with false, which causes the engine to check for a
n_to property routine. Finding one, it executes the move to the north lawn.
In general, this is the method one should always use when employing the
mappers (indeed, a case can be made that this is the method that should be
used always and everywhere--but that's an argument for a different time and
place).

<end excerpt>


Blah blah blah etcetera etcetera. If you want to read more, go download the
thing from gmd.de in the Hugo/library/contributions directory. Note that
there are many other valuable and helpful files there as well, such as
routines for making random maps (again, think of those areas in Beyond Zork
which had different room arrangements every game--that's what this does,
painlessly and easily, behind the scenes) and other neat things.

--Sneed the Sort of Crazy
or Cardinal T, for you oldtimers

Sneed the Sort of Crazy

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to
Actually, the thing is three years old and doesn't appear to work with the
current manifestation of Hugo, so I've updated it. Until it's moved, you can
find the new and improved AUTOMAP.H in (where else?) the incoming/if-archive
directory.

Sneed the Sort of Crazy

unread,
Apr 25, 2000, 3:00:00 AM4/25/00
to

"Kevin Forchione" <Lys...@email.msn.com> wrote in message
news:#HtAXyRr$GA.90@cpmsnbbsa04...

> It's easy enough to loop through every room and darkroom and determine if
> they've been seen or not. The preinit() function could be used to create a
> table of room names and screen positions, but there are some problems I
can
> foresee with this:
>
> a. TADS doesn't display based on screen position, it uses text
streams.
> b. Some algorithm for converting the relativity of north, south, east,
> west, etc, into xy-coordinates would have to be devised.
> c. Some rooms may exit with a twist, or have greater distances between
> their exits than others. In order to draw a neat map even the "virtual
> paper" approach requires shuffling rooms around. In fact, these are the
same
> problems faced by the "virtual paper" map developers, such as the author
of
> Guemap, etc.
>
> It poses an interesting problem (as computer programmers like to say.)

Point (a) above is a real showstopper for you TADS folks, imo. I don't see
how you can draw a map when there's no way to "draw" at all. However,
leaving that aside, there's a general problem regarding automapping that
applies to all systems, which is alluded to in points (b) and (c) above: to
wit, there's just no feasible way to code in advance for every possible
geographical effect that might be desired by a game author. Since room
location *relationships*, which are all i-f cares about, are not the same as
actual, physical, x-y coordinates, there's no coordinate system that could
ever possibly work--at least there's none that would work in every case. In
my automapper routines, which I've mentioned in another post, I endeavored
to create a system that would hold good for every case, which basically
required that I put the onus on the game author to follow certain rules of
procedure when designing his game. In theory, this doesn't create a problem,
since room *relationships* are always faithfully reported by the mapper.
However, it remains to be seen whether players will moan about the lack of
"realistic" distances between rooms and whatnot--in my routines, all rooms
are visually the exact same distance apart. No one seems to have been
bothered by this in Beyond Zork, however, and my system mimics Infocom's for
the most part, so I'm fairly optomistic that it represents a viable
solution--perhaps the only viable solution.

--Sneed the Sort of Crazy

aka Cardinal Teulbachs

Roger Carbol

unread,
Apr 25, 2000, 3:00:00 AM4/25/00
to
"Sneed the Sort of Crazy" <gos...@someone.else> wrote:

>> a. TADS doesn't display based on screen position, it uses text
>streams.

>Point (a) above is a real showstopper for you TADS folks, imo.


Note that HTML TADS supports HTML Tables, which can fairly easily
be pressed into service as a screen positioning tool. I wouldn't be
surprised if mapping was accomplished by the use of <TABLE>.


.. Roger Carbol .. rca...@home.com


Reply all
Reply to author
Forward
0 new messages