TADS 3 Ideas
Andrew Lewis Tepper
adventures. I would like TADS 3 to be the ultimate MUD language. I've
read (briefly) the programmers manual for the MOO language (This seems
to be the Mud that concentrates most on object oriented programming, and
creating "Text based virtual realities.") To do this, here are some
things I've thought of that would be needed:
* Real-Time daemons and fuses. (Ex: Fuse runs after 5 seconds.)
* Dynamic object creation. The word 'a' would have to be supported.
* Constructers and Destructers. For player objects, methods to
support connecting and disconnecting would have to be present.
* Run-time class checking. (There must be another name for this.)
Suppose 'red-ball' is a type of 'ball', and 'red-rubber-ball'
is a type of 'red-ball'. There would have to be a way to test
if a 'red-rubber-ball' object is a 'ball' object. (Does TADS do
this now? I haven't run across the need yet.)
* Third person verbs. Player #1 types "JUMP on table." (JUMP is 1st
person.) Player #1 sees "You JUMP on the table." (JUMP is 2nd
person.) Other players see "Player#1 JUMPS on the table." (JUMPS
is 3rd person.) In English I guess almost all verbs' 1st and 2nd
person forms are identical. 3rd person are unpredictable. Most
just add an 's', but some do not. (TRY->TRIES GO->GOES AM->ARE->IS)
I've said it before on this forum: MUDs could be the next advance in IF,
but all current systems I've seen are just hack-and-slash games, or chat
lines. Detail is universally terrible, multi-player puzzles are
non-existant (puzzles in general are rare), and parsers are primitive.
If Infocom had lasted, would we now be playing multiplayer IF?
Andy
Andrew C. Plotkin
Lewis Tepper@andr (1718)
> I've said it before on this forum: MUDs could be the next advance in IF,
> but all current systems I've seen are just hack-and-slash games, or chat
> lines. Detail is universally terrible, multi-player puzzles are
> non-existant (puzzles in general are rare), and parsers are primitive.
> If Infocom had lasted, would we now be playing multiplayer IF?
I started to work on a MUD-that-only-an-Infocommie-would-love once.
There are many pitfalls. Lemme see...
Infocom-style IF is a single-user art form. It would be easy to extend
it to an N-player art form for fixed N. (_Journey_ did this to some
extent, with one user playing all the game characters, but having one
user per character is just an interface issue.) However, I think it
would be very hard to extend it to the paradigm* of a MUD, where there
are an unlimited number of players and they're all logging on and off
whenever they feel like it. To exert the level of authorial control that
we're used to, you would need a definite party of players, each playing
one game character, all logged in at once. Each party would have its own
world state (saved game), as opposed to current MUDs, where there's only
one world state that everybody shares.
I didn't attempt this in my abortive MUD; I had a single world state.
However, I rapidly realized that any coherent puzzle-area in the MUD
would have to have locking mechanisms to let only 1 (or N) people in at
a time. Then it would need reset mechanisms to set up the game again
when new player(s) came along. Then it would need activity checkers so
that you couldn't reset the game when someone was already playing it...
then I gave up planning and just hoped it would all work out.
Second problem (tangential): I wanted every player to have the ability
to build. But I wanted to ensure that nobody had the ability to screw up
other people's areas... like building doorways out of someone else's
maze. But I *did* want objects to interact (you should be able to put
your hat on someone else's table, and if the table was actually a
teleporter, it should work. But what if the hat is a teleporter too? You
see the headaches... no pun intended.) I kept stumbling over security
holes, and I *think* I had a model which fixed them all; but since it
was never finished or tested, I can't say. I was using an OO system with
methods invocable by name; but the access control was sort of a hack,
and I probably should have redone it more flexibly. Separate
read/write/execute flags for player/creator/friend, on each method and
data field, say. Or worse. (Differentiate between a person doing
something and one of his objects doing something?)
There's also CPU usage. What if someone builds an object whose "view"
method is
{while (1) echo "Nyah"}
See system crash. I had a maximum execution time (measured in
instructions of the programming language); overruns were logged so the
admin could figure out if it was the player's fault or the builder's.
The trivial solution is to have a privileged class of builders who know
better than to trample each others' work. But I don't like that.
I'll comment on your comments:
> * Real-Time daemons and fuses. (Ex: Fuse runs after 5 seconds.)
Necessary. Also hard; it's a CPU usage problem; you have to worry about
people building thousands of fuses (say, fuses created by a recursive
function.)
> * Dynamic object creation. The word 'a' would have to be supported.
Necessary. My system had global methods "create" and "destroy"; you
could, for example, build a vending machine that created a "beer" every
time a player pushed a button. Naturally, builders had to be careful
that such auto-created objects cleaned themselves up -- including
self-destructing after a given period, just in case.
Oh, and there was another buttload of security holes. Can't allow
someone to create a copy of the magic one-use-only disenchant scroll...
I'm not sure what you mean by "the word 'a'". "Create a beer", perhaps?
I had the game programming language entirely separate from the
player-command parser, just as TADS and Inform do. I'd hate to think of
combining them -- major headaches. You could of course have a player
command "create {a} #OBJECT" which runs a subroutine which invokes the
"create" method, but this would be up to the builder of a particular
area, and probably very limited.
> * Constructers and Destructers. For player objects, methods to
> support connecting and disconnecting would have to be present.
Yes.
> * Run-time class checking. (There must be another name for this.)
> Suppose 'red-ball' is a type of 'ball', and 'red-rubber-ball'
> is a type of 'red-ball'. There would have to be a way to test
> if a 'red-rubber-ball' object is a 'ball' object. (Does TADS do
> this now? I haven't run across the need yet.)
Yes. Most OO systems have this sort of thing. Mine was a hack to some
extent; objects inherited from other objects, not from distinct classes.
You create a "red ball" as a subclass of (say) "archetypical object",
and then you create "red rubber ball" as a subclass of "red ball". This
made the interface a little cleaner. Of course, the admins somewhere
actually had "archetypical object" and "archetypical room" and so on.
This made it easy to add new behaviors; since all method-binding was at
runtime, the admins could just add methods to "archetypical object" and
all objects in the game would start responding to them.
> * Third person verbs. Player #1 types "JUMP on table." (JUMP is 1st
> person.) Player #1 sees "You JUMP on the table." (JUMP is 2nd
> person.) Other players see "Player#1 JUMPS on the table." (JUMPS
> is 3rd person.) In English I guess almost all verbs' 1st and 2nd
> person forms are identical. 3rd person are unpredictable. Most
> just add an 's', but some do not. (TRY->TRIES GO->GOES AM->ARE->IS)
I think you actually have to make this even more flexible. Consider the
teleporting table I mentioned earlier. The output would have to be "You
jump on the table. It goes ZING, your skin prickles, and the room
vanishes in a shower of sparks." Everyone else sees "PLAYER jumps on the
table. PRONOUN'S hair stands on end and PRONOUN vanishes in a shower of
sparks."
Then there are three-version messages, like "You give the rock to Fred.
What a relief." "Bob gives the rock to you. Whew, it's heavy!" "Bob
gives the rock to Fred, who staggers."
My solution was to have this all in code, rather than trying to
substitute words. The "archetypical player" had a method "see (string)",
which just sent the string to that player. Then there was "see_other
(string1, string2)", which looked like
{ self->see(string1);
foreach p in (contents_of(self->location)) do {
if is_a(p, archetypical player)
p->see(string2);
}
}
That is, self sees string1; then every other player in the same room
sees string2. (The syntax is not as I've written it; I forget exactly
how it looked, but it was probably much uglier.) A similar
"see_both(string1, string2, string3)" method handled the "you, me,
everyone else" case.
Pronouns were handled by special hack. You could have a string like "You
see \him{p} here.", and the game would invoke the him(p) function and
insert the resulting string in the original string. The list of
functions was not builder-extendible, because I didn't want to go
insane. Nameof(), the pronoun functions, and a few others. I think it
also took string expressions like \{flag ? "yes" : "no"}. However, these
embedded expressions could *not* have side effects.
(BTW, entirely as a side comment, I recommend at least four genders and
five pronouns.
he, his, his, him, himself
she, her, hers, her, herself
it, its, its, it, itself
je, je's, je's, je, jeself
There are several popular pronoun-sets that could be used for that last
line, of course. However, the five columns are *not* redundant, except
maybe for the last one.)
Heh. Enough babbling for now.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
Paul Francis Gilbert
>I can't think of any suggestions to improve TADS 2 for single player
>adventures. I would like TADS 3 to be the ultimate MUD language. I've
>read (briefly) the programmers manual for the MOO language (This seems
>to be the Mud that concentrates most on object oriented programming, and
>creating "Text based virtual realities.") To do this, here are some
>things I've thought of that would be needed:
...stuff deleted...
>Andy
I think MUDS and Infocom-Style IF should be kept seperate... I surely
don't mind people making MUDS, but the whole structure of a MUD is, by
definition, Multi-user, while good 'ol TADS lets us make our single user
worlds.
But on the subject, a few things I'd like to see in TADS 3:
o Bit masks, which has already been mentioned and has been told that they
will be implemented.
o Good handling support for multi-room objects. A good example is a
computer cable which can be plugged into different computers in seperate
rooms. The cable will need to be in several rooms simultaneously.
Currently all you can do (as far as I know) is to create a method for the
objects location property to check the player's location against against a
list of locations of the object and pass out the location if in the list.
I'd be easier if location could accept a list or a single location, for
more flexible (or least easier) object handling.
o Handling for the creation of multi-present objects. How to handle the
classical case of a box of matches, which incidentally was in the manual.
The manual just had a method defined to light a match and decrease a
counter containing the number of matches by one.
But what happens if you wish to let them remove a match? Or you have
vending machine supplying beer. Obviously you could have a radar sprout
from the top and regretfully inform the player that due to
waste-not/want-not laws you cannot have a new beer until the old one is
consumed, but that gets a bit ridiculous. Perhaps some sort of
dynamic-object allocation scheme (kind of like dynamic variable allocation
in languages like Turbo Pascal or C), with limiting capabilities. In this
case each object would have the exact same inheritance, giving it the same
characteristics, but all data concerned with each object would be seperate.
o A moot point, but window-dressing of the PC TDB (I'm not sure what the
Mac's is like) to give it a menu and mouse control. Much easier for those
long debugging tasks then trying to remember key combinations.
Those are all I can think of at the moment. TADS really is an excellent
product, and I join with others in wondering when we can expect version 3.
Paul
====
s940...@minyos.xx.rmit.edu.au
Ms. Pauline Benzies
Paul Francis Gilbert <s940...@minyos.xx.rmit.EDU.AU> wrote:
>
>o Good handling support for multi-room objects. A good example is a
>computer cable which can be plugged into different computers in seperate
>rooms. The cable will need to be in several rooms simultaneously.
>Currently all you can do (as far as I know) is to create a method for the
>objects location property to check the player's location against against a
>list of locations of the object and pass out the location if in the list.
>I'd be easier if location could accept a list or a single location, for
>more flexible (or least easier) object handling.
Check out my husbands 'wallpaper.t' module (on ftp.gmd.de in jeffslib). In
the case above, he would do something like
cable: wallpaper
and then tweak with a few methods to allow it to be handled. Of course, you
have to resolve the problem of "plug in" where the cable can be plugged into
multiple places. (You define in the rooms floating_items list that the cable
is present and all the other stuff just magically works - mostly)
These are, however, problems with "adv.t", not with "tads" per se. You can
always adjust the class library to match your requirements.
>o Handling for the creation of multi-present objects. How to handle the
>classical case of a box of matches, which incidentally was in the manual.
>The manual just had a method defined to light a match and decrease a
Hear here. hopefully, the cryptic hint Mike gave about two C++ operators
was "new" and "delete".
Darin Johnson
> to be the Mud that concentrates most on object oriented programming, and
> creating "Text based virtual realities.")
Debatable, but... It's big drawbacks are that it isn't well suited to
offline coding and stuff (DB oriented); it has no good examples of
anything other than tinystyle social muds.
> I've said it before on this forum: MUDs could be the next advance in IF,
> but all current systems I've seen are just hack-and-slash games, or chat
> lines. Detail is universally terrible, multi-player puzzles are
> non-existant (puzzles in general are rare), and parsers are primitive.
Maybe you should hunt around. I think LP's that go for that sort
of thing have the best puzzles around. Tinies and derivatives
usually don't because the players don't care much, and dikus
and other full combat oriented muds make it hard. LP is not
necessarily OO, only if you grab an existing combat oriented
library (like MOO, it has the drawback that it has few examples
of other orientations) - and it's nicely OO and configurable.
As far as parsers - you can end up with some great stuff with
existing parsers and muds. Remember, MUDs are big with lots
of players, and doing complicated parsing and object disambiguation
will just slow things down. The tools are already out there
NOW to create what you want.
--
Darin Johnson
djoh...@ucsd.edu
"You used to be big."
"I am big. It's the pictures that got small."
David Brain
I wish I could remember the name of the MUD game I played, a while ago
now, which had a well. Two people were needed. One got in the bucket,
and was lowered down by the other. First player then gets out, and loads
the treasure into the bucket (it was too heavy for both treasure and
player). Second player then winds bucket back up and (more often than
not) winds first player back up again to share the treasure. I liked
this game because it was (a) full of those sort of ideas, and (b) the
people who played it weren't b*st**ds who wouldn't think twice of running
off with the treasure and leaving you down the well. Mainly because you
were then unlikely to help him solving other puzzles (there was a several
player one involving a drawbridge as well I think).
I try to construct puzzles like this, but in solo games it is hard to
come up with convincing ways of making NPCs appear to listen to you.
David
(first posting here, so hello :-)
Andrew Lewis Tepper
by "David Brain"@cix.compul
>
> I wish I could remember the name of the MUD game I played, a while ago
> now, which had a well. Two people were needed. One got in the bucket,
> and was lowered down by the other. First player then gets out, and loads
> the treasure into the bucket (it was too heavy for both treasure and
> player). Second player then winds bucket back up and (more often than
> not) winds first player back up again to share the treasure.
Wow, this is exactly what I'm looking for. If you (or anyone reading
this) knows which MUD has these puzzles I'd be grateful for the info.
Andy
David Brain
> this) knows which MUD has these puzzles I'd be grateful for the info.
If I could remember, I would tell you. But I only played it a few times
back in 87 I think - it's amazing I can remember any of it, but puzzles
like that are so unique that you tend not to forget them.
David
Magnus Lie Hetland
--
Either the next statement is true, or this signature is a Paradox.
The previous statement is false and this signature is a Paradox.
Magnus
Lie
Hetland
Adam Thornton
Mike license WorldClass.t from Adventions, and include it with the
registered version as an alternate to adv.t?
Adam
--
ad...@io.com | ad...@netcom.com | ad...@phoenix.princeton.edu | Viva HEGGA!
"Double integral is also the shape of lovers curled asleep" : Pynchon
64,928 | TEAM OS/2 | "Ich habe einen Bierbauch!" | Linux | Fnord
You can have my PGP passphrase when you pry it from my cold, dead brain.
Ron Hale-Evans
>I think a lot of the problem lies with adv.t. Might I humbly suggest that
>Mike license WorldClass.t from Adventions, and include it with the
>registered version as an alternate to adv.t?
This sounds intriguing. I've seen enough of the work of Adventions in _GC_
to be very impressed with it and am using some of said code in my own
game. I gather that WorldClass.t is a proprietary alternative to adv.t; is
it for sale separately? Dave B., any comments?
I also read somewhere else that another person was working on an adv.t
alternative; is he here? And what about the guy who was doing monsters2.t?
--
Ron Hale-Evans ... rw...@netcom.com
Home page = file://ftp.cs.yale.edu/pub/evansr/home.html
"If you ever reach total enlightenment while you're drinking a beer,
I bet it makes beer shoot out your nose." -- Jack Handey
David Baggett
I wrote WorldClass for "The Legend Lives!". It completely replaces ADV.T,
and offers a few nice things that ADV.T doesn't support. E.g.:
- Objects can be in, on, under, or behind other objects, and
WorldClass actually keeps these notions separate. ADV.T
conflates all these into a generic "contained-in" idea,
which makes things like desks that can have things separately
on, in, and under them difficult to define. In WorldClass you
get a Desk class that works correctly.
- Containers determine whether or not the various senses
pass through themselves. For example, a box might pass
sight only when it's open. If the player stuffs his only
light source into the box and then closes it, he won't
be able to see anything.
This also lets you define things like vending machines that
block certain actions (like taking or smelling) but allow
others (like seeing, and possibly hearing).
- Support for sounds and smells. Sight is no longer required
by the substrate as it is in most games. (I.e., the dark
is no longer a complete obstacle.) Verbs define their
sensory requirements. Only verbs that require sight will
fail in the dark. So you'll still be able to smell things
in a dark room.
Similarly, objects can have smells and sounds attached to
them that are automatically printed in room descriptions.
The player will still get these even if he can't see.
- Better travel verb syntax. Instead of just
north = cave
you can say
verGoNorth(actor) = { ... }
goNorth(actor) = { return cave; }
This lets you make NPC's that move around by checking the
ver methods. E.g., you could do something like:
verGoNorth(actor) = {
if (actor = Me)
"You don't fit through the passage.";
}
which would allow other NPC's to go north but not the player.
- More consistent class and method naming.
- WorldClass keeps track of subjective, objective, and reflexive
case. It also supports plurals and determined nouns (like
proper names). This eliminates ungrammatical generated text
like "You can't hit you with the stick" and "The bananas
isn't something you can do that to."
- WorldClass keeps track of which objects the player knows
about. Generally, things the player has seen are considered
known, though the author can specifically make things known
when necessary. The player can only ask about known things.
Now that Adam has lured me into bragging about WorldClass (grin), there is
the matter of what to do with it. I'm not in general opposed to other
people using it, but it's considerably more complex than ADV.T (about 10K
lines vs. 4K lines), and is completely undocumented. I'm definitely not
going to have time to write any kind of manual for it in the next six
months.
Though I hate to admit it, it probably also requires a much better
knowledge of TADS to use. Most of the features I mentioned don't seem too
tricky at first, but supporting them in their full glory gets nasty very
quickly, and much of the code is nontrivial. (Listing room contents, in
particular, is hideous.)
This makes the lack of documentation even more problematic. The only way I
can see it ending up useful to other people is if someone were to volunteer
to figure out how to use it (with help from me, of course) and write a
manual for it. No small task, let me assure you!
Dave Baggett
__
d...@ai.mit.edu MIT AI Lab He who has the highest Kibo # when he dies wins.
ADVENTIONS: We make Kuul text adventures! Email for a catalog of releases.
Bob Newell
>the matter of what to do with it. I'm not in general opposed to other
>people using it, but it's considerably more complex than ADV.T (about 10K
>lines vs. 4K lines), and is completely undocumented. I'm definitely not
>going to have time to write any kind of manual for it in the next six
>months.
>can see it ending up useful to other people is if someone were to volunteer
>to figure out how to use it (with help from me, of course) and write a
>manual for it. No small task, let me assure you!
C'mon, now... you've gotten all of us into a feeding frenzy! If you release
it, it's about 99.9% sure that a lot of newsgroup correspondents will have
it documented and in use in short order......