Design of a New Language: 2
Greg Ewing
========
This is rather long, so here's a summary of what I'm asking:
1) Do you prefer static (compile-time) or dynamic
(run-time) type checking?
2) Would you prefer a language with lots of special
adventury constructs (like Alan) or something
simpler and more general (like Tads)?
3) Would Alan be a good starting point for my new
language?
Rambling
========
Well, I've spent the last few days doing a lot of thinking
about the design of my language. Unfortunately, most of it
has been in circles without much convergence. I'm going to
have to make some basic decisions before I can make any
more progress.
The first question I need to settle is: should it be
Alan-like or Tads-like? I'm not talking about details of syntax
here, but about what the underlying model is like.
In Alan we have static typing, a fixed set of object types with
limited extensibility, and a language which has many special
constructs to make common things straightforward, but lacks
flexibility when uncommon things are required.
In Tads we have dynamic typing, a highly extensible type
system, and a simple and general language. Most of the default
behaviour is embodied in a quite large and elaborate class
library, and thus can - in principle - be extensively
customised.
There are a couple of issues in there which need to be
separated out:
1) Static or dynamic type checking?
-----------------------------------
I tend towards favouring static type checking, because
it enables the compiler to find my more stupid mistakes
instead of having to wait until they cause an obscure
bug. It does, however, come at a price in flexibility.
Does anyone out there think that static type checking would
be too severe a restriction on their creativity?
2) Should the "smarts" be in the language or the library?
---------------------------------------------------------
This is supposed to be a *language for writing adventures*, so
it makes sense to include constructs designed specifically for
adventures. At the same time, more general facilities need to
be available.
To me it seems Alan provides a lot of good stuff, but is not
flexible enough. However, I'm not at all comfortable with the
opposite extreme taken by Tads. There's too much of an
'anything goes' feel about the Tads library for my liking.
This is made worse by the fact that the Tads library is not
particularly well documented. Alan may be rigid, but at least
it is fully documented and relatively easy to understand.
Does anyone else have a similar feeling?
Conclusion
----------
Currently I seem to be favouring something rather more
Alan-like than Tads-like. In fact I am thinking of starting
with Alan and using it as a base to experiment with extensions
and generalisations.
Since the source of the Alan system is not available, this
will require re-implementing it from scratch. Before I go to
that much effort, I'd like to hear if anyone has any alternative
suggestions.
So - do you have a better idea?
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of Japan Inc.|
gr...@cosc.canterbury.ac.nz +--------------------------------------+
Brendon Wyber
Data type checking at compile time seems the way to go. Makes things a hell
of a lot easier for the programmer.
A prefer the TADS style of flexibility with standard libraries. I think that
TADS 2.1 modify/replace ability is really great!
The Alan approuch is far too limiting. With the TADS style libraries you can
see what is going on.
--
Be seeing you,
Brendon Wyber Computer Services Centre,
b.w...@csc.canterbury.ac.nz University of Canterbury, New Zealand.
"Ph-nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn."
Gerry Kevin Wilson
Dynamic, like TADS. I like as much flexibility as you can provide me
with. I mean sure, static is easier, but easier will never beat out flexible
in my book.
2.) 'smarts' in language or library?
Well, it really depends on your programming style. However, I like the
author to keep his hands out of my game as much as possible. Your program
should be more of a programming language than a game. For instance, TADS
lets me change the statusline fairly easily, because that's not hardcoded
into the language. I'm already taking advantage of that in preparation for
my next game, Asphyxiation.
General comments:
I really enjoy TADS for its flexibility and pseudo-C code. I don't have to
learn a new language to use it. There are only a few things I would change.
On a MUD, you can have multiple copies of a standard blueprint (object). I
would love to see that in a language. Also, sound. Support sound as much
as will port from machine to machine. Make a gif-title loader that can be
easily ported from machine to machine. And finally, don't muck around with
too many verification calls. Let the user put it into the verb or what have
you. verDo and verIo still bewilder me sometimes, and I have to take time to
read that section in the manual again. That's it, otherwise, TADS has the
right idea.
--
*=== If there's one thing I've learned in this silly old thing called ===*
*=== Life, it's....umm....oh Hell, I've forgotten. ===*
*=== whiz...@uclink.berkeley.edu ===*
*=== Disclaimer: I am insane. Deal with it. ===*
Philip Stephens
>The first question I need to settle is: should it be Alan-like or Tads-like?
>I'm not talking about details of syntax here, but about what the underlying
>model is like.
Flexibility and extensibility is important; however, from what I've seen of
TADS, it relies far too much on library support to implement even the most
basic of IF concepts. This is a disadvantage, IMHO, not so much because it
requires a large library to run, but because it forces programmers to extend
that library on a frequent basis in order to achieve what they want. Witness
the continual stream of TADS related articles for improving on the standard
library.
In comparison, Alan has quite a good range of inbuilt features, but as you
say it is too inflexible to be generally useful. As I see it, there is a great
need for an IF language that can provide a balance between in-built features
and extensibility.
I've been thinking about what ought to be present in an IF language myself
lately, and here's a few ideas I've come up with:
1. Implement an improved parser that recognises more complex noun phrases,
particularly in respect to specifying pluralism i.e. specifying exact
and approximate quantities of things, with or without units of
measurement.
e.g. take one of the matches.
pour some water.
pour 5 litres of water into the bucket.
Also add support for multiple adverbial phrases.
e.g. pour some water from the bucket into the sink.
write my name in the book using the pencil.
2. Provide in-built support for modelling different kinds of objects, such
as solids, liquids, gases and particles. In other words, while we need
to be able to extend the properties of an object to implement unusual
features, the more inbuilt properties that are recognised (such as size,
weight, dimensionsi, quantity and so on), the better.
This is particular relevant in combination with parser design: the parser
should have enough intelligence to be able to determine the visibility
and available of objects given in a sentence, for instance, which means
that concepts such as visibility and availability should be in-built
constructs of the language.
3. Allow the definition of object classes, and the ability to create and
destroy objects dynamically.
>Does anyone out there think that static type checking would be too severe a
>restriction on their creativity?
As long as the syntax allows the casting of one type to another, as in C,
then I'd be in favour of some compile-time type checking.
>This is supposed to be a *language for writing adventures*, so it makes sense
>to include constructs designed specifically for adventures. At the same time,
>more general facilities need to be available.
I agree 100%.
>Currently I seem to be favouring something rather more Alan-like than
>Tads-like. In fact I am thinking of starting with Alan and using it as
>a base to experiment with extensions and generalisations.
Are you looking for partners to help you develop this system? I've been
tossing up whether to embark on such a project, and your ideas seem to be
along the lines of what I was considering.
>Since the source of the Alan system is not available, this will require
>re-implementing it from scratch. Before I go to that much effort, I'd like
>to hear if anyone has any alternative suggestions.
Even if you were to start with available source from such IF systems as
ADL, you wouldn't be able to use it in your own product without first getting
permission from the authors, I don't think. But it may be worth contacting
the authors to find out.
--
| Philip Stephens, Systems Programmer. | "Many views yield the truth. |
| Address: 43 Malcolm Road, Braeside, | Therefore, be not alone." |
| Victoria, 3195, AUSTRALIA. | |
| Internet: phi...@labtam.labtam.oz.au | -- Prime Song of the Viggies |
Greg Ewing
cct...@cantua.canterbury.ac.nz (Brendon Wyber) writes:
|> The Alan approuch is far too limiting. With the TADS style libraries you can
|> see what is going on.
I fully agree that Alan as it stands is too restrictive. The question is
whether there are any good things in Alan that can be adopted? And if
so, can Alan be modified into something more useful, or would it be
better to start again with a fundamentally different design?
There are many parts of Alan that I like. It has very natural ways
of expressing the most common things, e.g. the way verbs are divided
into CHECK and DOES sections, the way you can attach ELSE clauses
in various places where things might go wrong, and so forth.
Tads has mechanisms which are functionally equivalent, but much
more difficult to learn, and remember, how to use. The flexibility
of Tads is two-edged. It is easy to make the library big and complicated,
so it gets that way, and it's *not* always so easy to see what's going
on! Sorry, I'm starting to rant.
Anyhow, I want to pick the best parts of both approaches and somehow
merge them. But what *are* the best parts?
Opinions heard so far:
* Static type checking is good
* Tads-style flexibility is good
Does anyone else like anything about Alan, or am I the only one?
|> Brendon Wyber Computer Services Centre,
|> b.w...@csc.canterbury.ac.nz University of Canterbury, New Zealand.
Greg Ewing, Computer Science Dept, +--------------------------------------+
David Baggett
(Greg Ewing) writes:
>To me it seems Alan provides a lot of good stuff, but is not
>flexible enough. However, I'm not at all comfortable with the
>opposite extreme taken by Tads. There's too much of an
>'anything goes' feel about the Tads library for my liking.
I'd argue the exact opposite -- what you want is a solid, built-in
interface between the parser (which you shouldn't have to worry about) and
the language. TADS could be better in this regard, but is nevertheless
quite adequate.
Many people find flaws in adv.t and fault TADS. While this makes sense,
it's not entirely accurate. Try writing adv.t from scratch sometime and
you'll see how little actually *has* to work the way adv.t requires.
The point is that adv.t could be rewritten to handle all sorts of
funtionality. You could put in planning, an inference engine, a belief
system like Jorn wants, etc. Just because no one's done these things
doesn't mean they can't be done.
This a strong argument in TADS' favor. You'd lose that by building more
immutable stuff into the language. A good example of the success of
extensible systems is emacs -- it's very different from what it was 10
years ago, but because you can add your own features and radically change
the editor's behavior (e.g., vi mode) it's even more popular now than it
was then. Just because *most people* don't hack emacs lisp code (including
me) doesn't mean that it's not A Real Good Idea to have it.
>This is made worse by the fact that the Tads library is not
>particularly well documented.
In the 16 years I've been programming I don't think I've ever seen better
documented code than adv.t, except perhaps for Knuth's TeX and Metafont
source (which were published as books). There are more comments than
source lines in adv.t! Even without the manual you can figure out what's
going on.
Furthermore, I think the TADS manual is really good. There are BUGS in
adv.t that cause problems (try "remove x-ray specs" instead of "take off
specs" in UU2), but I don't really see how most of the classes could be any
*better* documented.
MHO.
Dave Baggett
__
d...@ai.mit.edu Boot up, log in, drop out. MIT AI Lab
ADVENTIONS: We make Kuul text adventures! Ask about Unnkulian 1, 2, 0, 1/2
PO Box 851 Columbia, MD 21044 USA / CIS: 76440,2671 / GEnie: ADVENTIONS
Greg Ewing
(Gerry Kevin Wilson) writes:
|> Your program
|> should be more of a programming language than a game.
We seem to have differing tastes here. I would like writing an IF game to
be more like writing a story than writing a program. I want to be able
to program when necessary, but I don't want to have to think in programming
mode all the time.
|> I really enjoy TADS for its flexibility and pseudo-C code. I don't have to
|> learn a new language to use it.
Well, seems to me that Tads is sufficiently un-C-like that you *do* have to
learn a new language to use it. I suppose it depends on how many languages
you've had prior exposure to. If you've only ever seen C before, it would
be easier to get into Tads than, say, AdvSys. Lisp, vice versa. Cobol
would prepare you for Alan, etc.
If you're like me and you've used every language ever invented, it won't
matter much.
But all this is largely irrelevant. I want to design a language for writing
adventures, without any bias towards existing programming languages.
The language should be designed for its purpose.
|> Also, sound. Support sound as much as will port from machine to machine.
Which is probably none :-(. Reasonable idea, though.
|> Make a gif-title loader that can be easily ported from machine to machine.
This too. Things to file away for later - not really fundamental.
|> And finally, don't muck around with
|> too many verification calls. Let the user put it into the verb or what have
|> you.
The idea of separating them is so that *all* the verification is done before
*any* of the actions occur. It seems to be a good design to me. I don't much
like the way it's implemented it Tads, either, but that doesn't mean it's
a bad idea. In Alan you say things like:
VERB take DOES
CHECK object IS NOT hot
ELSE "It's so hot that you drop it."
DOES
LOCATE object IN inventory.
which seems perfectly clear and straightforward to me. Would you like to
see it done differently? I'm open to suggestions.
|> *=== whiz...@uclink.berkeley.edu ===*
Greg Ewing
Baggett) writes:
|> TADS could be better in this regard, but is nevertheless quite adequate.
The whole idea behind this project is to make it *more* than just
"adequate". So, how could Tads do it better?
|> Many people find flaws in adv.t and fault TADS. [...]
|> The point is that adv.t could be rewritten to handle all sorts of
|> funtionality.
I know, and I agree that this is a desirable ability to have.
|> In the 16 years I've been programming I don't think I've ever seen better
|> documented code than adv.t,
Okay, perhaps that comment was too harsh. If you just want to use the
existing classes, or make simple extensions of them, the comments in
adv.t are quite adequate.
But if you want to customise anything more extensively, you find yourself
becoming concerned not just with *what* things do, but *how* they work.
At this point, depending on how well the class library has been designed,
things can become very difficult.
One of the main problems is that in Tads there is no clear distinction
between the public interface of the library and internals that you're
not supposed to mess about with. If you want to override a particular
behaviour, often there are several ways of going about it, but some of
them will cause undesirable side effects, and there's no easy way of
deciding which is the "right" way.
Making non-trivial extensions to the Tads library thus becomes a very
stressful activity, because you never know whether what you're doing
is going to cause something else to break. And if you're brave
enough to include someone else's extension...
I've encountered the same problem with every object-oriented system
I've used. The fact is, designing a class library for flexibility
and extensibility, and doing it well, is HARD!!!!! (Did I emphasise
that enough?) It is definitely not something you learn to do in an
afternoon. And you have to document not just how to use it, but
how to extend and modify it.
The point is, if you are going to rely on a class library to embody
the bulk of your default behaviour, you need to put as much care and
thought into its design as if you were building it into the language
itself. Saying "Oh, well, it's just a library, so if you don't
like it you can change it" is Not Good Enough.
|> Dave Baggett
|> __
|> d...@ai.mit.edu Boot up, log in, drop out. MIT
AI Lab
|> ADVENTIONS: We make Kuul text adventures! Ask about Unnkulian 1, 2, 0, 1/2
|> PO Box 851 Columbia, MD 21044 USA / CIS: 76440,2671 / GEnie: ADVENTIONS
Greg Ewing, Computer Science Dept, +--------------------------------------+
Neil K. Guy
> Flexibility and extensibility is important; however, from what I've seen of
>TADS, it relies far too much on library support to implement even the most
>basic of IF concepts. This is a disadvantage, IMHO, not so much because it
>requires a large library to run, but because it forces programmers to extend
>that library on a frequent basis in order to achieve what they want. Witness
>the continual stream of TADS related articles for improving on the standard
>library.
Personally, I think this is one of the strengths of TADS! TADS ships
with a pretty basic set of useful features, to which you can add your
own stuff if you want. Or, if you can't be bothered, you don't have
to. I enjoy having the choice. After all, who decides what's important
in a game and what isn't? Ultimately I think it should be the author
of the game, not the developer of the system upon which the game is
built. Besides, how can the developer possibly imagine all the useful
things that might be included in a game?
As for this "continual stream of TADS-related articles," I think this
is good too. TADS was written by one person, not a huge company. Mike
Roberts can't possibly implement everything for everyone, and what
better source of ingenious ideas than the Internet?
> In comparison, Alan has quite a good range of inbuilt features, but as you
>say it is too inflexible to be generally useful. As I see it, there is a great
>need for an IF language that can provide a balance between in-built features
>and extensibility.
Perhaps. I've never used ALAN - I've only gone through the
documentation. But it seems to me I'd very much prefer a sound
platform I can build on rather than wanting everything in a box. It'd
have to be a pretty big box to satisfy everyone. For example, some
people like writing hack and slash adventure games. I don't. I'd
rather have extensive code that permits the player to use telephones
and ride trains. What adventure system will have all three features?
For me, customizability of *everything* is very important.
> e.g. pour some water from the bucket into the sink.
> write my name in the book using the pencil.
This would be neat! It would require a fair bit of work, but I think
it would be interesting. Whether it's worth the work or not I don't
know - I find writing i-f a very time-consuming laborious activity.
- Neil K. (n_k...@sfu.ca)
Gerry Kevin Wilson
ftp site right now. The maintainer of the site (ftp.gmd.de) is currently
swamped with files, and says he will get to it when he has the time. You've
all seen my posts about it already, so I won't repeat it. Also, the water
item can be extended to any item that needs multiple copies done. (But I
think only in containers, all clumped in inventory would probably play silly
buggers with the object disambiguation. Enjoy when it gets there, report
bugs to me. I playtested for several hours on it, playing with various items
that float and sink, so it shouldn't (underline that) have any bugs. (insert
sounds of veteran IF writers howling with laughter)
Bob Newell
machine.
>
>Which is probably none :-(. Reasonable idea, though.
sound package for TADS for the Mac (HEAR.cpt) and I wrote one for the IBM PC
(MUSIC.Zip). Both are at ftp.gmd.de, but my point is that if there were to
be some sort of standard TADS invocation of sound functions at least they
could be coded and released on a machine by machine basis. In MUSIC.ZIP I
used a system very much like the Basic 'play' statement. Not that the
routines were particularly great but I wanted to at least get something
going.
Jorn Barger
what Phil G. is after. What I want is to kick CYC's butt by accumulating a
database of simple human story-plots, entirely by extending current object
hierarchies and verb-sets.
Here's the sort of objects I want (this list will be familiar to most):
element
motive
hunger
safety
sex
esteem
family
self-expression
thing
food
tool
container
vehicle
clothing
weapon
bodypart
waste
place
inside
home
livingroom
kitchen (etc)
school
office
outside
yard
street (etc)
person
gender
age
species
role?
modality
emotion
belief
etc
Here's the basic two-element verbs:
person thing: makes acquires uses maintains destroys disposes
person place: bornAt movesTo occupies movesFrom diesAt
person motive: suffers gratifies indulges abstains denies
relationship relationship: causes enables precedes becomes
person relationship (ie modality): imagines wants believes fears believes-
deserves
person person (usually with a 3rd element): begets kinTo marries harms
helps conflictsWith cooperatesWith communicatesWith hasStatusOver
motive motive: tradeoff exchange conflict substitute
thing thing: hasPart attachedTo
person skill: discovers learns practices uses forgets
The database would have stories built by chaining these:
person suffers hunger
then
person eats food
then
person gratifies hunger
person eats bad-food
then
person suffers health-motive [??? needs work]
person eats poison
then
person dies
I'd like to see an adventure-language that allows these stories to
be written in language as close to this level of simplicity as
possible. I think a lot of the complications of planning, etc,
can be broken out separately from these.
(And I'd like the sourcecode to be jointly developed and freely
distributed-- we have enough enthusiasm going, I'm thinking, to
take on such a project?)
jorn
David Baggett
>|> TADS could be better in this regard, but is nevertheless quite adequate.
>
>The whole idea behind this project is to make it *more* than just
>"adequate". So, how could Tads do it better?
OK, that's true. I guess my feeling is that I would rather retain 95% of
TADS and enhance (perhaps through redesign of the language itself) the 5%
that I think needs work. This argues against designing a new language.
But, hey, that's *me*. For you (and 4 billion other people, as far as we
know) TADS might not be on the right wavelength. By all means, work on new
designs. I just think that leaving out extensibilty would be a mistake.
That said, here are some things I'd like to see addressed in TADS 3, or in
a completely new TADS-like system:
- programmer-extensible parsing:
It would be nice if you could make your own rules for
specifying how command line parses turned into object
calls. The current TADS (verDo, verIo, do, io) system
would just be part of adv.t. But you could also handle
other things like multiple prepositions, special question
forms, etc. Any context-free grammar can be parsed in
O(n^3) using a standard (Earley) algorithm, so there's
no fundamental technical problem here. (Didn't say it
would be *easy* though.)
- more classes:
Standard classes for things like liquids and liquid-holders,
inter-room connections like doors and windows should be added
or made more natural.
- higher-level algorithms:
Planning. Shortest path computation. Inference computation.
All these would go into better NPC classes.
There are surely other things, but these are the main things I end up
spending lots of time dealing with (or just wishing I had) in practice.
>But if you want to customise anything more extensively, you find yourself
>becoming concerned not just with *what* things do, but *how* they work.
>At this point, depending on how well the class library has been designed,
>things can become very difficult.
I see your point, and the same thing applies to my earlier example, emacs.
It's true that massive extensibility can make the code hard to follow. The
TADS manual does tell you what all the common methods are, but when you
want to override low-level things like roomDrop you do have to be careful.
>The fact is, designing a class library for flexibility and extensibility,
>and doing it well, is HARD!!!!!
Agreed. But that said, I'm actually surprised at how few class modules
have been written for TADS. Seems like everyone rolls their own stuff but
few people release their code.
Matt Ackeret
Greg Ewing <gr...@huia.canterbury.ac.nz> wrote:
>In article <2bpjfd$6...@agate.berkeley.edu>, whiz...@uclink.berkeley.edu
>(Gerry Kevin Wilson) writes:
>|> Also, sound. Support sound as much as will port from machine to machine.
>Which is probably none :-(. Reasonable idea, though.
Not really. Especially if you deal with "raw" digitized sounds, those
can be played on basically any machine on earth, whether it has dedicated sound
hardware or not.
So providing a certain API that porters to each platform could follow
to play digitized sounds (and a callback when the sound was finished, for
example) would be very easy. That seemed to be the approach in ADVSYS1.3
(though I've never seen a game that actually USED that "improved" version).
Even for limited songs/melodies, with only a few notes at a time..
That is, even that can be done on most platforms. (I don't know the musical
term, but you know how with a song there is a basic set of notes you can play
to distinguish the song, but the "real" version has multiple instruments
simultaneously, etc). maybe 4 notes simultaneously would be a good limit for
most people. I can handle up to 16, but especially if that had to be
synthesized on computers w/out sound hardware, it wouldn't be worth it.
--
unk...@apple.com Apple II Forever
unk...@ucscb.ucsc.edu These opinions are mine, not Apple's.
Hans Persson
>In the 16 years I've been programming I don't think I've ever seen better
>documented code than adv.t, except perhaps for Knuth's TeX and Metafont
>source (which were published as books). There are more comments than
>source lines in adv.t! Even without the manual you can figure out what's
>going on.
>Furthermore, I think the TADS manual is really good. There are BUGS in
>adv.t that cause problems (try "remove x-ray specs" instead of "take off
>specs" in UU2), but I don't really see how most of the classes could be any
>*better* documented.
Well, yes and no. When we started to write Enhanced we had a copy of
TADS 2.1 and hadn't registered since we didn't at that point know if
it was any good. We learnt most of the features of the languages by
looking through how things were done in adv.t (and ditch.t, the sample
game that is included in the package). In this respect, the
documentation is very good since you can learn all the basics without
even looking in the manual. The problem is that if you try to do a
little more complicated stuff, there is suddenly no documentation at
all. The more basic something is, the less it seems to be supposed to
be modified or even understood by the user and it gets progressively
less documentation. I have mucked around quite a bit with the handling
of light/dark and what is reachable or not and the documentation of
those things leave things to be wished for -- not only in adv.t but
also in the manual.
An irritation at this point is that the latest version of TADS I have
found have had something very weird done to the comments in adv.t
rendering them almost unreadable. I suppose that they are marked up so
that they will print nicer but on my screen they look so bad that I
don't bother with them but read the code instead.
/ Hans
--
+----------------------------------------------------------------------------+
! Hans Persson / The Pink Unicorn SophistiChaos Game Design !
! uni...@lysator.liu.se, d88h...@und.ida.liu.se !
+----------------------------------------------------------------------------+
Hans Persson
>- programmer-extensible parsing:
>
> It would be nice if you could make your own rules for
> specifying how command line parses turned into object
> calls. The current TADS (verDo, verIo, do, io) system
> would just be part of adv.t. But you could also handle
> other things like multiple prepositions, special question
> forms, etc. Any context-free grammar can be parsed in
> O(n^3) using a standard (Earley) algorithm, so there's
> no fundamental technical problem here. (Didn't say it
> would be *easy* though.)
Yes!
>- more classes:
>
> Standard classes for things like liquids and liquid-holders,
> inter-room connections like doors and windows should be added
> or made more natural.
A simple vehicle item that can actually be moved in some standard way
for instance.
>- higher-level algorithms:
>
> Planning. Shortest path computation. Inference computation.
> All these would go into better NPC classes.
Yes, something like walk randomly in these rooms would for instance be
nice.
At the moment, though, what I'd like the most is a way to refer to one
of several identical objects.
>Agreed. But that said, I'm actually surprised at how few class modules
>have been written for TADS. Seems like everyone rolls their own stuff but
>few people release their code.
Set a good example. Release more code! :-)
Greg Ewing
Baggett) writes:
|> By all means, work on new
|> designs. I just think that leaving out extensibilty would be a mistake.
Agreed! Many people seem to have got the impression that I am
considering a non-extensible system.
To make myself clearer: I agree that extensibility and
customisability are very desirable, even vital.
But I don't want to lose those things about Alan which makes
it an adventure language, and not just an adventure library.
Somehow I want to steer a middle course between them.
|> - programmer-extensible parsing:
I have two mutually incompatible views in this area. If you
think that the player input language should be a natural-language
interface, then it makes sense to have the parser as flexible
as possible.
However, I'm not convinced that elaborate input languages are
a good idea, since they can lead to frustrating guess-the-verb
type puzzles. So the other half of my brain favours keeping the
parser as simple as possible, and not even assuming that there
will be a parser at all - a version of the run-time system
might present a menu-oriented interface instead, for example.
What do other people think?
|> Agreed. But that said, I'm actually surprised at how few class modules
|> have been written for TADS. Seems like everyone rolls their own stuff but
|> few people release their code.
Probably because most home-grown code is built to do the job at
hand, and isn't flexible or robust enough to be generally useful.
Another reason could be that the lack of documentation of adv.t
internals makes it impossible to write an extension with any
confidence that it won't break with the next release of Tads.
This seems to be a very serious problem which would severely
discourage anyone putting in the considerable effort needed
to create a general and useful extension.
|>
|> Dave Baggett
|> __
|> d...@ai.mit.edu Boot up, log in, drop out. MIT
AI Lab
Greg Ewing, Computer Science Dept, +--------------------------------------+
Neil K. Guy
>d...@min.ai.mit.edu (David Baggett) writes:
>>Agreed. But that said, I'm actually surprised at how few class modules
>>have been written for TADS. Seems like everyone rolls their own stuff but
>>few people release their code.
>Set a good example. Release more code! :-)
This is an important point, I think. I helped set up the TADS
examples directory on ftp.gmd.de (if-archive/programming/tads/examples)
because I think it's useful to have access to source code, and I think
it'd be great if everyone released their stuff!
However at the same time I know I've written *tons* of stuff for my
unfinished game that I probably won't put in there. Partly because
some of it isn't brilliant code, but mainly because I'd kinda like to
feel I have something in my game that everyone else hasn't. :) I mean,
I'm not too worried about competition per se - this is shareware we're
talking about - but it's a nice smug feeling to know that other people
don't have what you do.
Hmmm.. Well, I'll add some more stuff to the examples directory when
I get around to it, maybe. :)
- Neil K. (n_k...@sfu.ca)
Mike Roberts
> An irritation at this point is that the latest version of TADS I have
> found have had something very weird done to the comments in adv.t
> rendering them almost unreadable. I suppose that they are marked up so
> that they will print nicer but on my screen they look so bad that I
> don't bother with them but read the code instead.
Sorry about this - I made an error in building the latest release and
put the wrong version of adv.t in the archive. The weird formatting
codes are my own internal system that lets me build the printed adv.t
documentation from the same sources as the comments. I somehow managed
to put the "source" version of adv.t into the release, rather than the
filtered version with the formatting codes removed. I'm planning another
release in the near future to correct this problem (as well as fix a
number of other bugs).
Mike Roberts mrob...@hinrg.starconn.com
High Energy Software 415 493 2430 (Voice)
PO Box 50422, Palo Alto, CA 94303 415 493 2420 (BBS)
Paradise is a place exactly like where you are right now, only
much, much better.
--- Laurie Anderson