[All] I-f language design
Cardinal Teulbachs
relatively minor point when it came to evaluating the various i-f
programming systems--well, that's not *exactly* what he said, but
he'll hopefully forgive me if I've twisted his words slightly for the
sake of my article. I'm curious what others have to say about this
question in particular, and mostly what a) those who have never
programmed before, and b) those with some programming experience but
no experience in i-f authorship, have to say.
Since such a vague category as "ease of use" lends itself to many
interpretations, however, I'll go ahead and narrow it down slightly by
giving the original context of the remark. The question was whether,
in the end, a relatively simple and uncluttered syntax ("syntax" here
meaning mostly the punctuation marks required/not required by various
compilers) amounted to much of a selling point for an i-f language. My
answer was that it's probably no selling point at all to one who has
already mastered a syntactically complicated language, since that
person already knows what all the marks are for and is well-acquainted
with their typical usages, but for the newcomer it must surely flatten
the learning curve and present a somewhat friendlier and more
"familiar" face. I said also that I thought it had to be of real,
practical benefit in terms of game-writing, inasmuch as it frees up
the programmer's mind to concentrate on matters of substance in his or
her code instead of constantly having to worry over the punctuational
demands of the compiler (not to mention the time-savings it delivers
in not having all those aggravating rebuilds caused by misplaced
semicolons and whatnot).
What do you think? Is this a big deal or no? The comments of all are
welcome, but I'm particularly interested in hearing from the
"wannabes" lurking out there who've said in the past they're too
intimidated by all the high-falutin' talk and complicated programming
exercises displayed 'round these parts to take the plunge into i-f
writing. Do easier languages hold more actual or potential attraction
for you than difficult ones? Are you of the opinion or the impression
that a language must be complicated and "mysterious" in order to be
powerful? (And for you programming wizards, this one: *does* a
language have to be complicated and mysterious in order to be
powerful?) Inquiring minds would like to know.
P.S. This is not a "Which particular language is better than which
other particular language" question. It's intended to be more general
than that.
Thanks
--Cardinal T
I mean, what the hell kind of villain thwarts the hero's
progress with soup cans in the kitchen pantry?
--Russ Bryan
Gerry Kevin Wilson
Ok, what do I like in a an I-F language? I like as little 'code' between
the text that the player sees as possible. Thus this:
Katmandu: Room
ldesc = "This is Katmandu. Cats everywhere. What a smell!"
sdesc = "Katmandu"
north = Xanadu
south = Oz
east = Shangri-La
;
Is better than this:
"Katmandu":Room
{
long_description = "This is Katmandu. Cats everywhere. What a smell!"
short_description = "Katmandu"
north_exit = "Xanadu"
south_exit = "Oz"
east_exit = "Shangri-La"
}
The first is TADS, and the second is a really annoying syntax I just made up.
Of course, taking this idea to its loghical extremes, I'd like to see:
"Katmandu": Room
ld "This is Katmandu. Cats everywhere. What a smell!"
/*No sd, instead it looks at the programming object's name for that as a
default unless you explicitly define sd here. */
n Xanadu
s Oz
e Shangri-La
"Aunt's Thing": Thingy
etc.
/* Note that there is no seperating syntax there, it just realizes that
Aunt's Thing is the header for a new object and closes off Katmandu
automagically. */
Really key to ease of use is elimination of as much syntax as possible.
Use white space instead of ;'s or :'s if it's possible. Make things
serve double purposes where it is logical, while still allowing the
secondary functions to be overridden easily, like with the object name
and sd above. Only require "s around words when it is unclear how they
should be grouped. Never require use of both "s and a ; to seperate two
lines. These two devices are redundant. Use short property names, or
allow the author to easily redefine the names of the properties.
Of course, there are problems with doing the above. Properties would
have to have one-word descriptions, or else they'd need the old = back in
there again, so allow either syntax.
I think that the closer a screen of code looks to the same screen of the
finished game, the happier I am.
There's alot to be said for programming shells too. Hit F1 and it types
out the barebones stuff for a room, F2 does an item, etc. It can keep
what syntax you do have straight for the author, such as having {}s the
same color or indenting them to the right place for the author.
The single greatest thing any shell can do for a programmer is give him
multiple windows to play with. Without the shell I use and its four
windows, I'd be lost trying to program.
And GUI's, well, they're a whole new ballgame, that I won't get into.
So that's the result of about 5 minutes of thought. Sloppy, perhaps, but
mostly sound.
--
<~V~E~SOF~~~~~~~~~~~AVALON~~~~~~~~DUE~DURING~THE~20TH~CENTURY~~~~~~~~|~~~~~~~>
< RTI T Into the afterlife, with dogtag and helmet. Frank | ~~\ >
< G O WAR E Leandro is lost in a world of magic, love, and adventure.| /~\ | >
<_______________________...@uclink.berkeley.edu__|_\__/__>
Kathleen Fischer
>Do easier languages hold more actual or potential attraction
>for you than difficult ones? Are you of the opinion or the impression
>that a language must be complicated and "mysterious" in order to be
>powerful? (And for you programming wizards, this one: *does* a
>language have to be complicated and mysterious in order to be
>powerful?) Inquiring minds would like to know.
Well, I certainly qualify as a newbie who has tried in the past and failed...
mostly because I always started by trying to write my own engine first (NOT the
best way to get started, IMHO.)
A programmer by trade, I would have to say that I don't care too much if its
compilicated so long as its well documented AND that complication buys me
something. If its compilicated because the original programmer was lazy then I
wouldn't be happy, but if its complicated because they wanted to allow me to do
'X' and 'X' wasn't an easy thing to add then, that's life... and I except that.
In fact, I might CHOOSE a more complicated system over a simple one for that
very reason... after all, even *I* managed to get my programs to parse
sentances into Verb [Noun] [Prep] [Noun] and could pick up, drop, and examine
stuff. I was able to read in input from a file and code my room/object
descriptions there. I switched to [CENSORED as requested by the original
poster] system because the details were killing me. I was spending to much
time programming and not enough writing... anyway...
That said, programming should NEVER be mysterious. If I have to walk around my
chair three times, ring a bell, and chant the hungarian national anthem before
I hit the compile button then I would definitly CONSIDER moving to a more
rational system. (Unless that causes a gene to appear and automatically fix all
my syntax errors for me!) :)
I guess that means I don't mind compilicated so long as its documented,
logical, consistant in form and function, and it buys me something that I want.
Just my $0.02
Kathleen
--
// Kathleen Fischer
// kfis...@greenhouse.llnl.gov
// *** "Don't stop to stomp ants while the elephants are stampeding" ***
Roger Giner-Sorolla
I guess I'm just spoiled when it comes to designing text-VR environments.
I'm used to using Pavel Curtis' Lambdacore code, an object-oriented
programming language for multiuser environments. As a "builder" on
LambdaMOO (telnet://lambda.xerox.com:8888 ... and say hi to "Trism" when
you get there) I can start in an existing room, type "@dig east to
<NewRoomName>" and have a functional exit named "east,e" that leads to the
new room.
Once in the new room, I can dig a reciprocal exit back to the
old one, and input the room's basic description by typing "@describe here
as "A brand spanking new room."" I can also take advantage of other
programmers' labors by changing the parent of the room to a generic
room type that allows me to input "details" (room scenery that can only be
looked at), seats with customized sit-down and get-up messages, special
messages for different times of the day ... all by typing in single
commands at the prompt. There's no need to compile; any change you make
is reflected right away in the running environment. Beyond the basic
tinyscenery, objects and locations can be enhanced with programmable "verbs"
that respond to parsed input. One of my early objects, a wand, responded
to "zap <person> with wand" by displaying, to everyone in the room, a
random practical joke with the victim's and user's names inserted
appropriately.
Being used to this environment, just looking at Inform gave me an
enormous headache. I'm not normally a programmer, and I don't know C that
well, but I can write fairly sophisticated verbs in MOO code. Maybe I'll
come back to Inform someday... I would like to add my voice to those
calling for a simpler "front-end" so the writing of rooms, scenery, and
commonplace features can be more or less automated. Ideally, I'd like to
write an adventure game on a MOO (about the closest I came was
programming the complicated approach-route to my room on DhalgrenMOO,
telnet://dhalgren.english.uwashington.edu 7777; log on as a guest, cross
the bridge, and go south to Dockside, where crossing the channel is your
first task...), but most MOO's limit the amount of database space your
creations can occupy to well below the minimum for an acceptable game.
Roger Giner-Sorolla New York University gi...@xp.psych.nyu.edu
~~~~~~~~~~~~~~~~~~~ Department of Psychology ~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Sur l'oreiller du mal c'est Satan Trismegiste
qui berce longuement notre esprit enchante' ..." -- Baudelaire
Gareth Rees
> I like as little 'code' between the text that the player sees as
> possible.
These debates about the syntax of IF languages and whether template, GUI
or form-filling interfaces would be a good thing seem rather beside the
point to me.
If you browse among the sources to real games in Inform (but these
remarks are true of games in TADS as well), for example in the directory
<ftp://ftp.gmd.de/if-archive/games/source/inform/>, you'll see that
form-filling, or minimal syntax, is relevant to only a tiny portion of
the code, and that the least interesting part.
--
Gareth Rees
Palmer T. Davis
>(And for you programming wizards, this one: *does* a
>language have to be complicated and mysterious in order to be
>powerful?) Inquiring minds would like to know.
It could be argued that the opposite relation holds.
--
Palmer Davis ___
<p...@ptd.org> \X/ Vivo simpligxus se oni povus legi la fontan kodon....
Nulldogma
>or form-filling interfaces would be a good thing seem rather beside the
>point to me.
>
>If you browse among the sources to real games in Inform (but these
>remarks are true of games in TADS as well), for example in the directory
><ftp://ftp.gmd.de/if-archive/games/source/inform/>, you'll see that
>form-filling, or minimal syntax, is relevant to only a tiny portion of
>the code, and that the least interesting part.
But the most tedious, precisely *because* the least interesting. And, more
importantly, the part that new I-F programmers invariably start with, and
so the part that's most important to make user-friendly.
You still need to have a powerful and well-documented language for doing
the more complicated things, of course. (In my short time at LambdaMOO, I
was able to make all kinds of simple objects with the kinds of commands
Roger mentioned, but I could never figure out how to make it do anything
complicated.) But a simpler way of doing the simpler stuff could only be a
good thing.
Neil
Nulldogma
BASIC nearly 15 years ago) until I started writing a game in TADS, I'd say
ease-of-use is incredibly important. There were several times I almost
gave up trying to learn TADS because of all the compile errors I was
getting from misplaced semicolons and the like.
I'd also like to say that I use TADS rather than Inform because I find it
more intuitive to use, but it's probably just because I found TADS first.
Neil
Matthew Amster-Burton
be quoted in your sig.
card...@earthlink.net (Cardinal Teulbachs) wrote:
>(And for you programming wizards, this one: *does* a
>language have to be complicated and mysterious in order to be
>powerful?) Inquiring minds would like to know.
It has to have some level of complexity. I'd be exceedingly
frustrated writing IF in a language that didn't have the basic
conditional and loop constructs (while, if/then, etc.). Writing a
text game *is* software development, like it or not. (I believe
someone recently quoted an Infocomer as saying that writing IF is like
writing a spreadsheet--I agree.)
Nevertheless, I don't know that the tools have to be as thick as they
are today. I'm perfectly happy with TADS, but I was already
well-versed in C++ when I picked it up. Lately I've been playing
around with Visual Basic, which makes Windows programming--usually a
complex and boring task--easy and fun. Sure, you sacrifice some speed
and power, but for almost all tasks, it's worth it to avoid having to
deal with "int _PASCAL_ *hWnd..." and all that.
I'd really like to see technology like Visual Basic's applied to IF.
I realize I should write it myself, but who has time? Anyone working
on a CS thesis?
Matthew
bl...@ibm.net
>Someone mentioned recently to me that he thought ease-of-use was a
>relatively minor point when it came to evaluating the various i-f
>programming systems--well, that's not *exactly* what he said, but
>he'll hopefully forgive me if I've twisted his words slightly for the
>sake of my article. I'm curious what others have to say about this
>question in particular, and mostly what a) those who have never
>programmed before, and b) those with some programming experience but
>no experience in i-f authorship, have to say.
>
Okay, I'm in category b, but I don't know how typical my situation is. My
stumbling block is more in game design that programming.
>Since such a vague category as "ease of use" lends itself to many
>interpretations, however, I'll go ahead and narrow it down slightly by
>giving the original context of the remark. The question was whether,
>in the end, a relatively simple and uncluttered syntax ("syntax" here
>meaning mostly the punctuation marks required/not required by various
>compilers) amounted to much of a selling point for an i-f language.
>
Strictly speaking, syntax is a lot more than just punctuation. COBOL has a
pretty complex syntax, but the only punctuation you ever need in a COBOL
program are periods, parentheses and the occasional colon.
>What do you think? Is this a big deal or no? The comments of all are
>welcome, but I'm particularly interested in hearing from the
>"wannabes" lurking out there who've said in the past they're too
>intimidated by all the high-falutin' talk and complicated programming
>exercises displayed 'round these parts to take the plunge into i-f
>writing. Do easier languages hold more actual or potential attraction
>for you than difficult ones? Are you of the opinion or the impression
>that a language must be complicated and "mysterious" in order to be
>powerful? (And for you programming wizards, this one: *does* a
>language have to be complicated and mysterious in order to be
>powerful?) Inquiring minds would like to know.
>
It doesn't *have* to be. There's a well-known theorem in computer science
which demonstrates that the only constructs a language needs to provide are
arithmetic operators*, IF, and GOTO. Of course, even assembly language has a
richer syntax than that, and you don't see a lot of people writing i.f. in assembler.
In general, the more complex the syntax is, the less source code you'll have to
write, and the easier it will be. Lisp is a really powerful language with a very
simple syntax, but it's hard to learn and use because you constantly have to
break down your ideas to such a basic level.
*really, all you need are bitwise AND, OR and NOT**
**which can all be implemented with a single operator: NAND
======
Steven Howard
bl...@ibm.net
Magnus Olsson
Palmer T. Davis <pt...@po.CWRU.Edu> wrote:
>
>>(And for you programming wizards, this one: *does* a
>>language have to be complicated and mysterious in order to be
>>powerful?) Inquiring minds would like to know.
>
Of course, it depends on whether you use "complicated and mysterious"
to refer to the syntax or the semantics of the language.
The prime example of a language that's syntactically extremely simple,
but also extremely powerful, is Lisp. A minimal Lisp could have
basically just the following syntactic rules:
* There are atoms. These are what is called identifiers and literals
in other languages.
* There are lists, consisting of a series of atoms or lists surrounded by
parentheses and separated by whitespace. For example, this is a list of atoms:
(foo bar baz) and this is a list containing other lists:
(cond ((eq x 1) 1) (t (* x (- x 1))))). ('*' and '-' are allowed names
for atoms).
* Lists and atoms can be quoted by putting a sinlge quote in front of
them. This is a quoted list: '(foo bar)
This describes the entire syntax of the language. (Most Lisps have
more complciated syntax to accomodate macros, strings, and so on).
Add a few, simple, semantic rules, that describe how the language
works, and you're rocking. I suppose David Bagget or some other AI
person could tell you lots abotu just how powerful Lisp is, despite
its simplicity.
--
Magnus Olsson (m...@df.lth.se)
John Baker
(Cardinal Teulbachs) writes:
>Since such a vague category as "ease of use" lends itself to many
>interpretations, however, I'll go ahead and narrow it down slightly by
>giving the original context of the remark. The question was whether,
>in the end, a relatively simple and uncluttered syntax ("syntax" here
>meaning mostly the punctuation marks required/not required by various
>answer was that it's probably no selling point at all to one who has
>already mastered a syntactically complicated language, since that
>person already knows what all the marks are for and is well-acquainted
>with their typical usages, but for the newcomer it must surely flatten
>the learning curve and present a somewhat friendlier and more
>"familiar" face. I said also that I thought it had to be of real,
>practical benefit in terms of game-writing, inasmuch as it frees up
>the programmer's mind to concentrate on matters of substance in his or
>her code instead of constantly having to worry over the punctuational
>demands of the compiler (not to mention the time-savings it delivers
>in not having all those aggravating rebuilds caused by misplaced
>semicolons and whatnot).
Semantics are more important than syntax, and if you've mastered a
syntactically complicated language, an easier one shouldn't present you
with any difficulty whatsoever. It may cost you a few days up front,
and then save you many times that over the life of a 2 month project.
If you're a newcomer to programming, it makes sense to learn an easier
language first - especially if it's designed for the task at hand. As
you said.
If you've been programming a long time in several different lanuages,
you *know* the importance of choosing the right tool for the project
regardless of your familiarity with it. I wrote JFW for the express
purpose of teaching myself TADS, and I can tell you right now that it
would still be unfinished if I had been using C. (I knew/know C well
enough to do projects as a contract consultant, BTW)
If you're in the middle and know 1 language well, you're probably
completely enamored with it. "I can do *anything* with this." You're
right, but you don't have the experience mentioned above yet. Using
the right tool will still save you a huge amount of time. You'll pay a
little more up-front cost than someone who habitually learns new
langauges, but you will *still* save time over the life of the project.
Not to mention the fact that you'll be gaining insight that you didn't
have before.
--
John Baker
"What the hell does that mean? Huh? 'China is here.'?
I don't even know what the hell that means!"
- Jack Burton
John Baker
Kevin Wilson) writes:
>Of course, taking this idea to its loghical extremes, I'd like to see:
>
>"Katmandu": Room
> ld "This is Katmandu. Cats everywhere. What a smell!"
> /*No sd, instead it looks at the programming object's name for that
> as a default unless you explicitly define sd here. */
> n Xanadu
> s Oz
> e Shangri-La
>
>"Aunt's Thing": Thingy
> etc.
>/* Note that there is no seperating syntax there, it just realizes
> that Aunt's Thing is the header for a new object and closes off
> Katmandu automagically. */
>
IMO, too much contraction of either syntax or variable names makes code
look confusing and turns it into a maintenance nightmare.
I once was forced to take over a dBase for DOS project (bad enough
already) where the programmer had used all the contractions instead of
the full command names. Mustering all the will power I had, I didn't
hunt her down and kill her.
Cardinal Teulbachs
>Well, I certainly qualify as a newbie who has tried in the past and failed...
>mostly because I always started by trying to write my own engine first (NOT the
>best way to get started, IMHO.)
Agreed, although I think the impulse must be pretty much universal.
I've certainly had dreams along the same line--the difference being
that I simply don't have the ability to even begin to write my own
engine.
>A programmer by trade, I would have to say that I don't care too much if its
>compilicated so long as its well documented AND that complication buys me
>something. If its compilicated because the original programmer was lazy then I
>wouldn't be happy, but if its complicated because they wanted to allow me to do
>'X' and 'X' wasn't an easy thing to add then, that's life... and I except that.
>In fact, I might CHOOSE a more complicated system over a simple one for that
>very reason...
My feeling as well. Isn't it true, though, that given the choice
between two equally powerful systems (accept complete parity here for
the sake of argument), one of which lacked a picky syntax and the
other of which demanded it, you'd choose the one with the easier
syntax? I think I would, all other things being equal.
>after all, even *I* managed to get my programs to parse
>sentances into Verb [Noun] [Prep] [Noun] and could pick up, drop, and examine
>stuff. I was able to read in input from a file and code my room/object
>descriptions there. I switched to [CENSORED as requested by the original
>poster] system because the details were killing me. I was spending to much
>time programming and not enough writing... anyway...
Yep, the devil's in the details. You've got to design for them from
the outset, it seems to me, or you end up with a really sloppy and
(probably) unworkable system. But to do that means setting aside any
hope of actually writing a game for awhile, as the language design
requires a full-time effort and it would be pretty hard to write in an
environment where the rules are constantly changing, anyway.
>That said, programming should NEVER be mysterious. If I have to walk around my
>chair three times, ring a bell, and chant the hungarian national anthem before
>I hit the compile button then I would definitly CONSIDER moving to a more
>rational system. (Unless that causes a gene to appear and automatically fix all
>my syntax errors for me!) :)
Agreed that programming shouldn't be mysterious. A further question,
then, is "how much mysterious is too much mysterious?" Is there any
kind of threshold beyond which you would simply refuse to go? Don't
sweat it if you can't answer; it's a difficult question that probably
doesn't admit of any kind of absolute, all-encompassing response.
>I guess that means I don't mind compilicated so long as its documented,
>logical, consistant in form and function, and it buys me something that I want.
The bottom-line answer. Thanks.
>Just my $0.02
Gratefully accepted.
--Cardinal T
I mean, what the hell kind of villain thwarts the hero's
progress with soup cans in the kitchen pantry?
--Russ Bryan
Cardinal, I follow up your post in the hopes that some
day I too will be quoted in your sig.
--Matthew Amster-Burton
Cardinal Teulbachs
>Cardinal, I followup your post in the hopes that some day I too will
>be quoted in your sig.
As it is written, so shall it be done.
>It has to have some level of complexity. I'd be exceedingly
>frustrated writing IF in a language that didn't have the basic
>conditional and loop constructs (while, if/then, etc.). Writing a
>text game *is* software development, like it or not. (I believe
>someone recently quoted an Infocomer as saying that writing IF is like
>writing a spreadsheet--I agree.)
Me, too. I'd never suggest that an i-f language do away with
functionality in favor of simplicity. What I was really asking was how
you would view a highly functional language that was fairly complex
vs. one that was relatively simple, the answer to which I believe you
give in the next snippet.
>Nevertheless, I don't know that the tools have to be as thick as they
>are today. I'm perfectly happy with TADS, but I was already
>well-versed in C++ when I picked it up.
Ok, thanks for your comments.
>Lately I've been playing
>around with Visual Basic, which makes Windows programming--usually a
>complex and boring task--easy and fun. Sure, you sacrifice some speed
>and power, but for almost all tasks, it's worth it to avoid having to
>deal with "int _PASCAL_ *hWnd..." and all that.
Agreed, and although this is slightly off-topic, I'd like to ask: if
you were forced to program for Windows in C++, is the Visual
environment better for you or no? Would the GUI and the browsers and
all that make your task significantly easier, or is such talk just a
lot of hype?
>I'd really like to see technology like Visual Basic's applied to IF.
>I realize I should write it myself, but who has time?
In a crude way, it's been done already, with a product called the
Computer Novel Construction Set.
Den of Iniquity
> Ok, what do I like in a an I-F language?...
[snip]
> There's alot to be said for programming shells too. Hit F1 and it types
> out the barebones stuff for a room, F2 does an item, etc. It can keep
> what syntax you do have straight for the author, such as having {}s the
> same color or indenting them to the right place for the author.
>
> The single greatest thing any shell can do for a programmer is give him
> multiple windows to play with. Without the shell I use and its four
> windows, I'd be lost trying to program.
But you can do this sort of stuff with any decent word processor; even
some freeware text processors allow the user to define long macros and
tab-spacing and multiple windows. At no extra cost I use the same text
processor for Inform programming as I use for writing letters and I have
a set of macros to make easier work of scripting HTML files too.
Just thoughts...
Dennis Smith
Gerry Kevin Wilson
Den of Iniquity <dms...@york.ac.uk> wrote:
>
>But you can do this sort of stuff with any decent word processor; even
>some freeware text processors allow the user to define long macros and
>tab-spacing and multiple windows. At no extra cost I use the same text
>processor for Inform programming as I use for writing letters and I have
>a set of macros to make easier work of scripting HTML files too.
Other useful, more IF slanted things would be to be able to take a file,
and read into memory a list of objects and verbs, then let you go to any
of them by clicking on the name of the object or verb.
I could see a lot of uses for a shell that remembered what I'd done like
that.
--
<~~~VERTIGO~~~~~~~~~~~~~~~~SPAG~~~~NINHTH~ISSUE~DUE~REAL~SOON~NOW~~~~|~~~~~~~>
< The Society for the Preservation of Adventure games. Filled with | ~~\ >
< reviews, ratings, and advertisements...all about text adventures. | /~\ | >
<___SOFTWARE______E-MAIL...@uclink.berkeley.edu__|_\__/__>
Matthew Amster-Burton
> Ok, what do I like in a an I-F language? I like as little 'code' between
> the text that the player sees as possible. Thus this:
[snippets snipped]
Those looked almost exactly the same to me, and would be equally easy to
learn--the second would just require less typing.
> Really key to ease of use is elimination of as much syntax as possible.
> Use white space instead of ;'s or :'s if it's possible. Make things
> serve double purposes where it is logical, while still allowing the
> secondary functions to be overridden easily, like with the object name
> and sd above. Only require "s around words when it is unclear how they
> should be grouped. Never require use of both "s and a ; to seperate two
> lines. These two devices are redundant. Use short property names, or
> allow the author to easily redefine the names of the properties.
I would be *stunned* to find a single "traditional" programmer who agreed
with this. If you could somehow sort out all the time you've spent on
Avalon, how much of that time was spent typing quotes and semicolons? Do
you think it's even 0.1 percent?
Semicolons, quotes, parens, and other grouping tools make compilers better
and code easier to read and maintain. This will save you much more time
than not having to type the damn things would. And if you're worried
about having to type "sdesc" instead of "sd," why not just make yourself a
key macro so you only have to type sd, or hit ctrl-s, or something?
If you're feeling curious, you might check out a
little-known-outside-of-CS system called CWEB
(ftp://labrea.stanford.edu/pub/cweb). Based on a system by programming
legend Donald Knuth, it lets you write your code and documentation
together in one file which can then be transformed into C (or C++ or Java)
for compiling, or TeX source for typesetting. The code, when printed,
literally reads like a book. You end up writing more to start off with,
yet (if you believe the hype, as I do), projects get done faster and are a
snap to return to even years later.
> I think that the closer a screen of code looks to the same screen of the
> finished game, the happier I am.
David Parsley (you still around, Dave?) and others have suggested a system
that is extensible at run-time, so you could add objects, change
descriptions, etc., while playing the game. This is the closest thing my
little brain can imagine to what you're talking about.
A text game has practically infinite game states. If what you mean is
that you want the syntax of the language to be as unobtrusive, I can't
disagree, but many scenes in the game aren't going to appear in one screen
of source code, and that, frankly, is life.
> The single greatest thing any shell can do for a programmer is give him
> multiple windows to play with. Without the shell I use and its four
> windows, I'd be lost trying to program.
This can be helpful, but I find Emacs's windowing annoying. Generally, I
make far more use of text searches than windows. What system do you use
and how does its windowing help you?
Matthew
Allison Weaver
> Gerry Kevin Wilson <whiz...@uclink.berkeley.edu> wrote:
> > I like as little 'code' between the text that the player sees as
> > possible.
>
> If you browse among the sources to real games in Inform (but these
> remarks are true of games in TADS as well), for example in the directory
> <ftp://ftp.gmd.de/if-archive/games/source/inform/>, you'll see that
> form-filling, or minimal syntax, is relevant to only a tiny portion of
> the code, and that the least interesting part.
But the 'form-filling' part allows one to get the least interesting, bare
bones part entered with less worry about ; [ / " ' >> , syntax problems.
It's so frustrating to be on a roll with a new idea, type in pages of new
code, only to be confronted with reams of syntax errors upon compile.
Syntax errors caused by 1) a single error near the top, or worse 2) a
consistent error all the way through. The second one wouldn't be so bad
if it was of the type to respond to a search and replace, but what if you
left out a necessary character? Then you have to search and find each
place that character should have been.
My solution has been to create template files for an object, room, actor,
event, whatever I need in whichever language I'm currently using. Then
each time I need to create a new object (or whatever), I read in the
template of bare bones, and fill in the interesting stuff. This does not
remove the need for remembering if something need to be " ' or not quoted
at all, but it has helped.
Allison
athol-brose
>and read into memory a list of objects and verbs, then let you go to any
>of them by clicking on the name of the object or verb.
Emacs will do this, or, indeed, any editor with a half-decent implementation
of a tag utility. In fact, in my current DOS editor (Semware's TSE), I
can think of a way to do this with one regular expression -- assuming
one source file.
I've been thinking of really teaching TSE what TADS is all
about... but that is time I would rather spend coding my contest
entry. :)
--r.
--
r. n. dominick -- cinn...@one.net -- http://w3.one.net/~cinnamon/
<*> Remember the time I saw a seagull fly out of your lips?
Uncle Bob
:
: Agreed, although I think the impulse must be pretty much universal.
Some years ago when the only game in town was AGT, I too started off by
writing my own engine, and actually completed it. It was syntactically
very simple... and as I soon found, not powerful enough. So I added to
it, one feature at a time... eventually it became _not_ syntactically
very simple at all, and although it was reasonably powerful in most
respects, it did have one failing, which was the language parser. It
wasn't a matter of a bad parser, it was a matter of _no_ parser. Isn't
myopia wonderful?
There are two morals to the story:
1. Don't reinvent the wheel.
2. If you really have to reinvent the wheel, study previous wheels first.
Bob N.
John Holder
bl...@ibm.net mentioned in rec.arts.int-fiction that::
> **which can all be implemented with a single operator: NAND
You may find a <jump on less-than> control flow command useful, as well.
Those two form the minimum machine.
--
John Holder (jho...@nmsu.edu) http://speedracer.nmsu.edu/~jholder/
"Anyone who considers arithmetical methods of producing random
digits is, of course, in a state of sin." - John von Neumann
bout...@med.wcc.govt.nz
> writing. Do easier languages hold more actual or potential attraction
> for you than difficult ones?
'easier' is a fairly difficult comparitive to define. I'm going to take it to
mean 'closer to plain english' as opposed to 'requiring less code'. I have to
admit that when I started, I had no real idea of how easy or hard the learning
process would be. I chose Inform for the simple reason that it was billed as
'infocom-like', and whatever sacrifices of time and education were necessary to
achieve that form were part and parcel of the end-goal.
There are aspects of the language that go completely over my head, even in this
group. I don't find this off-putting, however, because so far, whenever I have
needed to create something myself, I have been able to. It might take a few
tries, but the novelty of turning 78 compiler errors into 14, then 3, then none
has yet to wear off.
As far as 'plain english' goes - as a non-programmer I think this is only
really useful for people like me, who need a certain amount of explanation of
coding concepts that are old hat to programmers. Once that stage has been
passed, 'plain english' could become a hindrance, as it probably also entails
more code. I would prefer to have to grapple with arcane symbols for a short
time in the beginning, rather than have an albatross (however helpful) tied to
me for the duration.
Are you of the opinion or the impression
> that a language must be complicated and "mysterious" in order to be
> powerful?
Heh, even the 'simplest' language would be 'complicated and mysterious' to me
at some level. I take that as a given, and concentrate on building my hanglider
while the other turtles fly across the sun :)
> P.S. This is not a "Which particular language is better than which
> other particular language" question. It's intended to be more general
> than that.
>
As a footnote, I should add that even though Inform has its occasional glitch,
the effort I have put into it makes me unlikely to switch to anything else for
a while.
Tangle
PS - Is it true that TADS lets you compile objects at run-time (hope I've got
my terminology right there)? I thought I saw somebody mention it, but lost the
post. If it's true that Inform can't do this due to z-machine limitations, then
any language which pulls it off certainly has some enticement value. Is this
possible/planned with any of the other languages?
Thomas Nilsson
a) the simplicity/expressiveness/level/difficulty in a language
b) the support for mechanical typing and editing
To address the second one first, I'd say that a visual programming environment has a
lot going for them. But we must not confuse the environment with the language. Visual
Basic is not my favorite language but has a lot of support from the 'programming'
environment. But as has been said before, a decent programming editor (notably the
Emacs family) can be programmed to support functionality like that, and IFAIK there
actually are a couple of 'modes' available for Alan, TADS and Inform.
However this has nothing to do with the langauge, its complexity or expressiveness.
On the contrary there exists some systems that allow you to build (at least major
parts of) programming environments from formal definitions of a language. As far as I
know no IF language/tool has used this approach because we are limited (at least now
and a couple of years more) by the size and power of the normal personal computer
(not many of us use, or even have, computers at work that have the power to drive
these systems).
John Baker said:
> you're in the middle and know 1 language well, you're probably
> completely enamored with it. "I can do *anything* with this."
This is a common experience, once discovered the power of one Turing-complete
langauge is overhelming (remember: "when equipped with only a hammer, every problem
looks like a nail"?). As someone also stated, assembly langauge is also *powerful and
expressive* enough to be used for any programming task.
However, we don't do that much any more. Why? Because it takes to much time and
effort to do it! So languages that have loops and structures are designed to help us
forget about, jumping backwards a number of instructions or adding offsets to our
variable addresses.
The same usually goes for simple languages like Lisp or Forth. They are simple in
their structure (although in some sence 'higher-level' that assembly) but to be able
to do something useful in reasonable time, a large library has to be built (and often
those libraries evolve into separate 'langauges' with different dialects, cf.
Frans-List, Interlisp, etc. etc.)
bout...@med.wcc.govt.nz wrote:
>
> 'easier' is a fairly difficult comparitive to define. I'm going to take it to
> mean 'closer to plain english' as opposed to 'requiring less code'. I have to
> admit that when I started, I had no real idea of how easy or hard the learning
> process would be.
I think we are talking three different things here, simplicity, expressiveness and
ease of use.
The issue of simplicity, as I would like to define it, has already been discussed
above, so I'll go on with the other two.
First "ease of use" (not including "ease of typing", see above) is a relative term
and it must be related to the typical use and the typical user.
Most of our current programming languages are not suffiently easy to use for a novice
programmer, because the languages were designed for the programming domain of
problems. So a typical novice user would still have to learn a lot about programming
first, such as data structures, which algorithms are available, when and how to apply
them etc.
mam...@u.washington.edu wrote:
> It has to have some level of complexity. I'd be exceedingly
> frustrated writing IF in a language that didn't have the basic
> conditional and loop constructs (while, if/then, etc.). Writing a
> text game *is* software development, like it or not. (I believe
> someone recently quoted an Infocomer as saying that writing IF is like
> writing a spreadsheet--I agree.)
The future of the software industry lies in the possiblity to take the next step,
when this is not so necessary anymore. Look at the spreadsheet concept, this made it
possible for people not so programming-literate to develop software, or rather
software based applications.
Now accountants can develop their own accounting systems (at least at some simple
level), imagine letting IF authors develop their stories without much programming
knowledge.
Alan is an IF langauge which doesn't have loops! Possibly this will scare some
programmers, but loops are not designed out of the langauge because loops are a bad
thing, but because they have not been necessary. Instead the structure of the Alan
language and the run-time system is designed in such a way that loops are not
necessary for the typical work of IF. This can make some very advanced things
difficult to do, but the average *author* without programming skills will never miss
them.
I agree that you should also be able to do more complex things (what ever that is!)
but this possiblity should *never* interfere with this direct coupling between
concepts in the domain and the language! So development of advanced features must be
done by using the language and developing it to support those too.
Alan has been built to support authors, not programmers, in the sole purpose of
letting them spend more time on the development of their story than on programming.
I *am* sorry if this looks like a long advertisment for Alan. I assure you that this
was not my intention, it's just that this is my favourite topic (I'll give a talk on
it this friday during the International Conference on Compiler Construction here in
Linköping, Sweden, if anybody is interested ;-).
It would be very interesting to hear any voices from Alan authors as to the validity
(and success) of my claims.
To summarise my points
- don't confuse simplicity with brevity
- don't confuse ease of use with support environment
- don't confuse expressivness and power with loops and programming features
/Thomas
--
"Little languages go a long way..."
(ThoNi of ThoNi&GorFo Adventure Factories in 1985)
------------------------------------------------------------------------
Thomas Nilsson Phone Int.: (+46) 13 12 11 67
Stenbrötsgatan 57 Phone Nat.: 013 - 12 11 67
S-582 47 LINKÖPING Email: th...@softlab.se
SWEDEN alan-r...@softlab.se for info
------------------------------------------------------------------------
PAZ SALGADO
at all for PC (when I say *parser* I refer to I-Fs developement
language). I and one friend (Javier San Jose) start to develope two
diferents languages just at same time.
I love NPCs (I hate the classical sensation in I-F that the player
is the only person in world), so I develope a new language with
WHILE, FOR, SWITCH and a lots of powerful instructions. in order to
produce realistic NPCs.
JSJ wanted a PC-PAWS, and just do it, his SINTAC was exactly a remake
of PAWS for PC (with an spanish parser, of course).
My product had much more possibilities, and had a version not only
at PC but in AMIGA, so you can write and I-Fs in CAECHO on PC and
just obtain the AMIGA version.
In Spain, people choosen SINTAC because it was just PAWS and they
have learned PAWS yet.
I was only wanted to say that the most of I-Fs creators just only
want to sit down and write animated novels, lots of locations and
objects and some amazing puzzles. They dislike to program and are
very lazy to type strange constructions. I think in this way. the
possibilities of doing a realistic I-Fs, with goods NPCs are near to
imposible, but it's the raw reality.
Meliton Rodriguez, from 115 room
Dan Schmidt
card...@earthlink.net (Cardinal Teulbachs) says:
|
| Since such a vague category as "ease of use" lends itself to many
| interpretations, however, I'll go ahead and narrow it down slightly by
| giving the original context of the remark. The question was whether,
| in the end, a relatively simple and uncluttered syntax ("syntax" here
| meaning mostly the punctuation marks required/not required by various
| compilers) amounted to much of a selling point for an i-f language. My
| answer was that it's probably no selling point at all to one who has
| already mastered a syntactically complicated language, since that
| person already knows what all the marks are for and is well-acquainted
| with their typical usages, but for the newcomer it must surely flatten
| the learning curve and present a somewhat friendlier and more
| "familiar" face. I said also that I thought it had to be of real,
| practical benefit in terms of game-writing, inasmuch as it frees up
| the programmer's mind to concentrate on matters of substance in his or
| her code instead of constantly having to worry over the punctuational
| demands of the compiler (not to mention the time-savings it delivers
| in not having all those aggravating rebuilds caused by misplaced
| semicolons and whatnot).
I'm an experienced programmer (heck, I write games for a living - if
you have an IBM PC, check out Terra Nova, from Looking Glass
Technologies, it's my baby), so I'm willing to trade some ease of use
for power. When I had to pick TADS or Inform, I looked at samples of
code from both languages and browsed through both manuals; and TADS
won by such a large factor that I'm surprised that Inform seems to be
the language of choice on this group.
Inform is certainly somewhat more powerful, in that the parser is
written in Inform itself, and you have more low-level control of the
virtual machine, but TADS is just so much _cleaner_. Personally, I
think TADS is one of the nicest language designs I've seen. It maps
to the problem space extremely well, its object-orientedness is very
well done (and this is a key feature in writing adventure games,
IMHO), and it's clean. Inform looks more to me like a bunch of hacks
piled on top of each other.
I know that I'm not being fair to Inform; lots of people do like it,
and Graham has done a great job of putting it together. (I also think
that his essay on the rights of the user (don't remember the actual
title) is brilliant.) But to me personally, I can't imagine wanting
to use it while TADS is around. Inform reminds me in some ways of
TeX, a language not famed for its ease of use. And looking at the
manual (which reminds me of the TeXbook), I see it was formatted in
plain TeX, with a bunch of recondite macros, rather than a ``cleaner''
language like LaTeX. Perhaps there is a connection between the kinds
of languages people like? I don't like TeX much either. I really
want to, and I'm the world's biggest Knuthophile, but to me it's too
much of... a bunch of hacks piled on top of each other.
Dan Schmidt | df...@lglass.com | http://www2.lglass.com/~dfan
Russell L. Bryan
Dan Schmidt wrote:
> Inform is certainly somewhat more powerful, in that the parser is
> written in Inform itself, and you have more low-level control of the
> virtual machine, but TADS is just so much _cleaner_. Personally, I
> think TADS is one of the nicest language designs I've seen. It maps
> to the problem space extremely well, its object-orientedness is very
> well done (and this is a key feature in writing adventure games,
> IMHO), and it's clean. Inform looks more to me like a bunch of hacks
> piled on top of each other.
TADS does look quite clean in code, but when you play a TADS game you'll
notice that there are a number of functions that can not be cleanly
done. Among these are the automatic sack object which is a God-send
when you're juggling two hundred objects, plural manipulation (a couple
of "bugs" that I reported on Lost New York, such as the annoyance of
manipulating fifty napkins, were based on TADS incapabilities), and your
afore-mentioned access to the virtual machine. Not to mention the fact
that Inform is portable to the point where you can play many games on a
personal organizer!
I used to use TADS, and am a registered user, but I've switched to
Inform because I have found that as a PLAYER I'm happier with Inform. I
think one of the reasons so many games in the commercial market fail to
please is because their development was based on what worked best for
the programmer, rather than what worked best for the player.
Incidentally, in what ways does TADS outclass Inform when it comes to
its object-orientedness? I just don't see it.
-- Russ
Nulldogma
>TADS does look quite clean in code, but when you play a TADS game you'll
>notice that there are a number of functions that can not be cleanly
>done. Among these are the automatic sack object which is a God-send
>when you're juggling two hundred objects, plural manipulation (a couple
>of "bugs" that I reported on Lost New York, such as the annoyance of
>manipulating fifty napkins, were based on TADS incapabilities)
I wouldn't be too quick to blame this on TADS -- a better programmer than
I probably could have been able to write this more cleanly. Yes, TADS
needs a better way for handling plurals, but I think that can easily taken
care of by either a rewrite of ADV.T or a simple extension patch, if
someone felt like devoting the time to it. (Actually, correct me if I'm
wrong, but I got the impression WorldClass handled plurals somewhat
better.)
Also, I should point out that what I did with the napkins in Lost NY, you
*couldn't* do in Inform, since it involves dynamic creation of objects at
runtime, something Inform doesn't offer.
Neil
Dan Shiovitz
In article <4m9bvc$3...@newsbf02.news.aol.com>,
Nulldogma <null...@aol.com> wrote:
>>TADS does look quite clean in code, but when you play a TADS game you'll
>>notice that there are a number of functions that can not be cleanly
>>done. Among these are the automatic sack object which is a God-send
>>when you're juggling two hundred objects, plural manipulation (a couple
>>of "bugs" that I reported on Lost New York, such as the annoyance of
>>manipulating fifty napkins, were based on TADS incapabilities)
>
>I wouldn't be too quick to blame this on TADS -- a better programmer than
>I probably could have been able to write this more cleanly. Yes, TADS
>needs a better way for handling plurals, but I think that can easily taken
>care of by either a rewrite of ADV.T or a simple extension patch, if
>someone felt like devoting the time to it. (Actually, correct me if I'm
>wrong, but I got the impression WorldClass handled plurals somewhat
>better.)
done this already? If not, maybe I will.
>Also, I should point out that what I did with the napkins in Lost NY, you
>*couldn't* do in Inform, since it involves dynamic creation of objects at
>runtime, something Inform doesn't offer.
...And this is a surprisingly handy thing to be able to do. If for no other
reason than that it's annoying to have to thing of cute excuses why the
player can't take more than 47 fish.
>Neil
--
dan shiovitz scy...@u.washington.edu sh...@cs.washington.edu
slightly lost author/programmer in a world of more creative or more sensible
people ... remember to speak up for freedom because no one else will do it
for you: use it or lose it ... carpe diem -- be proactive.
my web site: http://weber.u.washington.edu/~scythe/home.html some ok stuff.
Trevor Barrie
scy...@u.washington.edu (Dan Shiovitz) wrote:
>Also, the sack object would be pretty easy to code up in TADS. Has anyone
>done this already? If not, maybe I will.
I'm waiting for somebody else to do it.:) While it wouldn't be
mindbogglingly tricky of course, I'm not sure it would be "pretty
easy" either.
Dan Shiovitz
In article <4mecj9$s...@bud.peinet.pe.ca>,
I'm not confident enough about my WorldClass ability to code it there,
but it seems doable under adv.t without too much difficulty. The basic
mechanism would be similar to autotake.t, another code fragment that I've
been meaning to u/l to gmd but haven't gotten around to, apparently.
autotake.t copies inform's behavior of (taking the fish first) if you
type "eat fish" while the fish is on the ground. But I digress, somewhat.
To code this up, I think you'd want to do it this way:
Anywhere in your code you have a doTake statement, you'd put in a call to
MakeRoom (we'll call it) at an appropriate place. MakeRoom, in turn,
would do the actual work. It would look something like this, in
semi-pseudocode (psuedo-pseudocode?):
MakeRoom()
{
local o = true if global.sack_object is open already, false otherwise
if (global.sack_object.isCarriedBy(Me))
{
if (it's possible to open the sack object or o is true)
{
if (o is false)
call sack_object.doOpen();
loop through each item in inventory, pick an appropriate one to
try and put in the sack object
if (it's possible to put the object in)
ok, exit from the loop, and note this object
end loop
if we haven't found an object to put away, then exit from MakeRoom
with an appropriate error message and return nil
else, if we have, call the object's doPut
}
else
return nil; //couldn't open it, so can't put things in it. might
// call sack's verDoOpen again, to give an error,
// before we exit from MakeRoom
// now we might want to try and close the sack
if (o is false)
{
// unfortunately, we have to manually check the ver method before
// calling the do method.
if (it's possible to close the sack object)
call the sack.doClose(), then return true from MakeRoom
else
call sack.verDoClose() to give an error message, then return
true from makeroom anyway (since we did manage to make room for it.)
}
else
return true from makeroom, since we don't need to close sack and thus
are all done.
}
else
return nil; //couldn't make room, because didn't have a place to put it
}
end bad pseudocode;
Checking if a verify method allows the action or does not can be done with
the (brain gears grind) outhide function in TADS. You call outhide, then
call the verify method, then outhide again. Outhide (appropriately) hides
the output, then the second call to it tells you if you had output from
the verify method, which would mean it failed and gave an error message.
Read the docs for a better explanation.
I apologize for the muddled nature of this code. I just wanted to toss
something out and see if anyone had an easier way of doing it before i
set out to code it myself.
Roger Giner-Sorolla
Aeons ago,
> >scy...@u.washington.edu (Dan Shiovitz) wrote:
> >
> >>Also, the sack object would be pretty easy to code up in TADS. Has anyone
> >>done this already? If not, maybe I will.
> >
Am I missing something, or is not "Lost New York" a TADS game with a
fully working knapsack?
Roger Giner-Sorolla New York University, New York, NY
gi...@xp.psych.nyu.edu Dept. of Psychology (Social/Personality)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This scholar, rake, Christian, dupe, gamester, and poet.
David Garrick, "Jupiter and Mercury"
Nulldogma
>> >>Also, the sack object would be pretty easy to code up in TADS. Has
>anyone
>> >>done this already? If not, maybe I will.
>> >
>Am I missing something, or is not "Lost New York" a TADS game with a
>fully working knapsack?
I think what people are suggesting is a sack that you can automatically
transfer things to when your hands are full -- i.e., if you try to pick up
more than you can carry, the game replies, "In order to make room for the
X, you put the Y in your sack."
Unless *I'm* missing something, though, there's a much simpler solution
that Dan's suggestion. Can't you just replace the bit of code in the
global doTake routine that checks for weight and bulk limits? (bad
pseudocode to follow)
if (bulk of what I'm carrying + bulk of what I'm picking
up)>Me.maxbulk
cycle through items in my inventory until I find something big
enough to make up the difference, then move it into the sack
same thing, only with weight instead of bulk
Dan Shiovitz
In article <4mkpqa$k...@newsbf02.news.aol.com>,
>PUT THE FROG IN THE SACK
The frog pleads with you not to put him in the sack, and you can't bear to
do so.
>TAKE THE BEACH BALL
(Putting the frog in the sack to make room)
Taken.
>LOOK IN SACK
The sack contains a frog.
Also note that in most cases, you won't want to do this for the weight check,
just for the bulk check.
Finally, isolating this sort of thing in functions can sometimes be a little
more readable, and anyway, I've already written the code :)
Speaking of which:
(note this has not been playtested, because I just finished it about 10
minutes ago. Anyone who finds a bug in it is strongly encouraged to email
me. Or pick it apart in the newsgroup, if it's a problem worthy of group
discussion.)
----------------------------------------------------------------------------
/*
Function makeRoom
This is a function to simulate Inform's "(Putting the jellybean in the
backpack to make room)" code in TADS. It has not been tested, and may not
even work correctly. If you do wish to test it, here's how the function
is used:
* The only place you need to make the modification is in the doTake
routine (the verDoTake routine is fine), but this needs to be changed
every time you define a new doTake routine, assuming you want it to
have this behavior.
* The old code in adv.t, under the item class, looks like this (in part):
if ( totweight > actor.maxweight )
"%Your% load is too heavy. ";
else if ( totbulk > actor.maxbulk )
"%You've% already got %your% hands full. ";
else
{
self.moveInto( actor );
"Taken. ";
}
* You'll want to change it to something like this:
if (totweight > actor.maxweight )
"%Your% load is too heavy. ";
else if ( totbulk > actor.maxbulk )
{
if ( makeRoom(actor, self) )
{
self.moveInto( actor );
"Taken. ";
}
}
else
{
self.moveInto( actor );
"Taken.";
}
And that's it!
This basic function suggestions some interesting modifications, which
I might even get around to making someday:
* It wouldn't be too hard to have *several* global sack objects,
and this function would use the one that you were carrying
* Currently, it has a fairly sketchy use of bulk. Perhaps makeRoom should
take a second argument, bulk_to_clear, a number indicating what bulk of
object needs to be removed from your inventory.
* A magical bag of holding might make things weigh less if you put them
inside it. In that case, "(Putting the rock in your bag of holding to
allow you to lift the frog)" might be perfectly valid behavior.
* And, of course, if someone would implement this for WorldClass, I'd
be spared the trouble.
--Dan Shiovitz
scy...@u.washington.edu
*/
function makeRoom(actor, newItem)
{
local obj, i, l, os;
os = global.sackObject.isopen;
if (global.sackObject and // if the sack object exists
global.sackObject.isIn(actor)) // and I have it
{
outhide(true); // hide output until outhide(nil) is called
global.sackObject.verDoOpen( actor ); // call the *verify* method
if ( not os ) // ie, if the sack object is closed
{
if ( outhide(nil) ) // outhide(nil) returns t if there was output
// which means the verify failed and we can't
// open the sack
{
return nil; // exit from makeRoom(), function failed
}
else // otherwise, if we can open it, do open it.
{
globalsackObject.doOpen( Me );
}
}
// the sack object is now open. now we try and figure out which
// object to put in
for (i = 0; i < length(actor.contents); i++)
{
local tryThis;
tryThis = actor.contents[i];
outhide(true); // check to see if this is a viable storable
tryThis.verDoPutIn( actor, global.sackObject );
if (not outhide(nil)) // if no output, then ok.
{
obj = tryThis;
break;
}
}
if (obj = nil) // if obj never got set to anything
return nil; // exit from makeRoom, function failed
// we now have an object. let's put it in the sack.
obj.doPutIn( actor, global.sackObject );
"Putting <<obj.thedesc>> into <<global.sackObject.thedesc>> to make
room for <<newItem.thedesc>>.";
// easy, wasn't that?
// the only thing left to do is close the sack, if it was closed
// originally
if (not os)
{
outhide(true); // one last time
os.verDoClose();
if ( not outhide(nil) ) // if the verify succeeded
os.doClose();
// note that we do *not* exit from makeRoom if this verify fails,
// because, after all, we did make room for the new object.
}
return true;
}
else // if no global.sackObject or we can't open it
return nil;
}
--------------------------------------------------------------------------
Marnix Klooster
In article <4m3r8c$q...@senator-bedfellow.mit.edu>,
Dan Schmidt <dsch...@athena.mit.edu> wrote (amongst other things):
> Personally, I
>think TADS is one of the nicest language designs I've seen. It maps
>to the problem space extremely well, its object-orientedness is very
>well done (and this is a key feature in writing adventure games,
>IMHO), and it's clean.
I recently wondered about this point... As far as I can see, all
current I-F languages are object-oriented in some sense. Would it be
possible to use another paradigm? One that comes to mind is
`interactive documents': a work of interactive fiction is just like a
static document, except that the user/player has ways to change and
extend it. Hypertext, only better. Maybe one needs
object-orientedness at some stage, but it would be interesting to see
how far one can get without it. BTW, I just invented the phrase
`interactive documents', but I wouldn't be surprised if somebody
somewhere researched and/or implemented such beasts.
> Inform looks more to me like a bunch of hacks
>piled on top of each other.
You should take into account the aim of Inform, which is to provide a
way to create Infocom-compatible story files. This makes that the
Inform language is geared towards the Infocom virtual machine, with
all its restrictions and quirks.
> Inform reminds me in some ways of
>TeX, a language not famed for its ease of use. And looking at the
>manual (which reminds me of the TeXbook), I see it was formatted in
>plain TeX, with a bunch of recondite macros, rather than a ``cleaner''
>language like LaTeX. Perhaps there is a connection between the kinds
>of languages people like? I don't like TeX much either. I really
>want to, and I'm the world's biggest Knuthophile, but to me it's too
>much of... a bunch of hacks piled on top of each other.
You should check out Lout, a document formatter that is cleaner than
both TeX and LaTeX. Get it at
ftp://ftp.cs.su.oz.au/jeff/lout
>Dan Schmidt | df...@lglass.com | http://www2.lglass.com/~dfan
Greetings,
<><
Marnix
--
Marnix Klooster
kloo...@dutiba.twi.tudelft.nl