Why does Tads/Inform exist?
Nizam U Ahmed
Is there any reason why interactive fiction programming
languages exist? I understand that, to provide a realistic
simulation of a world it is necessary to have an
object-oriented definition system, which both TADS and Inform
provide.
But why have people gone to the trouble of creating full
programming languages when any object-oriented language, eg
Smalltalk, could be used to write an interpreting engine, leaving
the IF author to code up a class hierarchy in Smalltalk defining
their IF project. These objects could then be 'animated' by the
IF engine.
It would be no more difficult creating a class hierarchy in
SMalltalk than it would in TADS/Inform, in fact it might be easier
because the IF author would maybe not have to learn a new 'special'
language if they already knew Smalltalk.
Just wondering...
--
****** NIZAM U AHMED <cs4...@surrey.ac.uk> ******
*** University of Surrey at Guildford , UK ***
****** Web : http://www.surrey.ac.uk/~cs41na/ ******
The Wildman
On Wed, 25 Feb 1998 18:09:59 +0000, Nizam U Ahmed uttered the words:
[...]
>It would be no more difficult creating a class hierarchy in
>SMalltalk than it would in TADS/Inform, in fact it might be easier
>because the IF author would maybe not have to learn a new 'special'
>language if they already knew Smalltalk.
Portability. It is far easier for an IF author to create a game file which
can be read by interpreters on a variety of platforms, than for the author
to port his work to other platforms.
What if the author doesn't know Smalltalk? I don't, and I'm a programmer by
profession. Most IF authors are only doing this for a hobby. Some IF authors
know nothing at all about programming, but are able to produce very fine
work with TADS. If you know Smalltalk, and want to use that, fine. Don't
expect most of us to be able to help you if you get stuck, though. :)
It is certainly not necessary to produce IF using any particular language at
all. One could try it in assembler (if s/he had the guts). It just happens
to be easier for most people.
BTW - How did you learn Smalltalk? Did you download the compiler, buy a book,
or learn it in school? That's another factor. You can download TADS, sample
code, and a manual, as well as ask others for help.
--
The Wildman
-------
There is no gravity.
The earth just sucks.
Andrew Plotkin
Nizam U Ahmed (cs4...@surrey.ac.uk) wrote:
> Is there any reason why interactive fiction programming
> languages exist? I understand that, to provide a realistic
> simulation of a world it is necessary to have an
> object-oriented definition system, which both TADS and Inform
> provide.
Basically because the interpreter preceded the language.
In the case of Inform, there was a pre-existing virtual machine from
Infocom. Graham started by more or less writing an assembler for the
z-machine, and then added features until it looked like a language.
In the case of TADS, the virtual machine is pretty complicated, and is
very IF-specific. I don't know for sure, but I get the feeling that the
TADS engine was the "real" part of the system, with the programming
language as a way to extend it.
In both cases, a side-effect has been extreme portability. Both the TADS
and Z-machine intepreters have pretty minimal I/O capacities, tailored to
IF, which makes them very easy to port (compared to a full language
system like Smalltalk.)
> But why have people gone to the trouble of creating full
> programming languages when any object-oriented language, eg
> Smalltalk, could be used to write an interpreting engine, leaving
> the IF author to code up a class hierarchy in Smalltalk defining
> their IF project. These objects could then be 'animated' by the
> IF engine.
This question has some land mines buried in it. In one sense, we *have*
taken exactly this approach, using C as the base language instead of
Smalltalk. There's an interpreting engine, and it "animates" the VM
binary code embedded in the objects. Right?
This also ties in to the "do you really need a programming language?"
perennial question.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Nizam U Ahmed
The Wildman wrote:
>
> On Wed, 25 Feb 1998 18:09:59 +0000, Nizam U Ahmed uttered the words:
> [...]
> >It would be no more difficult creating a class hierarchy in
> >SMalltalk than it would in TADS/Inform, in fact it might be easier
> >because the IF author would maybe not have to learn a new 'special'
> >language if they already knew Smalltalk.
> There are some very good reasons for TADS/Inform/whatever.
> Portability. It is far easier for an IF author to create a game file which
> can be read by interpreters on a variety of platforms, than for the author
> to port his work to other platforms.
But many OO languages are available on multiple platforms already. Why
were
they not used as the basis of an 'IF language' in the first place,
because
the portability would have already existed.
Lots of interpreters have been written for TADS. If one "IF animator"
had
been written in Smalltalk, to work with an IF class/object hierarchy
(also
written in Smalltalk), no other interpreters would need to be written.
The
source code would be directly usable on any system on which Smalltalk
would run!
All the user would do is create classes and objects based on
pre-existing IF
classes eg rooms, actors, props, in Smalltalk syntax.
> What if the author doesn't know Smalltalk? I don't, and I'm a programmer by
> profession. Most IF authors are only doing this for a hobby. Some IF authors
> know nothing at all about programming, but are able to produce very fine
> work with TADS.
TADS is pretty much a programming language. It requires the author to
understand the concepts of OO, message passing etc, just like Smalltalk.
Its complex to learn, just like Smalltalk. It is available on many
platforms, just like Smalltalk (i think). I can't see TADS and Inform
being accessible to non-programmers, to me they are just programming
languages, like Smalltalk.
If you know Smalltalk, and want to use that, fine. Don't
> expect most of us to be able to help you if you get stuck, though. :)
> It is certainly not necessary to produce IF using any particular language at
> all. One could try it in assembler (if s/he had the guts). It just happens
> to be easier for most people.
> BTW - How did you learn Smalltalk? Did you download the compiler, buy a book,
> or learn it in school? That's another factor. You can download TADS, sample
> code, and a manual, as well as ask others for help.
I don't know it! Just an example. Anyway, I'm still wondering: why have
programming languages for IF been created? Why not simply write a
program
in an existing OO language which can process classes/objects defined by
the IF author in that same language. I like TADS and Inform, I'm just
unsure
about their history, and the reasons behind their invention.
>
> --
> The Wildman
> -------
> There is no gravity.
> The earth just sucks.
--
Paul F. Snively
In article <34F45E...@surrey.ac.uk>, Nizam U Ahmed
<cs4...@surrey.ac.uk> wrote:
> Is there any reason why interactive fiction programming
> languages exist? I understand that, to provide a realistic
> simulation of a world it is necessary to have an
> object-oriented definition system, which both TADS and Inform
> provide.
This is actually untrue. It's not *necessary* to have an object-oriented
system (the folks who wrote the Zork trilogy didn't; Scott Adams didn't...)
It's probably very desirable, however.
> But why have people gone to the trouble of creating full
> programming languages when any object-oriented language, eg
> Smalltalk, could be used to write an interpreting engine, leaving
> the IF author to code up a class hierarchy in Smalltalk defining
> their IF project. These objects could then be 'animated' by the
> IF engine.
Typically because the level of abstraction is still too low: Inform and
TADS both provide some things out of the box--I'm primarily thinking of the
language parsing stuff, timers, fuses, etc.--that Smalltalk, Lisp, C++,
etc. don't offer out of the box.
> It would be no more difficult creating a class hierarchy in
> SMalltalk than it would in TADS/Inform, in fact it might be easier
> because the IF author would maybe not have to learn a new 'special'
> language if they already knew Smalltalk.
While true in the abstract, the number of IF authors who already know
Smalltalk/Lisp/C++/etc. is vanishingly small.
> Just wondering...
It's a very reasonable question. I've long thought of creating a really
awesome IF system based on some of the cooler knowledge representation
systems out there (LOOM, CLASSIC, SNePS, whatever), but in the end I've
always concluded that the cost:benefit ratio of building such a system
sucked too hard.
> ****** NIZAM U AHMED <cs4...@surrey.ac.uk> ******
> *** University of Surrey at Guildford , UK ***
> ****** Web : http://www.surrey.ac.uk/~cs41na/ ******
Paul Snively
Zachery J. Bir
On Wed, 25 Feb 1998 19:20:02 +0000, Nizam U Ahmed <cs4...@surrey.ac.uk> wrote:
>
>I don't know it! Just an example. Anyway, I'm still wondering: why have
>programming languages for IF been created? Why not simply write a
>program in an existing OO language which can process classes/objects
>defined by the IF author in that same language. I like TADS and Inform,
>I'm just unsure about their history, and the reasons behind their
>invention.
Ahh, well. Probably for the same reason that Smalltalk was invented.
Someone sometime thought, "Well, this'd be neato keen." And did it. In the
case of Inform that neato-keener was Graham. And kudos to him for it.
Why'd Edison invent the lightbulb? Candles were working just fine...
Zac
Andrew Plotkin
> >
> > There are some very good reasons for TADS/Inform/whatever.
> > Portability. It is far easier for an IF author to create a game file which
> > can be read by interpreters on a variety of platforms, than for the author
> > to port his work to other platforms.
> But many OO languages are available on multiple platforms already. Why
> were
> they not used as the basis of an 'IF language' in the first place,
> because
> the portability would have already existed.
For the Z-machine, the target platforms were the Apple 2, Commodore 64,
and even smaller things. TADS was much later, but it was developed in, I
think 1990 or 91? On not-very-powerful IBM home machines.
> Lots of interpreters have been written for TADS. If one "IF animator"
> had
> been written in Smalltalk, to work with an IF class/object hierarchy
> (also
> written in Smalltalk), no other interpreters would need to be written.
> The
> source code would be directly usable on any system on which Smalltalk
> would run!
Now you've switched from talking about the IF *languages* to the IF
*virtual machines*. We've got a world where your game is usable on any
system on which the interpreter will run. And the fact that it's compiled
really isn't very significant.
At any rate, the hard part of all this is the IF parser and object
library. That isn't any easier in Smalltalk than it was for TADS and
Inform. (In the case of TADS, more of the work is handled by the engine
as opposed ot the library -- but that's just a shift in division of
labor.)
> All the user would do is create classes and objects based on
> pre-existing IF
> classes eg rooms, actors, props, in Smalltalk syntax.
And then do the programming work, meaning writing Smalltalk code to
handle all the special cases.
You're still asking questions which are loaded, or at least biased.
You're implying that IF creation would be *simpler* if developed in
Smalltalk to run on a Smalltalk system. I don't think that's true.
The bare question is "Why is the development in Inform/TADS rather than
Smalltalk?" (Or Prolog, or Lisp...) See my previous post.
Jason Compton
: would run!
And my guess is that there are more readily available C compilers for
different platforms than there are "systems on which Smalltalk would run."
--
Jason Compton jcom...@xnet.com
Editor-in-Chief, Amiga Report Magazine VP, Legacy Maker Inc.
http://www.cucug.org/ar/ http://www.xnet.com/~jcompton/
Choose and renounce... throwing chains to the floor.
Dancer
Nizam U Ahmed wrote:
> Is there any reason why interactive fiction programming
> languages exist? I understand that, to provide a realistic
> simulation of a world it is necessary to have an
> object-oriented definition system, which both TADS and Inform
> provide.
>
> But why have people gone to the trouble of creating full
> programming languages when any object-oriented language, eg
> Smalltalk, could be used to write an interpreting engine, leaving
> the IF author to code up a class hierarchy in Smalltalk defining
> their IF project. These objects could then be 'animated' by the
> IF engine.
>
> It would be no more difficult creating a class hierarchy in
> SMalltalk than it would in TADS/Inform, in fact it might be easier
> because the IF author would maybe not have to learn a new 'special'
> language if they already knew Smalltalk.
Bullets:* Inform itself was written to provide a high-level language on
top of an existing lower-level one (z-code).
* Smalltalk is resource-hungry, and would probably be a bad choice as a
language for portability's sake.
* The majority of if-authors are writers first, and programmers second.
The TADS/Inform systems shield them from the rudeness of programming, if
they so desire, allowing them to merely define. (some programming is
obviously required for complex things, but if we don't tell them that,
they won't notice)
* No, it is _not_ necessary to use an object-oriented system to provide
a realistic simulation of a world. I state this from either of two
standpoints: (1) That we cannot make anything even vaguely describable
as a realistic simulation of a world. (2) That what we _can_ do in that
regard, weak as it is, can be done without OOP.
* Any specialised language operates better within it's field than a
generalised one within that same field.
Paul F. Snively
In article <34F46E...@surrey.ac.uk>, Nizam U Ahmed
<cs4...@surrey.ac.uk> wrote:
> But many OO languages are available on multiple platforms already. Why
> were
> they not used as the basis of an 'IF language' in the first place,
> because
> the portability would have already existed.
If IF were being invented today, this might be a valid point, but as Andrew
Plotkin pointed out in an earlier post in this thread, Inform's target
language--Z-code, or the Z-machine--has been around since the 1970's, being
the runtime system for the old Infocom text adventures. However, the
genesis of the Zork trilogy goes back even farther, at least to the early
1970's, and in fact were written in a very early dialect of Lisp called
MDL. MDL didn't survive; ZIL survived, believe it or not, right up until
"Return to Zork" from Activision (yes, folks, "Return to Zork" was written
in ZIL, believe it or not). Of course, the "Z-machine" that "Return to
Zork" implements would be unrecognizable to fans of the "Z-machine" that
ran the text games, and that Inform targets. Anyway, the ZIL compiler
sources have long since been lost, and lately even Activision authors who
have created text games have used Inform to generate them.
> Lots of interpreters have been written for TADS. If one "IF animator"
> had
> been written in Smalltalk, to work with an IF class/object hierarchy
> (also
> written in Smalltalk), no other interpreters would need to be written.
> The
> source code would be directly usable on any system on which Smalltalk
> would run!
Both of them? 1/2 ;-)
Don't misunderstand me; I like Smalltalk quite a bit, principally for its
orthogonality. But it's useless to write shrink-wrapped (or downloadable)
software in.
> All the user would do is create classes and objects based on
> pre-existing IF
> classes eg rooms, actors, props, in Smalltalk syntax.
And the system would understand English how, exactly?
> TADS is pretty much a programming language. It requires the author to
> understand the concepts of OO, message passing etc, just like Smalltalk.
> Its complex to learn, just like Smalltalk. It is available on many
> platforms, just like Smalltalk (i think).
A helluva lot more platforms than Smalltalk!
> I can't see TADS and Inform
> being accessible to non-programmers, to me they are just programming
> languages, like Smalltalk.
As I mentioned before, the real primary difference that I see is that
Inform and TADS give you a ton of tools to help specifically with the task
of creating IF; Smalltalk doesn't. Apart from that, there is the issue of
memory and disk footprint, and distribution of end results.
> I don't know it! Just an example. Anyway, I'm still wondering: why have
> programming languages for IF been created? Why not simply write a
> program
> in an existing OO language which can process classes/objects defined by
> the IF author in that same language. I like TADS and Inform, I'm just
> unsure
> about their history, and the reasons behind their invention.
I've alluded to the history behind Inform above; Inform is a new language
with a new compiler that targets an interpreter that, within the computer
industry, can properly be considered "ancient." The motivation behind TADS
is a little less clear to me in any terms other than the technical ones
I've already mentioned.
> --
Allen Garvin
Lots of interpreters have been written for TADS. If one "IF animator"
had been written in Smalltalk, to work with an IF class/object
hierarchy (also written in Smalltalk), no other interpreters would
need to be written. The source code would be directly usable on
any system on which Smalltalk would run!
How many systems have Smalltalk? Not many. A lot of people I know have
never heard of it. I learned it 4 years ago by downloading a beta of GNU
smalltalk and compiling it under HP-UX 8 after much trouble. It took up
a lot of space which I eventually had to give up because of a disk
quota at the time. TADS and Inform only require people to get a very small,
easily portable game-file interpreter. People who play the games need
to have no knowledge at all of the languages they were written in. How
many smalltalks can compile programs that are then portable around many
systems?
All the user would do is create classes and objects based on
pre-existing IF classes eg rooms, actors, props, in Smalltalk syntax.
There's also the parser, which is at the heart of every IF language. Building
the object library is just time-consuming and could be easily accomplished
in most OO languages.
I don't know it! Just an example. Anyway, I'm still wondering: why
have programming languages for IF been created? Why not simply write a
program in an existing OO language which can process classes/objects
defined by the IF author in that same language. I like TADS and
Inform, I'm just unsure about their history, and the reasons behind
their invention.
People love to create new, specialized programming languages! For one
small example, just about everything you do in Perl could be accomplished
in Awk, or C, it'd just be a lot more work. Inform (both the language
and its library) is full of conveniences for just writing text adventures.
And its game files are extremely portable. It's great for the specialized
purpose it was designed for, and only has a small initial learning curve
for anyone who has programmed before.
--
Allen Garvin kisses are a better fate
--------------------------------------------- than wisdom
eare...@faeryland.tamu-commerce.edu
http://faeryland.tamu-commerce.edu/~earendil e e cummings
Matt Ackeret
In article <34F45E...@surrey.ac.uk>,
>languages exist? I understand that, to provide a realistic
>simulation of a world it is necessary to have an
>object-oriented definition system, which both TADS and Inform
>provide.
>
>But why have people gone to the trouble of creating full
>programming languages when any object-oriented language, eg
>Smalltalk, could be used to write an interpreting engine, leaving
Is there a Smalltalk interpreter for 8 bit Apple IIs, or Newtons,
or a bazillion other types of computers on the planet?
--
mat...@area.com
David Lebling
Paul F. Snively wrote:
> However, the
> genesis of the Zork trilogy goes back even farther, at least to the early
> 1970's, and in fact were written in a very early dialect of Lisp called
> MDL.
Well, Zork itself dates back to the summer of 1977, hardly "early
1970s." MDL itself came earlier than that -- 1971 or 1972, I think;
perhaps you were thinking of it? I've often wondered why Graham Nelson
refers to it as a "particularly unhelpful variety of Lisp." It had a
lot of features that I wish C++ had; for one, the ability to mix
interpreted and compiled code. Of course, he's never had the
opportunity to program in it.
> MDL didn't survive; ZIL survived, believe it or not, right up until
> "Return to Zork" from Activision (yes, folks, "Return to Zork" was written
> in ZIL, believe it or not). Of course, the "Z-machine" that "Return to
> Zork" implements would be unrecognizable to fans of the "Z-machine" that
> ran the text games, and that Inform targets. Anyway, the ZIL compiler
> sources have long since been lost, and lately even Activision authors who
> have created text games have used Inform to generate them.
As far as I know, _Return to Zork_ wasn't written in ZIL. It certainly
doesn't look or play like it was written in ZIL. I suppose it's
possible that some of the game could have been prototyped as a text
adventure or _Zork Zero_ style illustrated text adventure, but I doubt
it. I had heard that the ZIL development environment, which Infocom ran
on TOPS-20 and Unix, didn't survive the trip from Cambridge to
California. I'd be curious to know where you heard this, and wonder if
Laird could give a more definitive answer. A ZIL (and hence, a
Z-machine) that could do MPEG video and such would be an interesting
thing, but I suspect that we've sighted a manatee here, not a mermaid...
-- Dave Lebling
David Betz
David Lebling wrote:
> As far as I know, _Return to Zork_ wasn't written in ZIL. It certainly
> doesn't look or play like it was written in ZIL. I suppose it's
> possible that some of the game could have been prototyped as a text
> adventure or _Zork Zero_ style illustrated text adventure, but I doubt
> it. I had heard that the ZIL development environment, which Infocom ran
> on TOPS-20 and Unix, didn't survive the trip from Cambridge to
> California. I'd be curious to know where you heard this, and wonder if
> Laird could give a more definitive answer. A ZIL (and hence, a
> Z-machine) that could do MPEG video and such would be an interesting
> thing, but I suspect that we've sighted a manatee here, not a mermaid...
Zork Zero may have been written in a variant of AdvSys that I built for
Activision for their project to port Manhole to the PC. AdvSys was a
sort of poor mans ZIL that I wrote after reading an article about how
the Infocom games were implemented. It wasn't as powerful as ZIL but it
did have the advantage that the tools ran on a PC which wasn't true of
the ZIL development tools at the time.
I don't know if the ZIL compiler has survived somewhere but I have a
copy of a manual called "Learning ZIL or Everything You Always Wanted to
Know About Writing Interactive Fiction But Couldn't Find Anyone Still
Working Here to Ask". It describes the ZIL language in a tutorial. I
haven't seen a ZIL reference manual.
--
David Betz
db...@xlisper.mv.com
Andrew Plotkin
David Betz (db...@xlisper.mv.com) wrote:
> I don't know if the ZIL compiler has survived somewhere but I have a
> copy of a manual called "Learning ZIL or Everything You Always Wanted to
> Know About Writing Interactive Fiction But Couldn't Find Anyone Still
> Working Here to Ask". It describes the ZIL language in a tutorial. I
> haven't seen a ZIL reference manual.
If you could scan or otherwise transcribe this manual, and put it
on-line, a whole lot of us would be utterly fascinated to read it.
I bet you could find volunteers to simply type it in, too, if you mailed
out a photocopy.
Mark J Musante
David Betz (db...@xlisper.mv.com) wrote:
> I don't know if the ZIL compiler has survived somewhere but I have a
> copy of a manual called "Learning ZIL or Everything You Always Wanted to
> Know About Writing Interactive Fiction But Couldn't Find Anyone Still
> Working Here to Ask". It describes the ZIL language in a tutorial. I
> haven't seen a ZIL reference manual.
If you send me a copy I'll turn it into a set of web pages. Postage on
me.
-=- Mark -=-
David A. Cornelson
In article <34F45E...@surrey.ac.uk>,
Nizam U Ahmed <cs4...@surrey.ac.uk> wrote:
>
> Is there any reason why interactive fiction programming
> languages exist? I understand that, to provide a realistic
I'm curious about something. I've been following this thread and one question
comes to mind. It seems you're obsessed with SmallTalk. If I owned a
Commodore 64, could I use your theoretical development tool based on
SmallTalk on my machine. What about an Amiga? An Apple MessagePad?
But wait! Where would I have gotten SmallTalk for free? And if you knew
SmallTalk, would you design and build a system by which IF could work?
Hmmmm, I didn't think so.
David A. Cornelson, Chicago
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
David Betz
Andrew Plotkin wrote:
>
> David Betz (db...@xlisper.mv.com) wrote:
>
> > I don't know if the ZIL compiler has survived somewhere but I have a
> > copy of a manual called "Learning ZIL or Everything You Always Wanted to
> > Know About Writing Interactive Fiction But Couldn't Find Anyone Still
> > Working Here to Ask". It describes the ZIL language in a tutorial. I
> > haven't seen a ZIL reference manual.
>
> on-line, a whole lot of us would be utterly fascinated to read it.
>
> I bet you could find volunteers to simply type it in, too, if you mailed
> out a photocopy.
>
> --Z
>
> --
>
> "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
> borogoves..."
I'd be happy to if someone can get permission from Activision. I assume
they still hold the copyright.
--
David Betz
db...@xlisper.mv.com
Paul F. Snively
In article <34F5BD...@avid.com>, David Lebling <david_...@avid.com>
wrote:
> Well, Zork itself dates back to the summer of 1977, hardly "early
> 1970s." MDL itself came earlier than that -- 1971 or 1972, I think;
> perhaps you were thinking of it?
Hello, David! Nice to make your acquaintance! Yes, I was thinking of MDL
itself--thanks for setting me straight!
> I've often wondered why Graham Nelson
> refers to it as a "particularly unhelpful variety of Lisp." It had a
> lot of features that I wish C++ had; for one, the ability to mix
> interpreted and compiled code. Of course, he's never had the
> opportunity to program in it.
Hmmm. I suspect that most of us with any familiarity with Lisp would think
of MDL as "particularly unhelpful" by way of comparison to either Common
Lisp or Scheme, as opposed to, say, MDL vs. Lisp 1.5 or, as you point out,
MDL vs. C++.
> As far as I know, _Return to Zork_ wasn't written in ZIL. It certainly
> doesn't look or play like it was written in ZIL. I suppose it's
> possible that some of the game could have been prototyped as a text
> adventure or _Zork Zero_ style illustrated text adventure, but I doubt
> it. I had heard that the ZIL development environment, which Infocom ran
> on TOPS-20 and Unix, didn't survive the trip from Cambridge to
> California. I'd be curious to know where you heard this,
At Activision. :-) I was there for the development of "Spycraft: The Great
Game," which was in development during a period of time in which active
development of various SKU's of "Return to Zork" was happening (MPEG,
international, etc.) You might not have recognized the "ZIL" that Return to
Zork was written in, but ZIL it was. How on earth they compiled it I swear
I can't recall--I do recall that the _source code_ to the compiler was
lost.
All of this, along with other considerations, prompted Activision's
Technology Department, of which I was a member, to rewrite their "story
game" engine in C++. The C++ engine was used to develop "Spycraft: The
Great Game" and "Zork: Nemesis" that I am aware of, and possibly other
titles that I am not aware of.
> and wonder if
> Laird could give a more definitive answer.
Laird can certainly speak to "Zork: Nemesis" and later titles; I _think_
(but am not sure) that "Return to Zork" predates him, although he may know
specifics about some of the SKU's I mentioned above.
> A ZIL (and hence, a
> Z-machine) that could do MPEG video and such would be an interesting
> thing, but I suspect that we've sighted a manatee here, not a mermaid...
Well, in that case I'm delighted to be able to tell you that the mermaid
existed, once, for a brief, shining moment (that is, one title--although
said title shipped, last I hear, some 15 distinct SKU's).
> -- Dave Lebling
Paul Snively
Paul F. Snively
> Zork Zero may have been written in a variant of AdvSys that I built for
> Activision for their project to port Manhole to the PC. AdvSys was a
> sort of poor mans ZIL that I wrote after reading an article about how
> the Infocom games were implemented. It wasn't as powerful as ZIL but it
> did have the advantage that the tools ran on a PC which wasn't true of
> the ZIL development tools at the time.
Hmmm... this raises the distinct possibility that the Lisp-y code I saw for
"Return to Zork" was not ZIL, but rather AdvSys, code, in which case I owe
David Lebling an apology.
> I don't know if the ZIL compiler has survived somewhere but I have a
> copy of a manual called "Learning ZIL or Everything You Always Wanted to
> Know About Writing Interactive Fiction But Couldn't Find Anyone Still
> Working Here to Ask". It describes the ZIL language in a tutorial. I
> haven't seen a ZIL reference manual.
There was a CD-ROM when I was at Activision with the entire contents of
some ancient Infocom-era Sun's file system on it. There's some percentage
chance that the sources to the ZIL compiler are on it, but the combined
efforts of David Zobel, David Harr, and myself failed to unearth them.
Ditto any pertinent documentation.
> --
> David Betz
> db...@xlisper.mv.com
Paul Snively
Michael Naunton
On Thu, 26 Feb 1998 16:43:51 -0500, David Betz <db...@xlisper.mv.com> wrote:
>
>Zork Zero may have been written in a variant of AdvSys that I built for
>Activision for their project to port Manhole to the PC. AdvSys was a
>sort of poor mans ZIL that I wrote after reading an article about how
>the Infocom games were implemented. It wasn't as powerful as ZIL but it
>did have the advantage that the tools ran on a PC which wasn't true of
>the ZIL development tools at the time.
Ah, AdvSys brings back memories. Beautiful little object oriented
language (seemed to have a strong xlisp influence.) David, I don't know
if you recall this, but I hacked out the AdvSys library that did recursive
containment, verb preact/postact, etc (on BIX back in 1986 or so,) you
were kind enough to clean it up and move it to the right public area.
-- MMN
Dancer
Hmm. I had advsys running on a couple of things, way back when. Personally, I
found it very awkward to work with. Probably just a matter of style, and how I
think. I would have been better with C than advsys, I think.
D
Michael Naunton wrote:
--
Did you read the documentation AND the FAQ?
If not, I'll probably still answer your question, but my patience will
be limited, and you take the risk of sarcasm and ridicule.
Mark J Musante
I wouldn't even know where to start requesting permission for
something like this. I think we're all understandably curious
about ZIL. Could you point us in the right direction?
Thanks.
-=- Mark -=-
David Betz (db...@xlisper.mv.com) wrote:
> Andrew Plotkin wrote:
> >
> > David Betz (db...@xlisper.mv.com) wrote:
> >
> > > I don't know if the ZIL compiler has survived somewhere but I have a
> > > copy of a manual called "Learning ZIL or Everything You Always Wanted to
> > > Know About Writing Interactive Fiction But Couldn't Find Anyone Still
> > > Working Here to Ask". It describes the ZIL language in a tutorial. I
> > > haven't seen a ZIL reference manual.
> >
Patrick Kellum
In article <34F5BD...@avid.com>, David Lebling was talking about:
>Well, Zork itself dates back to the summer of 1977, hardly "early
>1970s." MDL itself came earlier than that -- 1971 or 1972, I think;
>perhaps you were thinking of it? I've often wondered why Graham Nelson
>refers to it as a "particularly unhelpful variety of Lisp." It had a
>lot of features that I wish C++ had; for one, the ability to mix
>interpreted and compiled code. Of course, he's never had the
>opportunity to program in it.
I'm really trying to figure out MDl at the moment and was wondering if you
or anyone else know of any referance manuals or such available on the
internet? Also, how different was MDL from ZIL? Was MDL a very common
language back in the early 70s?
Thanks,
Patrick
---
A Title For This Page -- http://www.syix.com/patrick/
Bow Wow Wow Fan Page -- http://www.syix.com/patrick/bowwowwow/
The Small Wonder Page -- http://smallwonder.simplenet.com/
My Arcade Page -- http://ygw.bohemianweb.com/arcade/
"I have photographs of you naked with a squirrel." - Dave Barry
Patrick Kellum
[ I'm responding to myself, very strange experance. ]
In article <6d5jd4$246$1...@neko.syix.com>, Patrick Kellum was talking about:
>I'm really trying to figure out MDl at the moment and was wondering if you
>or anyone else know of any referance manuals or such available on the
In my searches I've come accross mention of the following:
The MDL programming environment
The MDL programming language
MDL primer and manual
RFC-0578: Using MIT-Mathlab MACSYMA from MIT-DMS Muddle
and I was wondering which would be the most helpful in getting a basic
idea of the layout of the language. The RFC sounds like it might help but
it is one of those RFCs that doesn't seem to be available anywhere :-(
Torbj|rn Andersson
David Lebling <david_...@avid.com> wrote:
> I had heard that the ZIL development environment, which Infocom ran
> on TOPS-20 and Unix, didn't survive the trip from Cambridge to
> California.
Aaaauuuuuggghhh!
(Call me sentimental, but I was just hoping that there would still be
copies of this somewhere, even if I'd never get to see them myself.)
Torbjörn
Allen Garvin
In article <6d5bql$rtn$1...@nnrp1.dejanews.com>,
David A. Cornelson <dcorn...@placet.com> wrote:
I'm curious about something. I've been following this thread and one
question comes to mind. It seems you're obsessed with SmallTalk. If
I owned a Commodore 64, could I use your theoretical development
tool based on SmallTalk on my machine. What about an Amiga? An
Apple MessagePad?
An Amiga surely, perhaps those other ones as well. SmallTalk was developed
at PARC in the 70's on computers that were quite primitive by even mid-80s
standards. Those PARC people were amazing visionaries in everything except
business. There were commercial versions for the earliest Mac's.
But wait! Where would I have gotten SmallTalk for free?
GNU smalltalk from prep.ai.mit.edu. However, *it's* not small or primitive.
Need a good 16-32M memory to run it well. It'll run on a wide variety of
systems. Of course, it's not nearly as easy to set up and run as "inform".
J. Holder
Thus spake David Lebling <david_...@avid.com>:
: Paul F. Snively wrote:
: > However, the
: > genesis of the Zork trilogy goes back even farther, at least to the early
: > 1970's, and in fact were written in a very early dialect of Lisp called
: > MDL.
: Well, Zork itself dates back to the summer of 1977, hardly "early
: 1970s." MDL itself came earlier than that -- 1971 or 1972, I think;
: perhaps you were thinking of it? I've often wondered why Graham Nelson
: refers to it as a "particularly unhelpful variety of Lisp." It had a
: lot of features that I wish C++ had; for one, the ability to mix
: interpreted and compiled code. Of course, he's never had the
: opportunity to program in it.
Although you _can_ still read about it, including one document by
Mr. Lebling himself...
From do...@MIT.EDU:
AUTHOR :Galley, Stuart Wilbur.
TITLE :MDL primer and manual : for versions 54 and 104 / S. W. Galley
and Greg Pfister.
LANGUAGE :ENGLISH
PUBLISHED :Cambridge : Laboratory for Computer Science, Massachusetts
Institute of Technology, 1977.
PHYSICAL DESC :270 p. ; 28 cm.
NOTES :Title from cover.
Includes index.
FUNDING INFO :Office of Naval Research contract N00014-75-C-0661
BIBLIOGRAPHY :Bibliography: p. 260.
OTHER AUTHOR :Pfister, Greg.
---------------------------------------------------------------------
AUTHOR :Galley, S. W.
TITLE :The MDL programming language / S.W. Galley and Greg Pfister.
LANGUAGE :ENGLISH
PUBLISHED :Cambridge, Mass. : Laboratory for Computer Science,
Massachusetts Institute of Technology, c1979.
PHYSICAL DESC :276 p. : ill. ; 28 cm.
SERIES :MIT/LCS/TR; 293
FUNDING INFO :Supported by the Advanced Research Projects Agency of the
Dept. of Defense. N00014-75-C-0661
BIBLIOGRAPHY :Includes bibliographical references.
OTHER AUTHOR :Pfister, Gregory F.
OTHER AUTHOR :Massachusetts Institute of Technology. Laboratory for Computer
Science.
OTHER TITLE :Programming language, The MDL.
-------------------------------------------------------------------
AUTHOR :Lebling, P. David.
TITLE :The MDL programming environment / P. David Lebling.
LANGUAGE :ENGLISH
PUBLISHED :Cambridge, Mass. : Laboratory for Computer Science,
Massachusetts Institute of Technology, 1980.
PHYSICAL DESC :iv, 137 p. ; 28 cm.
SERIES :MIT/LCS/TR; 294
BIBLIOGRAPHY :Includes bibliographical references and index.
OTHER AUTHOR :Massachusetts Institute of Technology. Laboratory for Computer
Science.
OTHER TITLE :Programming environment, The MDL.
Dear John,
These documents are available for $24 each, including airmail shipment. The
first title on your list did not show up on our database, I have given the
cite of the closest title. If you would like to purchase a copy, please
reply with your VISA, MasterCard or American Express number with expiration
date and name as it appears on the card. Or, if you prefer, you may fax
that information to us at 617-253-1690. I have included ordering and price
information at the end of this message.
Thank you,
-Trish Reid
MIT Document Services
do...@mit.edu
MIT LIBRARIES
DOCUMENT SERVICES
Room 14-0551
Cambridge, MA USA 02139-4307
(voice) 617-253-5668
(fax) 617-253-1690
(e.mail) do...@MIT.EDU
WWW: http://lauren.mit.edu/depts/document_services/docs.html
--
John Holder (jho...@frii.com) http://www.frii.com/~jholder/
Sr. Programmer Analyst, J.D.Edwards World Source Company, Denver, CO
http://www.jdedwards.com/
John Francis
In article <6d5t6q$97o$1...@neko.syix.com>,
Patrick Kellum <pat...@syix.com> wrote:
>[ I'm responding to myself, very strange experance. ]
>
>In article <6d5jd4$246$1...@neko.syix.com>, Patrick Kellum was talking about:
> >I'm really trying to figure out MDl at the moment and was wondering if you
> >or anyone else know of any referance manuals or such available on the
>
>In my searches I've come accross mention of the following:
>
>The MDL programming environment
>The MDL programming language
>MDL primer and manual
>RFC-0578: Using MIT-Mathlab MACSYMA from MIT-DMS Muddle
>
>and I was wondering which would be the most helpful in getting a basic
>idea of the layout of the language. The RFC sounds like it might help but
>it is one of those RFCs that doesn't seem to be available anywhere :-(
I'd assume the primer would be the most use (if you could find one).
You don't really care too much about the programming environment (unless
you already know far too much about ITS to be healthy), and the language
reference manual will be too detailed for a casual skimming. The RFC is
almost certainly a description of how to get the MDL environment and the
MACSYMA environment to coexist without stepping on each other.
--
John Francis jfra...@sgi.com Silicon Graphics, Inc.
(650)933-8295 2011 N. Shoreline Blvd. MS 43U-991
(650)933-4692 (Fax) Mountain View, CA 94043-1389
Unsolicited electronic mail will be subject to a $100 handling fee.
axo...@aol.com
I think it's kind of interesting that there was some kind of Defense
Department funding involved with a language that helped spawn interactive
fiction. Not necessarily significant, but interesting.
-stuff cut out-
>---------------------------------------------------------------------
>
> AUTHOR :Galley, S. W.
> TITLE :The MDL programming language / S.W. Galley and Greg Pfister.
> LANGUAGE :ENGLISH
> PUBLISHED :Cambridge, Mass. : Laboratory for Computer Science,
> Massachusetts Institute of Technology, c1979.
> PHYSICAL DESC :276 p. : ill. ; 28 cm.
> SERIES :MIT/LCS/TR; 293
> FUNDING INFO :Supported by the Advanced Research Projects Agency of the
> Dept. of Defense. N00014-75-C-0661
> BIBLIOGRAPHY :Includes bibliographical references.
> OTHER AUTHOR :Pfister, Gregory F.
> OTHER AUTHOR :Massachusetts Institute of Technology. Laboratory for
Computer
> Science.
> OTHER TITLE :Programming language, The MDL.
>
>-------------------------------------------------------------------
Jason Gilman axo...@nospam.aol.com
J. Holder
Thus spake axo...@aol.com:
: I think it's kind of interesting that there was some kind of Defense
: Department funding involved with a language that helped spawn interactive
: fiction. Not necessarily significant, but interesting.
: -stuff cut out-
: > FUNDING INFO :Supported by the Advanced Research Projects Agency of the
: > Dept. of Defense. N00014-75-C-0661
Actually ARPA supported TONS of non-defense related projects.
ARPANet, for one (precursor to the Internet), and, well MDL, and....
(I'd have to dig out some books froom home, and I'm at work....)
Notice I didn't say ARPA _invented_ anything. They were just
a source of funds, and sometimes helped coordinate projects...
Jeff Hatch
Paul F. Snively wrote:
>
> In article <34F45E...@surrey.ac.uk>, Nizam U Ahmed
> <cs4...@surrey.ac.uk> wrote:
> > But why have people gone to the trouble of creating full
> > programming languages when any object-oriented language, eg
> > Smalltalk, could be used to write an interpreting engine, leaving
> > their IF project. These objects could then be 'animated' by the
> > IF engine.
>
> TADS both provide some things out of the box--I'm primarily thinking of the
> language parsing stuff, timers, fuses, etc.--that Smalltalk, Lisp, C++,
> etc. don't offer out of the box.
[snip]
Whether Smalltalk etc. offer the good stuff "out of the box" is entirely
beside the point. The question is: "Why didn't Graham Nelson and the
others merely write a little C++ add-on library that would offer all the
language parsing stuff, timers, fuses, etc?"
Or maybe you mean that it wouldn't be possible for C++ etc. to offer all
the little conveniences that Inform, TADS, and Hugo have. It probably
couldn't have all the minor shortcuts, like double-quoted strings that
automatically print themselves. But it'd be easy to provide good
classes for language parsing, timers, and fuses.
It seems to me that writing a C++ library would have been a better use
of time than creating TADS or Inform, but once TADS and Inform were
created I don't see the point in creating a C++ library. One good IF
development system is enough. Two are more than enough.
-Rúmil, with a straight face, and not meaning to "denigrate" Hugo by
omission
Jeff Hatch
Dancer wrote:
> * Any specialised language operates better within [its] field than a
> generalised one within that same field.
Usually, not always! C++ would definitely be more useful to write IF
than the first version of AGT that I saw many years ago. All
generalizations are bad.
-Rúmil
Rhodri James
In article <34F77C...@hatch.net>,
Jeff Hatch <je...@hatch.net> wrote:
> Whether Smalltalk etc. offer the good stuff "out of the box" is entirely
> beside the point. The question is: "Why didn't Graham Nelson and the
> others merely write a little C++ add-on library that would offer all the
> language parsing stuff, timers, fuses, etc?"
Apart from small details such as C++ at the time not being the all-
consuming (in several senses) behemoth that it has become?
But to answer the spirit of your question, the answer is "because that
wasn't what they were trying to do." In the case of Inform, in
particular, it grew from the desire to specifically target the Z-machine,
and like Topsy, the assembler grew.
--
Rhodri James *-* Wildebeeste herder to the masses
If you don't know who I work for, you can't misattribute my words to them
... I'm sure I had a life around here somewhere
Dancer
Just clarify for me, weren't DARPA and ARPA two distinctly different groups? (one
part of DoD and the other a sort of prototypical NSF)
D
J. Holder wrote:
--
Dancer
Jeff Hatch wrote:
> Paul F. Snively wrote:
> >
> > In article <34F45E...@surrey.ac.uk>, Nizam U Ahmed
> > <cs4...@surrey.ac.uk> wrote:
> [snip]
> > > But why have people gone to the trouble of creating full
> > > programming languages when any object-oriented language, eg
> > > Smalltalk, could be used to write an interpreting engine, leaving
> > > the IF author to code up a class hierarchy in Smalltalk defining
> > > their IF project. These objects could then be 'animated' by the
> > > IF engine.
> >
> > Typically because the level of abstraction is still too low: Inform and
> > TADS both provide some things out of the box--I'm primarily thinking of the
> > language parsing stuff, timers, fuses, etc.--that Smalltalk, Lisp, C++,
> > etc. don't offer out of the box.
> [snip]
>
> Whether Smalltalk etc. offer the good stuff "out of the box" is entirely
> beside the point. The question is: "Why didn't Graham Nelson and the
> others merely write a little C++ add-on library that would offer all the
> language parsing stuff, timers, fuses, etc?"
>
> Or maybe you mean that it wouldn't be possible for C++ etc. to offer all
> the little conveniences that Inform, TADS, and Hugo have. It probably
> couldn't have all the minor shortcuts, like double-quoted strings that
> automatically print themselves. But it'd be easy to provide good
> classes for language parsing, timers, and fuses.
>
> It seems to me that writing a C++ library would have been a better use
> of time than creating TADS or Inform, but once TADS and Inform were
> created I don't see the point in creating a C++ library. One good IF
> development system is enough. Two are more than enough.
Bah. You missed the point. Inform was written to fill a need: A high-level
language that converts to Z-code. As for TADS, I think C++ was still in it's
infancy when TADS was built (perhaps not yet born).
D
Dancer
When I generalise, I sort of imply that I'm oversimplifying. :)
D
Jeff Hatch wrote:
--
Neil Bowers
Dancer <dan...@brisnet.org.au> wrote:
: Just clarify for me, weren't DARPA and ARPA two distinctly different groups?
The D comes and goes depending on political climate, I guess.
For example, you can use either URL:
http://www.arpa.mil/
http://www.darpa.mil/
neilb
--
The hottest places in hell are reserved for those who in time of great
moral crises maintain their neutrality.
-- Dante Alighieri 1265-1321
David Kinder
David Lebling <david_...@avid.com> wrote in article
<34F5BD...@avid.com>...
> I had heard that the ZIL development environment, which Infocom ran
> on TOPS-20 and Unix, didn't survive the trip from Cambridge to
> California. I'd be curious to know where you heard this, and wonder if
> Laird could give a more definitive answer.
On a related topic, what became of the original MDL sources to
Zork/Dungeon?
Have these been lost as well or do they exist on an old Infocomer's hard
drive
somewhere? Even though we have the C/Fortran version of Dungeon, playing
the
original would be fun.
David
Paul F. Snively
> Whether Smalltalk etc. offer the good stuff "out of the box" is entirely
> beside the point. The question is: "Why didn't Graham Nelson and the
> others merely write a little C++ add-on library that would offer all the
> language parsing stuff, timers, fuses, etc?"
Well, as has been pointed out before, in the _specific_ case of Graham, the
answer's easy: he was targeting the existing ZIP architecture that dates to
the mid-to-late 1970s. I suppose he could have taken an existing, e.g. C++
compiler such as gcc/g++ and tried to target ZIP with it, but *ouch*. It
was all but certainly less work to create a new source language--and, while
he was at it, to have the source language pretty much directly reflect the
semantics of the target language, which C++ (again, for example only)
definitely does not.
Look on the bright side: at least Inform source code resembles C instead of
Lisp. ;-)
> Or maybe you mean that it wouldn't be possible for C++ etc. to offer all
> the little conveniences that Inform, TADS, and Hugo have. It probably
> couldn't have all the minor shortcuts, like double-quoted strings that
> automatically print themselves.
Of course it would be possible; C++ and C (in which Inform and TADS are
written) are trivially Turing equivalent. And actually, in C++, I'd be
willing to bet that double-quoted strings self-printing would be pretty
damned easy to create.
> But it'd be easy to provide good
> classes for language parsing, timers, and fuses.
For some definition of "easy," sure. I've certainly never argued otherwise.
> It seems to me that writing a C++ library would have been a better use
> of time than creating TADS or Inform, but once TADS and Inform were
> created I don't see the point in creating a C++ library. One good IF
> development system is enough. Two are more than enough.
Creating a C++ library would have been fine if everyone who ever wanted to
create Interactive Fiction were a C++ programmer with access to C++
development tools. Inform is simply a new source language with a compiler
that produces an ancient intermediate representation that just happens to
be very popular by virtue of being the "binary format" for all of the
Infocom text (?) adventures. I'm not sure what the motivation behind TADS'
creation was, but I suspect that it also has to do with being appropriate
to the application domain.
C++, to stick with the specific example, has many features that it either
inherits from C or introduces that not only wouldn't prove especially
helpful in creating Interactive Fiction, but would actively get in the way
_of the average IF author who didn't have a programming background, let
alone a C or C++ background_. I think this last point deserves
underscoring. To name just one obvious example, there's no good reason for
an IF author to deal with pointers at all, or, for that matter, memory
management at all. With an Inform or a TADS, you get both a library
semantics that's apropos of IF authoring _and_ a language semantics (and
yes, I realize that the line between language and library semantics is
quite blurry). Neither TADS nor Inform will allow you to go poking around
arbitrary memory locations, nor should they. C and C++ not only both do,
it's difficult to do anything meaningful in them without taking advantage
of the fact (although, to be fair, C++ with the Standard Template Libraries
mitigates this observation to a considerable extent, and in fact, it's only
the existence of the STL that _might_ induce me to write a new IF system in
C++ rather than, say, Scheme).
In the final analysis, I think the significant flaw in your argumentation
remains the idea that IF authors may as well learn a full-blown
general-purpose programming language _as we know and understand them
today_, Smalltalk wouldn't suffer from the weaknesses mentioned here, but
nevertheless is possessed of a porcine bulk irrelevant to IF and a lack of
portability (though how its portability compares to C++'s depends, in this
context, a great deal upon whether you're talking about source code
portability or binary portability). TADS and Inform both have the quality
of Turing equivalence--which, as I've discussed in this newsgroup at some
length, I believe to be important--but also a minimalist quality with
respect to being nevertheless heavily IF-focused. This tends to make them
both considerably more tractable to the wayfarer who wishes merely to lend
expression to their creative impulses in a new medium--that is, to someone
for whom the programming language is an (annoying, perhaps) means to an
end, rather than an end in itself.
> -Rúmil, with a straight face, and not meaning to "denigrate" Hugo by
> omission
Paul likewise, again omitting Hugo only due to lack of direct experience.
L. Ross Raszewski
In article <34F77D...@hatch.net>,
je...@hatch.net wrote:
> [snip] All
> generalizations are bad.
This is a paradox. (and yes, I did syuspect that it was intentional)
L. Ross Raszewski
In article <34F77C...@hatch.net>,
je...@hatch.net wrote:
> created I don't see the point in creating a C++ library. One good IF
> development system is enough. Two are more than enough.
Problem. By your logic (well, mostly by the logic of the original poster, but
you seem to agree with him on this point), you could also say that one general
purpose language is enougn, so after C++, why would anyone need to write Java.
For that matter, after FORTRAN, why would anyone need to write C.
For that matter, why the h--- do all of these languages exist anyway, you
could just write a library of asm calls :-)
For that matter, couldn't we just rite some libraries for the abacus...
Patrick Kellum
In article <6d7bo3$41...@fido.asd.sgi.com>, John Francis was talking about:
>In article <6d5t6q$97o$1...@neko.syix.com>,
>Patrick Kellum <pat...@syix.com> wrote:
>>The MDL programming environment
>>The MDL programming language
>>MDL primer and manual
>>RFC-0578: Using MIT-Mathlab MACSYMA from MIT-DMS Muddle
>I'd assume the primer would be the most use (if you could find one).
Cool, thanks. I'm mainly trying to find out the basic structor of the
language (how each command is written) and have figured out some of it
myself but it is a rather confusing language :-) I'll have to order a
copy of the primer when I get some spending money.
Ivan Cockrum
> Zork Zero may have been written in a variant of AdvSys that I built for
> Activision for their project to port Manhole to the PC. AdvSys was a
> sort of poor mans ZIL that I wrote after reading an article about how
> the Infocom games were implemented.
I find this fascinating yet baffling. Activision used a text adventure
programming language to imitate Apple's HyperCard? (Perhaps this explains
why the Millers were so unhappy with the original PC port.)
Incidentally, David, I didn't know that you still followed the IF
community. I played with AdvSys for awhile, many years ago. I got as far
as recreating my office environment. I remember AdvSys fondly (if not
well), and enjoyed Columbus Adventure.
-- Ivan
----------------------------------------------------------------------
Ivan Cockrum www.cockrumville.com iv...@NOSPAMcockrumville.com
----------------------------------------------------------------------
To reply by email, remove "NOSPAM" from the address above.
David Betz
Ivan Cockrum wrote:
>
> I find this fascinating yet baffling. Activision used a text adventure
> programming language to imitate Apple's HyperCard? (Perhaps this explains
> why the Millers were so unhappy with the original PC port.)
>
They used AdvSys as the scripting language part and built their own
graphics system. The AdvSys parser was removed entirely.
> Incidentally, David, I didn't know that you still followed the IF
> community. I played with AdvSys for awhile, many years ago. I got as far
> as recreating my office environment. I remember AdvSys fondly (if not
> well), and enjoyed Columbus Adventure.
>
I just started reading this group. I'm still interested in text
adventures but never seem to have the time to work on them. Recently,
I've started wondering about using a-life algorithms to build an
adventure game that the author could have fun playing. The idea would be
to build a model of a world where creatures evolved and then set it
running on its own for a while. The player could then jump in later
after the original creatures had evolved and hopefully were somewhat
different from the originals. Of course, this would have to be the
evolution of already somewhat intelligent creatures or they wouldn't be
interesting characters.
--
David Betz
db...@xlisper.mv.com
Jeff Hatch
L. Ross Raszewski wrote:
>
> In article <34F77C...@hatch.net>,
> je...@hatch.net wrote:
> > created I don't see the point in creating a C++ library. One good IF
> > development system is enough. Two are more than enough.
>
> Problem. By your logic (well, mostly by the logic of the original poster, but
> you seem to agree with him on this point), you could also say that one general
> purpose language is enougn, so after C++, why would anyone need to write Java.
> For that matter, after FORTRAN, why would anyone need to write C.
> For that matter, why the h--- do all of these languages exist anyway, you
> could just write a library of asm calls :-)
Assembler is very difficult to read, regardless of the quality of the
library. C's syntax is more elegant than FORTRAN's, and C++ may have
some poor syntax for
object-oriented programming, but it's still better than C's. Java is
designed to do something entirely different from C++.
In short, any time a new language is created, it should be better than
the existing languages in some respect. C++ is obviously better than
Inform as a general-purpose language, but Inform is so well suited to
the task of writing interactive fiction that it seems it would be a
waste of time to create a C++ library at this point.
But I don't fully believe my argument either. I'm writing my own
authoring system, which can do some things Inform, TADS, and C++ can't.
-Rúmil
Jeff Hatch
> > the little conveniences that Inform, TADS, and Hugo have. It probably
> > couldn't have all the minor shortcuts, like double-quoted strings that
> > automatically print themselves.
>
> Of course it would be possible; C++ and C (in which Inform and TADS are
> written) are trivially Turing equivalent. And actually, in C++, I'd be
> willing to bet that double-quoted strings self-printing would be pretty
> damned easy to create.
Turing equivalence essentially means you can do anything, not
that you can do it simply. BASIC is Turing equivalent, but there's no
way in most implementations of BASIC to abbreviate the line "A=A+1" to
simply "A++". I defy you to
show me a simple way to make double-quoted strings self-print in C++.
[snip]
> C++, to stick with the specific example, has many features that it either
> inherits from C or introduces that not only wouldn't prove especially
> helpful in creating Interactive Fiction, but would actively get in the way
> _of the average IF author who didn't have a programming background, let
> alone a C or C++ background_. I think this last point deserves
> underscoring. To name just one obvious example, there's no good reason for
> an IF author to deal with pointers at all, or, for that matter, memory
> management at all. With an Inform or a TADS, you get both a library
> semantics that's apropos of IF authoring _and_ a language semantics (and
> yes, I realize that the line between language and library semantics is
> quite blurry). Neither TADS nor Inform will allow you to go poking around
> arbitrary memory locations, nor should they. C and C++ not only both do,
> it's difficult to do anything meaningful in them without taking advantage
> of the fact (although, to be fair, C++ with the Standard Template Libraries
> mitigates this observation to a considerable extent, and in fact, it's only
> the existence of the STL that _might_ induce me to write a new IF system in
> C++ rather than, say, Scheme).
With a good library, a newbie could write a C++ IF without any use of
pointers or memory management. But I do agree that the language
semantics of Inform and TADS are better suited to IF than C++'s
semantics, because of the aforementioned shortcuts..
-Rúmil
(Hey, So why WAS Hugo created? Anyone? The only impression I've gotten
of Hugo is that it does graphics better than TADS and Inform, and that
doesn't seem to be a compelling reason to write a new system.)
Jeff Hatch
Dancer wrote:
> Jeff Hatch wrote:
> > It seems to me that writing a C++ library would have been a better use
> > of time than creating TADS or Inform, but once TADS and Inform were
> > development system is enough. Two are more than enough.
>
> language that converts to Z-code. As for TADS, I think C++ was still in it's
> infancy when TADS was built (perhaps not yet born).
I know that's why, but I personally never thought the extra portability
of the Z-machine was worth Graham Nelson's trouble. And nobody seems
quite sure why TADS was created.
I'm working on my own authoring system, though, so don't take anything I
said too seriously. :-)
-Rúmil, wondering why Hugo was created
Neil K.
je...@hatch.net wrote:
> I know that's why, but I personally never thought the extra portability
> of the Z-machine was worth Graham Nelson's trouble. And nobody seems
> quite sure why TADS was created.
I'm sure Mike Roberts knows.
My guess would be that he wrote it so that people could write
Infocom-quality text adventures. Until TADS was released there were no
common tools for writing Infocom-quality games. AGT and AdvSys came close,
but didn't quite make it, in my opinion. They could be used to write Zork
I-ish games, but nobody seems to have been able to take them much beyond
that, and I'm assuming that limitations of the systems had much to do with
that.
- Neil K.
--
t e l a computer consulting + design * Vancouver, BC, Canada
web: http://www.tela.bc.ca/tela/ * email: tela @ tela.bc.ca
Dancer
Personally I'm happy with inform and Z. Up to a point.
I want: Better linking, better array support, maybe dynamic memory allocations,
and either fixed-point or floating point types and manipulations.
Maybe when the ZZ machine comes out. I don't think portability would get injured
_too_ much. Dynamic allocation would cut a _few_ machines off the support tree,
and the fixed/floating point would probably do another few.
Heck, any machine too old for someone to write/modify the existing interpreter
would be lost.
D
Jeff Hatch wrote:
> Dancer wrote:
> > Jeff Hatch wrote:
> > > It seems to me that writing a C++ library would have been a better use
> > > of time than creating TADS or Inform, but once TADS and Inform were
> > > created I don't see the point in creating a C++ library. One good IF
> > > development system is enough. Two are more than enough.
> >
> > Bah. You missed the point. Inform was written to fill a need: A high-level
> > language that converts to Z-code. As for TADS, I think C++ was still in it's
> > infancy when TADS was built (perhaps not yet born).
>
> I know that's why, but I personally never thought the extra portability
> of the Z-machine was worth Graham Nelson's trouble. And nobody seems
> quite sure why TADS was created.
>
> I'm working on my own authoring system, though, so don't take anything I
> said too seriously. :-)
>
> -Rúmil, wondering why Hugo was created
--
Andrew Plotkin
> I want: [...] maybe dynamic memory allocations, [...]
What, you can get malloc source code, can't you? It can be ported to
Inform. Go for it. :)
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Dancer
That would mean adding operations to the Z-machine, yes? Which makes it
a thing not done lightly.
D
Andrew Plotkin wrote:
--
Francis Irving
On Mon, 02 Mar 1998 18:49:31 +1000, Dancer <dan...@brisnet.org.au>
wrote:
>> > I want: [...] maybe dynamic memory allocations, [...]
>>
>> What, you can get malloc source code, can't you? It can be ported to
>> Inform. Go for it. :)
>
>That would mean adding operations to the Z-machine, yes? Which makes it
>a thing not done lightly.
Not at all. It could allocate memory _within_ a single static array.
This is a compromise, but still useful. I think that Andrew must have
done something like this to write Lists and Lists.
Francis.
Home: fra...@pobox.co.uk Web: www.meta.demon.co.uk
Francis Irving
On Sun, 01 Mar 1998 08:40:56 -0500, David Betz <db...@xlisper.mv.com>
wrote:
>I just started reading this group. I'm still interested in text
>adventures but never seem to have the time to work on them. Recently,
>I've started wondering about using a-life algorithms to build an
>adventure game that the author could have fun playing. The idea would be
>to build a model of a world where creatures evolved and then set it
>running on its own for a while. The player could then jump in later
>after the original creatures had evolved and hopefully were somewhat
>different from the originals. Of course, this would have to be the
>evolution of already somewhat intelligent creatures or they wouldn't be
>interesting characters.
That sounds interesting... It would be something quite different from
IF, though. A sort of text/language-based alife environment. You'd
probably need something like the Erasmatron (www.erasmatazz.com) to
underly it, and then evolve from there.
You'd end up in a strange alien world, where tensions and stories
would be very different from in this one.
Allen Garvin
In article <01bd4461$72f642e0$6e3e63c3@default>,
David Kinder <D.Ki...@xyzzybtinternet.xyzzycom> wrote:
From my archive of interesting Rec.arts.int-fiction posts, last may
John Francis posted:
Unfortunately I think I just threw out my collection of 7-track magtapes.
One tape contained the MDL sources to the version of Zork around the time
it was ported to the PDP-11.
I just asked for a 1200' tape from the operators. As it was only for low-
priority backups I said a pre-used tape was OK. I was rather surprised to
find the ZORK sources on the tape, so I decided the backups weren't that
important anyway!
--
John Francis jfra...@engr.sgi.com Silicon Graphics, Inc.
(415)933-8295 2011 N. Shoreline Blvd. MS 43U-991
(415)933-4692 (Fax) Mountain View, CA 94043-1389
Unsolicited electronic mail will be subject to a $100 handling fee.
I think we should all give him a collective bonk on the head. *8-)
--
Allen Garvin kisses are a better fate
--------------------------------------------- than wisdom
eare...@faeryland.tamu-commerce.edu
http://faeryland.tamu-commerce.edu/~earendil e e cummings
Torbj|rn Andersson
Dancer <dan...@brisnet.org.au> wrote:
> Personally I'm happy with inform and Z. Up to a point.
>
> I want: Better linking, better array support, maybe dynamic memory
> allocations, and either fixed-point or floating point types and
> manipulations.
Well, you could simulate dynamic memory allocation by allocating one
big array statically, and then write functions to allocate parts of it
dynamically. Andrew Plotkin's "Lists and Lists" contains such a beast.
As far as I can see it only allocates fixed-size blocks, but it should
be reasonably simple to write up one that can allocate blocks of
arbitrary length.
In fact, I wrote one up just to test the idea, but since it's in a
state of severe untestedness I'm hesitant to upload it. (Unless, of
course, someone wants it anyway.)
Torbjörn
Andrew Plotkin
Francis Irving (fra...@ncgraphics.co.uk) wrote:
> On Mon, 02 Mar 1998 18:49:31 +1000, Dancer <dan...@brisnet.org.au>
> wrote:
> >> > I want: [...] maybe dynamic memory allocations, [...]
> >>
> >> What, you can get malloc source code, can't you? It can be ported to
> >> Inform. Go for it. :)
> >
> >That would mean adding operations to the Z-machine, yes? Which makes it
> >a thing not done lightly.
> Not at all.
I was about to post "Not at all" myself...
> It could allocate memory _within_ a single static array.
> This is a compromise, but still useful. I think that Andrew must have
> done something like this to write Lists and Lists.
Exactly. (The code won't do you much good because it's for fixed-size
blocks. Sigh. The string heap (for atom names) allocates any size blocks,
but it can't *de*allocate; when it's full you have to push the yellow
button and start over.)
The Glassers
Dancer <dan...@brisnet.org.au> wrote:
> Just clarify for me, weren't DARPA and ARPA two distinctly different
> groups? (one part of DoD and the other a sort of prototypical NSF)
Here's a quote from a cool AI history book I'm in the middle of reading
(AI: The Tumultous History of the Search for Artificial Intelligence, by
Daniel Crevier). On p. 115, there is a reference to DARPA with this
footnote:
"* By then, the alphabet-soup strategists had added "Defense" to the
Advanced Research Projects Agency's name, turning ARPA into DARPA."
So the answer is mainly no, but sorta yes.
--David Glasser
gla...@NOSPAMuscom.com
Check out my new I-F website at http://onramp.uscom.com/~glasser
Or, for a waste of time almost as good as spatch.net,
http://www.geocities.com/SoHo/6028/
The Glassers
> Object Foo "Bar"
> with
> aprop 0,
> anotherprop 1,
> Include "customprops.h";
> ;
>
> Doesn't work as intended. Obviously (as with my previous gripe-of-the-day)
> it's because of the statement-nature (something like the zen-nature) of
> the Include directive. The object definition is neatly closed off before
> the Include, as if a semi-colon were present.
> Le sigh. Not that it's a bad thing. Don't get me wrong, but it's 6am, and
> I've been shoehorning these base-classes around all night.
#include "customprops.h"
possibly. Many of the Inform compilation control directives (Ifdef,
Include, etc.) have a # variation that acts pretty much the same.
Or you could define a class that includes your customprops.
--David Glasser
gla...@NOSPAMuscom.com
Check out my new unfinished website at http://onramp.uscom.com/~glasser
It is better than my two-year-old unfinished website at
http://www.geocities.com/SoHo/6028/
Dancer
I must take a look at that. I've got to do some hefty array work for the
game I'm working on.
I've come up with a mediocre sort of solution to an in-game problem. Damned
if I can figure out how to run cabling through a dozen locations, and have
the player able to rewire everything, so I'm going to simplify by playing
with junctions.
D
Francis Irving wrote:
> On Mon, 02 Mar 1998 18:49:31 +1000, Dancer <dan...@brisnet.org.au>
> wrote:
>
> >> > I want: [...] maybe dynamic memory allocations, [...]
> >>
> >> What, you can get malloc source code, can't you? It can be ported to
> >> Inform. Go for it. :)
> >
> >That would mean adding operations to the Z-machine, yes? Which makes it
> >a thing not done lightly.
>
> Not at all. It could allocate memory _within_ a single static array.
> This is a compromise, but still useful. I think that Andrew must have
> done something like this to write Lists and Lists.
>
> Francis.
>
> Home: fra...@pobox.co.uk Web: www.meta.demon.co.uk
--
Dancer
I'm tempted...But not tempted enough. I write memory allocators before
breakfast. I suppose I should stop whining and sit down and do it.
I should never have expanded on this part of the simulation, damnit. Now
I'm stuck with the quinsequonces. :/
The inform library suffereth mightily under my new base-classes. (Okay, so
I changed the word 'Object' in a few places, and added an Include in
parserm. Anything to stop the beast complaining).
Gripe of the day:
Object Foo "Bar"
with
aprop 0,
anotherprop 1,
Include "customprops.h";
;
Doesn't work as intended. Obviously (as with my previous gripe-of-the-day)
it's because of the statement-nature (something like the zen-nature) of
the Include directive. The object definition is neatly closed off before
the Include, as if a semi-colon were present.
Le sigh. Not that it's a bad thing. Don't get me wrong, but it's 6am, and
I've been shoehorning these base-classes around all night.
D
Torbj|rn Andersson wrote:
--
Dancer
Andrew Plotkin wrote:
> Francis Irving (fra...@ncgraphics.co.uk) wrote:
> > On Mon, 02 Mar 1998 18:49:31 +1000, Dancer <dan...@brisnet.org.au>
> > wrote:
>
> > >> > I want: [...] maybe dynamic memory allocations, [...]
> > >>
> > >> What, you can get malloc source code, can't you? It can be ported to
> > >> Inform. Go for it. :)
> > >
> > >That would mean adding operations to the Z-machine, yes? Which makes it
> > >a thing not done lightly.
>
> > Not at all.
>
> I was about to post "Not at all" myself...
>
> > It could allocate memory _within_ a single static array.
> > This is a compromise, but still useful. I think that Andrew must have
> > done something like this to write Lists and Lists.
>
> Exactly. (The code won't do you much good because it's for fixed-size
> blocks. Sigh. The string heap (for atom names) allocates any size blocks,
> but it can't *de*allocate; when it's full you have to push the yellow
> button and start over.)
Well, I implemented a simple allocate/free for arbitrary sizes, out of (yes)
an array called Heap. It's a slightly wasteful algorithm, in that it uses
double the HeapSize. (It has an allocation map)
However it works for what I want it to do at the moment, and only totals a
measly 55 lines.
*sigh* Get this, 732 lines of simulation code...that's code with nothing much
to do with the basic mechanics of places, directions, the player, and the
player's equipment...and I think there's about 70% of the simulation to code
yet...
Although my triumph had to be squeezing a 110-line description property down
into 20 lines (there are a couple of fairly complex objects lurking in the
simulation.)
D
Dancer
The Glassers wrote:
> > Object Foo "Bar"
> > with
> > aprop 0,
> > anotherprop 1,
> > Include "customprops.h";
> > ;
> >
> > Doesn't work as intended. Obviously (as with my previous gripe-of-the-day)
> > it's because of the statement-nature (something like the zen-nature) of
> > the Include directive. The object definition is neatly closed off before
> > the Include, as if a semi-colon were present.
> > Le sigh. Not that it's a bad thing. Don't get me wrong, but it's 6am, and
> > I've been shoehorning these base-classes around all night.
>
> #include "customprops.h"
>
> possibly. Many of the Inform compilation control directives (Ifdef,
> Include, etc.) have a # variation that acts pretty much the same.
>
> Or you could define a class that includes your customprops.
That's actually what I did. The point is, I ultimately ended up wedging it
sideways into the library. No problem, I thought, so long as I can include some
of the properties for once specific object from a user-supplied file, then it's
still generic and not tied to a specific game-environment.
No such luck.
D
Dancer
D'oh. Silly me. The answer was trivial.
First I define 'class Root_' in baseclasses.h, without any custom props (at least
no custom game-specific pseudo-attributes), then just after it is defined, I
include gameroot.h (supplied by the game) which has:
class Root
class Root_
with
! custom game-specific props
;
Then all the remaining classes in baseclasses.h (and indeed, every object in the
game) inherits directly or indirectly from Root.
Why did I not see this before?
BTW....I noticed during the cant_go discussion that Graham stuck his two bits in,
and changed a property on 'Object'. Hmm. That leads me to wonder if I can merge the
Root class back into Object somehow. That would save the minor library tinkering I
did.
D
Dancer wrote:
--
Jeff Hatch
Dancer wrote:
>
> Personally I'm happy with inform and Z. Up to a point.
>
> I want: Better linking, better array support, maybe dynamic memory allocations,
> and either fixed-point or floating point types and manipulations.
What bothers you about Inform arrays? Anything other than the fact they
can't be dynamically
resized beyond a preset length?
-Rúmil
Dancer
Jeff Hatch wrote:
Mostly that they feel stumbling-bloody-awkward. I guess that's more my gripe than
anything. I wouldn't mind being able to dynamically allocate them...but simply
working-with/printing the things is a nuisance.
D
Jeff Hatch
Jeff Hatch wrote:
> What bothers you about Inform arrays? Anything other than the fact they
> can't be dynamically
> resized beyond a preset length?
Dancer wrote:
> Mostly that they feel stumbling-bloody-awkward. I guess that's more my gripe than
> anything. I wouldn't mind being able to dynamically allocate them...but simply
> working-with/printing the things is a nuisance.
Just syntax? I ask because I'm just about to begin work on arrays for
WhateverTheHeckImGoingToCallMySystem 1.0. I'm planning on allowing
dynamically resizeable arrays which can contain only your basic two-byte
data types, which could be numbers, references to objects, or dictionary
words. Syntax will be mostly similar to C, maybe something like this:
array CDial dials = { FirstDial, SecondDial, ThirdDial }; // initialize
array
dials [0].SetValue (17); // set FirstDial to 17
if (dials.GetSize () != 3) Error ("Array error!"); // never happens
Any thoughts? Is there anything else you would want? Two-dimensional
arrays? An array comparison operator? Arrays of strings? Would you
want to allow actual arrays OF objects instead of arrays of references
to objects, so that you could actually create four dials with the line
"array object CDial dials"?
-Rúmil
Dancer
I would find just arrays of values and/or pointers/references to be sufficient. There's
no need to do arrays of any aggregate object, IMO. I'd be careful though, if you make
the syntax too much like C or C++, people will probably just go out and use C or C++.
D
Jeff Hatch wrote:
--
Darin Johnson
Jeff Hatch <je...@hatch.net> writes:
> Whether Smalltalk etc. offer the good stuff "out of the box" is entirely
> beside the point. The question is: "Why didn't Graham Nelson and the
> others merely write a little C++ add-on library that would offer all the
> language parsing stuff, timers, fuses, etc?"
Because IF games can run on many computers. *Including* computers
with only 64K or less!!
Remember, Inform was written to compile to the same codes used by the
original Zork games, and those certainly ran on a large number of
machines that couldn't support C++ or Smalltalk.
They're more economical too. Most people can't afford a good
Smalltalk system just to devlop a game (much less just to play one).
Even C++ isn't ubiquitous. It's expensive for commercial versions
(the cheapest current systems are $99), and even if you use a free
gcc, it's large and takes up much space.
Plus, these systetms are *portable*. Not just source-code portable,
but portable binaries as well. Maybe some Windows bigots don't care
about portability, but the rest of the world does. It cuts down on
all those people asking "can you port your game to the Mac", "where's
the VAX version", etc. And it means you can develop anywhere too.
TADS and Inform are free and small. The runtime systems are easily
gotten by most people, and run most anywhere. The languages are easy
to learn and use, and are very powerful. I'd much rather use TADS
than C++ for this sort of stuff (although I think I'd love to use
Smalltalk too, but that's just too impractical).
Finally - languages are cool. Why not invent a new one? Writing new
languages is fun. Learning new languages is fun. Choosing the right
language for the job is fun. Making fun of people that don't like
all those languages is fun.
> It seems to me that writing a C++ library would have been a better use
> of time than creating TADS or Inform, but once TADS and Inform were
> created I don't see the point in creating a C++ library. One good IF
> development system is enough. Two are more than enough.
Only the people spending the own time should make the determination
that it was a waste of time or not. Was my time squandered when I
spent it wroking on a hobby instead of something others might feel was
a better use of time? Why then should the authors of IF languages,
who did this in their own spare time, be criticized? It would have
been a better use of time if we all had spent last night helping out
at a homeless shelter instead of watching TV too.
If you think a C++ class library would be good, then *you* can write one.
--
Darin Johnson
da...@usa.net.delete_me
Jeff Hatch
Darin Johnson wrote:
> Jeff Hatch wrote:
> > Whether Smalltalk etc. offer the good stuff "out of the box" is entirely
> > beside the point. The question is: "Why didn't Graham Nelson and the
> > others merely write a little C++ add-on library that would offer all the
> > language parsing stuff, timers, fuses, etc?"
>
> Because IF games can run on many computers. *Including* computers
> with only 64K or less!!
>
> but portable binaries as well. Maybe some Windows bigots don't care
> about portability, but the rest of the world does. It cuts down on
> all those people asking "can you port your game to the Mac", "where's
> the VAX version", etc. And it means you can develop anywhere too.
>
> TADS and Inform are free and small. The runtime systems are easily
> gotten by most people, and run most anywhere. The languages are easy
> to learn and use, and are very powerful. I'd much rather use TADS
> than C++ for this sort of stuff (although I think I'd love to use
> Smalltalk too, but that's just too impractical).
Those are unarguably wonderful traits! But I don't think portability is
very important compared the power of a language and the thoroughness of
its library. TADS and Inform are powerful enough for IF, but they're
still far less versatile than a full-fledged commercial programming
language. Last week I learned that Inform doesn't even have string
concatenation in the basic package!
Yes, TADS and Inform are wonderful, free tools for writing interactive
fiction. But (I speculate without firsthand knowledge) they're free
partly because there's not enough demand for specialized IF-writing
tools for them to make much money anyway.
I do think TADS and Inform are better for writing IF than C++ would be.
(And I wasn't stating my own question in my post, merely repeating
someone else's.) But a C++ library could be nearly as good in most
respects (and better in a few) with far less effort. When writing an IF
development system is such a time-consuming and unprofitable task, why
not take the easy route?
> Finally - languages are cool. Why not invent a new one? Writing new
> languages is fun. Learning new languages is fun. Choosing the right
> language for the job is fun. Making fun of people that don't like
> all those languages is fun.
Exactly! I think that's the #1 reason why Inform, TADS, and many other
systems were developed. A C++ library would have been more practical,
but an entirely new language is far more fun to write.
> > It seems to me that writing a C++ library would have been a better use
> > of time than creating TADS or Inform, but once TADS and Inform were
> > created I don't see the point in creating a C++ library. One good IF
> > development system is enough. Two are more than enough.
>
> Only the people spending the own time should make the determination
> that it was a waste of time or not. Was my time squandered when I
> spent it [working] on a hobby instead of something others might feel was
> a better use of time? Why then should the authors of IF languages,
> who did this in their own spare time, be criticized? It would have
> been a better use of time if we all had spent last night helping out
> at a homeless shelter instead of watching TV too.
I didn't mean to criticize the authors of IF languages. Yes, I do feel
that a C++ library would have been more practical. But I would never
dare use such a stark phrase as "waste of time"! I intended the phrases
"It seems to me" and "I don't see" to soften my statements by
emphasizing the subjective nature of my opinions. As you point out,
time spent on an enjoyable hobby is time well spent.
Darin Johnson wrote:
> If you think a C++ class library would be good, then *you* can write one.
Um...I did just say that "once TADS and Inform were created I don't see
the point in creating a C++ library.
But I am writing my own new interactive fiction authoring system!
That's why I had the nerve to write that "One good interactive fiction
authoring system is enough" with no apologies to anyone. I expected the
if.arts.int-fiction regulars to remember some of my posts regarding my
authoring system and perceive a bit of irony in that sentence. IIRC I
did sign that message as "Rúmil, with a straight face."
My authoring system already has several features that aren't available
in C++, Inform, or TADS. No, I don't think they're valuable enough to
justify the hundreds of hours I've spent programming! I know *quite*
well that "Writing new languages is fun." If it weren't, I'd use
Inform.
-Rúmil
P.S. What is this, the third time I've responded to a response to my
response? :-) Remind me not to be subtly ironic in a text-only
medium. At least not without immediately explaning my real intent.
P.P.S. No you don't ACTUALLY need to remind me. That's just a figure
of speech.
P.P.P.S. Yes, I know you already knew it was a figure of speech. That
postscript was meant to be ironic, by explaining my real intent even
though this time it was quite obvious.
P.P.P.P.S. Yes, I know you already realized that, too. I was being
ironic in explaining my own irony, too. Repeat as needed.
Alan Shutko
>>>>> "J" == Jeff Hatch <je...@hatch.net> writes:
J> Those are unarguably wonderful traits! But I don't think
J> portability is very important compared the power of a language and
J> the thoroughness of its library.
Curses was written by someone on an Acorn. If it _weren't_ portable,
I don't think you'd have ever had a chance to play it.
I'll bet most of Zarf's games were written on a Mac. If they weren't
portable, I'd never have played them, and statistics say you probably
wouldn't have either.
If I were limited to games written on my platform, I wouldn't have
played the vast majority of games that are out. I would certainly
have been hindered in my attempts to play the old Infocom games.
Portability may not be important to you, which makes me bet that you
are running Windows 95. If you weren't running Win95, you'd probably
realize that without portable game systems, you wouldn't be able to
play most interactive fiction.
--
Alan Shutko <a...@acm.org> - By consent of the corrupted
Old soldiers never die. Young ones do.
L. Ross Raszewski
In article <3504F3...@hatch.net>,
je...@hatch.net wrote:
>
> Those are unarguably wonderful traits! But I don't think portability is
> very important compared the power of a language and the thoroughness of
> its library. TADS and Inform are powerful enough for IF, but they're
> still far less versatile than a full-fledged commercial programming
> language. Last week I learned that Inform doesn't even have string
> concatenation in the basic package!
Well, that's perhaps a poor decision distributionwise, but not a limitation of
the language. C doesn't have string contatenation in hte basic language, you
have to add the standard library files for that. Inform is every bit
as versitile as a "full fledged" language for almost all applications.
(PLUG!!!!) And there _is_ a string library for inform, available at the
primary Inform distribution site (istring.h, by me :-)
>
> Yes, TADS and Inform are wonderful, free tools for writing interactive
> fiction. But (I speculate without firsthand knowledge) they're free
> partly because there's not enough demand for specialized IF-writing
> tools for them to make much money anyway.
TADS wasn't always free. Inform is free, I think, mostly because it was a
labour of love on the part of its very dedicated programmer.
> I do think TADS and Inform are better for writing IF than C++ would be.
> (And I wasn't stating my own question in my post, merely repeating
> someone else's.) But a C++ library could be nearly as good in most
> respects (and better in a few) with far less effort. When writing an IF
> development system is such a time-consuming and unprofitable task, why
> not take the easy route?
Because the hard route, as you say, produces a better language for the task at
hand.
>
> Exactly! I think that's the #1 reason why Inform, TADS, and many other
> systems were developed. A C++ library would have been more practical,
> but an entirely new language is far more fun to write.
No, a C++ library would have been _easier_. a new langueage would have been
_better_, and in fact, was.
>
> Um...I did just say that "once TADS and Inform were created I don't see
> the point in creating a C++ library.
Actually, if you thought you could add something to the world by doing it, I'd
say do it. However (and please don't take this the wrong way) the fact that
you don't see the point in doing it sort of implies that you are not the
person to do such a thing (and I certaintly am not the person to do it :-) I
do encourage anyone who thinks that can make a C++ library that will have
some advantage over what already exists to do it, by all means.
>
> My authoring system already has several features that aren't available
> in C++, Inform, or TADS. No, I don't think they're valuable enough to
> justify the hundreds of hours I've spent programming! I know *quite*
> well that "Writing new languages is fun." If it weren't, I'd use
> Inform.
>
Here here!
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
Mark J. Tilford
On Tue, 10 Mar 1998 00:01:27 -0800, Jeff Hatch <je...@hatch.net> wrote:
>
>Yes, TADS and Inform are wonderful, free tools for writing interactive
>fiction. But (I speculate without firsthand knowledge) they're free
>partly because there's not enough demand for specialized IF-writing
>tools for them to make much money anyway.
>
it freely later.
--
-----------------------
Mark Jeffrey Tilford
til...@cco.caltech.edu
Chris Marriott
In article <6e45i2$3q$1...@nnrp1.dejanews.com>, L. Ross Raszewski
<rras...@hotmail.com> writes
>C doesn't have string contatenation in hte basic language, you
>have to add the standard library files for that.
But the libraries ARE a part of the language. The ANSI C standard
defines both the language AND the libraries which every conformant
compiler MUST have. Functions like, for example, "strcpy", are
guarenteed to be available in every C implementation and are totally
portable.
Chris
----------------------------------------------------------------
Chris Marriott, SkyMap Software, UK (ch...@skymap.com).
Visit our web site at: http://www.skymap.com
Astronomy software written by astronomers, for astronomers.
Andrew Plotkin
Chris Marriott (ch...@chrism.demon.co.uk) wrote:
> In article <6e45i2$3q$1...@nnrp1.dejanews.com>, L. Ross Raszewski
> <rras...@hotmail.com> writes
> >C doesn't have string contatenation in hte basic language, you
> >have to add the standard library files for that.
> But the libraries ARE a part of the language. The ANSI C standard
> defines both the language AND the libraries which every conformant
> compiler MUST have. Functions like, for example, "strcpy", are
> guarenteed to be available in every C implementation and are totally
> portable.
Well, now that istring.h is written, it's guaranteed to be available to
every Inform programmer (unless gmd.de crashes) and it's totally
portable. So what's the difference?
Chris Marriott
In article <erkyrathE...@netcom.com>, Andrew Plotkin
<erky...@netcom.com> writes
>Chris Marriott (ch...@chrism.demon.co.uk) wrote:
>> In article <6e45i2$3q$1...@nnrp1.dejanews.com>, L. Ross Raszewski
>> <rras...@hotmail.com> writes
>> >C doesn't have string contatenation in hte basic language, you
>> >have to add the standard library files for that.
>
>> But the libraries ARE a part of the language. The ANSI C standard
>> defines both the language AND the libraries which every conformant
>> compiler MUST have. Functions like, for example, "strcpy", are
>> guarenteed to be available in every C implementation and are totally
>> portable.
>
>Well, now that istring.h is written, it's guaranteed to be available to
>every Inform programmer (unless gmd.de crashes) and it's totally
>portable. So what's the difference?
Very little; I was merely responsing to the previous poster's incorrect
assertion that the C's string libraries aren't a part of the C language.
Patrick Kellum
In article <OoIqmTAm...@chrism.demon.co.uk>, Chris Marriott was talking about:
>guarenteed to be available in every C implementation and are totally
>portable.
So, never used C on a Commodore 64?
Patrick
---
A Title For This Page -- http://www.syix.com/patrick/
Bow Wow Wow Fan Page -- http://www.syix.com/patrick/bowwowwow/
The Small Wonder Page -- http://smallwonder.simplenet.com/
My Arcade Page -- http://ygw.bohemianweb.com/arcade/
Tales Of The Wyrm -- http://www.syix.com/patrick/tales_of_the_wyrm.shtml
"Animal crackers in my poop." - Shirley Temple
"I have photographs of you naked with a squirrel." - Dave Barry
Jeff Hatch
Alan Shutko wrote:
> >>>>> "J" == Jeff Hatch <je...@hatch.net> writes:
>
> J> Those are unarguably wonderful traits! But I don't think
> J> portability is very important compared the power of a language and
> J> the thoroughness of its library.
>
> Curses was written by someone on an Acorn. If it _weren't_ portable,
> I don't think you'd have ever had a chance to play it.
>
> I'll bet most of Zarf's games were written on a Mac. If they weren't
> portable, I'd never have played them, and statistics say you probably
> wouldn't have either.
>
> If I were limited to games written on my platform, I wouldn't have
> played the vast majority of games that are out. I would certainly
> have been hindered in my attempts to play the old Infocom games.
>
> Portability may not be important to you, which makes me bet that you
> are running Windows 95.
Guilty as charged.
> If you weren't running Win95, you'd probably
> realize that without portable game systems, you wouldn't be able to
> play most interactive fiction.
I'd really like to see some statistics on this. Has anyone taken a
formal survey that says what platforms IF authors use? Pardon my
skepticism, but AFAIK virtually all new computers sold these days are
Windows- or Mac-compatible. And certainly all commercial software is.
It's nice that people can play interactive fiction on machines that are
totally incapable of running modern software, yes, but since a majority
of computer users have modern machines, I believe a majority of IF users
have them. Maybe this is wrong, since many IF fans bought their first
computers in the Infocom era. I don't know.
And I didn't mean I was totally unconcerned about portability, only that
I didn't much value the extreme portability of the Z-machine.
Portability is a relative term: C is quite portable compared to FORTRAN
and BASIC, but compared with Inform it's still so un-portable that right
now Graham has fallen off his chair laughing.
I'm planning on making sure that my full-fledged authoring system can
run on a Macintosh, and that the games produced using the system can run
on several of the other relatively popular platforms. I've spent
hundreds hours working on this system, and I'm certainly willing to
spend another few dozen to make sure more people can use it. But my #1
priority is to make sure that on a DOS-supporting machine my system is
far better than any other system, and until that goal is met I won't
bother porting!
If Inform and the Z-machine weren't portable, someone would have gone to
the trouble of porting Curses by now anyway. It's that good.
-Rúmil
Jeff Hatch
> > very important compared the power of a language and the thoroughness of
> > its library. TADS and Inform are powerful enough for IF, but they're
> > still far less versatile than a full-fledged commercial programming
> > language. Last week I learned that Inform doesn't even have string
> > concatenation in the basic package!
>
> the language. C doesn't have string contatenation in hte basic language, you
> have to add the standard library files for that. Inform is every bit
> as versitile as a "full fledged" language for almost all applications.
No, not really. Any C++ library will allow you to overload the plus
operator so that you can simply say "StringA = StringB + StringC". In
Inform this isn't possible, and never will be. Inform is far less
flexible than C++ in this regard. My system already allows this kind of
string concatenation, but it's built into the language, and operator
overloading is not allowed, so my system will never be nearly as
versatile as a "full fledged" language, either.
My point isn't that C++ is the best tool for programming IF; if I
thought so, I wouldn't be writing a new system. My point is simply that
no language written for IF will ever be nearly as flexible as a
professional-quality programming language, and we're deluding ourselves
if we don't recognize the disadvantages of these specialized languages,
as well as their advantages.
> (PLUG!!!!) And there _is_ a string library for inform, available at the
> primary Inform distribution site (istring.h, by me :-)
And now that you've created that string library, Inform is as good as C
in that area, though still not as good as C++. My point was simply that
any specialized language has a huge disadvantage, since the programmers
for that language must reinvent dozens of simple, basic features that
would already exist if Graham Nelson had just created a C++ library
patch. I *don't* believe that I personally would have been impressed
with the initial incarnation of Inform. Through the efforts of a large
community of devoted IF authors, it's become far more than it originally
was.
Once any tool becomes widely used, it can become good enough to be worth
using. If Graham Nelson had written a C++ library for a DOS shell, I
think we would see a similar phenomenon. The first release would have
been a bit more powerful, and a bit more flexible, but it wouldn't have
been quite as portable, or as well-suited to interactive fiction. And
after a few years, some devoted Inform fan would port his library to the
Acorn. Later, some clever fellow would write a precompiling utility
that allows double-quoted strings to be automatically print and return
"true."
Pure speculation, of course. Nobody can prove one way or the other what
would happen if a C++ library had been written instead. Let's just be
glad that we have excellent tools for writing interactive fiction,
regardless of the path taken to get them.
-Rúmil
Stephen Robert Norris
In article <350659...@hatch.net>,
Jeff Hatch <je...@hatch.net> intoned:
> I'd really like to see some statistics on this. Has anyone taken a
> formal survey that says what platforms IF authors use? Pardon my
> skepticism, but AFAIK virtually all new computers sold these days are
> Windows- or Mac-compatible. And certainly all commercial software is.
> It's nice that people can play interactive fiction on machines that are
> totally incapable of running modern software, yes, but since a majority
> of computer users have modern machines, I believe a majority of IF users
> have them. Maybe this is wrong, since many IF fans bought their first
> computers in the Infocom era. I don't know.
If this isn't a troll, you're an idiot. If it is, you're an idiot.
I buy a lot of hardware for clients that doesn't run Windows or MacOS.
All my clients write or purchase commercial software. I run Linux;
I use a word processor and a spreadsheet etc. that is commercial.
Stephen
Mark J. Tilford
On Wed, 11 Mar 1998 01:31:00 -0800, Jeff Hatch <je...@hatch.net> wrote:
>skepticism, but AFAIK virtually all new computers sold these days are
>Windows- or Mac-compatible. And certainly all commercial software is.
Have you ever heard of Linux? OS/2? FreeBSD? or other non-windows
operating systems that run on modern computers? PC != Microsoft, and
there is commercial software available for these OS's.
(Although my computer came with Windows 95 preinstalled, I found it to be
awful. I tried Linux, loved it, and have never regretted it.)
>If Inform and the Z-machine weren't portable, someone would have gone to
>the trouble of porting Curses by now anyway. It's that good.
>
>-Rúmil
I disagree. If Curses had been Acorn only, only a few people would have
played it; it would not have acquired a big enough following that anybody
would have bothered porting it.
David Given
In article <350659...@hatch.net>, Jeff Hatch <je...@hatch.net> wrote:
[...]
>I'd really like to see some statistics on this. Has anyone taken a
>formal survey that says what platforms IF authors use? Pardon my
>Windows- or Mac-compatible. And certainly all commercial software is.
>totally incapable of running modern software, yes, but since a majority
>of computer users have modern machines, I believe a majority of IF users
>have them. Maybe this is wrong, since many IF fans bought their first
>computers in the Infocom era. I don't know.
Be afraid. Be very afraid. You have just opened a portal to Somewhere that
you did not want to go. You have just started what may be the biggest
flame war that raif has seen for many a week...
I have played IF on Linux, DOS, Risc OS and OSF/1. I use Linux at work
(Win95 on Mondays when I need to do a spreadsheet in Excel) and DR-DOS at
home (my machine won't run Linux). Trying to insist that all computers run
Windows or MacOS is sheer arrogance.
[...]
>I'm planning on making sure that my full-fledged authoring system can
>run on a Macintosh, and that the games produced using the system can run
>on several of the other relatively popular platforms. I've spent
>hundreds hours working on this system, and I'm certainly willing to
>spend another few dozen to make sure more people can use it. But my #1
>priority is to make sure that on a DOS-supporting machine my system is
>far better than any other system, and until that goal is met I won't
>bother porting!
If your system only runs on Windows and MacOS, then a number of people
large enough to surprise you (including me) can't and won't use it. Is
there any way of making your authoring system produce, say, Z code? That
would solve all your portability problems at a stroke.
>If Inform and the Z-machine weren't portable, someone would have gone to
>the trouble of porting Curses by now anyway. It's that good.
No, it wouldn't, because no-one would have heard of it. The Acorn world is
*tiny* (I know, I used to have one). It's about the same size as the I-F
world, but the two don't overlap much and it's confined almost exclusively
to Britain and some parts of Europe. It Curses hadn't been portable, maybe
a dozen people in the UK would be raving about it and the rest of world
would forget about it after learning that it didn't run on anything else.
Do you know how much money the computing world is putting in to
portability? Java? Cross-platform development? The company I work for
has portability as its entire raison d'etre; a year ago it had less
then ten people, now we're round about fifty. Does this suggest anything
to you?
--
David Given
d...@freeyellow.com
David Betz
> > I'd really like to see some statistics on this. Has anyone taken a
> > formal survey that says what platforms IF authors use? Pardon my
> > skepticism, but AFAIK virtually all new computers sold these days are
> > Windows- or Mac-compatible. And certainly all commercial software is.
> > It's nice that people can play interactive fiction on machines that are
> > totally incapable of running modern software, yes, but since a majority
> > of computer users have modern machines, I believe a majority of IF users
> > have them. Maybe this is wrong, since many IF fans bought their first
> > computers in the Infocom era. I don't know.
>
>
> I buy a lot of hardware for clients that doesn't run Windows or MacOS.
>
> All my clients write or purchase commercial software. I run Linux;
> I use a word processor and a spreadsheet etc. that is commercial.
>
> Stephen
Well, obviously just Windows 95 and the Macintosh isn't sufficient. What
about a game system that could run on any modern 32 bit or better system
that had an ANSI C compiler available for it? Would that be portable
enough? I guess what I'm asking is do we really need to support older 8
and 16 bit machines anymore? Can I assume a large address space 32 bit
machine for a new game system?
David
--
David Betz
db...@xlisper.mv.com
Chris Marriott
In article <6e5gcj$hvr$1...@neko.syix.com>, Patrick Kellum
<pat...@syix.com> writes
>In article <OoIqmTAm...@chrism.demon.co.uk>, Chris Marriott was talking
>about:
>
> >guarenteed to be available in every C implementation and are totally
> >portable.
>
>So, never used C on a Commodore 64?
You missed out the previous sentence where I said "Any compiler
conformant with the ANSI C standard...". By definition, if a C compiler
doesn't support the standard libraries, it's not ANSI C compatible and
so the sentence you've quoted (out of context) above doesn't apply.
Patrick Kellum
In article <350659...@hatch.net>, Jeff Hatch was talking about:
>skepticism, but AFAIK virtually all new computers sold these days are
Amigas are still being manufactored and sold as well. Then, lets consider
BeOS which replaces MacOS (and soon Windows).
>Windows- or Mac-compatible. And certainly all commercial software is.
Wrong, most is but new commercial software is still developed and sold for
other OS, Amiga and even the Commodore 64 (surprisingly).
>It's nice that people can play interactive fiction on machines that are
>totally incapable of running modern software, yes, but since a majority
Mac and Win are NOT the only machines capable of running modern software!
Name one thing that Win95 can do that Amiga can't (besides crashing twice
as often).
>of computer users have modern machines, I believe a majority of IF users
>have them. Maybe this is wrong, since many IF fans bought their first
>computers in the Infocom era. I don't know.
Well, there are a fw Amiga users, some Acorn users, at least one C64 user,
and I use an Osborn-1 on occasion just for the hell of it. Then you can
start adding up all those little mini computers (Newton and PalmPilot
*giggle*).
>And I didn't mean I was totally unconcerned about portability, only that
>I didn't much value the extreme portability of the Z-machine.
But you do value haveing to recomplie a game for every possable platform?
Sounds like a waste.
>Portability is a relative term: C is quite portable compared to FORTRAN
>and BASIC, but compared with Inform it's still so un-portable that right
Depends. For simple text based output, C is almost portable. For
anything involving the simplest of GUI routines C is very UnPortable since
massive amounts of code would have to be re-written. I personally have
little trouble porting BASIC to the various versions out there. I ported
a QBASIC (or GWBASIC, I forget) text adventure to the C64 a while back,
extreamly simple.
>If Inform and the Z-machine weren't portable, someone would have gone to
>the trouble of porting Curses by now anyway. It's that good.
Maybe a few ports, but I doubt you would see it on as many machines as it
is now simply because it is such a large game. The Z-Machines virtual
memory system is designed to fit large games into small computers :-) The
question really is, would Curses (or the majority of new IF) ever have
been written if it weren't for TADS/Inform?
Patrick Kellum
In article <3fUUrEBW...@chrism.demon.co.uk>, Chris Marriott was talking about:
>In article <6e5gcj$hvr$1...@neko.syix.com>, Patrick Kellum
><pat...@syix.com> writes
>>In article <OoIqmTAm...@chrism.demon.co.uk>, Chris Marriott was talking
>>about:
>>
>> >guarenteed to be available in every C implementation and are totally
>> >portable.
>>
>>So, never used C on a Commodore 64?
>
>You missed out the previous sentence where I said "Any compiler
>conformant with the ANSI C standard...". By definition, if a C compiler
>doesn't support the standard libraries, it's not ANSI C compatible and
>so the sentence you've quoted (out of context) above doesn't apply.
Different sentence, but in this one you said "every C implimination" NOT
"every ANSI C implimination".
Joe Pfeiffer
Jeff Hatch <je...@hatch.net> writes:
>
> I'd really like to see some statistics on this. Has anyone taken a
> formal survey that says what platforms IF authors use? Pardon my
> totally incapable of running modern software, yes, but since a majority
> have them. Maybe this is wrong, since many IF fans bought their first
> computers in the Infocom era. I don't know.
Ummmm.... suggesting to a Linux user that either Windows or MacOs is
a more modern system is laughable, at best (and BeOS is sneaking up on
us Linux users).
Besides I play IF games on my PalmPilot, not any of my real computers.
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University http://www.cs.nmsu.edu/~pfeiffer
Stephen Griffiths
All the talk in this thread about using an IF library with c or c++
has raised a question in my mind that I haven't seen clearly answered
yet.
The various IF systems have two advantages over general purpose
languages
- its easier to program IF in an IF system
- the IF systems produce a binary game file or files that can be
played on any operating system with a runtime interpreter program
compiled for that o.s.
My question is, could an add-in library allow a c or c++ compiler
output a binary gamefile that was playable with an appropriate runtime
interpreter on a variety of o.s.'s
I'll hazard a guess in answer to my own question .... I thought that a
c or c++ compiler would only output an o.s. specific executable file.
So no matter how easy an add-in library made the authoring of IF, the
c or c++ compiler's disadvantage - that an author would have to
compile a specific executable for each o.s. using a specific compiler
for that o.s. - would remain.
As each potential IF author does not have access to a multitude of
o.s.'s or a bevy of friendly and always-obliging 'porters' my second
reason for IF systems existence remains valid unless, as some-one said
in this thread, portability is not a priority.
Anyway, I'm interested (out of academic curiosity really) whether a c
or c++ compiler could theoretically output a portable gamefile. Thanks
for any answers!
--
SteveG.
(Please remove the typo from my address
if you want to send me mail.)
Patrick Kellum
In article <6e6ovp$cn$1...@wnnews1.netlink.net.nz>, Stephen Griffiths was talking about:
>I'll hazard a guess in answer to my own question .... I thought that a
>c or c++ compiler would only output an o.s. specific executable file.
To be exact they produce assembler for there own OS. The assembler is
then assembled into a binary :-) But I'm gettting far to picky here :-)
Using a c compiler would require seperate binaries for every single OS on
the face of the plannet, ranging from PalmPilot *giggle* and Commodore 64
to the mighty BeOS.
Matt Ackeret
In article <3504F3...@hatch.net>, Jeff Hatch <je...@hatch.net> wrote:
>Those are unarguably wonderful traits! But I don't think portability is
>very important compared the power of a language and the thoroughness of
>its library. TADS and Inform are powerful enough for IF, but they're
>still far less versatile than a full-fledged commercial programming
>language. Last week I learned that Inform doesn't even have string
>concatenation in the basic package!
Egads, C must not be a "full-fledged commercial programming language."
I guess thousands and thousands of programmers have to throw it out
because it "doesn't even have string concationation in the basic package!"
(standard libraries don't count, as they're not part of C proper.)
Heck, I guess by your regard AppleSoft BASIC is better!
(Right? I can do A$ = B$ + C$?? I remember MID$ and all the rest.)
>I do think TADS and Inform are better for writing IF than C++ would be.
Because IF people, as a generalization, care about portability, yes they're
better.
Plus, where is your parser and all of the extra "junk" underneath that
Inform takes care of gonna come from? Write it all as C++ objects?
--
mat...@area.com
Matt Ackeret
In article <6e6no2$4c6$1...@neko.syix.com>,
Patrick Kellum <pat...@syix.com> wrote:
>In article <350659...@hatch.net>, Jeff Hatch was talking about:
>
>
>BeOS which replaces MacOS (and soon Windows).
>
>
>other OS, Amiga and even the Commodore 64 (surprisingly).
And while it isn't "commercial" since it is not charged for, Wolfenstein 3D
for the Apple IIGS just came out. (But it is a legal version, not a clone
done by a bunch of "hackers".)
--
mat...@area.com
Chris Marriott
In article <1bn2ewe...@cs.nmsu.edu>, Joe Pfeiffer
<pfei...@cs.nmsu.edu> writes
>Ummmm.... suggesting to a Linux user that either Windows or MacOs is
>a more modern system is laughable, at best (and BeOS is sneaking up on
>us Linux users).
NT is unquestionably more "elegant" and (from an architectural
viewpoint) modern than Linux, being one of the few radically new
operating systems designed from the "ground up" in the late '80s. Why
use Windows 95 when the hugely better Windows NT is available?
Patrick Kellum
In article <qwNjwSAx...@chrism.demon.co.uk>, Chris Marriott was talking about:
>NT is unquestionably more "elegant" and (from an architectural
>viewpoint) modern than Linux, being one of the few radically new
>operating systems designed from the "ground up" in the late '80s. Why
>use Windows 95 when the hugely better Windows NT is available?
Why use NT when BeOS is available?
Patrick
---
A Title For This Page -- http://www.syix.com/patrick/
Bow Wow Wow Fan Page -- http://www.syix.com/patrick/bowwowwow/
The Small Wonder Page -- http://smallwonder.simplenet.com/
Jeff Hatch
Stephen Robert Norris wrote:
> If this isn't a troll, you're an idiot. If it is, you're an idiot.
>
> I buy a lot of hardware for clients that doesn't run Windows or MacOS.
>
> All my clients write or purchase commercial software. I run Linux;
> I use a word processor and a spreadsheet etc. that is commercial.
Reading all the responses to my post makes it obvious that I was quite
ignorant about software sales, but that doesn't mean I'm an idiot.
Anyone who knows me would scoff at your use of the term. But it stings,
even coming from an ignorant stranger.
Um, speaking of ignorance, what's a "troll" in this context?
-Rúmil
Jeff Hatch
I wrote:
> If Inform and the Z-machine weren't portable...
[snip]
Wait a minute! What am I talking about? Inform has been ported to many
platforms, but it's not necessarily more "portable" than most other
systems, if you define "portable" to mean that it's easy to write a copy
of Inform for a system that doesn't have it. Graham Nelson went through
so much work in porting Inform to other platforms that whenever "C" and
"portability" are mentioned in the same sentence, he "falls off his
chair laughing."
The Z-machine isn't really "portable" either, except in the sense that
it has very light system requirements. AFAIK the major difference
between the Z-machine and the TADS-machine is simply that the Z-machine
has been ported more, not that it's easier to port the TADS-machine.
Of course, games _written for_ the Z-machine are inherently more
portable, by this definition. But the main difference isn't that Inform
or the Z-machine is designed to be ported easily; the main difference is
simply that the Z-machine got ported to a lot of computers back in the
Infocom era, and targeting the Z-machine simply saves a would-be
authoring system creator the hassle of porting a new machine.
A C library could be almost as portable, if there were a sufficiently
uniform standard of C that was widely available. There isn't, of
course, but I expect the difficulties involved in porting a C library
would be no more than the difficulties involved in porting Inform. The
main difference is that use of a C library would require games to be
recompiled for each platform, which would be a nuisance.
-Rúmil
Dancer
Using a variation of self-replicating programs, you _could_ have a C/C++
setup in which you wrote your code that compiled to a native program
that output some kind of portable binary (java or Z-machine).
It's a double-step process though, but I see no barriers other than that
the initial implementation of the system to do so would be a horror.
D
In article <6e6ovp$cn$1...@wnnews1.netlink.net.nz>,
stephen....@moc.govt.typo.nz (Stephen Griffiths) wrote:
>All the talk in this thread about using an IF library with c or c++
>has raised a question in my mind that I haven't seen clearly answered
>yet.
>
>The various IF systems have two advantages over general purpose
>languages
> - its easier to program IF in an IF system
> - the IF systems produce a binary game file or files that can be
>played on any operating system with a runtime interpreter program
>compiled for that o.s.
>
>My question is, could an add-in library allow a c or c++ compiler
>output a binary gamefile that was playable with an appropriate runtime
>interpreter on a variety of o.s.'s
>
>I'll hazard a guess in answer to my own question .... I thought that a
>c or c++ compiler would only output an o.s. specific executable file.
>
>So no matter how easy an add-in library made the authoring of IF, the
>c or c++ compiler's disadvantage - that an author would have to
>compile a specific executable for each o.s. using a specific compiler
>for that o.s. - would remain.
>
>As each potential IF author does not have access to a multitude of
>o.s.'s or a bevy of friendly and always-obliging 'porters' my second
>reason for IF systems existence remains valid unless, as some-one said
>in this thread, portability is not a priority.
>
>Anyway, I'm interested (out of academic curiosity really) whether a c
>or c++ compiler could theoretically output a portable gamefile. Thanks
>for any answers!
>
>
--
before [; Thinking: <post message>; ];
J. Holder
Thus spake Jeff Hatch <je...@hatch.net>:
: Um, speaking of ignorance, what's a "troll" in this context?
One of the definitions of "troll"(v) is used in fishing, as in
"to troll a lure through the water." Trolling is done with a
"troll" (n), which is a lure or a line with its lure and hook,
used (of course) in trolling.
Basically, he was saying "If this isn't bait on your hook for
people to respond to, then you're an idiot."
Not that _I_ think that. I'm just explaining...
Onwards,
John
--
John Holder (jho...@frii.com) http://www.frii.com/~jholder/
Sr. Programmer Analyst, J.D.Edwards World Source Company, Denver, CO
http://www.jdedwards.com/
J. Holder
Thus spake Chris Marriott <ch...@chrism.demon.co.uk>:
: In article <1bn2ewe...@cs.nmsu.edu>, Joe Pfeiffer
: <pfei...@cs.nmsu.edu> writes
: >Ummmm.... suggesting to a Linux user that either Windows or MacOs is
: >a more modern system is laughable, at best (and BeOS is sneaking up on
: >us Linux users).
: NT is unquestionably more "elegant" and (from an architectural
: viewpoint) modern than Linux, being one of the few radically new
: operating systems designed from the "ground up" in the late '80s. Why
: use Windows 95 when the hugely better Windows NT is available?
While I agree that WinNT is superior to Win95, and that WinNT is designed
from the ground up, I question the "unquestionably more elegant from an
architectural viewpoint."
In UNIX, I can start up and shutdown services at will, INCLUDING network
interface cards, without rebooting. The thing that still irritates me
beyond belief is that I have to reboot so dang often when installing
new toys, for no apparant reason under NT. Under UNIX, I rarely if ever am
forced to reboot. (Okay, under Linux, when installing a sound card, life
can be tough, and require a reboot. This is the one thing I have found
that causes a reboot).
Under UNIX, my servers don't have to waste cycles and memory running a GUI
to offer network services.
Under UNIX, my Graphics GDI isn't buried in the kernel, and can't crash
or lock up my machine when my video driver has problems.
Don't get me wrong - I have an NT workstation (4.0, sp3, 128MB ram 20"
trinitron, 5GB disk) here on my desk. But I also have a Linux box (same
configuration) that I vastly prefer, and an Xterm to my HP that I use
far more as well.
I am curious, what do _you_ find vastly superior about NT?
Personally, I find it clumsy and irritating to perform most admin tasks.
One concession I will make is that I do like the design of the NTFS
filesystem.
Alan Shutko
>>>>> "C" == Chris Marriott <ch...@chrism.demon.co.uk> writes:
C> NT is unquestionably more "elegant" and (from an architectural
C> viewpoint) modern than Linux, being one of the few radically new
C> operating systems designed from the "ground up" in the late
C> '80s.
This post really belongs in an advocacy group.
Suffice it to say that many argue that Unix is more elegant than NT,
that NT has many architectural aspects of both Unix and VMS in it, but
has a number of problems with various subsystems, etc.
--
Alan Shutko <a...@acm.org> - By consent of the corrupted
If you have to ask how much it is, you can't afford it.
Chris Marriott
In article <6e8t49$3ug$1...@europa.frii.com>, J. Holder
<jho...@io.frii.com> writes
>One of the definitions of "troll"(v) is used in fishing, as in
>"to troll a lure through the water." Trolling is done with a
>"troll" (n), which is a lure or a line with its lure and hook,
>used (of course) in trolling.
I've always thought that trolls lived under bridges and had a bone
fixation :-).