Why Inform?
Adam Conover
TADS came out before Inform. TADS has clearer syntax than Inform -- or
at least, it seems to to me since I have some experience with C. I
assume that others would feel the same way -- and, in any case, I've
heard complaints that Inform's syntax doesn't really make much sense.
Inform also has a nasty size limit -- see games like Dangerous Curves,
which seemed like it had been so richly programmed that there wasn't
any space left for a very long story. (Yes, I loved DC.) Yes, Inform
runs on the Z-Machine, which is really cool, I admit, and its
interpreters seem nicer than the equivalents for TADS (I love DOS
Frotz) -- but this doesn't seem like it would affect people's
decisions. Finally, TADS came out before Inform, so it's not as if
there was a large number of people already programming in it -- it had
to make up for lost time in the language race, so to speak.
So, my question is: why are there so many more games released for
Inform than TADS? I feel like I must be missing something here, some
huge benefit to using Inform that I haven't considered. Authors: why
did you choose Inform over TADS? I'm sure this subject has already
caused enough flame-wars, but think of it as explaining the situation
to someone who just doesn't get it.
Thanks!
- adam
(write e-mail address numerically to reply)
i blog at:
http://students.bard.edu/~ac484/blog.html
Lucian P. Smith
: Ok. Here's something I don't quite get.
:
: TADS came out before Inform....
<snip>
: So, my question is: why are there so many more games released for
: Inform than TADS?
Three things:
1) The Designer's Manual
2) Inform was freeware when TADS was shareware.
3) The z-machine is a bigger factor than you probably realize.
4) (did I say three? I meant four.) The *syntax* may be prettier in
TADS, but the *words* are prettier in Inform.
and actually, there may be:
5) People may prefer the Inform standard library (as players) than the
TADS one. By which I almost exclusively mean 'the default responses'.
At least, those are my guesses.
-Lucian
Adam Conover
>Three things:
>
>1) The Designer's Manual
Ah. I'd noticed that TADS was a bit lacking in the tutorial
department.
>2) Inform was freeware when TADS was shareware.
Ah, but the discrepency between Inform and TADS games released has
become -larger- since TADS was made shareware, if you use IFComp as a
reference point, so this doesn't entirely answer the question.
>3) The z-machine is a bigger factor than you probably realize.
How so? I mean, granted, it's cool, and TADS isn't open to
z-machine-style abuse, but what's the big deal? Someone explain it to
me. :)
>4) (did I say three? I meant four.) The *syntax* may be prettier in
>TADS, but the *words* are prettier in Inform.
What?
Thanks for your help. :)
Taliesin
"Lucian P. Smith" <lps...@rice.edu> wrote in message
news:94q274$i3s$1...@joe.rice.edu...
> Adam Conover (acfoure...@bard.edu) wrote in
<3a6fdf2c...@News.CIS.DFN.DE>:
>
> : Ok. Here's something I don't quite get.
> :
> : TADS came out before Inform....
>
> <snip>
>
> : So, my question is: why are there so many more games released for
> : Inform than TADS?
Maybe its up to you and some others to redress this balance eh?
I'll give it a go.
Tal'
Neil Cerutti
>So, my question is: why are there so many more games released
>for Inform than TADS? I feel like I must be missing something
>here, some huge benefit to using Inform that I haven't
>considered. Authors: why did you choose Inform over TADS? I'm
>sure this subject has already caused enough flame-wars, but
>think of it as explaining the situation to someone who just
>doesn't get it.
For me it was timing. TADS was shareware at the time I chose a
language. It was hard to choose in favor of the $40 dollar
language when the free language was just as good.
I've ported lots of TADS code to Inform, so I can vouch for TADS
readability. Inform is even *more* readable than TADS, but it
sure isn't as writable. I could understand all Inform code long
before I could write my own. This was by design actually, since
Graham designed Inform by prettying up the practically bare-bones
z-machine operations until he thought it looked good. See the
Inform Technical Specification for more info on the early
evolution of pre-release Inform.
Many people praise Inform's great manual, and I concur. The
Designer's Manual had an even bigger advantage at the time,
though, because the TADS manual was only for those who paid $40
dollars.
Graham Nelson was writing competition-winning games (with Inform)
and was much more active in the raif community, at the time, than
Mike Roberts.
"Curses" also brought a lot of new people to the hobby, who were
obviously inclined to try Inform first.
A couple of the most higly regarded current author's joined the
community at about the same time, and now Andrew Plotkin and Adam
Cadre both use Inform, creating even more cachet.
With TADS advancement, freeness, and with Graham's lower profile,
TADS is bound to make a stunning comeback. As you say, Inform
doesn't really have any astounding advantages except for
popularity.
--
Neil Cerutti <cer...@together.net>
"If you're gonna score 125 points in a game, you've only got to
play good enough defense to hold the other team to 124. How
the hell hard is that?" -- Red Auerbach
Mark Musante - Sun Microsystems
> 5) People may prefer the Inform standard library (as players) than the
> TADS one. By which I almost exclusively mean 'the default responses'.
It'd be interesting to see a TADS library with Inform's look'n'feel.
-markm
Adam Cadre
> Authors: why did you choose Inform over TADS?
(1) The manual begins, "In trying to be both a tutorial and reference
work, this book aims itself in style halfway between the two extremes
of manual, Tedium and Gnawfinger's Elements of Batch Processing in
COBOL-66, third edition, and Mr Blobby's Blobby Book of Computer Fun.
(This makes some sections both leaden and patronising.)" This remains
one of the most wonderful paragraphs I have even encountered. I was
sold.
(2) You speak of TADS's "clearer syntax," but I am not a programmer
and found Inform much more intuitive: "move cat to mat;" (Inform) vs.
"cat.moveInto(mat);" (TADS). The TADS version may better achieve some
ideal of object-oriented consistency or whatnot, but I couldn't care
less about that -- it makes my eyes bleed, so no thanks.
-----
Adam Cadre, Sammamish, WA
web site: http://adamcadre.ac
novel: http://www.amazon.com/exec/obidos/ASIN/0060195584/adamcadreac
Adam Conover
wrote:
>Adam Conover wrote:
>> Authors: why did you choose Inform over TADS?
>
>(1) The manual begins, "In trying to be both a tutorial and reference
>work, this book aims itself in style halfway between the two extremes
>of manual, Tedium and Gnawfinger's Elements of Batch Processing in
>COBOL-66, third edition, and Mr Blobby's Blobby Book of Computer Fun.
>(This makes some sections both leaden and patronising.)" This remains
>one of the most wonderful paragraphs I have even encountered. I was
>sold.
Oh, I heartily agree.
>(2) You speak of TADS's "clearer syntax," but I am not a programmer
>and found Inform much more intuitive: "move cat to mat;" (Inform) vs.
>"cat.moveInto(mat);" (TADS). The TADS version may better achieve some
>ideal of object-oriented consistency or whatnot, but I couldn't care
>less about that -- it makes my eyes bleed, so no thanks.
Ah. That's the thing. Like I said, I was raised on C -- I don't
currently program, but that's how my mind thinks. Also, for years I
was programmed objects on MOOs, which for the uninformed are a
descendent of MUDs, but are social areas where anyone can program. The
interface resembles IF with a simplified parser ("verb direct objects
prep. indirect object") -- and its programming language is as
object-oriented as one can get. So yes, "cat.moveInto(mat);" DOES make
more sense to me, and move cat to mat; seems bizarrely arbitrary.
Lucian P. Smith
: On 25 Jan 2001 20:27:16 GMT, lps...@rice.edu (Lucian P. Smith) wrote:
: >3) The z-machine is a bigger factor than you probably realize.
:
: How so? I mean, granted, it's cool, and TADS isn't open to
: z-machine-style abuse, but what's the big deal? Someone explain it to
: me. :)
For me personally, I got a z-machine game up and running approximately one
year before I got a TADS game up and running. Looking back, I'd say they
were approximatly equal difficulty. But I figured one out first, and
didn't bother trying the other until much later.
Tied in with this is the fact that z-machine interpreters are in the
'Infocom' directory at gmd (and have been forever).
: >4) (did I say three? I meant four.) The *syntax* may be prettier in
: >TADS, but the *words* are prettier in Inform.
:
: What?
I mean that I pull up a random TADS source code file, and see things like
"ldesc", "verDoGo", "doGo", and "dobjGen". I pull up a random Inform
source code file and see things like "description", "Go", "before", and
"light". The latter is soothing to newbies, and, I think, helps them get
over the initial programming hump. To put it in chemical terms, the TADS
syntax may mean that the energy difference is lower, but the familiar
words in Inform make the energy *barrier* lower. Let's see if I can do
this in ASCII:
_
/ \
| |
| | _
| | / \
| | | |
| | | |
| | | |____
| | |
| | |
| | |
| |___ |
| |
| |
| |
| |
_____| ______|
TADS Inform
Eh, that's tolerable. You see what I'm getting at. The point is, it
takes more effort to learn TADS, even if it's 'simpler' or 'cleaner'. Or
at least, it *seems* like it would take more effort to learn TADS, even if
that's not necessarily true. I've never tried to learn TADS, so I
wouldn't know. I do know Inform was easy to learn, and I've never had a
problem with it.
-Lucian
Adam Cadre
> "ldesc", "verDoGo", "doGo", and "dobjGen"
My eyes! My eyes! Aieeeee!
Mark Musante - Sun Microsystems
> (2) You speak of TADS's "clearer syntax," but I am not a programmer
> and found Inform much more intuitive: "move cat to mat;" (Inform) vs.
> "cat.moveInto(mat);" (TADS). The TADS version may better achieve some
> ideal of object-oriented consistency or whatnot, but I couldn't care
> less about that -- it makes my eyes bleed, so no thanks.
In fact, if someone were to write a brand new OO-based library in
Inform (which zarf mentioned in another thread a few days ago), one
would be required to have something similar to cat.moveInto(mat); as
part of the library. This would give a chance for the cat and/or the
mat to object to the move, or react to it in some other way.
That's what the moveInto member function of TADS does. You COULD
theorectically do
if ( cat.location ) cat.location.contents -= cat;
cat.location := mat;
mat.contents += cat;
in TADS (which is what 'move cat to mat;' does in Inform) but that
bypasses the whole OO design.
-markm
Magnus Olsson
Adam Conover <acfoure...@bard.edu> wrote:
>On 25 Jan 2001 20:27:16 GMT, lps...@rice.edu (Lucian P. Smith) wrote:
>
>>Three things:
>>
>>1) The Designer's Manual
>
>Ah. I'd noticed that TADS was a bit lacking in the tutorial
>department.
Not really, IMHO - the TADS manual is quite good, though perhaps
lacking in the DM's literary qualities (that's not to say that the
TADS manual is badly written; au contraire, it's very well-written,
but it's still "computer manual prose", unlike the literary style of
the Inform DM). The various third-party Inform tutorials on the
Web are recent additions.
But I still think that non-programmers who were a bit turned off
by the TADS manual just couldn't stop reading the Inform DM :-).
>>2) Inform was freeware when TADS was shareware.
>
>Ah, but the discrepency between Inform and TADS games released has
>become -larger- since TADS was made shareware, if you use IFComp as a
>reference point, so this doesn't entirely answer the question.
Mainly, I think, this is because success breeds success. Inform managed
to attract a large user base while it was freeware and TADS wasn't. And
during the same period, Inform was being very actively developed, while
TADS was in a bit of a limbo.
Once this lareg Inform user base was in existance, new users would be
attracted by this - they'd notice that a lot of other people used
Inform, and that most discussion on r.a.i-f was about Inform, so
Inform would be a natural first choice.
There's a lot of inertia in people's language choice. I'm sure all
the people who've released new IF languages lately will agree with
this point. :-)
>>3) The z-machine is a bigger factor than you probably realize.
>
>How so? I mean, granted, it's cool, and TADS isn't open to
>z-machine-style abuse, but what's the big deal? Someone explain it to
>me. :)
In one word: portability. TADS is widely ported, but not nearly as
widely as the Z-machine.
And you're underestimating the coolness factor. In fact, when Inform
was first released, it felt so increadibly cool to realize that I,
too, could write games that would run on the same interpreters as
Infocom's.
>>4) (did I say three? I meant four.) The *syntax* may be prettier in
>>TADS, but the *words* are prettier in Inform.
>
>What?
Others have answered this already, but I'll give my view of it:
IMO, Inform isn't easier than TADS, but, judging by comments on
r.a.i-f, it apparently *looks* easier and less intimidating to the
non-programmer.
--
Magnus Olsson (m...@df.lth.se, m...@pobox.com)
------ http://www.pobox.com/~mol ------
Magnus Olsson
>(2) You speak of TADS's "clearer syntax," but I am not a programmer
>and found Inform much more intuitive: "move cat to mat;" (Inform) vs.
>"cat.moveInto(mat);" (TADS). The TADS version may better achieve some
>ideal of object-oriented consistency or whatnot, but I couldn't care
>less about that
You should care about it :-) (tongue firmly planted in cheek).
Actually, the advantage of the TADS notation is that it's general.
"move cat to mat" is easy to read, but Inform doesn't allow you to
define new operators like that, but forces you to use different syntaxes
in different places. In fact, Inform has
"move cat to mat" for certain common operations,
"< move cat mat >" for actions
and "cat.moveto(mat)" for everything that doesn't fit into the other
patterns.
Of course, this is far from apparent to the beginner.
Adam Conover
>Actually, the advantage of the TADS notation is that it's general.
>"move cat to mat" is easy to read, but Inform doesn't allow you to
>define new operators like that, but forces you to use different syntaxes
>in different places. In fact, Inform has
>"move cat to mat" for certain common operations,
>"< move cat mat >" for actions
>and "cat.moveto(mat)" for everything that doesn't fit into the other
>patterns.
>
>Of course, this is far from apparent to the beginner.
Dammit. I was just in the middle of reading the DM front to back for
the first time... now I'm all confused again. What do I choose? What
do I choose? Again, I'm a programmer with C and MOO experience
(although not currently programming), but I -do- think the z-machine
is cool and I play Inform games on my Palm m100 quite often... so, how
about recommendations. Magnus, if my memory is correct, you use TADS,
right? Why?
David Thornley
Neil Cerutti <cer...@together.net> wrote:
Just a few odd notes....
>
>For me it was timing. TADS was shareware at the time I chose a
>language. It was hard to choose in favor of the $40 dollar
>language when the free language was just as good.
>
For me, there was no such thing as Inform when I registered TADS.
TADS did have a priority advantage.
>I've ported lots of TADS code to Inform, so I can vouch for TADS
>readability. Inform is even *more* readable than TADS, but it
>sure isn't as writable.
TADS is perfectly readable and writable by anybody used to computer
software. Inform takes a less technical approach, and appeals
more to the non-technogeeks.
>Many people praise Inform's great manual, and I concur. The
>Designer's Manual had an even bigger advantage at the time,
>though, because the TADS manual was only for those who paid $40
>dollars.
>
Twenty dollars, if you just wanted the manual.
>Graham Nelson was writing competition-winning games (with Inform)
>and was much more active in the raif community, at the time, than
>Mike Roberts.
>
However, you have to remember David Baggett and company, who were
responsible for the Unkuulian Unventures and the Worldclass
library. Those were probably the highest-quality "hobbyist"
adventures before Curses.
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
David Thornley
>and found Inform much more intuitive: "move cat to mat;" (Inform) vs.
>"cat.moveInto(mat);" (TADS). The TADS version may better achieve some
>ideal of object-oriented consistency or whatnot, but I couldn't care
>less about that -- it makes my eyes bleed, so no thanks.
>
Inform - at a certain level it reminds me of COBOL. I won't
insult Nelson by implying any other similarity.
Dan Schmidt
| On 25 Jan 2001 20:27:16 GMT, lps...@rice.edu (Lucian P. Smith) wrote:
|
| >3) The z-machine is a bigger factor than you probably realize.
|
| How so? I mean, granted, it's cool, and TADS isn't open to
| z-machine-style abuse, but what's the big deal? Someone explain it to
| me. :)
People get warm fuzzies from writing to the same virtual machine that
Infocom did.
It's a bigger factor than I would have realized.
Matthew T. Russotto
Adam Conover <acfoure...@bard.edu> wrote:
}
}So, my question is: why are there so many more games released for
}Inform than TADS? I feel like I must be missing something here, some
}huge benefit to using Inform that I haven't considered.
Inform was _free_ first.
Z-Machine!
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
ical...@my-deja.com
acfoure...@bard.edu wrote:
> Inform also has a nasty size limit -- see games like Dangerous Curves,
> which seemed like it had been so richly programmed that there wasn't
> any space left for a very long story.
When I chose Inform, I was under the impression that its limitations
were large enough that I was "unlikely" to run up against them. They
weren't. :)
> Why did you choose Inform over TADS? I'm sure this subject has already
> caused enough flame-wars, but think of it as explaining the situation
> to someone who just doesn't get it.
I love the idea that I can play i-f on my PalmPilot. This was
one of the primary reasons I chose Inform instead of TADS.
irene
Sent via Deja.com
http://www.deja.com/
Adam Conover
>In article <3a6fdf2c...@News.CIS.DFN.DE>,
> acfoure...@bard.edu wrote:
>
>> Inform also has a nasty size limit -- see games like Dangerous Curves,
>> which seemed like it had been so richly programmed that there wasn't
>> any space left for a very long story.
>
>When I chose Inform, I was under the impression that its limitations
>were large enough that I was "unlikely" to run up against them. They
>weren't. :)
That's a shame, because I loved DC -- one of the most fully-realized
games I've played -- everything WORKED! The way I expected it to! (or
didn't, given my expectations of IF.) It was one of the first games I
played that actually made me feel like I was in a complete environment
where I could go anywhere or do anything. I could get drunk! And
drive! I was truly disappointed when the game itself was so short.
>> Why did you choose Inform over TADS? I'm sure this subject has already
>> caused enough flame-wars, but think of it as explaining the situation
>> to someone who just doesn't get it.
>
>I love the idea that I can play i-f on my PalmPilot. This was
>one of the primary reasons I chose Inform instead of TADS.
That too. I'm considering Inform now, actually... hm.
Kathleen M. Fischer
ical...@my-deja.com wrote:
> In article <3a6fdf2c...@News.CIS.DFN.DE>,
> acfoure...@bard.edu wrote:
>
> > Inform also has a nasty size limit -- see games like Dangerous
Curves,
> > which seemed like it had been so richly programmed that there wasn't
> > any space left for a very long story.
>
> When I chose Inform, I was under the impression that its limitations
> were large enough that I was "unlikely" to run up against them. They
> weren't. :)
I think your original impression is still true. Most people ARE unlikely
to run up against the size limitations. You're just... unusual. <g>
(besides, nothing makes you wrap up a game like lack of memory, eh?)
Seriously, I think an author has to work pretty hard to reach Informs
limits - which, with the advent of glulx (or whatever the heck it's
called) have sort of evaporated anyhow.
Kathleen
--
-- Masquerade (Comp00) - ftp://ftp.gmd.de/if-archive/games/zcode/Mask.z5
-- (but at the moment still in ftp://ftp.gmd.de/if-archive/incoming)
-- The Cove - Best of Landscape, Interactive Fiction Art Show 2000
-- ftp://ftp.gmd.de/if-archive/games/zcode/Cove.z5
-- Excuse me while I dance a little jig of despair
Adam Cadre
> I could get drunk! And drive! I was truly disappointed when the game
> itself was so short.
Well, c'mon. If you wanted the game to last longer, you shouldn't
have gotten plowed and wrapped your car around a tree.
Also, http://www.scottmccloud.com/comics/carl/3a/03.html
ems...@mindspring.com
> I think your original impression is still true. Most people ARE unlikely
> to run up against the size limitations. You're just... unusual. <g>
> (besides, nothing makes you wrap up a game like lack of memory, eh?)
> Seriously, I think an author has to work pretty hard to reach Informs
> limits - which, with the advent of glulx (or whatever the heck it's
> called) have sort of evaporated anyhow.
The reason I haven't put out a big game yet is that I haven't been able
to finish one in Inform, thanks to problems with the low memory
restrictions. (Conversation systems a la the heart of Galatea
require a lot of topic objects with a lot of properties.)
So I may perhaps also be... unusual, but still, I'd like to make the
leap to glulx for my larger projects. Which I will do just as soon as
there's a mac compiler for it.
-- Emily
Andrew MacKinnon
Although the Inform manual may have some better aspects, it seems to
assume you want to code things *his way*, and that only works well for
simple games. Experienced Inform authors have figured out how to get
around annoying parts of the Inform library and not append "The xxx is
currently switched on" to descriptions of switchable objects and not to
use when_on and initial and... so on. I don't know why Graham
implemented certain features (e.g. talkable, which NO ONE uses).
---
Fact: Although the current Inform library is okay, and most of it can be
gotten around, parts of it could afford to be changed. (Specifically,
the verblib section could have a modified/improved version). One comment
about Inform is that it has unclean handling of doors. I much prefer
TADS doors. (Automatic door opening and simpler door handling is handled
in my Inform library easydoors.h [1]) However, I primarily use Inform.
Inform is better for some people, TADS for other. Period.
[1] Easydoors.h is here:
ftp://ftp.gmd.de/if-archive/programming/inform6/library/contributions/easydoors.h
--
Andrew MacKinnon
andrew_mac...@yahoo.com
http://www.geocities.com/andrew_mackinnon_2000/
Andrew MacKinnon
>
> Kathleen M. Fischer <green_g...@my-deja.com> wrote:
> > I think your original impression is still true. Most people ARE unlikely
> > to run up against the size limitations. You're just... unusual. <g>
> > (besides, nothing makes you wrap up a game like lack of memory, eh?)
>
> > Seriously, I think an author has to work pretty hard to reach Informs
> > limits - which, with the advent of glulx (or whatever the heck it's
> > called) have sort of evaporated anyhow.
>
> The reason I haven't put out a big game yet is that I haven't been able
> to finish one in Inform, thanks to problems with the low memory
> restrictions. (Conversation systems a la the heart of Galatea
> require a lot of topic objects with a lot of properties.)
I think these memory restrictions can be raised. If you see an error
message saying that the memory property MAX_OBJECTS has been exceeded
and that the maximum is 512, add something like '$MAX_OBJECTS=1024' to
your command line. If you exceed the limitations of v5 games, switch to
v8.
> So I may perhaps also be... unusual, but still, I'd like to make the
> leap to glulx for my larger projects. Which I will do just as soon as
> there's a mac compiler for it.
--
Carl Muckenhoupt
wrote:
>TADS is perfectly readable and writable by anybody used to computer
>software. Inform takes a less technical approach, and appeals
>more to the non-technogeeks.
Except for one thing: Inform let you write Z-machine assembly code.
Nothing in TADS had that kind of technogeek appeal.
I don't think many people have actually *used* this capability, but
that hardly matters. It's like that old sports car commercial: "You
may never drive at 200 MPH, but it's great to know you could..."
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
ems...@mindspring.com
>> The reason I haven't put out a big game yet is that I haven't been able
>> to finish one in Inform, thanks to problems with the low memory
>> restrictions. (Conversation systems a la the heart of Galatea
>> require a lot of topic objects with a lot of properties.)
> I think these memory restrictions can be raised.
You are incorrect.
> If you see an error
> message saying that the memory property MAX_OBJECTS has been exceeded
> and that the maximum is 512, add something like '$MAX_OBJECTS=1024' to
> your command line. If you exceed the limitations of v5 games, switch
to
> v8.
Gratifyingly eager advice, in this case misapplied. The situation
to which I'm referring is one you may not have run into unless you've
had a reasonable amount of Inform experience, however.
The problem has to do with the amount of memory allotted for
certain kinds of things [eg. properties], which is inflexible. This
is the 'low memory.' Go above the limit and your program will compile,
but what it will produce will crash MaxZip and cause Nitfol to spit fatal
errors. So it's the '...a lot of properties' part of that sentence
that's important here.
I've been struggling with this for over a year now. L. Ross
Raszewski has written some libraries that allow you to do some
memory-saving tricks; it is also possible to gain a little breathing
room by using the same property name for two different things where
they won't overlap at all [eg., giving my topic objects a door_to
property -- since I know they will never be called on to act as doors
-- rather than a next_topic property.] The problem is that a) all that
kind of thing only buys you a little bit, and it's not enough room for
me to finish what I'm working on; and b) it obfuscates the code to a
degree that I find frustrating.
Since (at least part of) the point of this exercise is not only to
write a game but also to create and refine a conversation library that
someone other than myself could hope to understand, this is
unacceptable.
So I write short games. And wait. For glulx.
ES
Kevin Forchione
news:94q2t5$8a2$1...@eastnews1.east.sun.com...
I'm not sure what you mean by this. Do you mean Inform default responses and
language syntax, or do you mean the deeper structure of the library.
For me there is a clear distinction between the two systems: Inform's
library is a procedural system that operates on objects whose behaviors are
largely determined by library functions. This gives Inform a compactness,
but makes handling exceptions rather difficult. For contrast, instead of
having a listing routine that determines whether an object is a container, a
surface, a fixed item, etc; TADS has increasingly adopted the approach that
the objects handle their own listing, given merely the request. This
philosophy permeates the current trend in library development in TADS.
--Kevin
MFischer5
>So it's the '...a lot of properties' part of that sentence
>that's important here.
I found aliasing properties to a handy, space-saving, obfuscation obliteration
technique
Heavy usage of classes and routines for things done muliply save tons of space
as well. Of course, unique text blobs are probably going to kill you in the
end. You just write to much lovely text! :) :) :)
Kathleen
Jason Melancon
>lps...@rice.edu (Lucian P. Smith) wrote:
>>3) The z-machine is a bigger factor than you probably realize.
>
>How so? I mean, granted, it's cool, and TADS isn't open to
>z-machine-style abuse, but what's the big deal? Someone explain it to
>me. :)
One word: quote-boxes. :-)
cer...@together.net (Neil Cerutti) wrote:
> Graham Nelson was writing competition-winning games (with Inform)
> and was much more active in the raif community, at the time, than
> Mike Roberts.
> [snip]
> With TADS advancement, freeness, and with Graham's lower profile,
> TADS is bound to make a stunning comeback.
I think we've just hit on Graham's secret motivation for going AWOL.
He knew Mike was back working on TADS3. To atone for releasing a hit
free competitor to the venerable TADS shareware, he's passively
encouraging new authors to give Mike's renewed effort a chance.
The very first ever IF Competition had an equal number of TADS and
Inform entries. According to the Legend, the next fall comp that
achieves the old balance will break the spell, and Graham will return,
signalling the Golden Age of interactive fiction authoring systems.
In these enlightened days, of course, no one believes a word of it.
--
Jason Melancon
Adam Conover
wrote:
>I think we've just hit on Graham's secret motivation for going AWOL.
>He knew Mike was back working on TADS3. To atone for releasing a hit
>free competitor to the venerable TADS shareware, he's passively
>encouraging new authors to give Mike's renewed effort a chance.
Which reminds me -- is there any sort of time scale for the release of
TADS 3 in a usable form? (IIRC, the compiler and interpreters are out,
but no standard libraries?) MJR, if you're around -- any clues?
Richard Bos
> So, my question is: why are there so many more games released for
> Inform than TADS? I feel like I must be missing something here, some
> huge benefit to using Inform that I haven't considered. Authors: why
> did you choose Inform over TADS?
In my case (even though I barely qualify as Author): I started as a
player. I have not got the time and diskspace for two systems, two
'terps, two sets of story files. Hell, I haven't really got the time for
one. So I chose the one that already had the most promising history: the
one that played the great games I already knew, those of Infocom.
And thence, when I started mucking around with a compiler, I needed one
that could compile for Frotz. That was obviously Inform.
Richard
Magnus Olsson
Adam Conover <acfoure...@bard.edu> wrote:
>On 25 Jan 2001 22:25:38 GMT, m...@pobox.com (Magnus Olsson) wrote:
>
>>Actually, the advantage of the TADS notation is that it's general.
>>"move cat to mat" is easy to read, but Inform doesn't allow you to
>>define new operators like that, but forces you to use different syntaxes
>>in different places.
(snip)
>>Of course, this is far from apparent to the beginner.
>
>Dammit. I was just in the middle of reading the DM front to back for
>the first time... now I'm all confused again.
Good heavens, I didn't mean to discourage anyone from choosing Inform
- I was just responding to Adam Cadre's remark that he didn't know
(and didn't care) why TADS' syntax was considered better (from a
theoretical point of view), despite being worse (from his point of
view).
But regardless of whether you agree with me or Adam C, this is a
relatively unimportant matter in the big picture. It shouldn't really
be decisive one way or the other.
>What do I choose? What
>do I choose? Again, I'm a programmer with C and MOO experience
>(although not currently programming), but I -do- think the z-machine
>is cool and I play Inform games on my Palm m100 quite often... so, how
>about recommendations. Magnus, if my memory is correct, you use TADS,
>right? Why?
I use TADS *and* Inform. Both are exccellent languages for their
purpose. If you've read half the DM, and like what you've read so far,
by all means give Inform a try.
And why do I use TADS? Because I started using it before Inform was
released.
Branko Collin
>And you're underestimating the coolness factor. In fact, when Inform
>was first released, it felt so increadibly cool to realize that I,
>too, could write games that would run on the same interpreters as
>Infocom's.
This was for me _the_ reason to only consider Inform for authoring
text adventures in recent years (not that I have finished any). For me
it was a completely emotional choice.
--
branko collin
col...@xs4all.nl
Dave Holland
> move cat to mat; seems bizarrely arbitrary.
That's odd. I thought your English was pretty good...
Dave
Matthew T. Russotto
Andrew MacKinnon <andrew_mac...@yahoo.com> wrote:
}-snip-
}
}Although the Inform manual may have some better aspects, it seems to
}assume you want to code things *his way*, and that only works well for
}simple games. Experienced Inform authors have figured out how to get
}around annoying parts of the Inform library and not append "The xxx is
}currently switched on" to descriptions of switchable objects and not to
}use when_on and initial and... so on. I don't know why Graham
}implemented certain features (e.g. talkable, which NO ONE uses).
Talkable is likely there for a puzzle in Curses.
David Thornley
>limits - which, with the advent of glulx (or whatever the heck it's
>called) have sort of evaporated anyhow.
>
likely to be on a handheld any time soon, I suppose.
Andrew Plotkin
As long as we're posting our histories... my first IF programming
project was XZip, and I did it because the Z-machine had coolness
factor and I wanted to play IF with a better interface.
I later considered doing an XTADS, but at that time the TADS source
code wasn't available.
So when I decided to write an IF game, Inform was the obvious choice.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* George W. Bush was elected with just five votes.
Andrew Plotkin
> In article <94qig8$i7a$1...@nnrp1.deja.com>,
> Kathleen M. Fischer <green_g...@my-deja.com> wrote:
>>
>>Seriously, I think an author has to work pretty hard to reach Informs
>>limits - which, with the advent of glulx (or whatever the heck it's
>>called) have sort of evaporated anyhow.
>>
> Which brings up the question of whether a glulx interpreter is
> likely to be on a handheld any time soon, I suppose.
The hangup is the Glk library. The interpreter engine itself should be
fairly easy to port -- although I'm a little worried about speed,
a priori.
OKB -- not okblacke
My perspective is a little bit different from most of those I've read
(mainly in that I disliked many of the things other people liked), so I'll
throw it into the mix. . .
The main reason I chose Inform was because I liked its syntax and its
whole modus operandi better. In addition to the "move cat to mat" business
that Adam Cadre mentioned, it was much easier for me to grasp the way the
object tree was constructed in Inform ("Object mat; Object -> cat;") than in
TADS. Also, the Inform library seemed much more understandable. When I took a
gander at the TADS library, it seemed to be a long list of object definitions
with tiny routines, which I couldn't make sense of.
TADS C-like syntax, which has apparently been a factor in its popularity,
was actually a turnoff for me, since I find C syntax unbearable. (Even Inform
still lugs around those silly semicolons, but c'est la vie.) I didn't find
the IDM particularly exciting to read (in fact, I sometimes found that its
tedency toward literacy actually obfuscated the meaning), but it was definitely
above average for a programming manual. The TADS manual was a bit of pain to
obtain, and when I did get it it was in a hard-to-navigate HTML format, which
deterred me somewhat.
I have no nostalgia for Infocom, having never played a single Infocom game
(except Return to Zork, which wasn't a text adventure), so the z-machine thing
was both unknown and meaningless to me. I didn't like "Curses" or "Jigsaw".
Most of the text games I played before starting to write IF were TADS games
(albeit run-of-the-mill TADS games), in fact.
I didn't even know there WERE memory limitations until I read the IDM for
the second time, and I haven't encountered these problems yet. Glulx seems
ready to banish such would-be obstacles forever, as well as providing support
for windows, graphics, lots of text styles, and that kind of cool stuff. Plus
it has @setiosys, which makes my heart take two leaps, with a little skip in
between. Barring some unforeseen horror, my next game will probably be written
in Glulx.
But the structure of the Inform library and language somehow seemed more
like what I wanted, so I went with Inform. After programming a bit, I took
another look at TADS, but by then I'd looked at C, and the similarity was
frightening. So I stuck with Inform. I think in the end, like everything,
it's a matter of personal taste.
--OKB (Bren...@aol.com) -- no relation to okblacke
"Do not follow where the path may lead;
go, instead, where there is no path, and leave a trail."
--Author Unknown
ical...@my-deja.com
> In article <94qg4j$g30$1...@nnrp1.deja.com>,
> ical...@my-deja.com wrote:
> > When I chose Inform, I was under the impression that its limitations
> > were large enough that I was "unlikely" to run up against them. They
> > weren't. :)
>
> I think your original impression is still true. Most people ARE
> unlikely to run up against the size limitations. You're just...
> unusual. <g>
Oh, gee, thanks! :)
> (besides, nothing makes you wrap up a game like lack of memory, eh?)
That's very true. If I hadn't bumped up against Inform's limits,
I might STILL be working on DC!
irene
ical...@my-deja.com
acfoure...@bard.edu wrote:
> On Fri, 26 Jan 2001 00:24:58 GMT, ical...@my-deja.com wrote:
>
> >In article <3a6fdf2c...@News.CIS.DFN.DE>,
> > acfoure...@bard.edu wrote:
> >
> >> Inform also has a nasty size limit -- see games like Dangerous
> >> Curves, which seemed like it had been so richly programmed that
> >> there wasn't any space left for a very long story.
> >
> >When I chose Inform, I was under the impression that its limitations
> >were large enough that I was "unlikely" to run up against them. They
> >weren't. :)
>
> That's a shame, because I loved DC -- one of the most fully-realized
> games I've played -- everything WORKED! The way I expected it to! (or
> didn't, given my expectations of IF.) It was one of the first games I
> played that actually made me feel like I was in a complete environment
> where I could go anywhere or do anything. I could get drunk! And
> drive! I was truly disappointed when the game itself was so short.
I had two goals with DC: to simulate a "real-life" environment as
closely as possible and to tell a story. I was very disappointed
when I reached Inform's limits so early on. The compromises I was
forced to make meant that I could not fully realize either of my
goals. But I'm glad DC worked well enough for you to get a sense
of being able to go anywhere and do anything within the game's
environment. That is exactly what I was trying to do. :)
Joe Mason
Adam Conover <acfoure...@bard.edu> wrote:
>>
>>I love the idea that I can play i-f on my PalmPilot. This was
>>one of the primary reasons I chose Inform instead of TADS.
>
>That too. I'm considering Inform now, actually... hm.
No longer as much of a factor - TADS has been released for the Psion. This
is enouhg of a killer app that next week I'm taking my Handspring Visor back
and ordering a Revo.
Of course, you can *compile* Inform on a Revo.
Joe
Sean T Barrett
>Good heavens, I didn't mean to discourage anyone from choosing Inform
>- I was just responding to Adam Cadre's remark that he didn't know
>(and didn't care) why TADS' syntax was considered better (from a
>theoretical point of view), despite being worse (from his point of
>view).
As someone who's been programming for twenty years and writing
compilers and interpreters for ten, I find that the "theoretical"
flaws in Inform mentioned above are not what bother me about
Inform (although I do perceive them as flaws), nor is it the
seemingly arbitrary use of even more bizarre symbols than C for
some operations (if you read enough C code, you'll find the
idiom "!!x" used; consider the equivalent in Inform, which
uses "~~" instead of "!").
Rather, the things that bother me about Inform are the library
(far too many hacks, arbitrary things seemingly done for the
sake of Curses, insufficient modularity to allow you to modify
the libraries effectively, the list goes on and on) and the
DM (it may be well written from an English major's standpoint,
but it's not a great piece of technical writing in its function
as a reference manual--important information hidden in exercises,
poorly organized and difficult to find what you're looking for,
many things left entirely undocumented or unexplained [e.g.
the implicit switch on action]; it's not the lousiest reference
manual I've seen, but it's certainly the lousiest well-written
reference manual I've seen, and I'm constantly boggled by the
praise the community bestows upon it; I suppose it must be a
good tutorial at least).
Of course I have 3 WIPs in Inform and none in TADS, because
(a) I learned Inform before I realized how significant those
flaws were, and (b) I don't know if TADS is any better and
have learned to live with the Inform flaws for now.
SeanB
Sean T Barrett
Then consider the examples
give door locked;
and
if (cherries has moved) { ... }
Going too far down the 'englishization' leads to things like:
if cherries has moved then give door locked.
if cherries has moved then give door the attribute locked.
if my_object is container then give door the attribute locked.
if my object is container then give door the attribute locked.
Finally, if one finds "obj.MoveTo(location)" confusing, one
should not compare it to the phrase "move object to location"
but instead to the phrase "object, move to location", which
very closely parallels underlying meaning of that syntax (although
Smalltalk comes even closer by allowing a 'preposition' preceding
each parameter).
SeanB
Mike Roberts
acfoure...@bard.edu wrote:
> Which reminds me -- is there any sort of time scale for the release of
> TADS 3 in a usable form? (IIRC, the compiler and interpreters are out,
> but no standard libraries?) MJR, if you're around -- any clues?
I still can't name a date, sadly; I've been distracted with other
things for a few months, so progress has been slow. I'm very eager to
get it finished, though.
--
mjr underscore at hotmail dot com
Adam Conover
wrote:
>In article <3a7068c4...@News.CIS.DFN.DE>,
> acfoure...@bard.edu wrote:
>> Which reminds me -- is there any sort of time scale for the release of
>> TADS 3 in a usable form? (IIRC, the compiler and interpreters are out,
>> but no standard libraries?) MJR, if you're around -- any clues?
>
>I still can't name a date, sadly; I've been distracted with other
>things for a few months, so progress has been slow. I'm very eager to
>get it finished, though.
Hey, don't feel obligated -- TADS 2.2 is much more than I'd expect
from a free tool in the first place!
A question, though: if I learn TADS now (i'm beginning to), will I
have to completely relearn it for TADS 3, or will TADS3's upgrades be
more or less backwards-compatible with TADS 2.2 syntax?
OKB -- not okblacke
>(far too many hacks, arbitrary things seemingly done for the
>sake of Curses, insufficient modularity to allow you to modify
>the libraries effectively, the list goes on and on)
I agree about the insufficient modularity. The Replace directive only
allows you to replace entire routines, and since some of the routines are
behemoths, it means you have to cut-and-paste the whole dang thing, which seems
like a real stone-age kind of solution. So if you just want to add one little
line into this giant routine, you've got to either hack the actual library file
or copy the whole thing.
Yeah, geez, gripe, gripe gripe. It's still a very good language, so I'll
be quiet.
Carl Muckenhoupt
Are you implying that English isn't bizarrely arbitrary?
Carl Muckenhoupt
Barrett) wrote:
> if cherries has moved then give door locked.
> if cherries has moved then give door the attribute locked.
> if my_object is container then give door the attribute locked.
> if my object is container then give door the attribute locked.
This looks a lot like some scripts I've seen in Macromedia Director.
Director (or rather, Lingo, which is Director's scripting language)
generally lets you refer to properties by either C-like "dot notation"
(sprite(10).height) or a more verbose, Enlish-like notation (the
height of sprite 10). The fact that both forms are accepted means
that the keyword "the" is actually required for disambiguation.
Relevance to IF? There are a lot of bad Myst clones out there written
in Director. Which is a little ironic, come to think of it. The
scripting language supports something similar to what a text adventure
parser would accept, but the resulting game is entirely
point-and-click.
Alan Trewartha
> No longer as much of a factor - TADS has been released for the Psion. This
> is enouhg of a killer app that next week I'm taking my Handspring Visor back
> and ordering a Revo.
>
> Of course, you can *compile* Inform on a Revo.
which elliptically gives my reason for Informing rather than TADding. I'm
on a bonkers unused platform that may as well be in the North Sea on a
particularly nasty day weather-wise. Fortunately it's the same platform
that Graham wrote Inform on, so there is an interpreter and (crucially for
this discussion) a compiler -- dare I say it, *THE* compiler ;-)
For those not in the know (shame on you) Graham wrote Inform on an "Acorn"
computer (probably originally an Archimedes, and latterly a RiscPC). These
machines (manufactured by the now defunct Acorn) were the first home
computers with a RISC chip -- an ARM processor.
<elliptical_ramble>
All Psions (and almost all mobile phones!) now use ARM chips, largely
because of their low power consumption. Acorn also built the computers
used to fly Doctor Who's TARDIS -- but that's another story.
</elliptical_ramble>
Not really illuminating for the original asker of the question, but I
thought I'd add to this growing thread.
Matthew T. Russotto
Alan Trewartha <al...@no.spam.demon.co.uk> wrote:
}
}<elliptical_ramble>
}All Psions (and almost all mobile phones!) now use ARM chips, largely
}because of their low power consumption. Acorn also built the computers
}used to fly Doctor Who's TARDIS -- but that's another story.
}</elliptical_ramble>
Whereas Microsoft wrote the controller for the shape-changer?
Dan Schmidt
| Dave Holland <da...@biff.org.uk> wrote:
| >Adam Conover <acfoure...@bard.edu> wrote:
| >> move cat to mat; seems bizarrely arbitrary.
| >
| >That's odd. I thought your English was pretty good...
|
| Then consider the examples
|
| give door locked;
| and
| if (cherries has moved) { ... }
The thing that always boggles me is
give door ~~locked;
which always takes me by surprise whenever I'm coming back to Inform
after a break. Give the door the absence of a property? (Or maybe
that's an attribute, I forget.)
'set door locked' and 'set door ~~locked' would actually be okay by
me, I guess.
Dan Schmidt
| Rather, the things that bother me about Inform are the library
| (far too many hacks, arbitrary things seemingly done for the
| sake of Curses, insufficient modularity to allow you to modify
| the libraries effectively, the list goes on and on) and the
| DM (it may be well written from an English major's standpoint,
| but it's not a great piece of technical writing in its function
| as a reference manual--important information hidden in exercises,
| poorly organized and difficult to find what you're looking for,
| many things left entirely undocumented or unexplained [e.g.
| the implicit switch on action]; it's not the lousiest reference
| manual I've seen, but it's certainly the lousiest well-written
| reference manual I've seen, and I'm constantly boggled by the
| praise the community bestows upon it; I suppose it must be a
| good tutorial at least).
Agreed with you on the library. It functions well as is, but actually
changing and extending it is a big pain compared to any of the TADS
libraries I've seen.
I cut the DM a good bit of slack because it's so much better than the
2nd edition, which has the same flaws you mention but tenfold. Graham
obviously tried to remedy them (and mostly succeeded), which I have to
give him credit for.
But anyway, these things largely are a matter of taste. Plenty of
people think that Programming Perl 2nd ed is the best manual ever,
while I find that it suffers a lot from not deciding who its audience
is (this may be a result of having three authors). Luckily, as with
Inform, the next edition of the book was a lot better.
Magnus Olsson
Sean T Barrett <buz...@world.std.com> wrote:
>Dave Holland <da...@biff.org.uk> wrote:
>>Adam Conover <acfoure...@bard.edu> wrote:
>>> move cat to mat; seems bizarrely arbitrary.
>>
>>That's odd. I thought your English was pretty good...
>
>Then consider the examples
>
> give door locked;
>and
> if (cherries has moved) { ... }
>
>Going too far down the 'englishization' leads to things like:
>
> if cherries has moved then give door locked.
> if cherries has moved then give door the attribute locked.
> if my_object is container then give door the attribute locked.
> if my object is container then give door the attribute locked.
COBOL actually has a "feature" like this: alternative syntaxes
that get more and more verbose, or, alternativeely put, a lot of
optional syntax elements. A simple example: where most programming languages
would have something like
x = y / 2;
COBOL has
DIVIDE 2 INTO Y GIVING X.
Back to Inform: one drawback of the almost-English syntax is that when
it breaks down, it does so big time. I wonder how many beginning
Inform programmers ahve by mistake written
if (player has sword)
instead of
if (sword in player)
Paul O'Brian
> The thing that always boggles me is
>
> give door ~~locked;
Or even worse, "give door ~open;". (I don't think the double-~ is
necessary, is it?) At least the opposite of "locked" is "unlocked", and I
can get my brain to translate "~locked" into "unlocked." I have much more
trouble getting it to automatically see "~open" as "closed." I've had many
an unconscious moment in which I've written code like "give box closed;".
--
Paul O'Brian obr...@colorado.edu http://ucsu.colorado.edu/~obrian
Ready or not, here comes SPAG! Issue #23 is the annual competition special,
featuring interviews with top authors and a treasure trove of reviews!
Mike Roberts
acfoure...@bard.edu wrote:
> A question, though: if I learn TADS now (i'm beginning to), will I
> have to completely relearn it for TADS 3, or will TADS3's upgrades be
> more or less backwards-compatible with TADS 2.2 syntax?
More or less compatible is a good way to put it. You won't be able to
take code written for tads 2 and recompile it with tads 3, mostly
because the library will be so different. The language, though, is
mostly the same - some extensions, some gratuitous changes to make
it "better" (mostly to make it more consistent with Java and C syntax) -
but the learning curve if you're already familiar with tads 2 should
be pretty negligible. And, even though I just said the library will be
completely different, it will be clear that it's based on the tads 2
library, so a lot of it will be familiar even if the details are
different.
My goal and hope is that tads 2 users will find that tads 3 retains the
things they liked about tads 2, but adds many of the things they always
wished they could do.
--Mike
Adam Conover
wrote:
>My goal and hope is that tads 2 users will find that tads 3 retains the
>things they liked about tads 2, but adds many of the things they always
>wished they could do.
Great! Thanks, Mike!
Paul E. Bell
Speaking of Inform's limitations, I have two comments:
1) I'm sure that the limitations are one of the considerations in making
the library such as it is. If it were more modular, then the limitations
set by the Z-machine would mean less available functions for writing games.
2) Has anyone even tried to take advantage of Inform's ability (such as it
is) to save player information, and load it into another game (presumably a
continuation of the current game)?
This is something I might like to experiment with, some time, and see what
can become of it. Granted, anything one carries with him from one game to
the next, must be implemented in that next game (objects being carried, for
instance), but, I'm sure that somehow, it could be coded to have the player
leave anything that wasn't universally necessary to the various sections of
the game behind. Like I said, I haven't experimented with this, yet, but,
it would seem that the potential is there to write much larger games than
the Z-machine limits you to.
--
Paul E. Bell | Email and AIM: wd0...@millcomm.com | ifMUD: Helios
IRC: PKodon, DrWho4, and Helios | webpage: members.nbci.com/wd0gcp/
Member: W.A.R.N., Skywarn, ARES, Phoenix Developer Consortium, ...
_____ Pen Name/Arts & Crafts signature:
| | _ \ _ _ |/ _ _(
| | (_X (_/`/\ (_) (_` |\(_) (_) (_|_) (/`
)
Paul E. Bell
<3a6fdf2c...@News.CIS.DFN.DE>:
>Ok. Here's something I don't quite get.
>
>TADS came out before Inform. TADS has clearer syntax than Inform -- or
>at least, it seems to to me since I have some experience with C. I
>assume that others would feel the same way -- and, in any case, I've
>heard complaints that Inform's syntax doesn't really make much sense.
>Inform also has a nasty size limit -- see games like Dangerous Curves,
>which seemed like it had been so richly programmed that there wasn't
>any space left for a very long story. (Yes, I loved DC.) Yes, Inform
>runs on the Z-Machine, which is really cool, I admit, and its
>interpreters seem nicer than the equivalents for TADS (I love DOS
>Frotz) -- but this doesn't seem like it would affect people's
>decisions. Finally, TADS came out before Inform, so it's not as if
>there was a large number of people already programming in it -- it had
>to make up for lost time in the language race, so to speak.
>
>So, my question is: why are there so many more games released for
>Inform than TADS? I feel like I must be missing something here, some
>huge benefit to using Inform that I haven't considered. Authors: why
>did you choose Inform over TADS? I'm sure this subject has already
>caused enough flame-wars, but think of it as explaining the situation
>to someone who just doesn't get it.
Hmm. You know, I don't really remember. I know that, my first encounter
with Interactive Fiction was Zork II, which my brother-in-law had for his
NCR Decision Mate V. In fact, my dad got so hooked on that game that he
spent months playing it over and over again, trying to figgure out how to
win the game in the least number of moves. I think he was able to win the
game in somewhere around 8 less moves than the then-published minimum ever
attained. But, I digress...
When I started looking around for ways to write this kind of stuff, I found
Inform and TADS, however, as I was out of work at the time, I could not
afford to send anything in for TADS registration, or to buy a manual, but I
could get Inform. Then I found out that I could use Inform on my Amiga,
and couldn't use TADS on it, so, that clinched it. As for the interpreter
for Inform also working with the Infocom games, that was just a bonus. I
started collecting PC versions of the Infocom games, and using the game
files on my Amiga, using Frotz.
I sent in bug reports for the Inform libraries, especially when we moved
from Inform 5.5 to Inform 6. I got so involved with Inform that I didn't
have time to look at TADS, even to see if it was out for the Amiga. When I
got a PC of my own, and got on the internet, I moved my Inform stuff to the
PC.
Well, I have some other comments, but I will save those for reply to the
appropriate message.
Paul E. Bell
>On Thu, 25 Jan 2001 13:12:49 -0800, Adam Cadre <a...@adamcadre.ac>
>wrote:
>
>>Adam Conover wrote:
>>> Authors: why did you choose Inform over TADS?
>>
>>(1) The manual begins, "In trying to be both a tutorial and reference
>>work, this book aims itself in style halfway between the two extremes
>>of manual, Tedium and Gnawfinger's Elements of Batch Processing in
>>COBOL-66, third edition, and Mr Blobby's Blobby Book of Computer Fun.
>>(This makes some sections both leaden and patronising.)" This remains
>>one of the most wonderful paragraphs I have even encountered. I was
>>sold.
>
>Oh, I heartily agree.
>
>>(2) You speak of TADS's "clearer syntax," but I am not a programmer
>>and found Inform much more intuitive: "move cat to mat;" (Inform) vs.
>>"cat.moveInto(mat);" (TADS). The TADS version may better achieve some
>>ideal of object-oriented consistency or whatnot, but I couldn't care
>>less about that -- it makes my eyes bleed, so no thanks.
>
>Ah. That's the thing. Like I said, I was raised on C -- I don't
>currently program, but that's how my mind thinks. Also, for years I
>was programmed objects on MOOs, which for the uninformed are a
>descendent of MUDs, but are social areas where anyone can program. The
>interface resembles IF with a simplified parser ("verb direct objects
>prep. indirect object") -- and its programming language is as
>object-oriented as one can get. So yes, "cat.moveInto(mat);" DOES make
>more sense to me, and move cat to mat; seems bizarrely arbitrary.
Regardless of what you were raised on, I know C and C++, but, there is
something about 'move cat to mat' that speaks to me that the game is doing
the move, whereas 'cat.moveInto(mat)' seems to me that I have to write a
moveInto() property for every object in the game, which can be moved. It
speaks to me of unnecessary code duplication, and unnecessary fiddling on
my part, more overhead, and bigger game files. Perhaps that's just a
perception, perhaps TADS doesn't require me to run 'key.moveInto(lock)' or
'sandwich.moveInto(refrigerator)' when I put those things in those places,
or to write a moveInto() property for the key and the sandwich, but it sure
looks that way.
OTOH, if TADS adds a moveInto() property/routine to every object that is
not a room or scenery object, which is really a pointer to a common piece
of code, and the only time I have to deal with it is if I need to change
it, that's another story entirely.
As it sits now, I will stick with Inform syntax, and explore TADS further,
as time permits.
Adam Conover
wrote:
>Regardless of what you were raised on, I know C and C++, but, there is
>something about 'move cat to mat' that speaks to me that the game is doing
>the move, whereas 'cat.moveInto(mat)' seems to me that I have to write a
>moveInto() property for every object in the game, which can be moved. It
>speaks to me of unnecessary code duplication, and unnecessary fiddling on
>my part, more overhead, and bigger game files. Perhaps that's just a
>perception, perhaps TADS doesn't require me to run 'key.moveInto(lock)' or
>'sandwich.moveInto(refrigerator)' when I put those things in those places,
>or to write a moveInto() property for the key and the sandwich, but it sure
>looks that way.
>
>OTOH, if TADS adds a moveInto() property/routine to every object that is
>not a room or scenery object, which is really a pointer to a common piece
>of code, and the only time I have to deal with it is if I need to change
>it, that's another story entirely.
If I remember correctly (it's been awhile since I was learning TADS --
working on Inform right now), .moveInto() is a function (routine,
verb, whatever) defined on the parent class "object." The default code
is only written once, so there's no redundancy -- less, probably, than
Inform has, since .moveInto() is formed from more basic-level code. (I
could be way off-base here, however, since I don't have much insight
into the workings of either language.) And yes, you can override
moveInto() if you want to, without rewriting the whole thing -- you
could, for instance, have a new message be printed, then pass
execution to the original function.
Just to clarify. ;)
Mona Wuerz
wd0...@millcomm.com (Paul E. Bell) wrote:
> OTOH, if TADS adds a moveInto() property/routine to every object that is
> not a room or scenery object, which is really a pointer to a common piece
> of code, and the only time I have to deal with it is if I need to change
> it, that's another story entirely.
And this is exactly what happens: TADS' library (adv.t) defines the
class 'thing' whose properties and methods all other common objects
inherit. The moveInto() method is defined exactly once - for the
'thing' class. Therefore, unless you can't live with the defined method
for some reason, you would not code moveInto() for a single object. All
you do is say
myobject : item;
and you're done ('item' is also defined in 'adv.t' and it inherits from
'thing'). (Would be kind of un-OOP if it were otherwise.)
-mona
J. Robinson Wheeler
> People get warm fuzzies from writing to the same virtual machine that
> Infocom did.
>
> It's a bigger factor than I would have realized.
Actually, what gave me the warm fuzzies was when I started Being
Andrew Plotkin, and being able to compile to the same virtual machine
that Zarf had used, which meant I could reproduce certain text effects
(e.g. emphasis) exactly. That was pretty cool.
I started with TADS. Its syntax made instant sense to me (barring the
usual confusion at first with indirect object verification methods).
While I was learning TADS by writing a large game with it, I used to
read the Inform threads on the group. Everything with Inform seemed
to be about hacking into the library and doing all sorts of bizarre
programming contortions.
I learned Inform by doing a small sample game, a partial port of one
of my TADS games, and then the Coke Is It! project. I didn't pick it
up again until I started BAP, by which point it made sense to me at
a certain level, and was more intuitive than I thought, up to a point.
However, I did start modifying TADS's output to match the generic
Inform/z-machine look, because I liked it a little better.
What it seems to me is that I still have no clue how to do anything
with Inform that's particularly complicated. I use basic objects and
basic verbs and don't try to go beyond that. With TADS, I have a bit
more of a clue how to get the language to do specialized actions.
At this point, having released about an equal number of games in each,
I must say that I'm kind of being seduced by Inform and the z-machine.
The games I write run on more machines, including Palms. The games put
in the zcode directory on gmd get five times as many downloads. They
look good when you play them in DOS Frotz. Kind of superficial reasons,
but they're having an effect on my thinking.
--
J. Robinson Wheeler http://thekroneexperiment.com
whe...@jump.net
Magnus Olsson
Paul E. Bell <wd0...@millcomm.com> wrote:
>Regardless of what you were raised on, I know C and C++, but, there is
>something about 'move cat to mat' that speaks to me that the game is doing
>the move, whereas 'cat.moveInto(mat)' seems to me that I have to write a
>moveInto() property for every object in the game, which can be moved.
(...)
>It
>speaks to me of unnecessary code duplication, and unnecessary fiddling on
>my part, more overhead, and bigger game files.
And you say this despite knowing C++? Surely you can't have missed the
concepts called "object orientation" and "inheritance", can you?
OK, you seem to be talking about superficial appearances here - the
first impression you get from a language, right? In that case, it just
shows how dangerous going by superficial appearances is - like
deciding on not buying a car because it looks like it may handle badly
on icy roads, without actually test-driving it.
Yes, I know, many people *do* select IF systems by superficial
appearance, especially non-programmers.
Magnus Olsson
>(far too many hacks, arbitrary things seemingly done for the
>sake of Curses, insufficient modularity to allow you to modify
>the libraries effectively, the list goes on and on)
Agreed. I think *the* major deficiency of the library is its lack of
modularity - there are these huge routines with some switch statement
buried in the middle, and to modify the behaviour of one of your
objects you sometimes have to add a case to that switch statement, something
which is only possible if you replace the entire routine.
>and the
>DM (it may be well written from an English major's standpoint,
>but it's not a great piece of technical writing in its function
>as a reference manual--important information hidden in exercises,
>poorly organized and difficult to find what you're looking for,
>many things left entirely undocumented or unexplained [e.g.
>the implicit switch on action]; it's not the lousiest reference
>manual I've seen, but it's certainly the lousiest well-written
>reference manual I've seen, and I'm constantly boggled by the
>praise the community bestows upon it; I suppose it must be a
>good tutorial at least).
It's not a very good reference manual, no, but writing a good
reference manual for something as complex as the Inform library is no
mean task. As for why this isn't mentioned more often: well, I think
most people simply don't read reference manuals.
Alan Trewartha
<URL:mailto:russ...@wanda.vf.pond.com> wrote:
> }because of their low power consumption. Acorn also built the computers
> }used to fly Doctor Who's TARDIS -- but that's another story.
> }</elliptical_ramble>
>
> Whereas Microsoft wrote the controller for the shape-changer?
No, I think the Chameleon Circuit was a Sinclair product with a very wobbly
RAM pack. If only the doctor had realised a big slab of blu-tak would steady
the thing, then the whole Logopolis thing would never have happened.
sorry
I'll shut up
Dan Schmidt
| Regardless of what you were raised on, I know C and C++, but, there
| is something about 'move cat to mat' that speaks to me that the game
| is doing the move, whereas 'cat.moveInto(mat)' seems to me that I
| have to write a moveInto() property for every object in the game,
| which can be moved. It speaks to me of unnecessary code
| duplication, and unnecessary fiddling on my part, more overhead, and
| bigger game files. Perhaps that's just a perception, perhaps TADS
| doesn't require me to run 'key.moveInto(lock)' or
| 'sandwich.moveInto(refrigerator)' when I put those things in those
| places, or to write a moveInto() property for the key and the
| sandwich, but it sure looks that way.
|
| OTOH, if TADS adds a moveInto() property/routine to every object
| that is not a room or scenery object, which is really a pointer to a
| common piece of code, and the only time I have to deal with it is if
| I need to change it, that's another story entirely.
I'm surprised that that you have that perception, given that you know
C++.
moveInto is a virtual function, in C++ talk (as are all methods in
TADS). It's defined once, on class 'thing', and there is only one
copy of it in the .gam file. All objects that inherit from 'thing'
inherit moveInto behavior as well.
John Elliott
>In article <ant26205...@alant.demon.co.uk>,
>Alan Trewartha <al...@no.spam.demon.co.uk> wrote:
>}
>}<elliptical_ramble>
>}All Psions (and almost all mobile phones!) now use ARM chips, largely
>}because of their low power consumption. Acorn also built the computers
>}used to fly Doctor Who's TARDIS -- but that's another story.
>}</elliptical_ramble>
Not only that - in the Doctor Who universe, Acorn also supplied the
computers for:
* Controlling a whole load of androids for an insane villain;
* The nuclear missile guidance and launch system for a secret undersea
base.
>Whereas Microsoft wrote the controller for the shape-changer?
Sounds reasonable. The technobabble for it is based on the Z80 instruction
set, and Microsoft did write Z80 software.
--
------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott |BLOODNOK: "But why have you got such a long face?"
|SEAGOON: "Heavy dentures, Sir!" - The Goon Show
:-------------------------------------------------------------------------)
Kevin Forchione
news:94rp1q$bpu$1...@news.lth.se...
> In article <3a70017a...@News.CIS.DFN.DE>,
> Adam Conover <acfoure...@bard.edu> wrote:
> >On 25 Jan 2001 22:25:38 GMT, m...@pobox.com (Magnus Olsson) wrote:
> >
> >>Actually, the advantage of the TADS notation is that it's general.
> >>"move cat to mat" is easy to read, but Inform doesn't allow you to
> >>define new operators like that, but forces you to use different syntaxes
> >>in different places.
>
> (snip)
>
> >>Of course, this is far from apparent to the beginner.
> >
> >Dammit. I was just in the middle of reading the DM front to back for
> >the first time... now I'm all confused again.
>
> Good heavens, I didn't mean to discourage anyone from choosing Inform
> - I was just responding to Adam Cadre's remark that he didn't know
> (and didn't care) why TADS' syntax was considered better (from a
> theoretical point of view), despite being worse (from his point of
> view).
>
> But regardless of whether you agree with me or Adam C, this is a
> relatively unimportant matter in the big picture. It shouldn't really
> be decisive one way or the other.
Whether you work in Inform or TADS, or any other language for that matter,
the Inform Designer's Manual is a tremendous resource for model world
puzzles -- challenges that I've used to push my library developments to the
envelop.
--Kevin
Matthew Russotto
I guess that beats the major prevaling theory: Lucas Electrics
Francis Avila
news:G7s9t...@world.std.com...
> In article <94rp1q$bpu$1...@news.lth.se>, Magnus Olsson <m...@pobox.com>
wrote:
> Inform (although I do perceive them as flaws), nor is it the
> seemingly arbitrary use of even more bizarre symbols than C for
> some operations (if you read enough C code, you'll find the
> idiom "!!x" used; consider the equivalent in Inform, which
> uses "~~" instead of "!").
Hmm, while I'm hardly qualified to comment on the problems of any language
(and my not being able to use it well is something I identify as a problem
with myself, not the language, at least at this stage) I will comment that
this little piece of Inform syntax (~~ logical not, ~ for negating
properties) never struck me as odd. It's like grade school Math, remember?
(Though that was admittedly a very long time ago.) When we'd take logic,
the usual notation for NOT (or false, when used with a variable) was ~. The
tilde. In fact, its something I've used ever since then when jotting down
quick notes, where an English 'not' would take too long to write.
But as for '!', that truly makes no sense to me. I can't see where one
would have gotten that.
There was also another comment about difficulties with attributes (e.g.
'~open' being 'closed') which never really struck me either. Sort of like
"light is the absence of dark, not a thing in itself." Or "evil is the
privation of a due good," and some such. They're not things in themselves,
but the lack of something else. Since most things do not admit of an open
state, it makes sense to me that 'open' would mean that an object is open,
and '~open' would mean that it admits of no such state of being open, and
acts like normal. Similarly with all other attributes: they're special
logical exceptions, and their not being there doesn't mean that their
opposite is true, but that they themselves are false. (Next time you try to
go through a door, instead of thinking, "The door is closed," try "the door
is not open.")
Admittedly, this is a very philosophical way of thinking of things, but it
makes sense to me.
BTW, attributes *do* use only one ~. Remember that they admit of only two
states and thus are bitwise. The bitwise operator is a single ~, whereas
the logical one is a double tilde.
--
Francis Avila
Branko Collin
wrote:
>2) Has anyone even tried to take advantage of Inform's ability (such as it
>is) to save player information, and load it into another game (presumably a
>continuation of the current game)?
I do not know if this has been tried, but there has been talk about
it. See Dejanews or the rai-f specific archive of postings.
Unfortunately, I remember nothing else about that thread.
--
branko collin
col...@xs4all.nl
Del Murray
I want to write stories. I want to create worlds. I want to construct
puzzles. I want to paint landscapes, and portraits.
I will just about suffer to become a computer programmer.
As someone who knows nothing of C, C++, KOBOLD, or any of these things,
I'm dismayed by the entire 'non-programmers pick Inform because it
caters to simpletons' stance that is being slowly but steadily implied
in this thread. Is IF a programming exercise? Or a _gaming_ one?
Having something to say is more important than an excellent command of
the language. In whatever language.
Worry about the game first. Once that is done then worry about the
player. Once that is done then worry about the language.
D xx
Magnus Olsson
Del Murray <del...@razorblade.co.uk> wrote:
>As someone who knows nothing of C, C++, KOBOLD, or any of these things,
>I'm dismayed by the entire 'non-programmers pick Inform because it
>caters to simpletons' stance that is being slowly but steadily implied
>in this thread.
I'm really sorry if I've in any way contributed to furthering that
attitude.
And, for the record, I don't think Inform "caters to simpletons".
However, what I do find interesting is that a number of people have
stated that they chose Inform over TADS because it "looked easier"
to them, as non-programmers. Why is it interesting? Not because I want
to laught at the poor non-programmers for being easily impressed, but
because it's an important lesson
a) for people who design languages - apparently, it's important for
beginners that the language shouldn't look too intimidating and
confusing; if it's easy for a newcomer to read and understand what
the code deos, then that person will probably find the language easier
to use. Both TADS and Inform could do better in this regard, though
apparently Inform is better at this than TADS.
b) for us others who are trying to ease the pains of people trying to
learn to write IF - if we know exactly what people find difficult or
easy about, say, Inform, we can try to do things to make the difficult
parts easier.
I hope we can agree on that.
>Is IF a programming exercise? Or a _gaming_ one?
Both. But I don't really see your point here - shouldn't we care about
making easy-to-use tools for IF writing?
>Having something to say is more important than an excellent command of
>the language. In whatever language.
In IF, unfortunately, if you don't have a command of the language, you
can't say *anything*.
>Worry about the game first. Once that is done then worry about the
>player. Once that is done then worry about the language.
Right. So when you've finished worrying about the game and the player,
it will just go ahead and write itself? Dream on...
Magnus Olsson
Francis Avila <fran...@mindspring.com> wrote:
>When we'd take logic,
>the usual notation for NOT (or false, when used with a variable) was ~. The
>tilde. In fact, its something I've used ever since then when jotting down
>quick notes, where an English 'not' would take too long to write.
>
>But as for '!', that truly makes no sense to me. I can't see where one
>would have gotten that.
The notation ~P for "not P" is common, yes, but there's also another one,
where the tilde is replaced by a little "hook" (like a minus sign with
a small downstroke at the left end). Perhaps C's "!" evolved from
that?
>There was also another comment about difficulties with attributes (e.g.
>'~open' being 'closed') which never really struck me either. Sort of like
>"light is the absence of dark, not a thing in itself." Or "evil is the
>privation of a due good," and some such. They're not things in themselves,
>but the lack of something else.
The problem, I think, is to remember whether openness is the negation
of closedness or vice versa - that is, whether it's open/~open or
closed/~closed. One way of simplifying this would be to let the
language allow the definition of something like C's "enums" - that is,
you say, casically, that the attribute called "openness" can take the
two values, "open" or "closed", rather than saying that the attribute
"open" can take two values, true or false.
Neil Cerutti
>There was also another comment about difficulties with attributes (e.g.
>'~open' being 'closed') which never really struck me either. Sort of like
>"light is the absence of dark, not a thing in itself." Or "evil is the
>privation of a due good," and some such.
Along the same lines, Inform's library chooses some unfortunate
negatives occasionally. I get confused writing parse_name
routines when I have to decide what return value I need to
say two objects are *not* indestinguishable. Yuck.
There was a terrific thread years back in which Dave Baggett made
many intelligent criticism's of Inform, and Graham Nelson
responded. Anyone who's reading this thread and hasn't read that
thread will find it very interesting. Unfortunately, I don't know
where it can be found any more. Anybody have it?
--
Neil Cerutti <cer...@together.net>
Stephen Granade
"people are implying that Inform is for simpletons" assertion aside
for the nonce. However:
Del Murray <del...@razorblade.co.uk> writes:
> Having something to say is more important than an excellent command of
> the language. In whatever language.
Perhaps, but this is edging rather too close to "the idea is the most
important thing" for my taste.
Ideas are cheap. I've got a barrelful of them sitting in a spare room
of my apartment. They gibber like mad, demanding that I do something
with them.
Similarly, "something to say" isn't that difficult. (Note that I did
not say "something worthwhile to say.") Plenty of people have things
to say.
Turning those ideas or statements into art of any kind, be it a novel,
a play, a painting, a sculpture, a symphony, or a game, is where the
work is.
> Worry about the game first. Once that is done then worry about the
> player. Once that is done then worry about the language.
These are not independent factors. Which tool you choose will affect
what game you create. It's no good wanting to make your own version of
a Picasso painting and then picking up a Bob Ross kit to do so.
Stephen
--
Stephen Granade | Interested in adventure games?
sgra...@phy.duke.edu | Visit About Interactive Fiction
Duke University, Physics Dept | http://interactfiction.about.com
Andrew Plotkin
> I want to write stories. I want to create worlds. I want to construct
> puzzles. I want to paint landscapes, and portraits.
> I will just about suffer to become a computer programmer.
Good. It's necessary.
> As someone who knows nothing of C, C++, KOBOLD, or any of these things,
> I'm dismayed by the entire 'non-programmers pick Inform because it
> caters to simpletons' stance that is being slowly but steadily implied
> in this thread. Is IF a programming exercise? Or a _gaming_ one?
> Having something to say is more important than an excellent command of
> the language. In whatever language.
Yes. However, if you can't program, you won't be able to say it.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* George W. Bush was elected with just five votes.
Magnus Olsson
> Having something to say is more important than an excellent command of
> the language. In whatever language.
This depends a lot on what you're doing. If you're doing
ground-breaking science, say, people are willing to decipher awful prose
in order to understand your great ideas - though an excellent command
of language helps in communicating your ideas.
If you're writing literature, it's almost the opposite. Sure, you must
have something to say, but if it's badly written nobody will want to
read it.
IF is like literature in this aspect, and then I'm not just referring
to the text, but to the programming as well. What use is it to have
the most marvellous ideas for puzzles, if you can't implement those
puzzles? How many good puzzles haven't we seen that were marred by bad
implementation? And, more importantly, how many good puzzles have we
*not* seen, because the person who had the idea didn't know how to
implement them?
John Colagioia
> Ok. Here's something I don't quite get.
[...]
> So, my question is: why are there so many more games released for
> Inform than TADS? I feel like I must be missing something here, some
> huge benefit to using Inform that I haven't considered. Authors: why
> did you choose Inform over TADS? I'm sure this subject has already
> caused enough flame-wars, but think of it as explaining the situation
> to someone who just doesn't get it.
Well, I wouldn't exactly call myself an "author" quite yet, having about
200K of miscellaneous source code intended to be parts of various
semi-abortive games, plus two "finished" works that I'm trying to bring
into a publically-presentable form.
However, I latched onto Inform the moment I saw it, and never really
bothered looking at TADS. I'd say I found it first, but that's not really
accurate, because I worked with a handful of primitive "adventure
construction sets" about ten years ago.
However, I think the reason is that I simply like the language--it has the
right "feel" for the way I view IF. I've worked in LOGO, BASIC, Fortran,
Pascal, C, C++, Java, APL, and...well...actually quite a few other
languages. Inform isn't the pinnacle of object-orientation, but I don't
really see that as a necessity, to be honest. It has a few "asymmetries"
in its syntax, but I actually find them (relatively) useful, since it
reminds me that I'm working in different "domains" of the game. It
doesn't look quite like any other language I've used, but, then, given the
list of things I've worked with, that's not really an issue--and, in fact,
I like my languages to look different, for some reason. If I had one
major complaint with Inform, it's actually the similarities to C, believe
it or not.
To give a quick data point regarding "initial learning curve," I teach a
course in programming languages, and I often use Inform to highlight
certain concepts about objects (inheritance and the like).
Students--graduates and undergraduates--take to it like it was second
nature. LOGO confused them. Go figure.
Anyway, one point I do find useful regarding Inform is the Z-Machine. Not
necessarily because Infocom used it (although that is fairly neat), but
because I know that any game I release (if I were to ever actually finish
and release a game) is usable on literally dozens of platforms, and its
behavior is nearly identical across the board--including on the C=64 that
sits in in my desk drawer and the TRS-80 my friend occasionally boots up
for nostalgia value...
...OK, I haven't quite figured out how to get it TO the TRS-80, yet, but
once I do...
Richard Bos
> As someone who knows nothing of C, C++, KOBOLD, or any of these things,
> I'm dismayed by the entire 'non-programmers pick Inform because it
> caters to simpletons' stance that is being slowly but steadily implied
> in this thread.
Well, for that matter, I like to think that I do know quite a bit about
C, and I still chose Inform. For reasons, I might add, that have nothing
to do with the language itself. But if I see the descriptions of TADS,
maybe I got lucky - I really do not like OO.
> Having something to say is more important than an excellent command of
> the language. In whatever language.
That is only true as long as you have enough command of the language
used for your mistakes not to get into the way of the message. After
all, hardly anybody likes h@x0r sp33k or ungrammerticul languge.
Richard
Richard Bos
> Hmm, while I'm hardly qualified to comment on the problems of any language
> (and my not being able to use it well is something I identify as a problem
> with myself, not the language, at least at this stage) I will comment that
> this little piece of Inform syntax (~~ logical not, ~ for negating
> properties) never struck me as odd. It's like grade school Math, remember?
> (Though that was admittedly a very long time ago.) When we'd take logic,
> the usual notation for NOT (or false, when used with a variable) was ~. The
> tilde. In fact, its something I've used ever since then when jotting down
> quick notes, where an English 'not' would take too long to write.
>
> But as for '!', that truly makes no sense to me. I can't see where one
> would have gotten that.
In C, ~ is the bitwise reverse. ! is the logical negation. IIRC it was
derived from !=, which again was derived from the mathematical
doesn't-equal sign. IOW, it's for hysterical raisins.
Richard
Daryl McCullough
>
>Del Murray <del...@razorblade.co.uk> wrote:
>> Having something to say is more important than an excellent command of
>> the language. In whatever language.
>
>Yes. However, if you can't program, you won't be able to say it.
Unless you get a collaborator who will handle the programming
part. There used to be an IF Collaborators list to pair writers
with programmers.
--
Daryl McCullough
CoGenTex, Inc.
Ithaca, NY
Eric Mayer
<del...@razorblade.co.uk> wrote:
>Aaarrgghh!
>
>I want to write stories. I want to create worlds. I want to construct
>puzzles. I want to paint landscapes, and portraits.
>
>I will just about suffer to become a computer programmer.
>
>As someone who knows nothing of C, C++, KOBOLD, or any of these things,
>I'm dismayed by the entire 'non-programmers pick Inform because it
>caters to simpletons' stance that is being slowly but steadily implied
>in this thread. Is IF a programming exercise? Or a _gaming_ one?
>
A word from a total nonprogrammer (me) might be in order :) I've
written a couple of short games in ALAN and I've had a lot of fun
doing so. When I discovered these old fashioned text games alive on
the web I thought they were amazing and the lure of being able to
write one myself was too great too resist, even for someone who had
never authored a single line of computer code in his life. So when
you say you want to write stories, I take it that what you mean,
precisely, is that you want to write stories in IF form. If you just
want to write stories it is easier doing it without the computer
coding! I do sometimes write stories, have even sold some, so if I
just wanted to write stories I wouldn't be wasting time programming.
Apart from the urge to write a game, I actually enjoy the puzzle
aspect that ALAN, simple as it may be, presents to me. Trying to
figure out how to create effects with code is different than trying to
create effects purely with words. So I'd urge you to take a look at
ALAN. I've coded up a couple rooms in InForm and I guarantee ALAN is
way simpler.
>Having something to say is more important than an excellent command of
>the language. In whatever language.
>
The problem is, if you try to write a computer game, without being
able to handle the programming, it is like trying to write in a
foreign language you aren't proficient in. (Don't I know it!)
There probably is not a person alive who doesn't have something to
say. Writing, of any sort IMHO involves technique. The difference
between someone who, say, is trying to sell fiction and hasn't done so
yet and someone who has is not so much that the person learning the
craft has no ideas, or lesser ideas or is in any way somehow less
inspired but rather a matter of technique. The "professional" writer
has learned how to shape his or her ideas into a format acceptible to
some market. Yes, at some point, no doubt, some ideas are better and
more inspired than others, but that is icing on the cake. You've got
to be able to get the cake baked before that comes into play.
So I would think that anyone who is primarily interested in writing an
IF game, and not in programming per se, would do well to choose the
simplest tool available which will express the ideas he or she wants
to express. Once again, my opinion, INFORM is amazing in what I have
seen it is able to do. However, certain types of IF currently being
produced, a lot of puzzleless and story oriented IF, really don't
makemush use of Inform's abilities. For many of these games the
language is kind of overkill, in a technical sense. If someone likes
programming in Inform they will naturally want to write in it but you
don't need to learn Inform to write such a game.
Coming back to your question is IF a programming exercise or a gaming
one, I would say that from the writing standpoint it is obviously a
programming exercise and IF authors are going to enjoy writing in and
discussing their favored language. From a playing viewpoint, however,
I don't see there should be any preference between Inform, Tads, Hugo,
Alan or AGT, Adrift , Quest etc etc outside the obvious limitation
that you need to be able to play the game on whatever machine you're
using.
--
Eric Mayer
Web Site: <http://home.epix.net/~maywrite>
"The map is not the territory." -- Alfred Korzybski
Jonadab the Unsightly One
> Director (or rather, Lingo,
*SHUDDER*
Lingo is without any question the worst language ever devised.
I accidentally took a class in college that used it, and it
was a very VERY bad experience. It's substantially worse than
CoBOL (which I also took by mistake; I'd never heard of it,
and they said "it's a programming language", so I took it).
- jonadab
Jonadab the Unsightly One
> : >4) (did I say three? I meant four.) The *syntax* may be prettier in
> : >TADS, but the *words* are prettier in Inform.
> :
> : What?
>
> I mean that I pull up a random TADS source code file, and see things like
> "ldesc", "verDoGo", "doGo", and "dobjGen". I pull up a random Inform
> source code file and see things like "description", "Go", "before", and
> "light".
The importance of this should not be underestimated. Sure, Inform
uses punctuation in ways that make C programmers cringe, but for
those of us who weren't C programmers when we learned Inform, that
isn't a big deal. When the punctuation is off, the first compiler
error almost always clues you in what to change, so no big deal.
Understanding what you're writing, being able to read it aloud
and have it make sense, that is a big deal.
Plus, back in the days of Inform 5, when the game--writing-tutorial
part of the DM was reasonably near the beginning, you could write
a simple two-room game with a simple object after reading for
a fairly short while.
-- jonadab, who always screws up the punctuation in C for loops.
Jonadab the Unsightly One
> On Thu, 25 Jan 2001 22:47:47 GMT, thor...@visi.com (David Thornley)
> wrote:
>
> >TADS is perfectly readable and writable by anybody used to computer
> >software. Inform takes a less technical approach, and appeals
> >more to the non-technogeeks.
>
> Except for one thing: Inform let you write Z-machine assembly code.
> Nothing in TADS had that kind of technogeek appeal.
>
> I don't think many people have actually *used* this capability, but
> that hardly matters. It's like that old sports car commercial: "You
> may never drive at 200 MPH, but it's great to know you could..."
Dave Barry recently pointed out in his humour column the tremendous
appeal of the sheer ability a Humvee has to inflate and deflate its
tires while driving. No other car can do that. People who ask,
"why?" just don't understand. I think this may be similar to the
appeal of zasm in Inform. It doesn't matter *why* you would want
to do it; it matters that you *can*.
Replacing library functions, OTOH, has really *useful* appeal
that TADS can't entirely match until T3.
- jonadab
Jonadab the Unsightly One
> use when_on and initial and... so on. I don't know why Graham
> implemented certain features (e.g. talkable, which NO ONE uses).
Talkable is handy for some things. I've used it several times.
(Okay, not in anything I actually *finished and released*, but
nevermind that.) Electronic devices especially. Telephones,
microphones, megaphones, ...
- jonadab
Jonadab the Unsightly One
> : So, my question is: why are there so many more games released for
> : Inform than TADS?
>
> Three things:
>
> 1) The Designer's Manual
> 2) Inform was freeware when TADS was shareware.
> 3) The z-machine is a bigger factor than you probably realize.
> 4) (did I say three? I meant four.) The *syntax* may be prettier in
> TADS, but the *words* are prettier in Inform.
>
> and actually, there may be:
>
> 5) People may prefer the Inform standard library (as players) than the
> TADS one. By which I almost exclusively mean 'the default responses'.
7) There was an advertisement for Inform in Curses, which was like
the best IF game *ever*, well, in the modern era at any rate.
- jonadab
Andrew MacKinnon
> Mark Musante <mmus...@Sun.COM> wrote:
> > Lucian P. Smith (lps...@rice.edu) wrote:
> > > 5) People may prefer the Inform standard library (as players) than the
> > > TADS one. By which I almost exclusively mean 'the default responses'.
> >
> > It'd be interesting to see a TADS library with Inform's look'n'feel.
>
> I'm not sure what you mean by this. Do you mean Inform default responses and
> language syntax, or do you mean the deeper structure of the library.
>
> For me there is a clear distinction between the two systems: Inform's
> library is a procedural system that operates on objects whose behaviors are
> largely determined by library functions. This gives Inform a compactness,
> but makes handling exceptions rather difficult. For contrast, instead of
> having a listing routine that determines whether an object is a container, a
> surface, a fixed item, etc; TADS has increasingly adopted the approach that
> the objects handle their own listing, given merely the request. This
> philosophy permeates the current trend in library development in TADS.
Yeah, I know. If you want to make a major library extension in TADS, then you
probably will have to modify the thing class. I really sort of prefer the TADS
system, in which the default library is coded mostly in the thing class and
other classes. However, I use Inform, so...
--
Andrew MacKinnon
andrew_mac...@yahoo.com
http://www.geocities.com/andrew_mackinnon_2000/
Andrew MacKinnon
> ca...@wurb.com (Carl Muckenhoupt) wrote:
>
> > David Thornley (thor...@visi.com) wrote:
> >
> > >TADS is perfectly readable and writable by anybody used to computer
> > >software. Inform takes a less technical approach, and appeals
> > >more to the non-technogeeks.
> >
> > Except for one thing: Inform let you write Z-machine assembly code.
> > Nothing in TADS had that kind of technogeek appeal.
> >
> > I don't think many people have actually *used* this capability, but
> > that hardly matters. It's like that old sports car commercial: "You
> > may never drive at 200 MPH, but it's great to know you could..."
>
> Dave Barry recently pointed out in his humour column the tremendous
> appeal of the sheer ability a Humvee has to inflate and deflate its
> tires while driving. No other car can do that. People who ask,
> "why?" just don't understand. I think this may be similar to the
> appeal of zasm in Inform. It doesn't matter *why* you would want
> to do it; it matters that you *can*.
>
> Replacing library functions, OTOH, has really *useful* appeal
> that TADS can't entirely match until T3.
I can think of one thing that is probably really hard in TADS. That is
dialling phone numbers. I have no idea how to allow someone to 'dial
234-5678' in TADS, but it must be hard or nearly impossible.
OKB -- not okblacke
>Along the same lines, Inform's library chooses some unfortunate
>negatives occasionally. I get confused writing parse_name
>routines when I have to decide what return value I need to
>say two objects are *not* indestinguishable. Yuck.
What I have to say is an entirely unrelated and gratuitous criticism, but
as long as we're picking Inform's nits. . . The reference to parse_name here
just reminded me how much I dislike the fairly common instances where the
underscore is used (parse_name, short_name, when_open, etc.).
--OKB (Bren...@aol.com) -- no relation to okblacke
"Do not follow where the path may lead;
go, instead, where there is no path, and leave a trail."
--Author Unknown
Paul E. Bell
<3a7377e7...@news.bright.net>:
You know, that brings up an issue that is being missed here.
I think what comes of it is this: There are at least two different groups
of people who write Interactive Fiction: programmers who are forced to
become literate authors in order to write I-F, and literate authors who are
forced to become programmers in order to write I-F.
I'm sure there is a whole range of people inbetween these, but, as I look
at the arguments, what comes to mind is that, for one reason or another,
Inform would seem to appeal to the person with the literary background,
some of which have played some of the old (or new) 'adventure' games, and
decided to try their hand at a new (for them) literary form, while TADS
would seem to appeal to the programmer who has decided to try his hand at
programming something a bit more exciting than a spreadsheet, word
processor, actuarial program, cell phone UI, nuclear missile guidance
program, or whatever they normally work with.
Granted, that's just a portion of the people who jump into I-F authorship,
but, it seems to me, from the replies here, that it's at least one more
piece of the puzzle to put on the table.
--
Paul E. Bell | Email and AIM: wd0...@millcomm.com | ifMUD: Helios
IRC: PKodon, DrWho4, and Helios | webpage: members.nbci.com/wd0gcp/
Member: W.A.R.N., Skywarn, ARES, Phoenix Developer Consortium, ...
_____ Pen Name/Arts & Crafts signature:
| | _ \ _ _ |/ _ _(
| | (_X (_/`/\ (_) (_` |\(_) (_) (_|_) (/`
)
Richard Bos
> Dave Barry recently pointed out in his humour column the tremendous
> appeal of the sheer ability a Humvee has to inflate and deflate its
> tires while driving. No other car can do that. People who ask,
> "why?" just don't understand.
Erm, yes, they do. There is a reason why it can do that; there is a
reason for _everything_ in that beast. It was designed for the military,
and I can only presume that this ability helps it to drive through hard
terrain.
> I think this may be similar to the
> appeal of zasm in Inform. It doesn't matter *why* you would want
> to do it; it matters that you *can*.
And similar here: it may not be useful for everyday work, but if you
want something _really_ awkward, it's nice to be able to use "machine
language".
Richard
jer...@mupwi.demon.co.uk
in...@hoekstra-uitgeverij.nl (Richard Bos) wrote:
> jon...@bright.net (Jonadab the Unsightly One) wrote:
>
> > Dave Barry recently pointed out in his humour column the tremendous
> > appeal of the sheer ability a Humvee has to inflate and deflate its
> > tires while driving. No other car can do that. People who ask,
> > "why?" just don't understand.
>
> Erm, yes, they do. There is a reason why it can do that; there is a
> reason for _everything_ in that beast. It was designed for the
> military, and I can only presume that this ability helps it to drive
> through hard terrain.
>
Could be. Sometimes if driving through mud/snow you may want to reduce
the pressure in the tyres to improve traction or something. Damn good
idea to be able to do that with out exposing yourself to the cold, the
wet, and enemy fire. Then of course thats the US military for you, their
guys can drive away in comfort. Life of riley, what? ;)
Regards,
Jeremy Silver
Mark Musante - Sun Microsystems
> I can think of one thing that is probably really hard in TADS. That is
> dialling phone numbers. I have no idea how to allow someone to 'dial
> 234-5678' in TADS, but it must be hard or nearly impossible.
Are you attempting to challenge us?
http://www.ministryofpeace.com/if/tads/examples/dial.gam
Perhaps we have different definitions of the word 'hard'.
-markm
Paul O'Brian
> I think what comes of it is this: There are at least two different groups
> of people who write Interactive Fiction: programmers who are forced to
> become literate authors in order to write I-F, and literate authors who are
> forced to become programmers in order to write I-F.
When I read statements like this, I always think, "Which am I?" I got my
degrees in English lit., but I earn my living as a programmer. I like
both. In fact, my observation has been that a significant number of IF
authors are people who enjoy both fiction writing *and* computer
programming, not devotees of one who are forcing themselves to tolerate
the other.
--
Paul O'Brian obr...@colorado.edu http://ucsu.colorado.edu/~obrian
Ready or not, here comes SPAG! Issue #23 is the annual competition special,
featuring interviews with top authors and a treasure trove of reviews!
Eric Mayer
<obr...@ucsu.colorado.edu> wrote:
>On Tue, 30 Jan 2001, Paul E. Bell wrote:
>
>> I think what comes of it is this: There are at least two different groups
>> of people who write Interactive Fiction: programmers who are forced to
>> become literate authors in order to write I-F, and literate authors who are
>> forced to become programmers in order to write I-F.
>
>When I read statements like this, I always think, "Which am I?" I got my
>degrees in English lit., but I earn my living as a programmer. I like
>both. In fact, my observation has been that a significant number of IF
>authors are people who enjoy both fiction writing *and* computer
>programming, not devotees of one who are forcing themselves to tolerate
>the other.
>
I tend to see things the way Paul Bell describes, but I suspect that
is my age showing because I've been amazed, in my little wile in the
IF community, seeing how many programmers of IF and otherwise have
nontechnical backgrounds. When I got my degree in English Lit there
weren't such things as home computers and English Lit majors certainly
didn't learn programming nor had they even been exposed to any in
school. So when I hear someone say they have an English Lit degree but
earn a lliving as a programmer -- well, I feel dated! Evidently there
is not nearly so much dichotomy today between liberal arts and
science.
Having said that, I think the general level of writing ability among
IF authors is far higher than that in other literary groups I've
encountered. Maybe people with some technical background realize that
it is most important, first of all, just to be clear in what you're
saying. Too often you see writing that is "pretty" but nonfunctional
in that it just doesn't convey anything to the reader.
Dan Schmidt
| I think what comes of it is this: There are at least two different
| groups of people who write Interactive Fiction: programmers who are
| forced to become literate authors in order to write I-F, and
| literate authors who are forced to become programmers in order to
| write I-F.
I think many people here already had feet in both worlds, even if not
equally strongly.