[Tads] Library features
Val Artlett
that, don't read it.
Over the past few years while almost everyone else has been working their
brainchild games, I've been, like a secret government agency, toying in R&D
with the default "adv.t" TADS library to see what improvements could be
made. After spending years learning Tads 2.x I was more or less suddenly
confronted by the changes made by Tads 3.x. A few days ago I decided to make
the switch and it should take me a couple of months, if not years, to get a
familiar grasp over what looks on the surface to be a completely rewritten
engine and library.
My experience with Tads 3.x is admittedly in its extreme infantile stages at
the moment so I won't presume anything about the new system.
I just wanted to share some of the mini-projects I've been working on. Not
the actual source code but the general progress I made, how I did it, why I
did it, and the problems I encountered. This may be insightful reading for
other library authors, especially those which like me are making their
forays into the expanded realm of Tads 3.x.
Tads mini-projects:
1. List disambiguator and unique objects with same vocabulary
I wanted to have several unique objects with the exact same vocabulary, yet
not indistinguishable. This is normally a taboo in a system that relies on
prose to disambiguate objects. One example of an instance where this would
be useful is if there were 3 pick-axes in a game all with the same
vocabulary and yet each being unique in that they would have variable
degrees of wear and tear on them. Giving them unique vocabulary properties
such as "a little bit worn out pick-axe" or "brand new pick-axe" would seem
quite forced. What I did was in these cases replace the prosy version with a
list version. The list version (picking items from a list by typing a
number) simply allowed me to pick an object based on some properties it
might have, such as its location, condition, or value, without those
properties having to be part of the name.
2. Extended visibility
I wanted the player to be able to see objects in other rooms, and look into
other rooms without travelling to them. To reduce the processing
requirements I created a permanent viewables list instead of requiring that
it be rebuilt every time a command was entered. This permanent list would
only be rebuilt when the player did something or moved something that would
change the visibility of some objects, and only those parts of the list that
needed to be rebuilt would be rebuilt, not the entire list. It was more
complicated than that in practice, but that was the gist of it. This
extended visibility also took into consideration the nature of exits insofar
as the exits could be either opaque or transparent.
3. All rooms have walls, ceilings, and a floor
This problem has been addressed in the past in a publically available module
by Kevin Forchione that dynamically creates and destroys such objects. My
understanding of this module is that the objects are created on a very tight
budget: they're created only when the player does something to them and
destroyed very soon afterwards. I wanted my approach to feel more real to
the player and just be more consistent so I experimented with a wider
tolerance: creating the objects during preinit, or creating them upon the
player entering a room for the first time. I wanted all these objects to
have unique properties and histories. The player should be able to write on
walls, smash down walls, or examine walls for trap doors and clues. Having
just one such special wall in a story presents the dilemma that now all
walls in that story then need to be examinable. I tried saving memory by
creating and destroying the objects dynamically and assigning any historical
properties to them during this dynamic creation process. I had a lot of
success with all of these techniques, but the main problem remained: I could
only have 200 objects in the entire game with the same vocabulary property
"wall" so any successes were bittersweet. The ultimate goal for a TADS
library should be to have all of these objects generated on startup or
compilation, and to exist as discrete, unique objects throughout the run.
4. Directions as objects
Every direction became an object, a direction object to be precise. The
player could type "north" as a verb, or "go north" using north as an object
noun. Additionally, the player could also type "look north", or "throw rope
north", or "face north" This was one of those little grammatical
improvements which should have been around all along. To move or slide an
object in a direction, a custom set of verbs was no longer required because
the construct became "move object to the north", north being the indirect
object noun.
5. Every body part of a player or NPC is represented
(Same as #3 above)
This is just one of those things which should be in a library, and can be in
a library. It allows for commands such as "slap Mary on her cheek" or "put
hand in hole" or "put bracelet on ankle"
6. Conversation trees
After much thought I concluded that the "ask about" method was no way to
tell a character-driven story. There is a publically available module for
this which I borrowed from heavily, as the module is of very good quality,
and I added a few utility functions and automatic behavior of my own. In
terms of automatic behavior, almost every conversation has "hello" and
"goodbye" etiquette choices which can be handled automatically. And most
choices should not be repeated during the same conversation so they can be
removed upon being used. I made some small utility functions which allowed
me to switch off or on an array of choices.
7. All objects dropped in a room should appear be on its floor, not floating
in space
I made a few cosmetic changes and a few deeper changes to force objects
dropped in a room to appear to be on its floor and to be listed as "On the
floor you see..." The objects were still technically in the room, not its
floor, but to the player it would seem as if they were. Ideally, every room
would have its own discrete, permanent floor object which would have its own
history.
8. Piles of objects
I extended the functionality of the indistinguishable items code to allow
the player to separate a pile of indentical items into piles on a table or
appropriate surface. Upon picking up the items in his hands, they would
again fuse into a single pile of items. The piles could be taken discreetly
and placed into separate containers. Trying to disambiguate between these
piles using prose would be an ambiguous nightmare (which pile do you want:
the big pile, the smaller pile, or the really tiny pile?), so I decided to
bring my informative list disambiguator into play and simply tell the player
exactly how many units were in each pile.
9. Blob-jects
I never actually implemented these, but I hypothesized an amorphous object
could be divided by the player into an infinite number of daughter objects.
This would be most useful for water, powders, or any substance. The player
would separate these blobs using volume measurements such as "pour 12 ml of
water into the tube" at which time the blob would spawn another dynamic
object much as the same as an amoeba does when it divides. A garbage
collector would sweep up any spills or messes once the player had left the
room.
10. Basic inventory realism
When holding a great number of objects in his hands if a player tries to
grab a new one, or tries to perform certain tasks, objects should randomly
fall out of his hands onto the floor.
11. Volume check on openable containers
There are some types of containers such as boxes which have a certain
maximum volume when open and a different one when closed. When a box or bag
is overstuffed it should be impossible to close the lid of the container. In
addition a command such as "clean up the box" could sort objects, pulling
them together more tightly and decreasing their overall volume.
12. Sound transmission
If the layout of rooms were somehow placed on a grid, the transmission of a
noise could be computed. The player would be able to hear (through prose)
explosions or other noises coming from other rooms to the degree that those
noises could transfer through various media and over space. I never even
started on the code for this.
13. Automapping
I experimented with a variety of techniques for creating attractive automaps
in TADS adventures. Sometimes the maps were represented with full-graphics
squares and lines, and sometimes a more generic text-oriented approach was
tried. The graphics end was easy to implement, but infinitely more difficult
was generating the grid layout and various levels simply from reading a
series of exit properties. I was never able to create such a grid
dynamically because I was leery of the necessary slicing and dicing of
lists, and always opted to type out the layout in advance. My automaps were
2 dimensional and represented various levels and altitudes as separate
pages.
14. Asking the parser questions
The player should be able to ask the parser "Where did I leave my shoes?",
"Where is Catherine?", "How can I get help for this game?", or "How many
points do I have?" Normally the parser expects either a command or an answer
to a question it asked. It should also be able to answer a reasonable query.
I never made any progress with this, as it is probably something best
handled on a deeper level by a more seasoned author. Being able to ask a
character a question, such as "Catherine, where did you leave the cart?"
would be an extra plus. The presence of a question mark (?) or the words
"who/what/when/where/why" would signal the parser to adopt a different
grammatical awareness.
I plan to try to add as many of these features as possible to the Tads 3
default library as I had already done to Tads 2 in the past, and hopefully
release that as a sort of expanded version (after being given the requisite
permission to do so). But don't hold your breath. I'm a perfectionist, so
until something I made is really perfect I usually don't show it to anyone.
Val Artlett
hide it well enough to bring anyone any peace. I used to go by the handle
Mercury. Yes, the <insert your preferred label here> Mercury. I haven't been
posting here under any other names in the past or present, other than Val
Artlett. Trying to turn me into a legend by associating me with other
historical or present trolls is flattering and fun, but inaccurate. Anyway,
I haven't come to spread any more of my trolling evilness and psychiatric
problems; I've just come under the hope some other TADS library designers
would be intrigued by what I managed to achieve last year. If someone
doesn't stupidly encourage me by saying something nice in reply to this,
this should be the last you'll hear from me for a while. But, like any great
villain, I'll always be back for the profitable sequels.
Plugh!
visibility might be covered in TADS 3. Possibly also 12. Sound
transmission, but I'm not 100% sure about that. It is the direction in
which Mike is moving, though. I thnk that he will make quite a few add
ons obsolete.
I am particularrly interested in 13. Automapping. Can you please tell
more? Do you have a URL where we can see an example? What are you
actually doing? I had thought of taking the source code of the TADS
Widnows Interpreter and tweaking the movememnt commands to auto-draw
the map. What did you do?
I would like to see more discussion in general on the topic of
libraies & add-ons.
Btw, do you have a good set of debug commands, for the author to use
when testing?
-----------------------------------------------------------------------------
Plugh! New web page http://www.plugh.info - beta test coming RSN (real
soon, now)
Val Artlett
>
> I am particularrly interested in 13. Automapping. Can you please tell
> more? Do you have a URL where we can see an example? What are you
> actually doing? I had thought of taking the source code of the TADS
> Widnows Interpreter and tweaking the movememnt commands to auto-draw
> the map. What did you do?
Because I had no experience coding in C or any other language but TADS I
opted to use features that were already included with multimedia TADS 2.x.
So what I suggest here can be done right away by anyone with minimal
programming knowledge and the results can be run on any multimedia TADS
platform. It looks professional if you prepare good looking map elements in
PNG format. The only problem is getting over the cheapness of it.
You start with predefined map data contained in your source code. The map is
made up of a collection of lists. At some point or other you might want to
autogenerate this data in preinit, but I never had the expertise to do that
and it makes no difference to the player.
Use a monospaced font to see this:
map: object
y1=[nil nil foyer nil nil]
y2=[nil 'diag2' 'doorvert' 'diag1' nil]
y3=[study nil hallway nil library]
y=[y1,y2,y3]
u1=[nil nil nil nil nil]
u2=[nil nil nil nil nil]
u3=[nil nil nil nil nil]
u=[u1,u2,u3]
;
Every room has to know its grid position. You could do this in preinit or by
hand, depending on your expertise.
foyer: room
grid=[1,3]
;
There are two maps defined here. Y is the absolute map and U is is the user
map, or what the player has already seen. Writing anything to the user map
causes it to appear on the automap the player sees, as the automap drawing
code only looks at the user map data. This is what makes the mapper fast: it
just draws what it finds in the user lists, and does no other processing.
The string values refer to the names of the image files you want to use to
represent the various joiners or links between the rooms. So you have to
prepare a variety of these joiners in PNG format such as "diag2.png" and
"doorvert.png" They all have to be exactly the same height and width.
To draw the map on screen, the map code uses a FOR loop to whiz through the
Ux lists. Inside each list, it uses another FOR loop to whiz through each
item in that list. When encountering various values, it does various things
to draw the elements using an HTML TABLE tag. One of the great things about
HTML tables is they contract automatically around empty fields. Each time
you encounter a nil make a <td>; each time you encounter a new list make a
<tr>; each time you encounter a string use that string in an IMG tag like
this <img src=<<map.u2[pos]>>.png border=0>; each time you encounter a room
object, first put <td width=200 height=50> or whatever width and height
matches your graphics and taste and then print in the name of the room. The
room name will not wrap at this point so if you want it to wrap to a small
square you need to give each room a special map string to use like
'li-\nbrary', or you might want to try cutting the string right then and
there if you have that expertise. To make the room field look like a box
give it a special background color. You can use different background colors
for different rooms; I recommend a different back color for the room the
player is currently in. This is a cheap trick but it works and looks good.
When the map is finished the HTML will not display a big white space for
unexplored areas but nothing at all as the nil fields take up no space. This
makes the map look dynamic, growing up and out as the player explores more
ground. Of course you should use a border=0 table.
To update the user map as the player moves around, you add in some code in
the enterRoom method to write in the name of the room in the appropriate
part of the user list. To add the joiner, modify the navigation code in
adv.t so it writes in the proper joiner name into the user map.
To make the map look super professional, the map HTML drawing code can add
in special images to draw attractive lines to form boxes. You start with an
image which will be the top of the square, complete with two top corners and
a horizonal line. To form the bulk of the square, you start with a vertical
line, then print the room name within a separate html field of specified
width, then put in another vertical line whose width would be around 3
pixels. Then put in the bottom of the square with another image that has two
bottom corners. The corners can be rounded, making the finished product look
very professional; although it is a big headache to set all this up.
Multimedia TADS has a very robust high performance HTML drawing engine that
makes the average browser look like a dinosaur. It draws all this stuff
instantaneously. I even tried it with a huge map and it was still as fast as
you please. Being a user-interface freak I would normally balk at using this
kind of approach but TADS pulls it off so smoothly it manages to make it
look hard coded.
There are so many other features you could add to this basic foundation. I
know from experience the foundation I have laid out here is a good one and
robust, and accomodates many more features such as multiple pages and
levels, adding notes to the maps, letting the user click a room to travel
there, etc. Just use your imagination. The average player just needs to get
their bearings once in a while as text adventures tend to be naggingly
difficult to navigate. The average player does not need a 3D map, although
if someone wanted to write one I certainly would not complain. Remember the
key here is to make Tads look better than Inform, so pull all the stops
(that was a joke).
>
> Btw, do you have a good set of debug commands, for the author to use
> when testing?
>
The Workshop debugger is so good I never found a need to make any debugging
commands except for a few new verbs.
Plugh!
solution of using HTML TADS. You approach sounds traightforward, but
still powerful. Can you post a URL of a screenshot of your automap in
action?
Does it only handle regular grid strucures (sounds very like it)? What
do you do with rooms with more than 8 exits? Could it handle Colossal
Cave (always the true test of an such tool, I tend to think).
> Remember the key here is to make Tads look better than Inform, so pull all
> the stops(that was a joke).
It shouldn't have been :-)
> The Workshop debugger is so good I never found a need to make any debugging
> commands except for a few new verbs.
I agree about the debugger. But, what are those magic verbs?
Val Artlett
> solution of using HTML TADS. You approach sounds traightforward, but
> still powerful. Can you post a URL of a screenshot of your automap in
> action?
No, because I threw it all away. You will just have to trust me when I say I
did succeed in doing it, and it looked sexy. Try it yourself. It does not
take long. I used Paint Shop Pro to make the line graphics.
>
> Does it only handle regular grid strucures (sounds very like it)? What
Yes only standard structures. Given as TADS only allows you to work with 8
compass point directions, I see no problem with it. If you had a game whose
layout was finalized, you could add any amount of customized graphics,
exits, drawings, etc. to the finished map. Remember, the map is just made of
an HTML table. Within that table you can do anything with squares of
graphics such as putting together larger images. Many websites provide ample
examples of how to do that.
I was working on a system that would work with any game. If you just wanted
to make your game look good you could for sketch out a large map by hand
with plenty of shaded graphics, scan it in, and then expose one part of it
at a time for the player. It would look completely hand-drawn at all times,
although it would have a blocky appearance if you failed to create some
blurring between the rooms. Try the multimedia Gold Skull demo to see how
far you can take multimedia TADS.
> do you do with rooms with more than 8 exits? Could it handle Colossal
> Cave (always the true test of an such tool, I tend to think).
There are parts of Colossal Cave that have no consistent exits, so in those
parts of the map you would have to put question marks instead of connecting
lines (and no other mapper would be able to do better than that). As for the
rest of its map, yes it would work. I mean, like I said this map works with
the 8 compass points, and so do virtually all TADS adventures. TADS is no
respecter of distances so that makes it work.
>
>
> > The Workshop debugger is so good I never found a need to make any
debugging
> > commands except for a few new verbs.
> I agree about the debugger. But, what are those magic verbs?
They just called various functions and printed the results.
If you want a useless but fun debugging tip, make a variable in global
called "debugon" or something like that. Then in any part of your code, do
this:
if(global.debugon) "Function was called with argument: <<arg1>>"
That way you can make your game print out all kinds of status messages and
debugging information, but then turn it off when you want to distribute the
game. Being able to turn it on and off means you can always go back to
development mode. Essentially you make your program turn into a chatterbox
about what it is doing. It can do some cool stuff like saying:
Objects in game: 2012
Actors: 23
Items: 32
Lamplist length: 8
Rooms: 42
You know, useless statistical junk like that which looks cool. I got a kick
out of timing all my commands, which told me when my code was taking too
long. When it takes too long or crashes that is because a while loop went to
hell. I thought of it as a kind of FPS meter for a text game. Yes, I am so
blasphemous I put a performance benchmark in a text adventure. So it says
like:
>north
.....
(Command took 3 milliseconds.)
Plugh!
> > A super slick auto-map solution. I hadn't thought of the obvious
> > solution of using HTML TADS. You approach sounds traightforward, but
> > still powerful. Can you post a URL of a screenshot of your automap in
> > action?
>
> No, because I threw it all away. You will just have to trust me when I say I
> did succeed in doing it, and it looked sexy.
> > Does it only handle regular grid strucures (sounds very like it)? What
> Yes only standard structures. Given as TADS only allows you to work with 8
> compass point directions, I see no problem with it.
Since when? TADS supports directions like SE, SSW, etc, in fact one
problem that I am having is that a magic word can be a direction (go
xyzzy from the well house to get to Y2), so there is a theoretically
limitless number of neighbouring rooms.
> If you had a game whose
> layout was finalized, you could add any amount of customized graphics,
> exits, drawings, etc. to the finished map. Remember, the map is just made of
> an HTML table. Within that table you can do anything with squares of
> graphics such as putting together larger images. Many websites provide ample
> examples of how to do that.
Yes, I can this will work and I agree that it could very slick -
especially for a single author-
I had been thinking of a generic tool - let's say a tweak to the
standard windows TADS interpreter which would allow any and every .GAM
file to be automapped, without access to the original source.
Now that you have pointed the way, I can also envisiage a half-way
house, where I provide a modified std.t or advt.t which overrides the
movement methods and which others could include in their own project
to get free automapping (maybe I need to add a magic transport verb
class, too).
> I was working on a system that would work with any game. If you just wanted
> to make your game look good you could for sketch out a large map by hand
> with plenty of shaded graphics, scan it in, and then expose one part of it
> at a time for the player. It would look completely hand-drawn at all times,
> although it would have a blocky appearance if you failed to create some
> blurring between the rooms. Try the multimedia Gold Skull demo to see how
> far you can take multimedia TADS.
Thanks, I will. I normal use text only, but I can see that this is an
area which I need to move into.
> > do you do with rooms with more than 8 exits? Could it handle Colossal
> > Cave (always the true test of an such tool, I tend to think).
>
> There are parts of Colossal Cave that have no consistent exits, so in those
> parts of the map you would have to put question marks instead of connecting
> lines (and no other mapper would be able to do better than that).
Ah, bedquilt! or was it the swiss cheese room? yes, this could always
be a problem. Of course, it all depends what my map shows - if I don't
label directions, but just show a connctoin, that could be ok.
> > I agree about the debugger. But, what are those magic verbs?
>
> They just called various functions and printed the results.
I see. What about debug verbs to give you any object, no matter if
it's far away, or even in NIL? Or unlock doors without the key? I am
sure that there are many more which people routinely use (allow to
carry more, make objects less bulky to pass through slits). OK, most
of that can be done with the workbench, but sometime a magic word is
just easier. I just haven't yet seen a truly impressive debug.t.
> If you want a useless but fun debugging tip, make a variable in global
> called "debugon" or something like that. Then in any part of your code, do
> this:
>
> if(global.debugon) "Function was called with argument: <<arg1>>"
>
> That way you can make your game print out all kinds of status messages and
> debugging information, but then turn it off when you want to distribute the
> game. Being able to turn it on and off means you can always go back to
> development mode. Essentially you make your program turn into a chatterbox
> about what it is doing. It can do some cool stuff like saying:
>
> Objects in game: 2012
> Actors: 23
> Items: 32
> Lamplist length: 8
> Rooms: 42
>
> You know, useless statistical junk like that which looks cool. I got a kick
> out of timing all my commands, which told me when my code was taking too
> long. When it takes too long or crashes that is because a while loop went to
> hell. I thought of it as a kind of FPS meter for a text game. Yes, I am so
> blasphemous I put a performance benchmark in a text adventure. So it says
> like:
>
> >north
> .....
> (Command took 3 milliseconds.)
Actuallly, I think that's kinda slick. Hmm, maybe you could make &
release ageneric HTML TADS about box, showing some of that info?
Val Artlett
say I
> > did succeed in doing it, and it looked sexy.
> And then you threw it away?! Why??
Depression
My brain still remembers how to do everything, so it is not really lost.
> Since when? TADS supports directions like SE, SSW, etc, in fact one
> problem that I am having is that a magic word can be a direction (go
> xyzzy from the well house to get to Y2), so there is a theoretically
> limitless number of neighbouring rooms.
>
The version of adv.t I was using only had 8 directions, plus out/in and
up/down.
I have perused a great many walkthrough maps for commercial games and mazes
and they always use text annotations for teleporter squares. Drawing lines
all over a maze or grid would look ugly and be impossible to read, unless
you worked it out with layers or animation. The automap allows the player to
get his/her bearings. It is not meant to squeeze out every atom of
information about how the game works. For instance if there is a trick
chute, putting that on the map would be giving away too much of the
challenge. Letting the player annotate his/her maps with their own notes is
preferable.
>
> I had been thinking of a generic tool - let's say a tweak to the
> standard windows TADS interpreter which would allow any and every .GAM
> file to be automapped, without access to the original source.
That sounds like an excellent idea, but beyond my ability. I think it should
be possible to add an automapper to any TADS source using an add-on module.
Any automap is going to need some tweaking at compile time to make sure any
exceptional or strange rooms are properly handled. And I think the choice
whether there should be a map or not should be put to the author of the
game, and no one else. An automap can alter the flow of a game in ways that
should up to the designer to control.
>
> Now that you have pointed the way, I can also envisiage a half-way
> house, where I provide a modified std.t or advt.t which overrides the
> movement methods and which others could include in their own project
> to get free automapping (maybe I need to add a magic transport verb
> class, too).
Right, I see that as the only compatible way.
> > > I agree about the debugger. But, what are those magic verbs?
> >
> > They just called various functions and printed the results.
> I see. What about debug verbs to give you any object, no matter if
> it's far away, or even in NIL? Or unlock doors without the key? I am
> sure that there are many more which people routinely use (allow to
> carry more, make objects less bulky to pass through slits). OK, most
> of that can be done with the workbench, but sometime a magic word is
> just easier. I just haven't yet seen a truly impressive debug.t.
>
I did all that. However you do it, it is really important to test a game to
death. TADS is so open ended you can make any verbs you want.
Here are some ideas.
Make an information verb. Typing info and the name of any object, regardless
of its visibility (change its validDoList to always return a list of all
objects in the game and its validDo to always return true) should display
some information about that object such as its location, properties, etc.
That can be handy while testing. It is a bit nicer than stopping the
execution and using the Workbench to get the properties for that object. The
information method is to be in the thing class. No need to go overboard with
the volume of information.
Give all the rooms vocabulary properties, then make a teleport verb to take
yourself there. See the paragraph above to make all rooms valid for that
verb. Testing a game often requires bouncing around various locations, and
walking back and forth for the 100th time gets very boring. Another,
sleazier way of doing this is to add debug exits to rooms. Where a wall is
supposed to be, for instance, you tell TADS to take you to another room. A
teleport method should be in the room class.
You can make a wizard verb which affects objects differently. For example
locked doors would respond to doWizard by opening. Puzzles would respond to
doWizard by solving themselves. You could make a magic debugging wand for
yourself and then give it to the player when he or she finishes the game, as
a reward. I think that would be a better reward than a gold nugget.
Various verbs can help to simulate various stages of game completion. They
can set variables and move objects around to bring the game into a different
state. This is very useful for testing a large game. I used to make verbs
that would be the whole package. It would advance the game, put the required
objects into my hands, and move me to the necessary room so I could test a
certain puzzle.
> Actuallly, I think that's kinda slick. Hmm, maybe you could make &
> release ageneric HTML TADS about box, showing some of that info?
Yeah, but what would be the point?
Uli Kusterer
> locked doors would respond to doWizard by opening. Puzzles would respond to
> doWizard by solving themselves. You could make a magic debugging wand for
> yourself and then give it to the player when he or she finishes the game, as
> a reward. I think that would be a better reward than a gold nugget.
>
> Various verbs can help to simulate various stages of game completion. They
> can set variables and move objects around to bring the game into a different
> state. This is very useful for testing a large game. I used to make verbs
> that would be the whole package. It would advance the game, put the required
> objects into my hands, and move me to the necessary room so I could test a
> certain puzzle.
This is useful, as long as you're aware of the caveats:
The "magic" code that solves a puzzle can do things the player can't.
This means that you might skip bugs that make the game unwinnable (e.g.
two puzzles that interdepend in such a way that you can't solve A
without having solved B and you can't solve B without solving A).
This is especially true if you take a room out of the game during
implementation which contains an important object for a riddle and then
put that object in another room, not noticing that the room isn't
accessible to the player yet.
Cheers,
M. Uli Kusterer
"The Witnesses of TeachText are everywhere..."
Plugh!
> > > No, because I threw it all away. You will just have to trust me when I
> say I
> > > did succeed in doing it, and it looked sexy.
> > And then you threw it away?! Why??
>
> Depression
>
> My brain still remembers how to do everything, so it is not really lost.
type it all back in quickly. As mentioned, it would be great to have
this in a tweaked adv.t.
> I have perused a great many walkthrough maps for commercial games and mazes
> and they always use text annotations for teleporter squares.
Yes, I agree with that. I think this might also be the solution to my
problem of how to show connections between maps, if I allow multiple
maps.
> The automap allows the player to
> get his/her bearings. It is not meant to squeeze out every atom of
> information about how the game works. For instance if there is a trick
> chute, putting that on the map would be giving away too much of the
> challenge.
I agree. So, this means that we are looking for a solution where the
author must consiously put auto mapping info in, rather than a
solution which automagically provides it for all .gam files?
> Letting the player annotate his/her maps with their own notes is
> preferable.
Yes, I would like to do that. I am still torn between a stand alone
mapping tool, which is easier to implement and tweaking the
interpreter code.
> > I had been thinking of a generic tool - let's say a tweak to the
> > standard windows TADS interpreter which would allow any and every .GAM
> > file to be automapped, without access to the original source.
>
> That sounds like an excellent idea, but beyond my ability.
Mike provides the source code for the interpreter and his code is
generally well commented. So, if you can do C, it would be an
interesting project. And, if you can't, it might be a good way to
learn ;-)
> I think it should
> be possible to add an automapper to any TADS source using an add-on module.
> Any automap is going to need some tweaking at compile time to make sure any
> exceptional or strange rooms are properly handled. And I think the choice
> whether there should be a map or not should be put to the author of the
> game, and no one else. An automap can alter the flow of a game in ways that
> should up to the designer to control.
Valid points, all, which tend to indicate a modified adv.t, rather
than tweaking the source code of the interpreter.
> > > > I agree about the debugger. But, what are those magic verbs?
If you have any code, might I suggest either posting it here, or
making a debug.t freely available?
> > Actuallly, I think that's kinda slick. Hmm, maybe you could make &
> > release ageneric HTML TADS about box, showing some of that info?
> Yeah, but what would be the point?
Errm, about the same point as benchmark timing the 'north' verb ;-)
Plugh!
[snip - debug verb discussion]
> This is useful, as long as you're aware of the caveats:
>
> The "magic" code that solves a puzzle can do things the player can't.
> This means that you might skip bugs that make the game unwinnable (e.g.
> two puzzles that interdepend in such a way that you can't solve A
> without having solved B and you can't solve B without solving A).
>
> This is especially true if you take a room out of the game during
> implementation which contains an important object for a riddle and then
> put that object in another room, not noticing that the room isn't
> accessible to the player yet.
Thanks, Uli, for reminding us of that.
Such debug verbs should be available to the author only, and are just
a lazy man's way of avoiding the workbench. Of course, a final alpha
test should be made with the verbs off and beta testers should not be
allwoed access to them under any circumstances.
Val Artlett
> Then, please, please, please, do the community a great service and
> type it all back in quickly. As mentioned, it would be great to have
> this in a tweaked adv.t.
>
It seems wrong to bother working on TADS 2.x code any more given as TADS 3.x
is going to make all of that work obsolete in due course. TADS 3.x, when
finished, will have revolutionary (for TADS) features that will change the
playing field dramatically to make 2.x code requiring of a re-write to take
it to the next level. So if I were to write 20 functions or 20 library files
for TADS 2.x, I would find in the 3.x environment they would be dated,
redundant, not at all using the features of 3.x, and all of them requiring a
rewrite to make them compatible with the structure of the new adventure
library.
The TADS 2.x system as it is is already more than good enough to produce
traditional IF. The purpose of TADS 3.x is not to add a shiny cow bell to
that, the purpose of TADS 3.x is to widen and broaden the horizons of what
is traditionally accepted.
For example in the future the traditional room model could change to a game
where there are no rooms and in which travelling in a certain direction
simply reveals more sensory data and makes objects reachable as opposed to
crossing a clear cut boundary into another room. Take the classic problem of
how to implement a large hall. If you segment the hallway into various rooms
as many designers do, you have to address the fact that the entire hallway
has to be visible all the time. If I drop a beach ball at the East End of
Hallway, I should be able to see it at the West End of Hallway. I should
also be able to run down the hallway without being stopped at every
intersection. In fighting these limitations, the whole concept of distinct
rooms starts to dissolve and seems downright obsolete. In the future a room
could be demoted to a mere convenience feature for when the player types a
direction without specifying the number of steps.
Stephen L Breslin
of Tads 3, especially as it relates to Tads 2. And I think none of you
should base any serious decisions on what he has said. He speaks with
a voice of authority, but (I speak very honestly here, and with no
malice) he really does not know what he is talking about. There will
be many posts in the upcoming months about the relation between Tads2
and Tads3; posts from reliable sources. I think it would be a mistake
to consider Val one of the reliable sources.
Warning: this is a shameless flame. As such, it is written for fun
(and written out of contempt). If you don't want to be a part of it,
_please_ don't read further. If you want to correct me, please feel
free to do so publicly. If you want a laugh about a pretentious dweeb
getting his cumuppins, please read on.
I think Val Artlett is pretty much lieing about his whole bit. But
I'll just respond to his last post. I don't have the time or energy to
bring to light each and every lie, but time, I'm sure, will show him
to be a liar in the absolute sense. In the future, I might revisit
some of his older posts, if I find any cause to butress the following
complaints.
"Val Artlett" wrote:
>It seems wrong to bother working on TADS 2.x code any more given as TADS 3.x
>is going to make all of that work obsolete in due course.
It's likely that people will continue working in T2 even after T3 is
fully operational, and for a long time thereafter. An analysis of this
is worth a serious thread, which I think Val is not knowledgable
enough to even broach.
>TADS 3.x, when
>finished, will have revolutionary (for TADS) features that will change the
>playing field dramatically
This is not based on any knowledge that Val has. Val has demonstrated
zero knowledge of Tads 3. The term "playing field" is a classic
Orwellian nonsense phrase (as is your casual and hyperbolic use of the
word "dramatically").
>to make 2.x code requiring of a re-write to take
>it to the next level.
Again, is Val actually saying anything, or is he spouting
"dramatically" shallow hyperboles? "Take it to the next level" is yet
another catchphrase-clue that he's spewing nonsense. Have you even
looked at the Tads 3 material at all, Val? You should either know
about what you're talking about, or not talk about it. Of couse, I
wouldn't mind if you speculate unknowingly, so long as you announced
it as untutored speculation. That's what it is, Val.
>So if I were to write 20 functions or 20 library files
>for TADS 2.x,
I very highly doubt you have ever written more than two or three
stupid, derivitive functions, based on a precursory understanding of
the tads2/examples file in the ifarchive. You have done nothing than
make a few obvious suggestions. You claim you're too depressed to
produce anything at all. I think you just have nothing to produce, and
plan on lieing about all you have accomplished, with nothing to show.
You have not accomplished anything. Prove me wrong and produce one
single thing that's of any interest, other than your bullshitting
speculation (which after all is of some interest, to the extent that
_other_ people will do what you claim to have done, after making the
necessary modifications -- think of an eighteenth-century child
claiming to have invented an airplane; how interesting is that, after
all).
>I would find in the 3.x environment they would be dated,
>redundant, not at all using the features of 3.x, and all of them requiring a
>rewrite to make them compatible with the structure of the new adventure
>library.
Firstly, you're guessing. You're partly right, but you're guessing.
You would first have to actually learn the library before making a
statement like this. Indeed most of your "ideas" are already
accomplished by the t3 library. If you bothered to learn about what
you're talking about, you would not have wasted our time with these
redundancies. Anyway, if you have any T2 sourcecode at all, why not
post it? I think you have written absolutely nothing that's worth
contributing (let alone written any super mappers; that's a bald face
lie, and you can just give up on that one). Prove me wrong and produce
a shread of something useful, other than your drivel and tripe which
plugh has unfortunately heretofore encouraged.
>The TADS 2.x system as it is is already more than good enough to produce
>traditional IF. The purpose of TADS 3.x is not to add a shiny cow bell to
>that, the purpose of TADS 3.x is to widen and broaden the horizons of what
>is traditionally accepted.
Well now you're the harbinger of change, standing on others work. Why
don't you ring the bell of silence instead, and let the announcements
come from the people who are actually working on the project? Do you
even know what traditional IF is? Do you have any sense of what
differs between T2 and T3? If you don't know what the difference is,
how do you have the gall to talk about it? How does T3 "widen and
broaden what is traditionally accepted"? If you can't answer that
question, you shouldn't make that statement. You fool.
>For example in the future the traditional room model could change to a game
>where there are no rooms and in which travelling in a certain direction
>simply reveals more sensory data and makes objects reachable as opposed to
>crossing a clear cut boundary into another room.
Wrong. T3 does not do that at all. Why don't you stop spouting
nonsense and crap you don't know about, and actually qualify yourself
as an intelligent commentator, before you egoistically pontificate?
Howabout that, you foolish dissembler? Maybe I can put it simpler:
shut your mouth, you're wrong and foolish, and what's worse, you're
possibly misleading and confusing people.
>Take the classic problem of
>how to implement a large hall. If you segment the hallway into various rooms
>as many designers do, you have to address the fact that the entire hallway
>has to be visible all the time. If I drop a beach ball at the East End of
>Hallway, I should be able to see it at the West End of Hallway. I should
>also be able to run down the hallway without being stopped at every
>intersection. In fighting these limitations, the whole concept of distinct
>rooms starts to dissolve and seems downright obsolete. In the future a room
>could be demoted to a mere convenience feature for when the player types a
>direction without specifying the number of steps.
You are blowing BS, buddy. You have no plan about how this can be
done, and no shame. Stop pretending to be a guru, and get to work
writing something useful. Or better yet, why don't you just fly a
kite, jump in a lake, take a long walk on a short pier, play in
traffic....
Val Artlett
deleted all my work in TADS 2 and when I decided for all intensive purposes
to no longer have anything to do with IF or TADS. There is no explanation
for this kind of concentrated and sadistic defamation other than pure
hatred. Arguing with a force whose only motivation is hatred is like trying
to cool oneself with fire.
Hatred is never justified, never right. Hatred and treating people hatefully
is wrong. I know I treated some people hatefully in the past, but this time
I will not return fire for fire.
"Stephen L Breslin" <bre...@acsu.buffalo.edu> wrote in message
news:3d0ffe8c....@news.buffalo.edu...
Stephen L Breslin
in the fun of flames should find this enjoyable.
I hope most of you are reasonable enough to delete this message
without further interest, as there is no real interest here. In any
case, I apologise on my behalf, and on Val's behalf, if I may so
presume. This is juvenile tripe, and I'll very likely not add further
flames, other than the present message.
"Val Artlett" wrote:
>This is the kind of diabolical hatred which helped to justify me when I
>deleted all my work in TADS 2
Firstly, I might be caustic and blunt. But really. Diabolical? I think
it's typically self-aggrandising for you to understand this as a
diabolical attack. Who are you? Is this Jesus vs. Satan? I'm just
giving you a ascerbic reality check, buddy. Don't use my reality check
as an excuse for you "deleting all your work" which I contend never
existed in the first place. You're using my rejection as an excuse for
the rejection you deserve. (No the logic doesn't work.)
> and when I decided for all intensive purposes
>to no longer have anything to do with IF or TADS.
I suppose you're re-entering the arena a bit egoistically, without
enough knowledge. If you would re-read what I have to say about your
posts, it mostly boils down to the fact that you don't know what
you're talking about. The cure for that is to learn about the subject
you're talking about. That's up to you, pal. I hope you come up with
something interesting to contribute.
>There is no explanation
>for this kind of concentrated and sadistic defamation other than pure
>hatred.
I think you're rather a pretentious fool. You're pretending to know
what you're talking about, but the cracks are showing.
You might seem (to an inexperienced reader) to be an authority. I
think this is a bit dangerous.
I corrected the problem rather bluntly, I admit. I don't want anyone
to believe that you know what you're talking about.
That's simply because you don't know what you're talking about. This
is not driven by some unmotivated sadistic hatred; this as rather a
corrective, since you are just convincing enough to confuse the
unwarned novices.
I was once a novice. I'm still a novice in some areas of T2 and
several areas of T3. But I can tell you are not the expert you pretend
to be, and I think I should let everybody know that.
You're blowing yourself up, to pretend to be attacked by someone
motivated by hatred. I don't know you, I don't hate you or anything
like that, and you know it. You are lieing and dissembling, pretending
that my comments are motivated by hatred. You know better. I just want
to dissuade you from pretending authority which you do not have.
Let's see some actual achievement for once. You drama queen with your
diabolocal enemies. Give us a break. Your diablo is common sense, bro,
and I hope it haunts you until you have something worth saying. Get
depressed about that, and give us a breather in the meanwhile.
[I am not responding to the remainder of Val's message, because I
think it doesn't make much sense. But I'm still including it here for
completeness.]
>Arguing with a force whose only motivation is hatred is like trying
>to cool oneself with fire.
>
>Hatred is never justified, never right. Hatred and treating people hatefully
>is wrong. I know I treated some people hatefully in the past, but this time
>I will not return fire for fire.
[Of course I agree with Val that hatred is bad (and by extension, love
is good). I have no knowledge of what he did in the past, by the way.
I can make some assumptions, but I won't speculate.]
[after this Val quoted my last post in entirety, I think.]
Andrew Plotkin
> I hope most of you are reasonable enough to delete this message
> without further interest, as there is no real interest here.
So, um...
> In any
> case, I apologise on my behalf, and on Val's behalf, if I may so
> presume. This is juvenile tripe, and I'll very likely not add further
> flames, other than the present message.
Thank you for limiting the noise, at least.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
Iain Merrick
> (I speak very honestly here, and with no malice)
Uh-oh...
[...]
> Warning: this is a shameless flame. As such, it is written for fun
> (and written out of contempt).
Also known as 'malice'.
> If you don't want to be a part of it, _please_ don't read further.
> If you want to correct me, please feel free to do so publicly. If
> you want a laugh about a pretentious dweeb getting his cumuppins,
> please read on.
I've seen lots of posts with warnings like this at the top, and none of
them were remotely worthwhile; yours follows the same pattern. I assume
you're trying to copy Adam Cadre's dissection of Paul Panks' post, over
in rgif. Please don't try.
--
Iain Merrick
ia...@diden.net
Plugh!
> > Then, please, please, please, do the community a great service and
> > type it all back in quickly. As mentioned, it would be great to have
> > this in a tweaked adv.t.
> It seems wrong to bother working on TADS 2.x code any more given as TADS 3.x
> is going to make all of that work obsolete in due course.
> TADS 3.x, when
> finished, will have revolutionary (for TADS) features that will change the
> playing field dramatically to make 2.x code requiring of a re-write to take
> it to the next level. So if I were to write 20 functions or 20 library files
> for TADS 2.x, I would find in the 3.x environment they would be dated,
> redundant, not at all using the features of 3.x, and all of them requiring a
> rewrite to make them compatible with the structure of the new adventure
> library.
Perhaps. But you could always take a look at TADS3 and make an
informed decision.
> For example in the future the traditional room model could change to a game
> where there are no rooms and in which travelling in a certain direction
> simply reveals more sensory data and makes objects reachable as opposed to
> crossing a clear cut boundary into another room. Take the classic problem of
> how to implement a large hall. If you segment the hallway into various rooms
> as many designers do, you have to address the fact that the entire hallway
> has to be visible all the time. If I drop a beach ball at the East End of
> Hallway, I should be able to see it at the West End of Hallway.
yep, afaik, this sort of thing is in TADS3.
> I should
> also be able to run down the hallway without being stopped at every
> intersection.
I'm not so sure about that being in TADS3. I haven't looked at it in
months, but as far as I remember, it was something like giving a
property to say "this object is visible from adjacent rooms" (with
qualifiers; and thibgs liek how bright a light is, how loud a noise
is, etc, controlling how far things 'permeate'). However, the concept
of a room is not going to go away and that's what we are talking about
for automapping.
> In fighting these limitations, the whole concept of distinct
> rooms starts to dissolve and seems downright obsolete. In the future a room
> could be demoted to a mere convenience feature for when the player types a
> direction without specifying the number of steps.
Nice idea, perhaps (I don't like it personally, but I can see the
appeal), but I don't expect to see it in TADS3.
Of course, maybe it's time I looked at TADS3 again. But, afaik, it's
pretty much solid as to what will be included, so we can probably
already start implementing.
Thirteenth Monkey
The only problem with TADS 3 is that some of us take years writing
TADS 2 games. I'm sure that by the time I release my (TADS 2) game
TADS 3 will have the same library support and be as stable as TADS 2.
I'm rather pleased that nobody is developping much TADS 2 stuff as it
means I don't have to keep thinking 'that's a good idea - how the f@ck
am I going to implement it?' Then again, I look at TADS 3 and think
'bugger'.
Personally, I think that TADS 3 so far looks great and much better
than other IF languages, but then I also believe that TADS 2 is more
powerful and better implemented than all of the other languages put
together. TADS 3 is a bit more sensible syntax-wise too. No more
verDoThis(actor). Thank God!
Cheers
Thirteenth Monkey