Limitations of Inform and TADS?
Gareth Rees
> I need some info from you Inform and TADS experts. My questions are
> how flexible are these systems? What are their limitations? What can
> an IF game in C do that can't be done with these systems? Will the use
> of these systems cause a possible stagnation in the IF game field due
> to their possible limitations?
See Bob Newell's comparison paper:
ftp://ftp.gmd.de/if-archive/info/TADS-vs-Inform.FAQ
The main limitations, as I understand them, are these:
Inform: no dynamic memory allocation
no dynamic creation of objects
object files limited to 512k
no graphics
TADS: programming the parser is difficult
some memory restrictions because it needs to run on PCs
no graphics
However, neither system is stagnant and both are being developed;
there's a beta version of TADS/graphic at the IF archive; recent
extensions to the design of the Z-machine have enabled Inform games to
double in size, and I think that there are people working on
interpreters for version 6 of the Z-machine, which would allow Inform to
produce graphical games.
--
Gareth Rees
Alfredo Liu-Perez
how flexible are these systems? What are their limitations? What can
an IF game in C do that can't be done with these systems? Will the use
of these systems cause a possible stagnation in the IF game field due to
their possible limitations?
Thanks in advance for your reply.
Alfredo
Allison Weaver
> I need some info from you Inform and TADS experts. My questions are
> how flexible are these systems? What are their limitations? What can
> an IF game in C do that can't be done with these systems? Will the use
> of these systems cause a possible stagnation in the IF game field due to
> their possible limitations?
Writing a game in C *could* make your game more portable than some of the
existing authoring systems -- if you released the source code and if all
all interested players owned C compilers.
It seems to me that any stagnation in the field would be caused by a lack
of imagination on the part of the game authors rather than limitations in
the compilers or interpreters. After the recent competition and recent
releases of several brand new larger scale games, it doesn't seem like
stagnation is currently a problem from the side of the authors.
Stagnation might also be caused by a lack of interest on the part of game
players. After all, how long is an author going to be productive and
creative without an audience? Have you noticed the activity on rgif since
Jigsaw was released? It was the same after the releases of Theatre,
Christminster, the competition entries, and others that I can't call to
mind immediately (I apologize to those authors). This doesn't seem to be
a stagnant audience (small, but not stagnant).
Why does stagnation concern you? And why do you feel that this would be
caused by the compilers?
Anthony Spataro
: IF games will someday will be more popular than books, but that day is
: still far into the future. What we need is having better interation with
: NPCs. The day we can't tell the difference between communicating with an
: NPC or communicating with someone over irc, is the day IF becomes more
: popular than books. I'd love to interact with my favorite book characters.
:
: >Why does stagnation concern you? And why do you feel that this would be
: >caused by the compilers?
:
: I don't know what TADS or Inform do, but from previous messages it seems
: they are almost programming languages themselves. If that's the case, it
: would be possible to give more intelligence to NPCs, and give them a way of
: representing knowledge of what goes on around them. At the time, NPCs give
: the impression of intelligence, but they don't seem to remember what has
: being said, don't react normally, and don't seem to change the plot.
: My feeling was that maybe the programs used to write these games had
: limitations that prevented such features in NPCs. Maybe it is lack of
: motivation, or the exponential growth in memory needed that keeps these
: NPC features from becoming a reality.
TADS and Inform are really languages in their own right; it's just that
they are specialized for IF (i.e. they provide a built-in parser).
IF is fun, I agree. But a few simple additions make it an order of
magnitude more entertaining. Take Gateway ][: Homeworld. You add music,
still pictures and a couple graphical interface widgets, and you've got
IF that actually sells!
I've been doing work on NPC interaction. So far, I've gotten a system
working where the player determines the flow of conversation by choosing
from a list of possible responses. Actually providing AI-style
facilities for NPC interaction would take a lot more work, and might not
even be as rewarding. If Bob is playing IF set in Colonial America and
he gets a choice of responses worded in the dialect of the period, it's
going to make him feel a lot more in-character than if he's allowed to
type "Yo, dude!"
--
_/\_ apathy: received SIGH, exiting. Why even bother to dump core?
/ L \ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
\_ C_/ Assertiveness is strength. Strength is power. Power is authority.
\/ Authority is asinine.
It seems like the less a statesman amounts to, the more he loves the
flag.
John Baker
writes:
Overrun an array boundary, clobber memory and cause a bug that doesn't
have anything to do with the code near it? :)
--
John Baker
"What the hell does that mean? Huh? 'China is here.'?
I don't even know what the hell that means!"
- Jack Burton
Gareth Rees
> Apart from the contributors to the IF newsgroups, I am the only other
> person that likes them.
Many more people play adventure games than have Usenet access or post to
rec.{arts,games}.int-fiction. At least if the e-mail I get about
"Christminster" is any guide.
> I don't know what TADS or Inform do, but from previous messages it seems
> they are almost programming languages themselves.
They *are* programming languages.
> My feeling was that maybe the programs used to write these games had
> limitations that prevented such features in NPCs. Maybe it is lack of
> motivation, or the exponential growth in memory needed that keeps these
> NPC features from becoming a reality.
The reason why NPCs are no good is not for any one these reasons, but
because representing good NPCs involves a combination of features, all
of which are at or beyond the cutting edge of AI research: common-sense
reasoning, sophisticated knowledge representation, belief representation
(for example, how do I establish and represent the fact that I know that
he knows, and he knows that I know, and I know that he knows that I
know? - the usual methods of encoding beliefs as propositions don't
extend gracefully to this kind of thing), adaptive planning based on
imperfect knowledge and possible frame-breaking (the "dead body in the
pub" problem), etc etc.
There is a lot of research in these areas (see the Oz project
<http://www.cs.cmu.edu/afs/cs.cmu.edu/project/oz/web/papers.html> for
research into representing goals and limited kinds of behaviour, and
Julia and other chatterbots <http://fuzine.mt.cs.cmu.edu/mlm/julia.html>
for some efforts to produce believable conversation on a limited
subject), but I don't think it's at a stage where it can easily feed
into adventure games.
If I'm wrong, then please let me know! I'd love to know how to write
improved characters (I have some ideas based on combining lots of
well-known AI techniques in an ad-hoc way, but they're very difficult to
implement).
--
Gareth Rees
Jacob Solomon Weinstein
>However, there seems to be an awful lot of resistance to making IF systems
>that assume faster machines for the sake of providing "higher level"
>language/system features. People seem wed to the idea that IF games ought
>to run on Timex-Sinclairs, Atari 800's, 8086 PC's, and other ancient
>machines.
What have you seen that makes you believe this? I've seen two major
discussions with regard to higher level langauge and features:
1) Complaints about the speed of world.t, as seen in the Legend Lives.
2) Debates about what systems should be allowed in the IF contest.
I don't think anybody has said "I'm philosphically opposd to an IF system
that needs a faster machine." Instead, people have mainly expressed an
attitude of, "I want a system that will run on my machine." There's a big
difference between the two.
(I'll also note that I don't mind dealing with a program that runs slowly
on my machine if I can see that it's a really cutting edge program. As
innovative as Legend was in some ways, I didn't see any features that
were worth the three-second wait I had between moves. The innovations
that I saw in it were things that didn't require any extra processor
time--the large blocks of text, etc.)
-Jacob
Carl D. Cravens
>The main limitations, as I understand them, are these:
>
>
> TADS: no graphics
Some of us consider "no graphics" to be a benefit, not a limitation. ;)
Graphics greatly change the nature of "text adventures" in a way that I
don't care for. Without even thinking about it, I mentally construct
pictures of locations in a text adventure... I find that when graphics
are added, I stop doing this. (I didn't even realize I did it until a
couple weeks ago... that I think way back to Zork (over ten years ago)
and realize that I don't remember the description of the white house,
but I "remember" what it "looks" like. I could probably draw you
pictures of the main parts of Theatre.)
To me, graphics aren't something that'd be nice, but are unnecessary...
graphics can ruin the game for me because they completely change the
flavor.
--
Carl (rave...@southwind.net)
* You are in a maze of twisty messages, all alike.
David Baggett
Jacob Solomon Weinstein <jwei...@phakt.usc.edu> wrote:
>What have you seen that makes you believe this?
Well, we seem to have a mini flamewar every few months about the fact that
TADS doesn't run on as many systems as Inform, and these are mainly
obsolescent systems people are complaining about.
I bet there is almost *no one* with net access who can't also get access to
a reasonably modern machine --- this *is* philosophical.
>Instead, people have mainly expressed an attitude of, "I want a system that
>will run on my machine." There's a big difference between the two.
Not when "my machine" is "An Amiga, though I have a PC but refuse to use it
for IF because I don't like DOS," or "my Atari 800, though I have a PC, but
IF *should* run on my 800, so if yours doesn't, I won't play it." I
certainly don't need to give people more reasons to not play my games, but
this is ridiculous!
>As innovative as Legend was in some ways, I didn't see any features that
>were worth the three-second wait I had between moves. The innovations that
>I saw in it were things that didn't require any extra processor time--the
>large blocks of text, etc.)
This comment exactly illustrates the attitude I'm talking about. You don't
feel you should need to use a faster machine to run games that only do
"standard adventure game" sorts of things, even if it means that IF authors
have to use low-paradigmicity languages to provide you with said games.
WorldClass *does* provide some whizzy features, though _Legend_ doesn't
much use them. However, WorldClass also makes an IF author's life easier,
which means that games can be written more quickly, and be delivered with
fewer bugs.
Going to a better langauge, like Scheme, would further improve things, but
probably at an even greater performance cost.
Dave Baggett
__
d...@ai.mit.edu
"Mr. Price: Please don't try to make things nice! The wrong notes are *right*."
--- Charles Ives (note to copyist on the autograph score of The Fourth of July)
Gareth Rees
> Most of the features people occasionally ask for in their game
> languages, such as a better parser, dynamic object allocation, and the
> like, are ill-conceived.
Different people mean different things by "better parser" and "dynamic
object allocation".
I find Inform's ability to parse portions of input in arbitrary ways
extremely useful. In preparation for a release 3, I've recently
completely rewritten the way "Christminster" deals with talking to
characters so as to search for keywords within the player's input. I'm
planning to extend the speech-parsing mechanism to do Eliza-like pattern
matching ("Christminster" won't make use of it, but my next game might).
By "dynamic object allocation" I really just mean "dynamic allocation"
in general; there are lots of algorithms that are expressed most
naturally using linked lists or dynamic arrays and it occasionally hurts
not to be able to express these in Inform.
> More interesting examples could come from production rule languages. If a
> dam releases water when 1) there is water behind it and 2) it is open, we
> would currently implement this by putting sentinels on water-extracting
> code and on the dam-opening code
If I were programming this, I'd write a daemon that monitored the state
of the water and the dam every turn; in Inform it would look something
like
Object Dam
with ...,
daemon [;
if (self.water_level > 5 && FloodGates has open)
! release the water
];
--
Gareth Rees
Matt Kimmel
>What have you seen that makes you believe this? I've seen two major
>discussions with regard to higher level langauge and features:
>
>1) Complaints about the speed of world.t, as seen in the Legend Lives.
This brings up a question that I've been meaning to ask for some time. Just
how slow is WorldClass? I am about to write a fairly large adventure and have
had a hard time deciding whether to do it in TADS/WorldClass or in Inform. Speed
is definitely a criterion. Is the three seconds between moves that you mention a
typical speed for a game that uses WorldClass? And, what kind of machine are you
using when you get that kind of speed?
-Matt
--
Matt Kimmel Network Specialist
OIT/Network Systems and Services, LGRC A145 Phone: (413) 545-1605
University of Massachusetts Fax: (413) 545-3203
Amherst, MA 01003 E-mail: kim...@nic.umass.edu
Michael S. Phillips
I have been working on an adaptive hints drop-in library for Inform, and
I have been tinkering with daemons and the like. On my piddly 386SX20,
the above solution (with the amount that the hints module has to do to
check game status) is significantly slower than, say:
! Note that this is declared as part of the player, but concealed,
! so the each_turn *is* done each turn.
Object Dam_Checker selfobj
with concealed...
each_turn [;
if (Dam.water_level > 5) && FloodGates has open)
! release the water
];
Like the daemon, this has the advantage of holding all the code within a
single object (with the exception of the one variable), and it *seems*
to run faster when dealing with large numbers of daemons.
Of course, I could be dreaming :-)
*Is* this solution faster than such a daemon?
Mike Phillips, msp...@aardvark.cc.wm.edu
David Baggett
>I also don't understand your comment about philosophy in this context.
>(Geez, I sound like a parser there.) What precisely is 'philosophical'
>about not owning, and not being able to afford to own, an IBM?
There's nothing philosophical about not owning, or being able to afford
anything. Perhaps philosophical was not the best word to use. What I'm
talking about is this pervasive sentiment:
>Everywhere I look today, I see video games loaded with six CDs of graphics
>and sound that won't play properly on anything less than a 66 MHz 486 with
>eight megs of memory, an SVGA card, and Windows.
>[...]
>This is to be expected from programs that want to push the limits of what
>is possible with graphics and sound [...]
>
>You must remember, however, that we are talking about text adventures.
The sentiment is that since these are "just text adventures", you should be
able to run them on an obsolete machine. That I, the "mere text adventure
author," should use low-level tools to write my games, even if it takes 10
times as long as a result, so you'll be able to run them. That graphics
and sound games "deserve" more resources, but all-text games don't.
This is a judgment based on preconceived notions about what all-text games
are, and, quite frankly, limits what they can be. Not because I can't
write fancy NPC code with Inform or TADS, necessarily, but maybe just
because it's a royal pain to fool around and experiment with new ideas in
languages like these. Higher level languages (and this is really a poor
term -- what I really mean is "higher abstraction languages") encourage
experimentation with more difficult algorithms. One is more likely to try
something if it takes 10 minutes than if it takes 2 days. And I do believe
that for a large class of problems --- particularly symbol-manipulation
problems that are very relevant to IF --- interpreted functional languages
like Scheme make that kind of development time difference. But at a
performance cost, and such that I doubt a virtual machine implementation of
a system like Carl described earlier, or even just a somehwat improved
TADS-like language written on top of a virtual machine Scheme would be fast
enough to support typical adventure games on a 286. (You could use a
Scheme to C compiler, of course, but only at the expense of portability.)
>Therefore, you want to do as much as you can to let everyone possible play
>your game, because the audience is so small to begin with.
Tell me: what do I gain by reaching a larger audience? I'm curious what
you think the big payoff is for writing IF --- for any machine.
I write IF mainly for fun. It's an interesting thing to do. It's a
creative outlet. It's a good way to get fiction writing experience. It
can generate useful feedback. But only people who are really interested in
IF as a medium provide such feedback. The tens of thousands (if that) who
just download the games every once in a while to waste some time don't ever
send *me* mail, at least.
And don't even get me started on the commercial potential of all-text IF.
Dave Leary and I have explored this, and have determined that there
basically isn't any.
>(I wouldn't expect my old Commie 128, or a TRS-80, to load up
>"Curses", but my Amiga happily multitasks it with my terminal program
>and a few shell windows...) They simply don't need huge whopping
>computer resources.
I don't see why you feel that a TRS-80 is too old to be supported while an
Amiga and 286 aren't.
>Use all the programming tools you want. (Though perhaps an optimizing
>compiler might not be a bad thing to have handy, that applies to language
>writers, not game writers.)
Optimization is really not the issue. It's that all these systems run on
emulated virtual machines, for the sake of portability. There are good
virtual machine implementations of Scheme out there (Scheme48 & VSCM), and
I'd be willing to bet that games written in languages built on top of them
would be slower than Curses on your 286, if you could get either to run
under crappy real mode DOS at all. So does that mean I shouldn't write
text adventures in Scheme, since you can't run them on your 286?
>However, as best I can interpret what you've just said, you're saying that
>it's my own fault I can't play 'Legend' because I can't afford to buy a
>'decent' PC.
First of all, you can probably get a used 386 motherboard for about $25 at
a flea market or hardware swap fest. Though I haven't checked mail order
prices recently, I bet that by now a 486 motherboard would be less than
what you paid for net access this year.
Second, you choose to spend your money on certain things and not on others.
Most IF "fans" who spend $10 on a pizza without a second thought won't
spend the same to register UU1, Save Princeton, or two dozen other good
shareware games. This is a choice, not a necessity.
Should I *really* be overly concerned about supporting the fair-weather
friends --- the ones who will play my stuff as long as it costs them
nothing and doesn't require them to go to any trouble? Been there, done
that. I wrote *Atari* software for 5 years.
>That's just... arrogant.
There's no reason that these kinds of discussions need to get personal. My
opinion is just that... an opinion. But I will say this: I may draw the
mandatory upgrade line much higher than you do, but you draw a line too.
Is that unfair to TRS-80 users? Is it arrogant, since you are in the
privileged class --- those who have mid 80's personal computers instead of
late 70's era ones?
I think drawing the line so far down the obsolescence hierarchy is not good
for IF, and it certainly makes my life much harder. Maybe it wouldn't take
two years to write a game like Curses or Legend if we could use
higher-abstraction languages instead of C derivatives.
David Baggett
Gareth Rees <gd...@cl.cam.ac.uk> wrote:
>If I were programming this, I'd write a daemon that monitored the state
>of the water and the dam every turn; in Inform it would look something
>like
>
> Object Dam
> with ...,
> daemon [;
> if (self.water_level > 5 && FloodGates has open)
> ! release the water
> ];
But what would happen if you defined a thousand such constrints using
daemons? Carl's point isn't that the simple example he gave is too hard to
implement in TADS, Inform, or C. It's that a general system that could
efficiently manage dozens of constraints per object would be more
expressive.
I'd agree with him, but I'm not sure how to deal with conflicting
constraints. How do you specify which constraints are checked first? Or
do you impose the rule that no constraint can depend on the result of
another constraint's satisfaction this turn? Offhand, it seems like it
offers programmers the same ability to tangle themselves in knots that a
direct object-oriented approach does. (Though I admit I probably haven't
thought about it enough to have an informed opinion. :)
Alfredo Liu-Perez
>...
>If I'm wrong, then please let me know! I'd love to know how to write
>improved characters (I have some ideas based on combining lots of
>well-known AI techniques in an ad-hoc way, but they're very difficult to
>implement).
I agree with you that creating NPCs that would interact with players the
same way a human player would interact is not possible right now. But, I
think it should be possible to have better NPCs than most current ones.
Usually talking to an NPC is very frustrating because of the player's
limited vocabulary and syntax (verb noun), and NPC's replies break the
illusion of one being in the game.
Someone mentioned writing an Eliza-type NPC. That sounds like a good idea.
I didn't like the idea of a menu with choice questions because it makes
the game look too artificial and once a player sees the menu he/she will
try all possible questions in order in fear something important might be
lost if it isn't asked or done. A more text-adventure way of implementing
a menu of items is by mapping several similar sentences to lists of
similar responses without repeating the responses. Once a list has been
exahausted, another list saying "I've already told you." and similar
responses can be used.
I'm glad to know that the field is still alive and that Inform and TADS
are more powerful than I thought. I'm terribly sleepy at the moment and
tend to get very verbose (and incoherent sometimes), so I'll quit here.
Alfredo
PS. The Magic Toyshop's tic-tac-toe puzzle was very original!
Dancer
: Alfredo Liu-Perez <a...@miller.cs.uwm.edu> wrote:
: > I need some info from you Inform and TADS experts. My questions are
: > an IF game in C do that can't be done with these systems? Will the use
: > of these systems cause a possible stagnation in the IF game field due
: > to their possible limitations?
: See Bob Newell's comparison paper:
: ftp://ftp.gmd.de/if-archive/info/TADS-vs-Inform.FAQ
: The main limitations, as I understand them, are these:
: Inform: no dynamic memory allocation
: no dynamic creation of objects
Make a class (UnallocatedClass), and two routines (ObjAllac and ObjFree)
which use the instances of UnallocatedClass as a 'free list' of objects.
There are limitations, of course (you could not use one of them to represent
something that has properties that UnallocatedClass does not have) but you
could set up N objects tto use for dynamic creation. Then all you need is a
set of constructors to assign the appropriate property-values to the object.
ObjFree will (of course) return the properties to a default, and mark it as
a member of the free list again.
D
Michael S. Phillips
|> msp...@aardvark.cc.wm.edu (Michael S. Phillips) writes:
|> > In article <GDR11.95N...@stint.cl.cam.ac.uk>, gd...@cl.cam.ac.uk (Gareth\
|> > Rees) writes:
|> > |> with ...,
|> > |> daemon [;
|> > |> if (self.water_level > 5 && FloodGates has open)
|> > |> ! release the water
|> > |> ];
|> >
|> > I have been tinkering with daemons and the like. On my piddly 386SX20,
|> > the above solution (with the amount that the hints module has to do to
|> > check game status) is significantly slower than, say:
|> >
|> > ! Note that this is declared as part of the player, but concealed,
|> > ! so the each_turn *is* done each turn.
|> > Object Dam_Checker selfobj
|> > with concealed...
|> > each_turn [;
|> > if (Dam.water_level > 5) && FloodGates has open)
|> > ! release the water
|> > ];
|> >
|> > *Is* this solution faster than such a daemon?
|>
|> Of course it is. each_turns are only executed when you're in the same
|> room (really, in scope). So if you have a bunch of your examples in
|> many different rooms, only one will be executed per turn. Whereas all
|> active daemons execute every turn.
|>
|> The question, of course, is whether it's acceptable for the water to
|> only release when you're in the dam room.
Note that the Dam_Checker is a concealed part of the player object
(selfobj), which means the each_turn *is* run each turn. However,
it still *seems* to run faster. I haven't yet done an absolute
comparison between a daemon running it and an each_turn running it,
but it sure seems to run faster and run each turn.
Sorry if I didn't make that clear.
Mike Phillips, msp...@aardvark.cc.wm.edu
Chris Thomas
> In article <47bjo8$l...@phakt.usc.edu>,
> Jacob Solomon Weinstein <jwei...@phakt.usc.edu> wrote:
>
> >What have you seen that makes you believe this?
>
> Well, we seem to have a mini flamewar every few months about the fact that
> TADS doesn't run on as many systems as Inform, and these are mainly
> obsolescent systems people are complaining about.
In that case, let me complain about something entirely different.
I'm running a PowerMac 7100/80. The TADS interpreter for Macintosh
really sucks. It's slow as hell, it doesn't use styles or colors,
it's just not very nice. The ZIP intepreter for Macs used to suck
in much the same way. Then, because the ZIP machine is a publicly
available standard, others wrote improved versions. We now have
a Truly Excellent ZIP intepreter for Macintosh in MaxZip. Going
from MaxZip to the TADS interpreter makes me very sad, and I now
avoid TADS games because of this! It's the difference between
ablack and white 6" TV and a 27" color TV with surround sound, it
really is.
[person doesnt want to run on a faster machine]
> >As innovative as Legend was in some ways, I didn't see any features that
> >were worth the three-second wait I had between moves. The innovations that
> >I saw in it were things that didn't require any extra processor time--the
> >large blocks of text, etc.)
>
> This comment exactly illustrates the attitude I'm talking about. You don't
> feel you should need to use a faster machine to run games that only do
> "standard adventure game" sorts of things, even if it means that IF authors
> have to use low-paradigmicity languages to provide you with said games.
The wait on a PowerMac is often a second or more.. I don't think
the machine makes a huge difference, honestly.
[WorldClass, scheme omitted]
--
Chris Thomas, c...@best.com
Carl D. Cravens
> It is hard for me to understand why IF games are so unpopular with the
>general audience. But I remember them always bein unpopular among my
>friends. Apart from the contributors to the IF newsgroups, I am the only
>other person that likes them.
Because of several odd factors... one being that IF games cause you to
_THINK_. You have to get out a paper and pen and map things out, take
notes, use your imagination, make twisted logical connections, etc. In
many graphical games, the computer does the mapping for you, takes
the place of your imagination, and don't have the same style of puzzles
because the interface won't allow it. Any many of today's computer
users have never learned how to type. And their grammar and spelling
suck. Imagine trying to play IF when you can't type or spell. And it
only seems natural that this generation of a race of visually-oriented
creatures raised on television would turn to visually-oriented games.
The point-n-click interface was created for those who either aren't
smart enough or don't have the patience to deal with a command line...
and it's the same between IF and more modern graphical games. The
graphical stuff is a logical extension of IF, but it fundamentally
changes the nature of IF as well.
> IF games will someday will be more popular than books, but that day is
>still far into the future.
When you say IF, are you talking text-only IF (as you seem to be in your
earlier paragraph where you say you know no one who enjoys it) or do you
include graphical IF. I disagree that text-based IF will be more
popular than books... text-IF has been in steady decline for years and
even I will read more novels in a year than IF games. The graphical
interactive "movie" might be different, but I believe that our society
is real big on passive entertainment and that, in general, anything that
requires thinking as a primary part of the entertainment just won't cut
it. There are times that all of us want to sit back and watch a movie
without having to make decisions. (One must admit that IF isn't always
a relaxing pastime. :)
> I don't know what TADS or Inform do, but from previous messages it seems
>they are almost programming languages themselves. If that's the case, it
They aren't "almost"... they _are_ programming languages.
> My feeling was that maybe the programs used to write these games had
>limitations that prevented such features in NPCs. Maybe it is lack of
>motivation, or the exponential growth in memory needed that keeps these
>NPC features from becoming a reality.
The problem isn't so much memory or the languages... it's that
artificial intelligence research isn't far enough along to provide
intelligent conversation on any scale. And even if the cutting-edge
stuff could produce the kind of characters we all want, it wouldn't run
on a desktop box.
--
Carl (rave...@southwind.net)
* Talk is cheap because supply inevitably exceeds demand.
Andrew C. Plotkin
> On 2 Nov 1995 04:19:43 GMT, a...@miller.cs.uwm.edu (Alfredo Liu-Perez) wrote:
> > It is hard for me to understand why IF games are so unpopular with the
> >general audience. But I remember them always bein unpopular among my
> >friends. Apart from the contributors to the IF newsgroups, I am the only
> >other person that likes them.
>
> Because of several odd factors... one being that IF games cause you to
> _THINK_. You have to get out a paper and pen and map things out, take
> notes, use your imagination, make twisted logical connections, etc. In
> many graphical games, the computer does the mapping for you, takes
> the place of your imagination, and don't have the same style of puzzles
> because the interface won't allow it.
I disagree. There *are* graphical adventures that make you think as
much as the average text adventure. (I won't say the *best* text
adventures.) Myst and Buried in Time have been large commercial
successes, and they have the very familiar styles of puzzles we've
seen since Colossal Caves. (And they don't do mapping for you.)
> Any many of today's computer
> users have never learned how to type. And their grammar and spelling
> suck. Imagine trying to play IF when you can't type or spell. And it
> only seems natural that this generation of a race of visually-oriented
> creatures raised on television would turn to visually-oriented games.
This is a separate point, and I absolutely agree with it. The
industrialized world spends far more time in front of TV than buried
in a book, and their game preferences are similar.
Mind you, people were the same twenty years ago. The blossoming of
graphical games comes from the expansion of the computer market beyond
technophiles, crossed with the increased graphical capability of
machines.
> The point-n-click interface was created for those who either aren't
> smart enough or don't have the patience to deal with a command line...
Now I disagree again. (As a Mac user and programmer.)
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
Gareth Rees
> Make a class (UnallocatedClass), and two routines (ObjAllac and
> ObjFree) which use the instances of UnallocatedClass as a 'free list'
> of objects.
That's static allocation, not dynamic allocation.
--
Gareth Rees
Gareth Rees
> I haven't yet done an absolute comparison between a daemon running it
> and an each_turn running it, but it sure seems to run faster and run
> each turn.
Based on what little I know about their implementation, I don't believe
that there could be any noticeable difference between running a daemon
and running an `each_turn' routine. But I could be persuaded by some
figures on this (it should be easy to produce an instrumented
interpreter).
--
Gareth Rees
David Leary
>In article <DHHGD...@eskimo.com>, Fred Sloniker <laz...@eskimo.com> wrote:
>>Everywhere I look today, I see video games loaded with six CDs of graphics
>>and sound that won't play properly on anything less than a 66 MHz 486 with
>>eight megs of memory, an SVGA card, and Windows.
>>[...]
>>This is to be expected from programs that want to push the limits of what
>>is possible with graphics and sound [...]
>>
>>You must remember, however, that we are talking about text adventures.
>
>The sentiment is that since these are "just text adventures", you should be
>able to run them on an obsolete machine. That I, the "mere text adventure
>author," should use low-level tools to write my games, even if it takes 10
>times as long as a result, so you'll be able to run them. That graphics
>and sound games "deserve" more resources, but all-text games don't.
I don't think that was Fred's point, but I'll let him respond on this
one...in the game industry in general, though, a lot of programmers are
getting sloppy. The original Doom will run (albeit slowly) on a low-end
386 - that's NEAT. (And Princess Maker 2 will run on a 286, which you'd
think would be a selling point, but these days...).
Surely you'd agree that it's possible to optimize TADS (even with the
stuff you've done) to make Legend run on a 286 - if you had an extra year
to spare. :)
<Much clipped about virtual adventure systems, etc.>
Fred continues:
>>Therefore, you want to do as much as you can to let everyone possible play
>>your game, because the audience is so small to begin with.
>
>Tell me: what do I gain by reaching a larger audience? I'm curious what
>you think the big payoff is for writing IF --- for any machine.
I'd say the legions of slathering female groupies. :)
>I write IF mainly for fun. It's an interesting thing to do. It's a
>creative outlet. It's a good way to get fiction writing experience. It
>can generate useful feedback. But only people who are really interested in
>IF as a medium provide such feedback. The tens of thousands (if that) who
>just download the games every once in a while to waste some time don't ever
>send *me* mail, at least.
Ahah! Here we see glimpses into Dave's "the artist is divorced from his
audience" mentality - aka "the audience doesn't really matter." While
it's true he gives a nod to "feedback" he clearly feels how the audience
reacts to his work is more or less meaningless...
Stop me if I'm wrong.
>And don't even get me started on the commercial potential of all-text IF.
>Dave Leary and I have explored this, and have determined that there
>basically isn't any.
More or less true. Trying Tim's idea might have been interesting...and
keep in mind that at their core, big popular multi-media (spit) titles
owe a lot to Infocom, et.al.
Fred continues, as the voice of reason:
>>(I wouldn't expect my old Commie 128, or a TRS-80, to load up
>>"Curses", but my Amiga happily multitasks it with my terminal program
>>and a few shell windows...) They simply don't need huge whopping
>>computer resources.
And Dave, completely missing the point, responds:
>I don't see why you feel that a TRS-80 is too old to be supported while an
>Amiga and 286 aren't.
Leaving aside the obvious comment that the TRS-80 predates the Amiga and
the 286 by a few years, the fact is that a text adventure - in ANY
incarnation - should not need to draw on as many CPU-intensive processes
as a real-time, graphics-intensive game of ANY sort. If it does,
something's amiss.
>Optimization is really not the issue. It's that all these systems run on
>emulated virtual machines, for the sake of portability. There are good
>virtual machine implementations of Scheme out there (Scheme48 & VSCM), and
>I'd be willing to bet that games written in languages built on top of them
>would be slower than Curses on your 286, if you could get either to run
>under crappy real mode DOS at all. So does that mean I shouldn't write
>text adventures in Scheme, since you can't run them on your 286?
Portability is an interesting issue, and probably your most valid point.
You're clearly bound by the limits of whatever language you're using to
write your games. If Scheme adventures won't work on a 286, well, yer
outta luck.
Fred continues:
>>However, as best I can interpret what you've just said, you're saying that
>>it's my own fault I can't play 'Legend' because I can't afford to buy a
>>'decent' PC.
>
>First of all, you can probably get a used 386 motherboard for about $25 at
>a flea market or hardware swap fest. Though I haven't checked mail order
>prices recently, I bet that by now a 486 motherboard would be less than
>what you paid for net access this year.
Ah, the attitude which makes the industry what it is today! Change "486"
to "Pentium" in the above paragraph, and Dave could work at Origin!
>Second, you choose to spend your money on certain things and not on others.
>Most IF "fans" who spend $10 on a pizza without a second thought won't
>spend the same to register UU1, Save Princeton, or two dozen other good
>shareware games. This is a choice, not a necessity.
I've recently come to conclude net access is a necessity. It's certainly
helping me look for a job, for instance. I think we're moving more and
more toward a society of two classes, the computer literate and everyone
else...but that's another thread.
>Should I *really* be overly concerned about supporting the fair-weather
>friends --- the ones who will play my stuff as long as it costs them
>nothing and doesn't require them to go to any trouble? Been there, done
>that. I wrote *Atari* software for 5 years.
What about the pure artistic satisfaction of your work? This doesn't
seem to fit with your stated reason for writing IF. See above.
>There's no reason that these kinds of discussions need to get personal.
Why not? S'more fun that way. ;)
>My
>opinion is just that... an opinion. But I will say this: I may draw the
>mandatory upgrade line much higher than you do, but you draw a line too.
>Is that unfair to TRS-80 users? Is it arrogant, since you are in the
>privileged class --- those who have mid 80's personal computers instead of
>late 70's era ones?
Ah, answering a question with a question. "I'm rubber, you're glue" type
o' argument. Been there, done that...
I would assert the following: games should be optimized to death, written
for the lowest possible CPU they can run on, and written efficiently.
You'll reach the biggest possible audience by doing so. If the "low-end"
machine for your game is a 486, well, them's the breaks. If it's a
TRS-80, but the game is still fun - so much the better.
>I think drawing the line so far down the obsolescence hierarchy is not good
>for IF, and it certainly makes my life much harder. Maybe it wouldn't take
>two years to write a game like Curses or Legend if we could use
>higher-abstraction languages instead of C derivatives.
Maybe. D'ya think Neb might have finished UU3 if he'd had a higher-level
language?
The big drag on my games was always story/plot issues rather than coding
issues. Once I knew where I was going, I could bang out stuff pretty
fast. And by God, that's how it should be - if the focus in IF is where
it should be.
-----
Dave Leary
(Nope, my views don't represent UMAB...good thing, huh?)
"I've been of thousand devils caught,
And thrust into that horrid place,
Where reign dismay, despair, disgrace." -- George Crabbe
Damien Neil
>Leaving aside the obvious comment that the TRS-80 predates the Amiga and
>the 286 by a few years, the fact is that a text adventure - in ANY
>incarnation - should not need to draw on as many CPU-intensive processes
>as a real-time, graphics-intensive game of ANY sort. If it does,
>something's amiss.
Justification? Rationale? If you're going to make an assertion of that
size, I want to see the reasoning behind it.
Certainly, the I/O code of a text adventure will consume less CPU power
than the I/O code of DOOM. The I/O is, however, the least important
portion of a text adventure. If text adventures were nothing but DOOM
without graphics, I'd never play one.
>I would assert the following: games should be optimized to death, written
>for the lowest possible CPU they can run on, and written efficiently.
>You'll reach the biggest possible audience by doing so. If the "low-end"
>machine for your game is a 486, well, them's the breaks. If it's a
>TRS-80, but the game is still fun - so much the better.
By this argument, all games should be written in assembly language. We
should throw both Inform and TADS out the door, as both are clearly
highly inefficient.
I own a 486/66 with 16MB of RAM. Much of the code I write and run on it
(generally unrelated to IF) would not run on my old C64. Should I be
ashamed of taking advantage of the resources at hand?
- Damien
Andrew C. Plotkin
Well, sure, but you're implementing a dynamic heap using static
memory. Isn't that exactly what all dynamic allocation is? It's not
like malloc() can send out for fresh memory chips when RAM is full...
If you don't want to using Z-machine objects as your units of
allocation, just declare a big empty array and steal some malloc() /
free() code. Now your only limit is the (I think) 64K of writable
address space in the Z-machine.
David Leary
Damien Neil <dam...@lugnut.stu.rpi.edu> wrote:
>On 5 Nov 1995 14:54:03 -0500, David Leary <dle...@trout.ab.umd.edu> wrote:
>>the 286 by a few years, the fact is that a text adventure - in ANY
>>incarnation - should not need to draw on as many CPU-intensive processes
>>as a real-time, graphics-intensive game of ANY sort. If it does,
>>something's amiss.
>
>size, I want to see the reasoning behind it.
You shrug off the I/O issues, but that's the foundation of my reasoning.
Other aspects common to both types of games don't generally hog the
machine quite so badly.
There are exceptions - I could see a sophisticated AI for an NPC being a
hog - but I stand by my general statement.
>Certainly, the I/O code of a text adventure will consume less CPU power
>than the I/O code of DOOM. The I/O is, however, the least important
>portion of a text adventure. If text adventures were nothing but DOOM
>without graphics, I'd never play one.
I agree, and my post was not a Doom vs. text adventure post. There's
nothing wrong with mindless violence, but that's not the kind of game *I*
want to write.
>>I would assert the following: games should be optimized to death, written
>>for the lowest possible CPU they can run on, and written efficiently.
>>You'll reach the biggest possible audience by doing so. If the "low-end"
>>machine for your game is a 486, well, them's the breaks. If it's a
>>TRS-80, but the game is still fun - so much the better.
>
>By this argument, all games should be written in assembly language. We
>should throw both Inform and TADS out the door, as both are clearly
>highly inefficient.
Not what I'd advocate, and if you look at the rest of my post, you'll see
that I don't. There's obviously a trade-off - ease of design/authorship
vs. speed. But a text adventure shouldn't (generally) require a 486.
>I own a 486/66 with 16MB of RAM. Much of the code I write and run on it
>(generally unrelated to IF) would not run on my old C64. Should I be
>ashamed of taking advantage of the resources at hand?
Absolutely not. My argument was about games in general, and IF in
particular. If you're doing serious number-crunching and you need a big
machine, fine. If you're writing Acme Soopur-Doohm (TM) in SVGA and you
need a 486, fine.
If you're writing a text adventure and it'll only run on a 486/66 with
16MB, I'd say something's wrong - maybe with the system you're using,
maybe with your own code, but something's wrong.
The original Unnkulia 1 was written on an Atari ST. I was more than
happy to move up to a 386 to write Unnkulia Zero - I had to, in fact,
because the ST wasn't "big" enough - but unless the technology changes
dramatically, I don't think you should ever need a Pentium to run a text
adventure.
If someone writes a game that both needs and justifies a Pentium, then
I'll be suitably impressed.
(Dave: this is NOT a flame of Legend. I've seen pieces of the code, and
I know darn well that you were pushing the limits of both TADS 2.0 and
the machines you were working on. You did what you could with what you
had, and I think if the people on the group knew everything that was
going on inside that monster of yours, they'd be a lot more forgiving of
the two-second delay between turns...)
David Baggett
Chris Thomas <c...@best.com> wrote:
>Going from MaxZip to the TADS interpreter makes me very sad, and I now
>avoid TADS games because of this!
Sounds like an excellent opportunity for you to improve it, since your
machine so acutely exhibits the problem. (For the record, I've run Legend
extensively on a Quadra 950 and a PowerMac 7200/90 and haven't found either
one to be slow.)
Sign an NDA. Get the source from Mike. Make a better version. Really:
we're all in this together; no one's making money providing you with these
tools, and I no longer have time to devote to free stuff.
Long ago, I was unsatisfied with the TADS ports, like you. I got the
source from Mike and ported TADS to Unix machines. I am not special. You
can do this too, for the Mac.
>The wait on a PowerMac is often a second or more. I don't think the
>machine makes a huge difference, honestly.
That's quite a generalization from a single data point. MacWeek has been
reporting that 7000 series PowerMaccs perform poorly (sub-Qudra speeds) on
a wide range of tasks. Supposedly, it helps a lot to have an L2 cache. I
don't have one on my 7200/90, and it seems fine. But I don't do much
compute-intensive work on it, either.
Lots of people have gotten a great deal of enjoyment from running TADS
games on much slower machines. If you can't, do your own native PowerMac
port of the interpreter, with support for whizzy fonts, styles, and
whatever other frills you need to make yourself happy. Your machine is
much faster than my 486/33 (not to mention that DOS real mode is such
garbage that it halves the practical performance of the machine), and I've
logged thousands of hours on TADS games with it. (And I wrote and
playtested UU2 on an 8Mhz 68000 Atari ST, and the performance was certainly
acceptable.)
Chris Thomas
> In article <ckt-041195...@ckt.vip.best.com>,
> Chris Thomas <c...@best.com> wrote:
>
> >Going from MaxZip to the TADS interpreter makes me very sad, and I now
> >avoid TADS games because of this!
> Sounds like an excellent opportunity for you to improve it, since your
> machine so acutely exhibits the problem. (For the record, I've run Legend
> extensively on a Quadra 950 and a PowerMac 7200/90 and haven't found either
> one to be slow.)
> Sign an NDA. Get the source from Mike. Make a better version. Really:
> we're all in this together; no one's making money providing you with these
> tools, and I no longer have time to devote to free stuff.
Sounds good to me. I hadn't even thought about it. Will attempt to
do so. Good point.
> Long ago, I was unsatisfied with the TADS ports, like you. I got the
> source from Mike and ported TADS to Unix machines. I am not special. You
> can do this too, for the Mac.
>
> >The wait on a PowerMac is often a second or more. I don't think the
> >machine makes a huge difference, honestly.
>
> That's quite a generalization from a single data point.
[etc]
This is true, but then I'm not getting paid for saying it. :)
--
Chris Thomas, c...@best.com
Andrew C. Plotkin
machines, so it should do so in the future" vs "Text IF has always run
on small machines, so it should not do so in the future."
I bet if someone wrote a game on a high-performance engine, say
Prolog-like, and distributed it as portable C source code (as portable
as ZIP), people would play it. A few courageous souls would build
Mac and IBM binaries, and it would be played and discussed to the same
extent that TADS and Inform games have been. And that would be cool.
(Not as cool as a portable game engine plus a game file, though. I
really think that absolute portability has been a much bigger factor
in the predominance of TADS and Inform than the ability to play on an
Amiga.)
(But you've heard my prejudices before.)
The point is: IF is not starving for CPU cycles because the players
refuse to play CPU-hungry games. It's because nobody has written games
heftier than Legend. *Write* the game of your dreams, and talk about
it later.
Jacob Solomon Weinstein
>(Dave: this is NOT a flame of Legend. I've seen pieces of the code, and
>I know darn well that you were pushing the limits of both TADS 2.0 and
>the machines you were working on. You did what you could with what you
>had, and I think if the people on the group knew everything that was
>going on inside that monster of yours, they'd be a lot more forgiving of
>the two-second delay between turns...)
Can Dave enlighten us as to what, exactly, was going on in the code? As
I've stated before, the reason that I found the delay so frustrating was
that I didn't see anything in the game that seemed to require more
CPU time than, say, the things that were going on in Unkuulian II.
If the NPCs in Legend seemed unusually alive, or if there were a
lot of complex interactions going on, I'd understand what was
causing the delay--but as I said earlier, Legend seemed to have
more text than the average text adventure, but I couldn't see
what was requiring all of the CPU time.
I'm particularly curious because if that two second delay was justified,
I must have missed out on a lot of neat stuff in Legend, and I'd better
go back and take another look at it.
-Jacob Weinstein
Jacob Solomon Weinstein
would be better for writing IF games than other languages? As a
non-computer-programmer, I know about languages like LISP and Pascal, but
I've never heard of Scheme. (I've heard of Prolog, but I don't know
anything about it.)
I would guess that the other non-programmer-types on r.a.if would be
interested in a bit of an explanation, so you may want to post your
reply. But if Scheme is something that everybody else here probably knows
about, and I'm embarassing myself by admitting I haven't heard of it,
then please feel free to e-mail me an explanation instead.
Thanks.
-Jacob "Hapless English Major" Weinstein
Greg Ewing
In article <478i7t$m...@life.ai.mit.edu>, d...@lf.ai.mit.edu (David Baggett) writes:
|> IF systems based on more
|> expressive languages (say Scheme or Prolog)
More expressive languages don't necessarily need more
processing power. Scheme, for example, is a very
small language, and a very compact implementation
ought to be possible if you're not too concerned
about speed.
|> Dave Baggett
|> d...@ai.mit.edu
Greg
David Baggett
David Leary <dle...@trout.ab.umd.edu> wrote:
>Surely you'd agree that it's possible to optimize TADS (even with the stuff
>you've done) to make Legend run on a 286 - if you had an extra year to
>spare. :)
It would be possible, but probably at the expense of portability. The real
charm of these languages is that they produce machine independent
executables, and that the interpreters are easily portable. Perhaps I
could write an assembly version of TADS that would run Legend with no delay
between commands on a 286. But the code would only be useful for 286's and
8086's. Is it better to spend time on such nonportable code, or to improve
the portable tools we already have?
>Ahah! Here we see glimpses into Dave's "the artist is divorced from his
>audience" mentality - aka "the audience doesn't really matter." While
>it's true he gives a nod to "feedback" he clearly feels how the audience
>reacts to his work is more or less meaningless...
I think it's a mistake to ignore one's target audience entirely. It's
also, I think, a mistake to cater to the audience, because it's not a
single entity with one mindset. If you listen to every comment you get
about your work, you'll end up chasing your tail.
>Leaving aside the obvious comment that the TRS-80 predates the Amiga and
>the 286 by a few years, the fact is that a text adventure - in ANY
>incarnation - should not need to draw on as many CPU-intensive processes
>as a real-time, graphics-intensive game of ANY sort. If it does,
>something's amiss.
1) If there were any doubt about my legitimacy in citing widespread
*philosophical* opposition to the notion that IF can and should use
whatever CPU resources are avaible, I hope this thread has finally put
them to rest. :)
2) 286 vs. TRS-80 vs. Timex-Sinclair is not the issue. The issue is that
the decision to label a 286 "necessary to support" and a TRS-80 "too
outdated to bother with" is arbitrary. The set of machines it makes
sense to support is a sliding window. I believe that 286's are well
outside that window. Further, I think that having that big a window
limits what IF authors can (or are willing to) try.
3) The claim that graphics and sound games are somehow entitled to
more CPU cycles than all-text games rests on a narrow view of
all-text games. Do you honestly believe there is no good use
one could put more than 1 MIPS to in an all-text game?
There are many problems relevant to IF that are nontrivial. The
algorithms people have used in IF to date are trivial from a
computational complexity standpoint. This seems to have had the
unfortunate result of misleading people into thinking that
all-text = trivial, which is certainly not the case.
Even apart from higher-abstraction tools that would reduce IF
development times at the expense of efficiency, there are innumerable
problems that deal with text-only inputs, that are relevant to IF,
and that appear to require more CPU cycles to solve than we have
had so far in the history of the universe.
IF is all about creating the illusion of interaction with intelligent
agents and a believable world. We're not even close to knowing
how to solve these problems given any imaginable computational
resources. Even gross approximations of intelligence and learning
seem terribly difficult (and certainly costly). To say that IF
doesn't need more CPU cycles is to deny the ideal that IF is
founded on!
>>First of all, you can probably get a used 386 motherboard for about $25 at
>>a flea market or hardware swap fest. Though I haven't checked mail order
>>prices recently, I bet that by now a 486 motherboard would be less than
>>what you paid for net access this year.
>
>Ah, the attitude which makes the industry what it is today! Change "486"
>to "Pentium" in the above paragraph, and Dave could work at Origin!
But I didn't say "Pentium," and that makes a big difference. A Pentium
motherboard costs upwards of $500. I checked a several-month-old Computer
Shopper and found that Cyrix 486 motherboards sell for around $80 *new*.
That's just slightly more than what a graphics and sound game costs. I
don't think it's unreasonable to ask that kind of financial commitment from
one with serious interest in a medium. That would get you into 3 to 5 LA
Philharmonic performances. It would buy you two dozen paperbacks.
You should also realize that if game authors assumed a 286 target platform,
you wouldn't have most of the interesting games that have come out in the
past five years, DOOM (which you mentioned was nifty) included. The game
I'm working on for my "real job" would be infeasible without the latest
hardware, not just because we crucially rely on this hardware's improved
performance, but also because we could never meet our deadlines without
development hardware like SGI's that make it possible for us to work
interactively with models composed of hundreds of thousands of polygons,
and to use productivity-enhancing tools like Common Lisp. Writing such a
game in assembly on a 286 would take considerably longer than the 18 month
window we have.
In short, gamers (naturally) want new gaming experiences. Innovation
requires better development hardware, and innovative games require more
computational resources. You are always free to save your money and stick
with an Atari 800. (I play games on mine all the time.) But is it
reasonable to ask game developers to *not* do what's necessary to innovate
(and yes, that includes not writing entire games in assembly, at the
expense of efficiency), just for the sake of supporting the hardware of 3
or 5 years ago?
It is your choice to support or ignore companies that assume state of the
art hardware. But there are people who *want* the latest thing and are
willing to pay for it
Bringing this back to all-text IF, I see the potential for tools that
vastly improve IF programmers' productivity. I see IF going in radically
new directions --- very little has changed since Adventure, really. But I
expect these things to come at the cost of efficiency, and not because
programmers are sloppy, but because their greatest enemy is development
time, and now that some games are actually starting to involve
compute-intensive algorithms (3D graphics games are the obvious example),
programmers must use higher level languages and tools in order to keep
reasonable schedules. The same is true of IF --- the algorithms will not
always be so simple if the medium evolves towards its ultimate goal.
>>Should I *really* be overly concerned about supporting the fair-weather
>>friends --- the ones who will play my stuff as long as it costs them
>>nothing and doesn't require them to go to any trouble? Been there, done
>>that. I wrote *Atari* software for 5 years.
>
>What about the pure artistic satisfaction of your work? This doesn't
>seem to fit with your stated reason for writing IF. See above.
My attitudes about art may change, but I think they are generally
self-consistent at any given time; you seem to think I'm confused. I get
satisfaction primarily from *creating* works, not from knowing that a
zillion people read them. If I release a work and you read it, I view it
as an act of kindness on my part, not yours. I gain nothing, while you
gain a certain invasion of my private thoughts.
This may seem paradoxical in light of our earlier discussion about what
constitues art --- I argued that an important criterion for a work of art
is that it communicate something. So why wouldn't I care if no one's on
the receiving end of this communication?
Well, I've never been of two minds about it: if a tree falls in the forest,
and no one's there to here it, it certainly does still make a sound. And
likewise, a beautiful thing is no less beautiful if one person sees than if
a million see it.
And from a practical standpoint, there will always be people who will
appreciate, somehow, what you have done, if you chose to make it available
to an audience and if it has merit.
>I would assert the following: games should be optimized to death, written
>for the lowest possible CPU they can run on, and written efficiently.
They you'll admit that your own games are an abomination? They're easily
100 times slower than they would be if you'd hand-coded them in assembly
for your target architectures.
The irony of this is that you're a real beneficiary of the very "sloppy
programer" philosophy you're trying to bury. Had you only been given
access to tools that would allow you to produce optimized-to-death games,
you'd never have finished even a fraction of an IF game. You and I both
know it would have been just too much of a pain, and would have taken far
too long.
I feel the same way about the present crop of IF tools. While they're fine
tools, impressive accomplishments, and worlds better than what we had 7
years ago, they're beginning to look a bit sorry alongside hypothetical
systems (which would run nicely on state-of-the-art machines) like Carl's
constraint management system, or, as I've said before, simply overall
better languages like Scheme.
>Maybe. D'ya think Neb might have finished UU3 if he'd had a higher-level
>language?
Let's not get absurd. (Sorry Neb!) :)
>The big drag on my games was always story/plot issues rather than coding
>issues. Once I knew where I was going, I could bang out stuff pretty
>fast.
How soon we forget things like THE MATCHBOOK. You spent, what, 2 weeks on
that? With a suitable language you could have coded it in under 5 minutes.
We are nowhere near maximal productivity yet, if there even is such a
thing.
I spent *weeks* writing that infernal Attachable class for WorldClass. And
I bet there are *still* bugs. It shouldn't be that hard.
Andrew C. Plotkin
> Could I bother somebody to tell me a little bit about Scheme and why it
> would be better for writing IF games than other languages? As a
> non-computer-programmer, I know about languages like LISP and Pascal, but
> I've never heard of Scheme. (I've heard of Prolog, but I don't know
> anything about it.)
Scheme is a LISP variant. It's LISP with a lot of the rough edges
removed; better type system, etc.
Prolog is a very weird language; instead of executing statements, it
kind of fiddles around with logical rules, trying to make conclusions.
I tend to think it's not a language, but a database system with a
powerful data-comparison engine. But that's not to say you couldn't
write IF with it.
I'm actually partial to SML, a language which might be described as a
distant descendant of LISP with the nicest type system I've ever seen.
Plus, the functions it generates are compiled into machine code, so
it's faster than most LISP derivatives. But I've only ever seen it
implemented for UNIX boxes.
Jarle Brinchmann
(And I wrote and
playtested UU2 on an 8Mhz 68000 Atari ST, and the performance was certainly
acceptable.)
Just to add to the record - I actually tried out Legend on my Atari
ST, and it worked acceptably, though a bit too slow for my taste but
the machine isn't that fast either.
(When I played Legend on an UNIX box, I didn't have any timelag BTW,
so get one today :-)
Both of these ports were done quite a while ago (incidentally both by
Dave who must have done quite a few ports), and compared with the
interfaces back then I think both of them are more than
acceptable. True, compared with MaxZip or XZip they might be lacking,
but those programs are slightly newer... (I'm actually pretty pleased
with the Atari version - I don't need anything more. The UNIX version
used to irritate me because I expected history editing on the cursor
keys :-)
Jarle.
--
---------------------------------------------------------------------
Nuke the Whales ! | Jarle Brinchmann,
| Email: ja...@ast.cam.ac.uk
International Krill Union. | Web: http://www.uio.no/~jarleb
David Baggett
Greg Ewing <gr...@cosc.canterbury.ac.nz> wrote:
>More expressive languages don't necessarily need more processing
>power. Scheme, for example, is a very small language, and a very compact
>implementation ought to be possible if you're not too concerned about
>speed.
I certainly agree that Scheme can be small. I don't think it can be as
fast as a good implementation of a language like C for most tasks, though.
There's been a fairly in-depth discussion about why programs written in a
functional style (which Scheme is designed for) are harder to optimize in
comp.lang.scheme. Many people who have implemented production Scheme
systems have posted on the topic.
My experience with Scheme on the PC leads me to believe that you pay a
fairly serious performance cost. Jeff Siskind's putting a lot of work into
his Stalin Scheme to C compiler --- perhaps it will set a new performance
standard. But to use it for IF you'd really have to convert it into a
bytecode compiler so that binaries would be machine independent.
One approach I've considered is to use a modified Stalin to compile Scheme
into a fairly rich virtual instruction set, then to translate this VM code
into native machine instructions at game load time. The drawback here is
that porting the run-time to new machines would be difficult, because you'd
have to write the instruction converter all over again every time. Also,
some architectures (like 80[2]86) would be harder to write a converter for
than others.
The advantage, of course, is that (I'm guessing) you'd get performance only
slightly worse than if you'd used a direct Scheme->C->native compilation.
David Leary
>It would be possible, but probably at the expense of portability. The real
>charm of these languages is that they produce machine independent
>executables, and that the interpreters are easily portable. Perhaps I
>could write an assembly version of TADS that would run Legend with no delay
>between commands on a 286. But the code would only be useful for 286's and
>8086's. Is it better to spend time on such nonportable code, or to improve
>the portable tools we already have?
Those aren't the only options. It's probably possible to make the tools
work on lower-end machines, or just fake more stuff (see below).
>I think it's a mistake to ignore one's target audience entirely. It's
>also, I think, a mistake to cater to the audience, because it's not a
>single entity with one mindset. If you listen to every comment you get
>about your work, you'll end up chasing your tail.
No argument here; I didn't change THOR's religious stuff because of a few
objections. But art/a game/whatever doesn't exist in a vacuum.
<Snippity-snip snip>
>2) 286 vs. TRS-80 vs. Timex-Sinclair is not the issue. The issue is that
> the decision to label a 286 "necessary to support" and a TRS-80 "too
> outdated to bother with" is arbitrary. The set of machines it makes
> sense to support is a sliding window. I believe that 286's are well
> outside that window. Further, I think that having that big a window
> limits what IF authors can (or are willing to) try.
We might be just talking about the size of the window here, with a
difference of opinion, but I think a 48K TRS-80 is not the same thing as
a 640K 286. It's an order of magnitude.
>3) The claim that graphics and sound games are somehow entitled to
> more CPU cycles than all-text games rests on a narrow view of
> all-text games. Do you honestly believe there is no good use
> one could put more than 1 MIPS to in an all-text game?
You're putting words in my mouth. I have yet to see said game. (See
below before you flame.)
> There are many problems relevant to IF that are nontrivial. The
> algorithms people have used in IF to date are trivial from a
> computational complexity standpoint. This seems to have had the
> unfortunate result of misleading people into thinking that
> all-text = trivial, which is certainly not the case.
I don't think it's trivial, but the player couldn't care less if you use
a fancy algorithm. My rule was to fake everything I could.
> Even apart from higher-abstraction tools that would reduce IF
> development times at the expense of efficiency, there are innumerable
> problems that deal with text-only inputs, that are relevant to IF,
> and that appear to require more CPU cycles to solve than we have
> had so far in the history of the universe.
Maybe. I'm unconvinced so far.
> IF is all about creating the illusion of interaction with intelligent
> agents and a believable world. We're not even close to knowing
> how to solve these problems given any imaginable computational
> resources. Even gross approximations of intelligence and learning
> seem terribly difficult (and certainly costly). To say that IF
> doesn't need more CPU cycles is to deny the ideal that IF is
> founded on!
YOU DON'T NEED TO SIMULATE INTELLIGENCE! While this might be a neat
compsci problem, it's completely uninteresting to me. I'm a crappy
programmer. I want to write a game that's interesting to play, and if I
have to fake realistic NPCs to do it, then that's fine, as long as the
player doesn't notice.
>But I didn't say "Pentium," and that makes a big difference. A Pentium
>motherboard costs upwards of $500. I checked a several-month-old Computer
>Shopper and found that Cyrix 486 motherboards sell for around $80 *new*.
>That's just slightly more than what a graphics and sound game costs. I
>don't think it's unreasonable to ask that kind of financial commitment from
>one with serious interest in a medium. That would get you into 3 to 5 LA
>Philharmonic performances. It would buy you two dozen paperbacks.
Weren't you just criticizing me for drawing a line at the TRS-80? How
come you're so willing to draw a line between 486's and Pentiums on the
other end?
>You should also realize that if game authors assumed a 286 target platform,
>you wouldn't have most of the interesting games that have come out in the
>past five years, DOOM (which you mentioned was nifty) included. The game
>I'm working on for my "real job" would be infeasible without the latest
>hardware, not just because we crucially rely on this hardware's improved
>performance, but also because we could never meet our deadlines without
>development hardware like SGI's that make it possible for us to work
>interactively with models composed of hundreds of thousands of polygons,
>and to use productivity-enhancing tools like Common Lisp. Writing such a
>game in assembly on a 286 would take considerably longer than the 18 month
>window we have.
Of course! And as you say yourself, this is because it's
graphics-intensive! There's a limit to how much faking you can do here.
(Though you only need to look an an Impressions game to realize a game
with fancy graphics can be horribly inefficient too.)
>In short, gamers (naturally) want new gaming experiences. Innovation
>requires better development hardware, and innovative games require more
>computational resources. You are always free to save your money and stick
>with an Atari 800. (I play games on mine all the time.) But is it
>reasonable to ask game developers to *not* do what's necessary to innovate
>(and yes, that includes not writing entire games in assembly, at the
>expense of efficiency), just for the sake of supporting the hardware of 3
>or 5 years ago?
Innovation doesn't have to mean more computational resources, ESPECIALLY
in IF. It can simply mean an original story and a better game.
Complexity isn't always good - remember the old "High Command" vs. "Clash
of Steel" debate in the wargaming community?
>It is your choice to support or ignore companies that assume state of the
>art hardware. But there are people who *want* the latest thing and are
>willing to pay for it
This is the Origin attitude in a nutshell.
>Bringing this back to all-text IF, I see the potential for tools that
>vastly improve IF programmers' productivity. I see IF going in radically
>new directions --- very little has changed since Adventure, really.
I agree with both statements here. Neither event requires better hardware.
>But I
>expect these things to come at the cost of efficiency, and not because
>programmers are sloppy, but because their greatest enemy is development
>time, and now that some games are actually starting to involve
>compute-intensive algorithms (3D graphics games are the obvious example),
>programmers must use higher level languages and tools in order to keep
>reasonable schedules. The same is true of IF --- the algorithms will not
>always be so simple if the medium evolves towards its ultimate goal.
I'm not sure there is an "ultimate goal." (What's the ultimate goal of
fiction in general?) I also note with amusement that you keep coming
back to the 3D graphics games as an example of something that requires
computationally-intensive programming - WHICH WAS MY EXAMPLE.
>My attitudes about art may change, but I think they are generally
>self-consistent at any given time; you seem to think I'm confused. I get
>satisfaction primarily from *creating* works, not from knowing that a
>zillion people read them. If I release a work and you read it, I view it
>as an act of kindness on my part, not yours. I gain nothing, while you
>gain a certain invasion of my private thoughts.
"Artist as Mother Theresa." I'm not buying it. If that's your motive, I
suspect you're more or less alone among artists. I agree it's not about
the money, but for most if not all, there's some ego involved. I suspect my
theory about "writing to pick up babes" is a lot closer to the truth.
>This may seem paradoxical in light of our earlier discussion about what
>constitues art --- I argued that an important criterion for a work of art
>is that it communicate something. So why wouldn't I care if no one's on
>the receiving end of this communication?
Good question...
>Well, I've never been of two minds about it: if a tree falls in the forest,
>and no one's there to here it, it certainly does still make a sound. And
>likewise, a beautiful thing is no less beautiful if one person sees than if
>a million see it.
I don't agree with you about the tree. As for your second statement,
what if NO ONE sees the "beautiful" thing?
(Whoah, man...heavy. Pass the bong, willya?)
>And from a practical standpoint, there will always be people who will
>appreciate, somehow, what you have done, if you chose to make it available
>to an audience and if it has merit.
Or even if it doesn't. See "The Bridges of Madison County."
(I said, somewhat lamely:)
>>I would assert the following: games should be optimized to death, written
>>for the lowest possible CPU they can run on, and written efficiently.
>
>They you'll admit that your own games are an abomination? They're easily
>100 times slower than they would be if you'd hand-coded them in assembly
>for your target architectures.
Well, okay, you got me here. But then again, I faked as much stuff as I
could.
>The irony of this is that you're a real beneficiary of the very "sloppy
>programer" philosophy you're trying to bury. Had you only been given
>access to tools that would allow you to produce optimized-to-death games,
>you'd never have finished even a fraction of an IF game. You and I both
>know it would have been just too much of a pain, and would have taken far
>too long.
True enough. But I did not, and will not, argue for writing text games
in assembly, just as I won't argue for writing games to run on a TRS-80.
We're both drawing lines. Let's not kid ourselves, Pentium-boy. ;)
>I feel the same way about the present crop of IF tools. While they're fine
>tools, impressive accomplishments, and worlds better than what we had 7
>years ago, they're beginning to look a bit sorry alongside hypothetical
>systems (which would run nicely on state-of-the-art machines) like Carl's
>constraint management system, or, as I've said before, simply overall
>better languages like Scheme.
More complexity doesn't always make better or more interesting games.
(Nebel-bashing deleted.)
I said, quite reasonably:
>>The big drag on my games was always story/plot issues rather than coding
>>issues. Once I knew where I was going, I could bang out stuff pretty
>>fast.
>
>How soon we forget things like THE MATCHBOOK. You spent, what, 2 weeks on
>that? With a suitable language you could have coded it in under 5 minutes.
>We are nowhere near maximal productivity yet, if there even is such a
>thing.
The matchbook was a notable exception. Most of that time was spent
running down dead ends. Once I figured out how to fake what I wanted to
do, it didn't take me that long.
>I spent *weeks* writing that infernal Attachable class for WorldClass. And
>I bet there are *still* bugs. It shouldn't be that hard.
I remember you working on that. I'll have to look at WorldClass sometime
and see how it ended up.
Gosh, I miss arguing with you in person! Let's start up that old
"monkeys can/cannot learn language" argument again! That'll have us
comparing each other to Nazis in no time! ;)
Gareth Rees
> Can Dave enlighten us as to what, exactly, was going on in the code?
Well, you can see for yourself; David Baggett has released the source to
"The Legend Lives":
(ftp://ftp.gmd.de/if-archive/games/source/tads/legend-src.tar.Z)
--
Gareth Rees
Carl D. Cravens
>a Truly Excellent ZIP intepreter for Macintosh in MaxZip. Going
>from MaxZip to the TADS interpreter makes me very sad, and I now
>ablack and white 6" TV and a 27" color TV with surround sound, it
>really is.
I have similar complaints going the other way on the PC, except I'm not
worried about glitz (it's only a text adventure) but functionality.
TADS on the PC has screen scrollback, command scrollback, multiple-level
UNDO, and a file requester... my version of ZIP has none of these.
--
Carl (rave...@southwind.net)
* If you don't support shareware, who will?
Carl D. Cravens
>portion of a text adventure. If text adventures were nothing but DOOM
>without graphics, I'd never play one.
Empty Hall 443
This looks about like every other hall you've seen. It runs north
and south.
You see a Type 3 demon six meters ahead, coming your way.
> attack demon with plasma rifle
The demon disappears in a cloud of blood and gore. You find an ammo
pack. Your score just went up.
> get pack
Taken.
> status
Life: 23% Weapon: Plasma Rifle Power: 55%
> push west wall
You find no secret door.
> n
Empty Hall 444
This looks about like every other hall you've seen. It runs south,
east, and west.
> push north wall
You find no secret door.
etc.
Yeah... I can see your point. :) (But Doom's really an arcade game,
not an adventure game... could you see playing Zork Invaders?
> shoot alien
Your score just went up.
There are 23 aliens left.
> shoot alien
Your score just went up.
There are 22 aliens left.
> shoot alien
Your score just went up.
There are 21 aliens left.
:)
--
Carl (rave...@southwind.net)
* If I want your opinion, I'll take you out of my killfile.
Carl D. Cravens
>I disagree. There *are* graphical adventures that make you think as
>much as the average text adventure. (I won't say the *best* text
>adventures.) Myst and Buried in Time have been large commercial
>successes, and they have the very familiar styles of puzzles we've
>seen since Colossal Caves. (And they don't do mapping for you.)
Okay, there are a few... but the majority of what I've seen don't stand
up to text adventures for enjoyment for me.
>Mind you, people were the same twenty years ago. The blossoming of
>graphical games comes from the expansion of the computer market beyond
>technophiles, crossed with the increased graphical capability of
>machines.
True. I also think that enjoying textual IF requires a certain mind-set
which has nothing to do with any of the things mentioned so far... it's
just one of those things you like or you don't like. I know plenty of
people who were hooked on Bard's Tale, King's Quest, etc. that tried
"that Zork thing" and really hated it. I wonder how much of an
inability to deal with getting "stuck" turns people off. One can't
tailor a game to the individual and different people will get stuck on
different things... get stuck on enough puzzles at once and the game
grinds to a halt. That's the point that I'm most likely to lose
interest. If someone with less interest in IF than I have hits this
point in the first couple games they try, they probably aren't going to
try any more. (I'm anxious to get back to Trinity... I started it
twice about a year apart on the Amiga, but got stuck in about the same
place. I'm asking for some Lost Treasure for Christmas.)
>> The point-n-click interface was created for those who either aren't
>> smart enough or don't have the patience to deal with a command line...
>
>Now I disagree again. (As a Mac user and programmer.)
Rash generalization, I know. Some smart folks do have a preference for
GUI's... but you're on a Mac and not Windoze. As a power user and
programmer, I can't stand how Windows tries very hard to hide things
from the user, making it hard to know what's really going on behind that
desktop. But if you take a look at the general trend in PC/Windows
software, you'll notice that the common denominator is getting lower and
lower. (And the hardware requirement gets higher and higher. :)
--
Carl (rave...@southwind.net)
* Press any key to continue or any other key to quit.
David Baggett
Jacob Solomon Weinstein <jwei...@alcor.usc.edu> wrote:
>Can Dave enlighten us as to what, exactly, was going on in the code? As
>I've stated before, the reason that I found the delay so frustrating was
>that I didn't see anything in the game that seemed to require more
>CPU time than, say, the things that were going on in Unkuulian II.
Well, the easy answer for me is that you can get the complete source
to _Legend_ from the IF archive and see for yourself. :)
The harder answer is that there are a few things that WorldClass does
as a matter of course that chew cycles. The big culprits include:
1) "Known" tracking. WorldClass keeps track of what game objects the
player has seen so far. Among other things, this allows the game
to intelligently respond to
>ask monk about dragon
when the player doesn't know about the dragon yet. It also
helps the hint system figure out (roughly) how far the player
is in the game.
Why does this use CPU resources? Because whenever the player
enters a room, the game has to mark everything in the room as
"known". This means it has to traverse the containment hierarchy
for the room, which is time-consuming.
2) Better contents listing. The contents lister is much more complex,
for the sake of better output and to support things like objects
that have a smell, but which you can't see. The dark is not
special in WorldClass --- you can still move around, get things,
and so forth. And you'll still get descriptions for things you
can hear, smell, and feel. New commands like "listen" and
"feel around" just call the standard contents lister with visual
contents listing turned off. You can see a few examples of this
in Legend --- while you're in the escape pod, for example,
"listen" when the engines start to roar.
3) No assumption that the current location is the player's sense
domain. When you use "key" as a direct object, WorldClass
considers every key in the whole game, not just those in the
current room. This allows many interesting things, but at
a fairly significant cost. (It also allows a first-class
distinction between verbs like "ask about" and versbs like "take",
where other systems handle this in an ad hoc manner.)
4) Sense reach checking. When you say "examine key", the game runs
a function called cansee on every key object. This function
(by default) checks with all containers between the player
and the key, seeing if any container objects to passing the
sense of sight. (e.g., a closed box won't.) If no container
objects, the command works. Otherwise, the container that
objected prints its failure message. (e.g., "You'll have to
open the box first.")
This makes some really cool stuff easy to do. E.g., the
vending machine in _Legend_ allows sight through, but not
smell, taste, touch, etc. One could do this with ad hoc
code, again, but WorldClass provides a *general* mechanism
for it.
One interesting use of this is tracking light sources.
To see if you're in the dark, WorldClass checks with the
player's location to see if it has an ambient light soruce.
If not, it then determines whether any light source in the
game has a line of sight to the room the player is in.
A consequence of this is that if the player takes his
lamp and locks it in a dark box, he won't be able to see
any more. Again, you could write ad hoc code to effect
this, but it simply falls out of a general mechanism with
WorldClass.
Are these things important enoguh to spend the cycles on them? I think
they could make for interesting new twists in adventure games. They also
cut down on the amount of ad hoc code you need to write, which in my view
is a wonderful thing.
>If the NPCs in Legend seemed unusually alive, or if there were a
>lot of complex interactions going on, I'd understand what was
>causing the delay--but as I said earlier, Legend seemed to have
>more text than the average text adventure, but I couldn't see
>what was requiring all of the CPU time.
You're still ignoring my general sentiment that features need not be
visible in the final product to make the use of CPU resources worthwhile.
If it takes me 3 months to write a WorldClass game where it would have
taken me 6 months to write the same game with ADV.T, is it not worth it to
use WorldClass, even if I don't use some of the more powerful features?
David Baggett
Jacob Solomon Weinstein <jwei...@alcor.usc.edu> wrote:
>Even so, Dave B, I don't think one response proves your point about
>_widespread_ philosophical objections to using high-level machines.
I'm not talking about a single response. Maybe it's just me, but I feel
like there's a constant barrage of complaints about what machines this or
that won't run on, how it's criminal that there's no Amiga, Atari Falcon,
Apple IIGS, etc. version of the TADS run-time, and so on. And almost
inevitably, the poster will argue that "these are just text adventures ---
there's no reason I shouldn't be able to run them on my ______."
>Dave B, if you'll come up with a statement that you believe summarizes
>the widespread philosophical objection to writing IF that requires a
>high-level processor--a statement like "No text adventure should ever
>require a powermac or a pentium"--I'll invite people to e-mail me whether
>or not they agree.
OK, how about:
What are reasonable hardware requirements for IF?
a. IF should run on any machine Infocom's Z Machine runs on.
b. IF should run on TRS-80 era machines. (Examples: Atari 800,
Apple II, C64)
c. IF should run on 286 era machines. (Examples: Atari ST,
Amiga 500, Apple IIGS, Mac Classic)
d. IF should run on 386 era machines. (Examples: Mac II)
e. IF should run on 486 era machines.
f. Don't care, as long as the end product is tangibly superior.
g. Anything is reasonable.
Andrew C. Plotkin
>
> the wheel! Yeah, sure, I can pull out Knuth vol 1 and write myself some
> heap allocation routines, but I think it's one of the marks of a good
> programming language that I don't have to do so.
I think C is a good programming language, and it doesn't have dynamic
allocation in it.
One of the best things about Inform is that it doesn't have a parser
in it. Kind of a strange advantage for a text-adventure language, huh?
Or, to be more direct:
You're complaining that Inform can't do X, and when I point out that
it can, you say you'd rather not write the library routines.
Matt Ackeret
>I'm not talking about a single response. Maybe it's just me, but I feel
>like there's a constant barrage of complaints about what machines this or
>that won't run on, how it's criminal that there's no Amiga, Atari Falcon,
>Apple IIGS, etc. version of the TADS run-time, and so on. And almost
>inevitably, the poster will argue that "these are just text adventures ---
>there's no reason I shouldn't be able to run them on my ______."
My main complaint is that TADS, specifically, is allegedly allowed
to be ported to new machines. Allegedly, but apparently not actually so.
I (and presumably the others) would definitely sign a non-disclosure
agreement, and would do the porting _ourselves_. That's why I think the
info in the FAQ posted here frequently is, at the very least, slightly
misleading.
Another of the really good things about the separated game
file vs. interpreter deal is that many of the speed issues you talk about
can be handled on the interpreter end. Obviously the code-to-be-interpreted
can be complex enough that it can't be interpreted fast enough on some machines.
However, from what I hear about TADS, and what I know about the Inform and
Infocom games, the interpreter's speed can be tweaked a lot. (This doesn't
hurt portability either, as there already are different drivers and other
calls specific to each platform.) If the "generic" portable code isn't
fast or feature-rich enough, the person doing the port can improve it in
a platform-specific way. (For example, there are some Amiga-specific calls
in the general ZIP distribution.) Also, Stefan Jokisch has removed
the VM-ish paging of ZIP in modifications he's done. I'm using those
modifications since I have the memory available and the speed increase
will (hopefully) outweigh the increased memory usage.
Basically, I think that the "generic datafile with interpreter"
model is one that should remain, and anyone who wants to should be allowed to
port it to whatever machine under the sun they want to (with obvious
NDAs, etc., for commercial products). Will the different environments get
complex or memory-hogging enough (*) so that slower machines can't run
them? Probably, but as I described above, machines "on the borderline"
can benefit from people who care about the machine and are willing to put the
extra work into optimizing a port of an interpreter that the original
author(s) may not be willing to do.
(*) Actually, with this, some sort of VM-like paging system as a
compile time option would be good. Infocom was clever by using this sort of
system. (Or it could be on by default, and someone else willing to do the
work would have to remove it.)
--
unk...@apple.com Apple II Forever
These opinions are mine, not Apple's.
Carl de Marcken
> would be better for writing IF games than other languages? As a
> non-computer-programmer, I know about languages like LISP and Pascal, but
> I've never heard of Scheme. (I've heard of Prolog, but I don't know
> anything about it.)
Scheme is a dialect of Lisp, of little enough importance, but used widely as a
scripting language, for many of the same reasons one might base an adventure
game language on it.
* It is _very_ simple.
Indeed, in many introductory computer science courses, students implement
Scheme compilers and interpreters. Writing portable interpreters for
scheme is easy. Scheme to C converters exist.
* It is _very_ extensible.
Scheme is probably the easiest language in existance to add powerful
constructs and intuitive syntax to. It would be possible to add
adventure-game-specific elements to Scheme without in any way
modifying the underlying language.
It does have a variety of drawbacks. There is not really an accepted standard
for Scheme (though the R4 manual comes close). Being so simple, it has no
static type-checking, and (in its bare-bones versions) no aspects of
object-oriented programming. Indeed, here at MIT in the introductory computer
science class, one homework (the introduction to o-o programming) is to add an
adventure-game package to Scheme. Anyone who thought the adventure-game
writing contest on the net recently was the first is wrong by at least 10
years- 350 people participate in one every year here, with some fantastic
results (though not obviously, ones capable of being played widely, given that
the participants have about a week to get their assignment done).
Carl de Marcken
Bruce Stephens
> I would assert the following: games should be optimized to death,
> written for the lowest possible CPU they can run on, and written
> efficiently. You'll reach the biggest possible audience by doing
> so. If the "low-end" machine for your game is a 486, well, them's
> the breaks. If it's a TRS-80, but the game is still fun - so much
> the better.
Quite so. Curses runs quite comfortably on a Psion Series 3a, which
is convenient: I can play it on the bus, or while watching TV.
There are other kinds of game that Inform can't do easily. For
example, a game where the NPCs had proper representation of knowledge,
where they would remember things that you had told them, and things
that you had asked them about, and behaved accordingly, perhaps
maintaining some kind of emotional state.
Another example (one which one of the programmers of the late Magnetic
Scrolls once played with) is a game in which things are more flexible;
where the landscape, objects and NPCs don't exist until you come
across them, at which point they are created, consistently with
everything that you've already seen.
If you want to write using some other language, then by all means do
so. If it produces a game which is interesting enough, then I'll play
it (on less portable hardware), but I'm not convinced at present that
Inform could be made dramatically easier to use by adding any fancier
features; it looks quite adequate for the kinds of games that it's
designed for.
If you write Zork-type games which require a 486, then I'm going to
wonder why.
I'm all for developing Inform and Z-code, however. I think it would
be interesting to redesign Z-code with the benefits of hindsight,
making it quicker to interpret, perhaps (this *is* an issue on some
machines which people want to use in playing games!), or adding some
features which are now practical. Or perhaps simply to compress text
better. But it doesn't seem compelling just at the moment.
--
Bruce Institute of Advanced Scientific Computation
br...@supr.scm.liv.ac.uk University of Liverpool
http://supr.scm.liv.ac.uk/~bruce/
Mathematical Institute, (01865) 2-73525
>>>>>> "David" == David Leary <dle...@trout.ab.umd.edu> writes:
>
>> I would assert the following: games should be optimized to death,
>> written for the lowest possible CPU they can run on, and written
>> efficiently. You'll reach the biggest possible audience by doing
>> so. If the "low-end" machine for your game is a 486, well, them's
>> the breaks. If it's a TRS-80, but the game is still fun - so much
>> the better.
>
> Quite so. Curses runs quite comfortably on a Psion Series 3a, which
> is convenient: I can play it on the bus, or while watching TV.
Speaking as someone who knows how Curses works, I think I'd say
that it runs at best uncomfortably...
> There are other kinds of game that Inform can't do easily. For
> example, a game where the NPCs had proper representation of knowledge,
> where they would remember things that you had told them, and things
> that you had asked them about, and behaved accordingly, perhaps
> maintaining some kind of emotional state.
I don't think this is really a limitation of Inform, as such: the
language is perfectly flexible enough to accommodate as much of this
as you want to implement, and I'm sure the same must go for TADS as
well. Features like this are hard to generalise implementations of,
so it would not really be appropriate to include them in the Library
anyway.
> Another example (one which one of the programmers of the late Magnetic
> Scrolls once played with) is a game in which things are more flexible;
> where the landscape, objects and NPCs don't exist until you come
> across them, at which point they are created, consistently with
> everything that you've already seen.
This is a much older idea, really! Antiquated mainframe maze games
(and their modern inheritor, NetHack) have done this for years. Again,
this is easy enough in Inform if you want to implement it.
> If you want to write using some other language, then by all means do
> so. If it produces a game which is interesting enough, then I'll play
> it (on less portable hardware), but I'm not convinced at present that
> Inform could be made dramatically easier to use by adding any fancier
> features; it looks quite adequate for the kinds of games that it's
> designed for.
Well, thanks! Yes, my present feeling is that Inform's library
implements about the right amount of "world model", and that any
really radical extras ought to be in separate, take-or-leave extra
library files.
> If you write Zork-type games which require a 486, then I'm going to
> wonder why.
>
> I'm all for developing Inform and Z-code, however. I think it would
> be interesting to redesign Z-code with the benefits of hindsight,
> making it quicker to interpret, perhaps (this *is* an issue on some
> machines which people want to use in playing games!), or adding some
> features which are now practical. Or perhaps simply to compress text
> better. But it doesn't seem compelling just at the moment.
This is an argument advanced every few months on the newsgroup. The
answer I always give is somewhat like yours, i.e., that there is little
point in redesigning the Z-machine unless some significant practical
gain would follow (the aim is not to design a "perfect" platform but
to maintain a healthy work-horse).
The Z-machine can be implemented pretty quickly. I can't, offhand,
think of a good way of improving speed by any significant margin,
given the compactness of the format. We probably could soup up the
text compression rate, but (again) that's probably not going to be
needed enough to make it worthwhile.
What I am working on is a much better-defined and better interpreted
present state of the Z-machine!
Graham Nelson
Gareth Rees
> [Inform] is perfectly flexible enough to accommodate as much of this
> as you want to implement, and I'm sure the same must go for TADS as
> well.
This is true but not especially useful. Almost all computer languages
are Turing powerful and capable of expressing any algorithm. However,
languages differ in how easy it is to express particular algorithms, and
some languages are more suitable for some problems than others.
For example, if I have a file and I want to know the most frequent word
in that file, I type
cat file | tr -cs A-Za-z '
' | tr A-Z a-z | sort | uniq -c | sort -n | tail -1
But I confess that I am at a complete loss as to how to write this
algorithm in Inform (even if I am guaranteed that there will be no
memory problems). Certainly it would take several tens of lines to code
up a solution.
So for this type of problem, shell scripts are a more productive
language than Inform (in the sense that I can spend less time writing a
program to solve the problem, and the resulting program is more flexible
and easier to maintain). Inform, on the other hand, is best suited for
the problem of writing "Trinity"- and "Curses"-like adventure games.
But for more complicated games involving character knowledge, reasoning
and planning, other languages may be more productive yet. People who
work in the AI field tend to use dynamic symbolic languages like Prolog,
Scheme and LISP because these languages allow them to manipulate complex
symbolic data structures easily, something which Inform does not allow
(I have to encode my symbols as numbers, and transform all my data
structures to fixed-size arrays or trees of objects). How do I
represent a conceptual dependency structure in Inform? A frame? A
plan? A semantic net?
This isn't really a criticism of Inform: no language can be good at
everything, and Inform is very good at what it is intended for.
--
Gareth Rees
Matthew Amster
David Baggett <d...@lf.ai.mit.edu> wrote:
>>(Chris Thomas)
>>The wait on a PowerMac is often a second or more. I don't think the
>>machine makes a huge difference, honestly.
>
>That's quite a generalization from a single data point. MacWeek has been
>reporting that 7000 series PowerMaccs perform poorly (sub-Qudra speeds) on
>a wide range of tasks. Supposedly, it helps a lot to have an L2 cache. I
>don't have one on my 7200/90, and it seems fine. But I don't do much
>compute-intensive work on it, either.
Indeed, I suspect there's something going on here in a system setting or
some such. I did about half my Legend playing on a Mac IIsi (yuk) at
work, and it was quite zippy--no pun intended.
I did run into an odd memory problem that made it impossible to take the
Akmi Wunder-Gro, but otherwise had no complaints. Sure as hell beat
playing it on my 486SX/25.
I'm with Dave, though: a native PowerMac version of TADS could be a real
screamer. I have no idea what's involved in doing such a port, but the
other features you might be looking for--snazzy fonts, formatting,
whatever--will be trivial.
Good luck,
Matthew
David Leary
>To a certain extent, you can squeak more cycles out of a machine by coding
>in assembly. But obviously there are limits, otherwise all machines could
>do everything, which is clearly ludicrous.
I feel like I'm repeating myself, but I'll try once more - I'm not
disagreeing with this general statement, and I'm not advocating assembly.
>I doubt it would be possible to optimize TADS, even by hand-coding it, to
>the extent that _Legend_ could figure out, with no visible delay on a 286,
>which hint is the best one to print out when the player types "hint".
>There are many other real-world IF problems which don't require
>particularly fancy algorithms or programming, but which nevertheless take a
>decent number of steps to solve.
Hmm. Well, once again we're talking about trade-offs. But please
continue...
>Could you fake _Legend_'s hint system? Sure, but it would require you to
>write many more lines of code (*), and would be correspondingly more buggy,
>and take that many more weeks of playtesting to get the bugs out. And you
>might *never* find all the bugs. As programming goes, IF is especially
>fiendish, because it offers the player a huge state space to explore --- so
>huge that your playtesters (or even your players) could never visit (test)
>every state. That's why I think it's worth spending cycles on elegant,
>robust solutions that require more time versus ad hoc solutions that are
>cheap but very error-prone.
Well, my solution would be to just not use such a hint system. This is
once again a trade-off: supporting more low-end machines vs. a specific
feature in your game. I personally am most interested in a game that
squeezes the most out of its minimum system (which actually, I think
Legend does, so you should stop using it as an example), but that's a
matter of personal philosophy.
And does the typical IF game have a bigger state space than, say,
Civilization? I think not!
>(*) Actually, in this *particular* case, that might not be true, but
> *only* because I had to rewrite the hint system in the most
> hideous manner to get it to fit under real mode DOS. GEE, I
> HAD TO WRITE CRAPPY CODE JUST TO SUPPORT AN OLD MACHINE --- WHAT A
> FREAKING COINCIDENCE!
Hey, but it worked, right? And on a 286, no less...the typical gamer
doesn't care that your code is hideous.
I wrote:
>>YOU DON'T NEED TO SIMULATE INTELLIGENCE! While this might be a neat
>>compsci problem, it's completely uninteresting to me.
And Dave asserts:
>Well, personally I no longer think you can fake intelligent NPC's well
>enough to even bother with them. It takes about 30 seconds to exhaust the
>NPC fakery in adventure games. There's no simple faking you can do to make
>this significantly better. If you want NPC's to interact with the player
>intelligently, they have to be intelligent.
Well, if that's what trips your triggers, so be it. I'm not sure you
need intelligent NPC's if your text is interesting enough. I think the
height of IF is a novel with choices, and you think it's a simulation of
the real world. Probably both are valid approaches.
We continued...
>>I'm a crappy programmer. I want to write a game that's interesting to
>>play, and if I have to fake realistic NPCs to do it, then that's fine, as
>>long as the player doesn't notice.
>
>What do you mean, "as long as the player doesn't notice?" Nobody thinks
>they're really talking to anything but a midless automaton when they
>"interact" with an IF NPC. Perhaps briefly the player will suspend
>disbelief, but this is hardly true throughout the entire game.
Probably most players don't think about it all that much. I'm not sure
there's a greater suspension of disbelief when they're watching some nice
full-motion video or when they're talking to Floyd in Planetfall.
Suspension of disbelief is more about mood, setting, and character than
whether your NPC's can pass the Turing test. If you want to write a game
with NPC's that are smarter than you are, have at it. I'd rather spend
time on the plot and descriptions.
And more back n' forth...
>>Weren't you just criticizing me for drawing a line at the TRS-80? How
>>come you're so willing to draw a line between 486's and Pentiums on the
>>other end?
>
>I think I'm having deja vu here. Let's see, "...rubber...glue..." It's
>hazy but, yes, I'm sure I've been here before... Wait! It's a maze of
>twisty non sequiturs, all alike! :)
Yes, we've been here before, but you neatly side-stepped my point. Why
shouldn't an IF game be written only for Pentiums?
>My point throughout this discussion is simple: I perceive significant
>opposition among IF fans to IF works that *require* modern hardware to run
>on. *I* never really wanted to draw lines in the sand here, but the whole
>"monetary investment in IF" argument came up, and to address that I argued
>that a 486 motherboard, in particular, is not what I'd consider a steep
>investment *relative to the investments one must make in other arts*.
No, it's not, but then they'll need a CD-ROM drive, then a better CD-ROM
drive, then SVGA, then Super-SVGA, then a Gameblaster, then a Pentium...
The upgrading treadmill never stops - or even slows down. You want them
to buy 486's today. You'll want them to buy Pentiums to run "Legend 2:
Duhdha's Omlet" (with full-motion video and "EggSmell" (TM) technology)
tomorrow.
Part of IF's charm, for me, is that the best DESIGNERS can make the best
games, not the guys that spend many thousands on their systems.
>I *don't care* what systems authors require for their games. I worry about
>the sentiment that ten-year-old hardware *must* be supported, otherwise
>something's wrong, "because after all, these are only all-text games." I
>believe that notion does limit what authors are willing to try. That is
>all.
This is not my argument. See above.
<Snippity-snip snip>
>I cited a bunch of graphics examples to address your comments about
>companies like Origin. You say they're sloppy and lazy. While this may be
>true to a certain extent (I'm not a big Origin fan myself), I think it's a
>mistake to blame increasing hardware requirements on either of these ills.
>Only the very latest hardware can run certain kinds of games. So when
>companies write these kinds of games, for the people who want them, they
>must require said hardware. Simple. The point is that there are things
>you can do with this year's hardware that you couldn't on last year's, even
>if you *do* write lots of assembly code. Our game wouldn't run on a Sega
>Genesis (the previous generation console hardware) if GOD HIMSELF wrote the
>code.
Is Myst more fun than Planetfall?
>But I also cited Common Lisp, which has nothing to do with graphics. It's
>a language and a development system. By C standards, it is dog slow. But
>since we have 200Mhz SGI's, that doesn't matter. Common Lisp makes us much
>more productive than C. So we depend on our fast SGI's not because our end
>product requires one to run, but because our fancy, productivity-enhancing
>development system is acceptably fast on them, but wouldn't be on, say, a
>286. Or a Pentium, probably.
How about the end game? I couldn't care less how powerful your
development system is...
>Of course, we don't write the end product in Common Lisp. But we do write
>tools that aren't a part of the game itself, but are essential to
>development, in Common Lisp. Which saves us a lot of time.
That's fine with me, and I never said otherwise.
More back n' forth...
>>Innovation doesn't have to mean more computational resources, ESPECIALLY
>>in IF. It can simply mean an original story and a better game.
>
>You're right, it doesn't *have* to. But *may* it? If so, then mandatory
>support for n-MIPS machines (you fill in the n) is a bad policy.
Read my previous message again. I wasn't arguing for mandatory support
for any machine.
(Origin attitude discussion snipped.)
As someone else pointed out on this newsgroup, there's quite possibly a
lot of lurkers out there with low-end machines. In my family, I know two
people with 386's, and two more with 286's. They have no interest in
upgrading. Their computers do everything they need to do. And I think
it would be nice if, now and then, they could buy a new game to play.
For Origin (or any other company) to completely ignore said customers is,
IMHO, a mistake.
>Can I not convince you that even if GOD HIMSELF is your programmer, your
>machine is not capable of running every programming language and
>environment we could ever conceive of, some of which might make us more
>productive IF authors?
Sure. Write the IF game that requires a Pentium and delivers a serious
increase in play value and fun beyond Planetfall, and I'll be suitably
impressed. As I said, I haven't seen it yet.
Art discussion follows...
>>"Artist as Mother Theresa." I'm not buying it. If that's your motive, I
>>suspect you're more or less alone among artists.
>
>How do you know what motivated Kafka? What about Robert Johnson? Was he
>writing blues tunes to make money, so the world would remember him, or just
>because *that was what he did?* And what about Thag the cave painter?
A lot of different things can motivate artists. Money, immortality,
religious fever, you name it. But even Thag didn't draw his horsies in a
vacuum. He was working for an audience, even if it was just his
flea-scratchin' wife.
Remind me sometime to loan you this book I've been reading about Easter
Island...it has something to contribute to this discussion...
>>I suspect my theory about "writing to pick up babes" is a lot closer to the
>>truth.
>
>There are other writers on Earth besides Kundera...
Name me one who was willing to paint his pictures in a closet and NEVER
SHOW THEM TO ANYONE. Hmm...well, such souls may exist, but WE'VE SURE
NEVER HEARD OF THEM!
Is their work art? Not without an audience, chucko...
>>Well, okay, you got me here. But then again, I faked as much stuff as I
>>could.
>
>Ah, you *think* you did. But in fact you could have simply made your
>program a massive table mapping input string and game state number to
>output string and new game state number. No explicit code required! This
>would run *really damn fast*. But it would be a bit of a memory hog.
That's not fakery, that's programming genius - and well beyond my meager
capabilities.
>>The matchbook was a notable exception.
>
>Yes, well what about "put axe in bucket"? :)
That was a different problem - I didn't understand a quirk of TADS.
>Nobody is perfect, of course, and no programming language prevents you from
>making *any* mistakes. But many of the kinds of bugs we get writing in
>these somewhat low-level C-like languages would all but disappear if we
>used more powerful systems.
At what price?
>I guess I should point out that I'm not trying to diminish what Mike and
>Graham have done with their development systems. Together they have
>brought IF into a new era --- the age of the amateur IF author who produces
>professional-quality IF. The number and quality of IF releases in the past
>few years is ample evidence of this.
Amateur meaning "not a programmer." Something about this definition
bothers me.
>I was hoping against hope that Nim Chimpsky would finish his adventure game
>in time for the contest this year, but --- alas --- he still can't get a
>grip on this whole "tree structure" thing...
You didn't happen to see Nature a couple of weeks ago, did you? They had
a chimp on that understood commands such as "put the apple in the
refrigerator" and "take the vacuum outside." That's about as
sophisticated as any IF parser has gotten...
Neil K. Guy
(various strong points of WorldClass deleted)
: Are these things important enoguh to spend the cycles on them? I think
: they could make for interesting new twists in adventure games. They also
: cut down on the amount of ad hoc code you need to write, which in my view
: is a wonderful thing.
Hm. Well I could just interject here to mention that my extremely
vaporous game in progress implements *most* of the things you've described
here, through ugly hacks to adv.t. My code is as non-elegant as you
can get (especially compared to WorldClass, which is frankly very
nice code. Especially, I'm sure, the bits that I simply don't understand
:) but it works and, most importantly for me, it does so without the
heavy speed penalty that WorldClass invokes. (mainly because it follows
the adv.t tradition of assuming that if an object ain't in the room
with you then it's out of bounds for most verbs and thus the game doesn't
spend yonks traversing the object tree)
So I guess my point is, I'm happy dealing with ugly messy hacks (mainly
since I wrote them and thus more or less understand them) if it allows
me to play my game on my Mac Plus in the corner, which was my development
system until this January. I think either route is perfectly fair - it
just depends on your own priorities in the game. (but I'm probably
not going to want to release my source mainly because I'm, well, kinda
embarrassed at how hideous the code is.) I feel perhaps it also depends
on where you're coming from. You're obviously a very good programmer,
so you've built a very strong and self-consistent model for you to create
your world within, and you're willing to pay the CPU price for it. I,
however, am not a very good programmer and am more interested in writing
what I hope will be a reasonably interesting game that's still playable
on some (though unfortunately certainly not all) older machines. And
if I ain't got a self-consistent model, oh well! It's the story and the
game that are important to me.
But I certainly concede your second point. Which can be amply proved
by the fact that your game is finished and mine, 3 years later, is not.
Anyway, I should shut up. It's easy for me to ramble on like this when
I've never shipped anything for public consumption!
- Neil (my game is nothing but special-case code) K.
David Baggett
David Leary <dle...@trout.ab.umd.edu> wrote:
>It's probably possible to make the tools work on lower-end machines, or
>just fake more stuff (see below).
To a certain extent, you can squeak more cycles out of a machine by coding
in assembly. But obviously there are limits, otherwise all machines could
do everything, which is clearly ludicrous.
I doubt it would be possible to optimize TADS, even by hand-coding it, to
the extent that _Legend_ could figure out, with no visible delay on a 286,
which hint is the best one to print out when the player types "hint".
There are many other real-world IF problems which don't require
particularly fancy algorithms or programming, but which nevertheless take a
decent number of steps to solve.
Could you fake _Legend_'s hint system? Sure, but it would require you to
write many more lines of code (*), and would be correspondingly more buggy,
and take that many more weeks of playtesting to get the bugs out. And you
might *never* find all the bugs. As programming goes, IF is especially
fiendish, because it offers the player a huge state space to explore --- so
huge that your playtesters (or even your players) could never visit (test)
every state. That's why I think it's worth spending cycles on elegant,
robust solutions that require more time versus ad hoc solutions that are
cheap but very error-prone.
(*) Actually, in this *particular* case, that might not be true, but
*only* because I had to rewrite the hint system in the most
hideous manner to get it to fit under real mode DOS. GEE, I
HAD TO WRITE CRAPPY CODE JUST TO SUPPORT AN OLD MACHINE --- WHAT A
FREAKING COINCIDENCE!
>YOU DON'T NEED TO SIMULATE INTELLIGENCE! While this might be a neat
>compsci problem, it's completely uninteresting to me.
Well, personally I no longer think you can fake intelligent NPC's well
enough to even bother with them. It takes about 30 seconds to exhaust the
NPC fakery in adventure games. There's no simple faking you can do to make
this significantly better. If you want NPC's to interact with the player
intelligently, they have to be intelligent.
>I'm a crappy programmer. I want to write a game that's interesting to
>play, and if I have to fake realistic NPCs to do it, then that's fine, as
>long as the player doesn't notice.
What do you mean, "as long as the player doesn't notice?" Nobody thinks
they're really talking to anything but a midless automaton when they
"interact" with an IF NPC. Perhaps briefly the player will suspend
disbelief, but this is hardly true throughout the entire game.
>Weren't you just criticizing me for drawing a line at the TRS-80? How
>come you're so willing to draw a line between 486's and Pentiums on the
>other end?
I think I'm having deja vu here. Let's see, "...rubber...glue..." It's
hazy but, yes, I'm sure I've been here before... Wait! It's a maze of
twisty non sequiturs, all alike! :)
My point throughout this discussion is simple: I perceive significant
opposition among IF fans to IF works that *require* modern hardware to run
on. *I* never really wanted to draw lines in the sand here, but the whole
"monetary investment in IF" argument came up, and to address that I argued
that a 486 motherboard, in particular, is not what I'd consider a steep
investment *relative to the investments one must make in other arts*.
I *don't care* what systems authors require for their games. I worry about
the sentiment that ten-year-old hardware *must* be supported, otherwise
something's wrong, "because after all, these are only all-text games." I
believe that notion does limit what authors are willing to try. That is
all.
>Of course! And as you say yourself, this is because it's
>graphics-intensive! There's a limit to how much faking you can do here.
I agree that graphics and sound tend to eat CPU cycles readily. What I
disagree with is the idea that they are the only things that *should*.
I cited a bunch of graphics examples to address your comments about
companies like Origin. You say they're sloppy and lazy. While this may be
true to a certain extent (I'm not a big Origin fan myself), I think it's a
mistake to blame increasing hardware requirements on either of these ills.
Only the very latest hardware can run certain kinds of games. So when
companies write these kinds of games, for the people who want them, they
must require said hardware. Simple. The point is that there are things
you can do with this year's hardware that you couldn't on last year's, even
if you *do* write lots of assembly code. Our game wouldn't run on a Sega
Genesis (the previous generation console hardware) if GOD HIMSELF wrote the
code.
But I also cited Common Lisp, which has nothing to do with graphics. It's
a language and a development system. By C standards, it is dog slow. But
since we have 200Mhz SGI's, that doesn't matter. Common Lisp makes us much
more productive than C. So we depend on our fast SGI's not because our end
product requires one to run, but because our fancy, productivity-enhancing
development system is acceptably fast on them, but wouldn't be on, say, a
286. Or a Pentium, probably.
Of course, we don't write the end product in Common Lisp. But we do write
tools that aren't a part of the game itself, but are essential to
development, in Common Lisp. Which saves us a lot of time.
>Innovation doesn't have to mean more computational resources, ESPECIALLY
>in IF. It can simply mean an original story and a better game.
You're right, it doesn't *have* to. But *may* it? If so, then mandatory
support for n-MIPS machines (you fill in the n) is a bad policy.
>>It is your choice to support or ignore companies that assume state of the
>>art hardware. But there are people who *want* the latest thing and are
>>willing to pay for it
>
>This is the Origin attitude in a nutshell.
Right, but you seem to think the attitude sucks, and I still don't really
understand *why*.
>>Bringing this back to all-text IF, I see the potential for tools that
>>vastly improve IF programmers' productivity. I see IF going in radically
>>new directions --- very little has changed since Adventure, really.
>
>I agree with both statements here. Neither event requires better
>hardware.
Can I not convince you that even if GOD HIMSELF is your programmer, your
machine is not capable of running every programming language and
environment we could ever conceive of, some of which might make us more
productive IF authors?
>"Artist as Mother Theresa." I'm not buying it. If that's your motive, I
>suspect you're more or less alone among artists.
How do you know what motivated Kafka? What about Robert Johnson? Was he
writing blues tunes to make money, so the world would remember him, or just
because *that was what he did?* And what about Thag the cave painter?
>I suspect my theory about "writing to pick up babes" is a lot closer to the
>truth.
There are other writers on Earth besides Kundera...
>Well, okay, you got me here. But then again, I faked as much stuff as I
>could.
Ah, you *think* you did. But in fact you could have simply made your
program a massive table mapping input string and game state number to
output string and new game state number. No explicit code required! This
would run *really damn fast*. But it would be a bit of a memory hog.
>The matchbook was a notable exception.
Yes, well what about "put axe in bucket"? :)
Nobody is perfect, of course, and no programming language prevents you from
making *any* mistakes. But many of the kinds of bugs we get writing in
these somewhat low-level C-like languages would all but disappear if we
used more powerful systems.
I guess I should point out that I'm not trying to diminish what Mike and
Graham have done with their development systems. Together they have
brought IF into a new era --- the age of the amateur IF author who produces
professional-quality IF. The number and quality of IF releases in the past
few years is ample evidence of this.
TADS and Inform are both low-level because they needed to be so when they
were written. (TADS because it was begun five years ago or so, and Inform
because it compiles down into Z-Machine code.)
>Let's start up that old "monkeys can/cannot learn language" argument again!
I was hoping against hope that Nim Chimpsky would finish his adventure game
in time for the contest this year, but --- alas --- he still can't get a
grip on this whole "tree structure" thing...
Dave Baggett
Joe Mason
DM>self-consistent at any given time; you seem to think I'm confused. I get
DM>satisfaction primarily from *creating* works, not from knowing that a
DM>zillion people read them. If I release a work and you read it, I view it
DM>as an act of kindness on my part, not yours. I gain nothing, while you
DM>gain a certain invasion of my private thoughts.
DM>This may seem paradoxical in light of our earlier discussion about what
DM>constitues art --- I argued that an important criterion for a work of art
DM>is that it communicate something. So why wouldn't I care if no one's on
DM>the receiving end of this communication?
DM>Well, I've never been of two minds about it: if a tree falls in the forest,
DM>and no one's there to here it, it certainly does still make a sound. And
DM>likewise, a beautiful thing is no less beautiful if one person sees than if
DM>a million see it.
Well, both literally and figuratively, a tree falling in the forest does
*not* make a sound if noones there to here it. (Oh, god, no! Not this
old debate! Isn't it solved YET?)
You see, "sound" is the way the brain interprets moving air impacting
the eardrum. If a tree falls in the forest, it displaces some air, but
if the air doesn't hit anybody's eardrum and be interpreted by the
brain, *there is no sound*.
Similarly, you can't say that a work which *communicates* something has
done its job just as well whether one person or a million see it.
Obviously, if your aim is to tell people something, you will want them
to see it.
But that's not the same as being beautiful. It all depends on whether
you just want to create something beautiful, or something insightful and
meaningful that everyone really should think about. (I'm not saying one
is better or more "art" then the other - I think they both qualify
equally well.)
Joe
* SLMR 2.1a * This is the Uncertainty Principle.. no, wait - Heisenberg
Andrew C. Plotkin
> I'm with Dave, though: a native PowerMac version of TADS could be a real
> screamer. I have no idea what's involved in doing such a port, but the
> other features you might be looking for--snazzy fonts, formatting,
> whatever--will be trivial.
Other way around, actually. Since there is already a Macintosh port of
TADS, it's trivial to do a native PowerMac version. You can
basically take the 68K source and recompile with a native compiler.
(There are a few new data structure to set up, but it should be about
an hour's work.)
Snazzy formatting takes real programming time. Trust me. :-)
John Wood
>
> --If you believe that there are any reasons not to write an IF game that
> requires hardware more sophisticated than X, please
> complete this sentence: "You shouldn't write such an IF game because:
> A) I only have X, and I want to play your game."
> B) Most people don't have something more sophisticated than X, and you
> probably want your game to reach as many people as possible."
> C) Most people don't have something more sophisticated than X, and it's
> not fair or nice to write a game that they can't play."
> D) IF games right now just aren't complicated enough to justify it."
> E) IF games will never be complicated enough to justify it."
> F) It's just morally wrong, dammit."
> G) None of the above.
Jacob's questions got me to thinking, and then it all just came out onto
the keyboard...
I don't believe that there are any *general* reasons not to write an IF
game requiring more sophisticated hardware, no matter what baseline you
choose. This depends on the author's aims.
If you want to reach a large target audience, you shouldn't write
anything that requires an SGI to run - but if you don't care who sees it,
go ahead and write it for whatever machine you want! If you write it for
SGIs only, I'll never play it - but then, if you write it for Macs only, or
CBM 64's only, I won't get to play it either. *Any* limitation is
justified, so long as you are prepared to deal with the consequences.
I may want to play your game, but you probably don't even know me - I have
no right to force you into doing what you don't want to do. Personally,
doing conversions was one of the aspects of games programming that really
used to wear me down - if I write a game for DOS and somebody insists I
convert it to Windows (or Unix, or ...) I'll probably tell them where to
get off!
It may not be "nice" or "fair" that player X can't play your game - but
it's not your fault, and it's not your responsibility. "Morals" don't
enter in to it. For my last few months as a professional games programmer
I was developing a game on a 33MHz 386, at a time when most of the
potential market had 486s, so I couldn't even play my *own* game at a
decent speed. You can't always cater for people in this sort of
situation. As they say, "Society's to blame!"
So much for my take on IF authorship in general. I've never written any
*real* IF, but I'm going to get some vapourware lined up for the pipeline
Real Soon Now...so here's my personal position:
I intend to use Inform. Being realistic, I don't suppose I'll ever write
anything as large as a Curses or Legend, or need more than a few "dirty
tricks", so this means just about everyone should be able to run it on
some machine. This is only a bonus - but it doesn't involve any extra
work for me, so why not? I *am* vain enough to want my work to be seen,
but it's not my primary goal.
I intend to take my time over it. I'll try not to announce anything too
soon, but if I do and people are waiting, that's tough. On the other foot,
I do care about whether or not people enjoy it - if I ever get as far as a
second work, feedback *will* affect what I do.
Enough for now.
--
John
John Wood
>
> Well, both literally and figuratively, a tree falling in the forest does
> *not* make a sound if noones there to here it. (Oh, god, no! Not this
> old debate! Isn't it solved YET?)
>
> You see, "sound" is the way the brain interprets moving air impacting
> the eardrum. If a tree falls in the forest, it displaces some air, but
> if the air doesn't hit anybody's eardrum and be interpreted by the
> brain, *there is no sound*.
Sorry to quibble, but this seemed wrong to me so I dug out my dictionary
to check. According to Collins, there are 18(!) definitions of sound
(excluding meanings such as "that's sound reasoning" or "sound out the
depths in The Sound").
What do you know? There's your definition, in there at number 3.
Definition number 1 begins:
"a periodic disturbance in the pressure or density of a fluid or
in the elastic strain of a solid..."
So I'm afraid the debate's not over yet...
--
John
Matthew Amster
>Other way around, actually. Since there is already a Macintosh port of
>TADS, it's trivial to do a native PowerMac version. You can
>basically take the 68K source and recompile with a native compiler.
>(There are a few new data structure to set up, but it should be about
>an hour's work.)
I did not know this. Thought it might be similar to moving a 16-bit
DOS app to 32-bit. Often painful.
>Snazzy formatting takes real programming time. Trust me. :-)
Well, depends what we're talking about. I the original poster (whoever it
was...amazing how that happens) was comparing the Mac TADS runtime with
MaxZip. I'm trying to think what it is that MaxZip does that TADS
doesn't. Commands you type are in boldface. I believe room titles are, as
well.
There may be a couple more commands on the menus, which I hope is
not what he meant, as I've never seen the purpose of this (does it take
more time to choose Go|West or type 'w'?). The biggie is that the status
line is a separate window. This annoys the hell out of me, especially
since the status line keeps resizing in many games (for quotes). But I'm
sure it could be done to the TADS runtime.
Really, I guess I'm confused as to what's missing from the TADS runtime
besides a splash of the boldface pen here and there. Original poster,
care to clue me in?
Matthew
Andrew C. Plotkin
> You can't do this with the current TADS runtime. TADS itself does support
> bold type (as you can see in the UNIX ports of the runtime that Dave
> Baggett has done) but not much else, formatting-wise. The Z-machine is
> more flexible. It supports bold, bold italic and italic in addition to
> regular type. Plus you can have that as normal or fixed-width (monospace)
> type, which gives you 8 choices.
I'm going to pick a nit and distinguish between layers of abstraction
here. The Z-machine supports 16 fonts (options of bold, emphasized,
reverse, and fixed-width.) The only requirements are that fixed-width
and reverse be implemented as such.
The interface can deal with that however it wants. MaxZip gives you
most of the options available for Mac fonts. However, it doesn't need
the Z-machine support for that. For example, your input is still bold
(or whatever) in a V3 game, even though the V3 Z-machine doesn't
support fonts.
The point... there is no point. I'm nit-picking.
> Anyway, the reason the Macintosh version of the TADS interpreter won't
> let you see boldface text or whatever is because it doesn't used styled
> TextEdit.
(Secretly, MaxZip doesn't either. I wrote my own styled text engine
for XZip, and just ported it. I don't know if TADS uses TextEdit or
not.)
> As has been noted, MaxZip does a fab job of supporting the Zmachine's
> multiple type styles. It also remembers your type style and size preferences
> between sessions; TADS does not, reverting to Monaco 9 each launch. MaxZip
> also remembers your window size, which TADS also doesn't. (I hacked my
> copy with ResEdit since it was annoying to have a teeny tiny window
> appropriate for Mac Pluses in Monaco 9.) MaxZip has a command history,
> which is a very handy timesaver. And finally, you can set custom text
> colours with MaxZip, though that's not a feature I consider all that
> important myself - black on white is the most readable colour combination
> for my eyes.
And note that I do *not* support the color features of the Z-machine.
I'm not sure how I'd make it compatible with my own color features.
> However this isn't to say that there are things about TADS that I do
> prefer over MaxZip. TADS has some useful commands in the menu bar, which
> I kind of like. TADS keeps the status line in the same window as the
> text, which I prefer to a floating status line (though I acknowledge
> there are times it's useful to have it that way)
I still don't know how to support a unified game window while still
allowing an arbitrarily-resizable story panel. (I get visions of
L-shaped windows. Bleah. And pop-quotes make everything much worse.
Where does the little floating box go when you resize?)
> There are two features that I'd like to see on both interpreters, though.
> First, drag and drop editing and second, zoom boxes on the windows. (MaxZip
> has one, but it doesn't seem to do anything on my copy.
It doesn't do anything. These are both features I want to write.
Someday.
> And, hm, I just
> noticed that MaxZip doesn't revert the cursor to the I-beam when in the
> text window
Fix out tomorrow.
> and that it doesn't support Internet Config's ICeTEe.
You are a funny person.
> Not
> that the latter really matters - I only know of one game with a URL in it
> and it's not even released!) And maybe custom macros would be nice, and
> support for Macintalk speech synthesis so you can entertain your friends
> at unsuccessful parties (though admittedly that might be handy for the
> visually impaired) and the ability to set the filetype for saved textfiles
> from scripts, and speech recognition and maybe some artificial intelligence
> routine that would write my thesis for me so I'd have time to play some
> of the IF contest games, and...)
You remain a funny person. Except for macros. There, I am a silly
person -- the capacity exists; I just never hooked it up. I still
haven't.
Neil K. Guy
: Well, depends what we're talking about. I the original poster (whoever it
: was...amazing how that happens) was comparing the Mac TADS runtime with
: MaxZip. I'm trying to think what it is that MaxZip does that TADS
: doesn't. Commands you type are in boldface. I believe room titles are, as
: well.
You can't do this with the current TADS runtime. TADS itself does support
bold type (as you can see in the UNIX ports of the runtime that Dave
Baggett has done) but not much else, formatting-wise. The Z-machine is
more flexible. It supports bold, bold italic and italic in addition to
regular type. Plus you can have that as normal or fixed-width (monospace)
type, which gives you 8 choices.
Anyway, the reason the Macintosh version of the TADS interpreter won't
let you see boldface text or whatever is because it doesn't used styled
TextEdit. (TextEdit is the built-in Macintosh text-editing system software)
You'd have to rewrite the runtime to support styles. Which isn't massively
hard but isn't trivial either.
: There may be a couple more commands on the menus, which I hope is
: not what he meant, as I've never seen the purpose of this (does it take
: more time to choose Go|West or type 'w'?). The biggie is that the status
: line is a separate window. This annoys the hell out of me, especially
: since the status line keeps resizing in many games (for quotes). But I'm
: sure it could be done to the TADS runtime.
Just a note about the menus - I find them pretty helpful. But that's
because I've added command-key equivalents for the directions on the
compass rose. You just type the command key you want and it'll type in
the command. Useful particularly if you want to move in the same direction
several times, etc. Not hugely significant, but I like it. :)
: Really, I guess I'm confused as to what's missing from the TADS runtime
: besides a splash of the boldface pen here and there. Original poster,
: care to clue me in?
As has been noted, MaxZip does a fab job of supporting the Zmachine's
multiple type styles. It also remembers your type style and size preferences
between sessions; TADS does not, reverting to Monaco 9 each launch. MaxZip
also remembers your window size, which TADS also doesn't. (I hacked my
copy with ResEdit since it was annoying to have a teeny tiny window
appropriate for Mac Pluses in Monaco 9.) MaxZip has a command history,
which is a very handy timesaver. And finally, you can set custom text
colours with MaxZip, though that's not a feature I consider all that
important myself - black on white is the most readable colour combination
for my eyes.
However this isn't to say that there are things about TADS that I do
prefer over MaxZip. TADS has some useful commands in the menu bar, which
I kind of like. TADS keeps the status line in the same window as the
text, which I prefer to a floating status line (though I acknowledge
there are times it's useful to have it that way)
There are two features that I'd like to see on both interpreters, though.
First, drag and drop editing and second, zoom boxes on the windows. (MaxZip
has one, but it doesn't seem to do anything on my copy. And, hm, I just
noticed that MaxZip doesn't revert the cursor to the I-beam when in the
text window, and that it doesn't support Internet Config's ICeTEe. Not
that the latter really matters - I only know of one game with a URL in it
and it's not even released!) And maybe custom macros would be nice, and
support for Macintalk speech synthesis so you can entertain your friends
at unsuccessful parties (though admittedly that might be handy for the
visually impaired) and the ability to set the filetype for saved textfiles
from scripts, and speech recognition and maybe some artificial intelligence
routine that would write my thesis for me so I'd have time to play some
of the IF contest games, and...)
- Neil K.
--
Neil K. Guy * ne...@sfu.ca * te...@tela.bc.ca
49N 16' 123W 7' * Vancouver, BC, Canada
Joe Mason
DMB>What are reasonable hardware requirements for IF?
DMB>f. Don't care, as long as the end product is tangibly superior.
I should qualify this. I think the program should run on the lowest
possible machine it could. Meaning if there is nothing in the game code
that can't run a TRS-80, it should be able to run on a TRS-80. This
means that the interpreter would have to run on that machine too.
However, if a game uses a sophisticated AI that won't run on anything
less then a 386, I see no problem with making that game.
The upshot of all this is that whatever interpreter you're using should
be available on a wide variety of machines, since there are people out
there who are still quite happy with C-64s and don't want to go out and
get anything higher. (I know a couple of them.)
Joe
* SLMR 2.1a * If this were an actual tagline, it would be funny.
Greg Ewing
In article <4808rb$c...@castor.usc.edu>, jwei...@castor.usc.edu (Jacob Solomon Weinstein) writes:
|> 4) I can't generalize about the hardware requirements of IF--it just
|> depends on the game.
I vote for that one.
Greg
Greg Ewing
In article <47k4bg$j...@life.ai.mit.edu>, d...@lf.ai.mit.edu (David Baggett) writes:
|> I certainly agree that Scheme can be small. I don't think it can be as
|> fast as a good implementation of a language like C for most tasks, though.
True, but I don't think it need be any worse than, for
example, the TADS interpreter. So it would be possible
to have a Scheme-based IF system that wasn't any less
efficient than what everyone is using now.
|> Dave Baggett
|> d...@ai.mit.edu
Greg
David Kinder
[more]
: For example, it's not quite clear what I'd need to do to allow
: proportional text; there are all sorts of routines which seem to want
: to be able to move to particular character positions on the screen, or
: want to be able to overwrite characters with spaces. I'm sure it can
: be done, because Bryan Scattergood's ITF ports do it correctly (at
: least most of the time), but it's not obvious to me.
From my recent experience of adding this to an interpreter, it's nowhere
near as difficult as it initially looks. I do it by having two fonts; one
proportional and one fixed width, but both of the same height. All
movement routines are done relative to the size of the fixed width font.
You generally need to replace the interpreter's code for splitting lines
of text, but for things like quotation boxes or status lines, Inform
always makes sure that the "USE_NON_PROP_FONT" bit in the header is set
at the appropriate point. This does mean that the game could mess up the
display, but everthing I've looked at worked fine (except MST3K, and
that's only a slight cosmetic problem).
David
Gareth Rees
> What can an IF game in C do that can't be done with these systems?
John Baker <bak...@ix.netcom.com> wrote:
> Overrun an array boundary, clobber memory and cause a bug that doesn't
> have anything to do with the code near it? :)
Not (quite) true. Inform stores code in "high memory", which cannot be
written to. Most C implementations arrange to store C code in read-only
memory so that the code cannot be accidentally corrupted (although there
are probably some low-end rip-off merchants who sell C compilers that
don't do this).
However, in either C or Inform it is easily to run of the end of an
array and clobber other bits of dynamic data (though C makes it trivial
for you to shoot yourself in the foot by providing the gets function).
Followups to comp.lang.c
--
Gareth Rees
Matt Ackeret
Bruce Stephens <br...@supr.scm.liv.ac.uk> wrote:
>>>>>> "Mathematical" == Mathematical Institute, (01865) 2-73525 <nel...@vax.oxford.ac.uk> writes:
>> The Z-machine can be implemented pretty quickly. I can't, offhand,
>> think of a good way of improving speed by any significant margin,
>> given the compactness of the format. We probably could soup up the
>> text compression rate, but (again) that's probably not going to be
>> needed enough to make it worthwhile.
>
>up by moving some of the information that's packed so carefully into
>separate bytes which can be operated on more quickly. Of course, this
>would probably create larger codes, and so would only be of benefit on
>machines (like the Psion) which couldn't really use it for space
>reasons.
On the interpreter end, there are a couple of things that could
be done to speed it up. (Of course, with freely available source, anyone
can implement these as they choose.)
o) Optionally removing the VM-ish paging. (This was done by
Stefan Jokisch but isn't in the main ZIP distribution.) This of course helps
speed things up on machines with 24 or 32 bit addressing and enough memory to
hold the whole datafile in memory at once. Optionally (at compile time)
since it's obviously preferable to leave it in for those that want it
(willing to trade time for RAM usage) or need it.
o) Changing the main interpret() loop to being a function-pointer
based dispatch, which definitely is constant speed no matter which
Z-machine instruction you're emulating.
There are probably many others, but these are the most obvious that
can be done while still maintaining portable C code.
Matthew Amster
writes:
>David Leary (dle...@trout.ab.umd.edu) wrote:
>: You didn't happen to see Nature a couple of weeks ago, did you? They had
>: a chimp on that understood commands such as "put the apple in the
>: refrigerator" and "take the vacuum outside." That's about as
>: sophisticated as any IF parser has gotten...
>
>But he takes 2 to 3 seconds to think about it because he's considering
>every vacuum he's ever seen, not just the ones in the room.
Oh my, that was a good one! I'm tempted to say he also hit himself on the head
due to some unintended game-state changes in a verDoXXX method, but now that I
think about it, that wouldn't be very funny at all.
Matthew
the ideal copy
writes:
> I certainly agree that Scheme can be small. I don't think it can be as
> fast as a good implementation of a language like C for most tasks, though.
On the other hand, it'd be a lot faster to write adventures in than C.
And any run-time speed penalty over raw C would be insignificant for this
particular application.
Almost everything you deal with in an adventure is a list of some sort.
Lists of properties of an object, inventory lists, lists of exits, lists
of objects visible... so whatever language you choose should definitely
have lists as first class data types.
Mind you, I wrote my first adventure in BASIC, and my second in 6502
assembler, though I never finished that one...
I'd certainly like to see a Scheme-based adventure programming system. A
good Scheme compiler for UNIX, Mac and PC would be a good start; then
build the rest as libraries.
I've tried many Scheme systems. MacGambit, SCM, Scheme48, scsh... I
can't find anything that'll run on my Mac at home *and* UNIX and Windows.
If I try and stick to what all the interpreters support, I find myself
missing useful features like time and date functions...
mathew
--
Checking whether HTML is correct by looking at it with a browser is like checking whether C code is correct by looking at it with a text editor.
http://www.domino.org/~meta/
Alexander Williams
In an arcane scroll, Alexander Williams quotes the holy scripturist
Greg Ewing, replying to the mystic words as written, saying:
>|> I certainly agree that Scheme can be small. I don't think it can be as
>|> fast as a good implementation of a language like C for most tasks, though.
Actually, for tasks heavy in symbolic manipulation which allocate
and deallocate objects with some steady parameters, Scheme can be
/faster/, on the whole, than C, especially once development time is
taken into consideration. IF, at heart, is not much /more/ than
symbolic manipulation, so things start looking really happy once you
consider using it for IF.
>True, but I don't think it need be any worse than, for
>example, the TADS interpreter. So it would be possible
>to have a Scheme-based IF system that wasn't any less
>efficient than what everyone is using now.
It seems to me that J Random Scheme (maybe Scheme48) should be
able to have the YASOS Scheme object-system plugged onto the front
of it and the appropriate inheritable-objects created (starting with
the hierarchial `thing' with the global code and traits, frfom which
`room' and `object' are inherited and add on their especial natures,
and so on). With closures, it should be easy to add on behaviours,
even without access to internals (though you could modify the source
library as well).
I suppose the real question is how would you distribute the
runnable file? Written Scheme-generic enough, you could develop
under Scheme48 or whichever your prefered platform is and then run
it through Bigloo or Scheme->C to create a native code binary (or
just leave it as C source). Of course, my experiments with Bigloo
suggest that it will create a minimum 400k executable for anything
that does more than one or two things, so ...
[It occurs to me that writing a native-code version of the S48
virtual machine shouldn't be too hard; in fact, most of the work's
done in S48 already to run at all. Just migrate the VM emulator
from platform to platform and you can use the very same
virtual-image dump on every platform for your game.]
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i
Comment: Auto-signed with Bryce's Auto-PGP v1.0beta3
iQCVAwUBMKiNPF6rnc26j4NHAQFS/wQAo98YxcGUsmR8yucc+80k06UEMI9AbZYN
8778NfqvRd1xfHs2fY4t4rHshRIRjodsk6pxWSyhhzOQrRumQ7GzSqtIsDxQM4lZ
vCy082cMarqJ3OQWZFQ/pAKy5ux/VqAIBkWHF7E6MkYeGQQQbY4fxqWUo6tqqkQH
mi2ER5ULdho=
=+Ax6
-----END PGP SIGNATURE-----
--
= 2.6 key avail: DF 22 16 CE CA 7F 98 47 13 EE 8E EC 9C 2D 9B 9B =
=== <a href="http://photobooks.com/~zander/">Home Page</a> ===
=``Two Shiva-class Battleships flying ground-support missions ?!?''=
====================================================================
Jeff Standish
Greg Ewing <gr...@cosc.canterbury.ac.nz> wrote:
>True, but I don't think it need be any worse than, for
>example, the TADS interpreter. So it would be possible
>to have a Scheme-based IF system that wasn't any less
>efficient than what everyone is using now.
>
Actually, I have implemented something like this. GINAS is an
interpreted IF language, with everything being writing in interpreted
LISP (LISP, Scheme... they're bother pretty much the same as the way
I use them). It even has class system for object definition, which
allows for multiple inheritance of properties and methods for objects.
I've implemented most of Adventure, converting it from the Inform
code that someone wrote up (I forget who at the moment). Unfortunately,
I can't comment upon the speed efficiency of the system. I've only run
it on SPARC workstations of various sizes, where it runs very fast. The
slowest part of it is reading in the game code, which is written in LISP
style code, and for Adventure, it only takes a couple of seconds. I've
never been able to get the system to compile and run correctly on a PC,
since as a LISP system it requires a huge heap, and I don't have access
to a PC compiler with the brains to allocate more than a 64K heap (which
means it crashes on anything larger than a toy system).
So I don't really know how well a LISP-style system would run on a PC,
but since I've been told that a 486 box is roughly comparable to most
SPARCs, I would hazard a guess that from the performance of my personal
system, that LISP/Scheme systems for IF would not have any real
performance problems.
Anyone really interested in checking out GINAS is more than welcome to
do so. There is a link to it from my homepage (the address is in my .sig).
I considered uploading it to the if-archive at gmd several months ago,
since the interpreter itself is pretty much in a final state. However,
the defaults file is about two-thirds of the way through a significant
revision, and I've yet to find the time to finish it, and without a
defaults file, doing IF becomes much more difficult, since you end up
reinventing the wheel time and again. But anyone interested is welcome
to have a peek and make comments upon it.
--
----------------------------------------------------------------------------
Jeff Standish The concept is simply
jest...@cs.indiana.edu staggering. Pointless,
http://www.cs.indiana.edu/hyplan/jestandi.html but staggering. -Dr. Who
----------------------------------------------------------------------------
Greg Ewing
In article <4875ps$4...@news.ox.ac.uk>, kin...@teaching.physics.ox.ac.uk (David Kinder) writes:
|> Bruce Stephens (br...@supr.scm.liv.ac.uk) wrote:
|>
|> : there are all sorts of routines which seem to want
|> : to be able to move to particular character positions on the screen, or
|> : want to be able to overwrite characters with spaces.
But these things should only be happening in the status
window, because that's the only place where it's legal
to move the cursor. So use a completely fixed font in
the status window, and proportional fonts in the main
window.
That's what I did in ZeX, and it seems to work, even
in games which use quote boxes and such weird things.
Greg
Greg Ewing
In article <meta-14119...@mcgyorgy.cam.harlequin.co.uk>, me...@harlequin.co.uk (the ideal copy) writes:
|> I've tried many Scheme systems. MacGambit, SCM, Scheme48, scsh... I
|> can't find anything that'll run on my Mac at home *and* UNIX and Windows.
Maybe it's time for someone to write a really small, simple
easily-ported Scheme interpreter for this purpose?
I once looked into trying to get Elk going on a Mac, but
it has too many Unix-dependencies entwined into it.
Perhaps I'll write one myself, and show everyone what
a really minimal Scheme system should be like!
|> mathew
Greg
Vassili Bykov
>
>In article <meta-14119...@mcgyorgy.cam.harlequin.co.uk>, me...@harlequin.co.uk (the ideal copy) writes:
>
>|> I've tried many Scheme systems. MacGambit, SCM, Scheme48, scsh... I
>|> can't find anything that'll run on my Mac at home *and* UNIX and Windows.
>
>Maybe it's time for someone to write a really small, simple
>easily-ported Scheme interpreter for this purpose?
IMHO, the Scheme implementation you (as well as some other posters on this
thread) are talking about--or at least something rather close to it,
already exists. Have you looked at David Betz's XScheme 0.28?
Language-wise, it is reasonably complete. Reasonably means you don't get
some optional language features right out of the box, but you do get
low-level macro facitility which is enough to use syntax extender
(Kohlbecker's hygienic macros).
According to the docs, XScheme 0.28 is supposed to be portable across DOS,
Unix, Mac, Amiga, and Atari ST. Supposed--because the standard 0.28
distribution includes only DOS makefile and OS interface primitives. I
have no idea why and where the rest got lost, but it took me just about an
hour to make it run under Linux by adapting interface code from an earlier
release. Even if the OS-specific code for other platforms is lost forever,
it is much easier to recreate it (not a lot to recreate, just some
character i/o and time functions) than to write something new from scratch.
Unix statically-linked executable produced by gcc is 102K. DOS .exe
produced by Borland C++ 3.1 is 128K. Probably for today's computers
this can be considered very small.
It is fast, too--about twice as fast as MIT Scheme, though I don't know how
does it scale. It compiles into bytecodes and executes the bytecodes,
which also gives a small resulting image.
Speaking of image, that is of distribution. It supports dumping memory
image in a file and loading a saved image on startup. That is, the image
can be distributed as the game file, and xscheme itself as the
interpreter--probably even reduced version of it, since not everything
included in the complete system is needed to execute the saved image.
Again, Dave Bagget's point was not in making as small Scheme as possible.
It was about taking a reasonably small and portable Scheme and turning it
into an IF tool of a higher level than the existing ones. Higher--not in
the sense that you don't have to program, or course, but in the sense that
your game objects and NPCs can be given more depth and intellect with about
the same amount of code.
This can and probably will sacrifice performance but it is not that
important. Infocom games ran on interpreters hosted by Apple ][ and
TRS-80. Today's average computer performance and memory must be almost
three orders of magnitude higher. Wouldn't it be nice to use it to get
some more life in the games rather than to just shorten response time?
--
Vassili
P.S. Anyone interested in Unix port of XScheme or anything else mentioned
Neil K. Guy
: (Secretly, MaxZip doesn't either. I wrote my own styled text engine
: for XZip, and just ported it. I don't know if TADS uses TextEdit or
: not.)
TADS does. I noticed because...
: > And, hm, I just
: > noticed that MaxZip doesn't revert the cursor to the I-beam when in the
: > text window
: Fix out tomorrow.
Cool!
: > and that it doesn't support Internet Config's ICeTEe.
: You are a funny person.
Well, as a follow-up to my previous comment about TextEdit, that's simply
the quickest way to tell if an application uses TextEdit or not - command-
click some text if you have ICeTEe installed. TADS lets me open an
embedded URL; MaxZip does not. Not that I care; I was just curious to see
if you'd assembled your own text engine, as you appear to have done. :) Of
course, this isn't a foolproof method, as an application with a custom
text engine can support ICeTEe, like BBEdit does, but I thought it rather
improbable that MaxZip would...
: You remain a funny person. [...]
Hm. I haven't figured out if this is an insult or a compliment. :)
Jacob Solomon Weinstein
As you may remember, Dave Bagget recently said something to the effect
of, "There's wide-spread philosophical opposition to IF games that
require lots of computing power." (I'm paraphrasing badly--my apologies
to Dave.) To see if this was true, I offered to do an informal survey of
r.a.if readers. I posted a survey, and received 9 responses.
The executive summary is that, while it's hardly a scientific survey,
nobody expressed any philosphical objection to IF games that require
heavy hardware. 4 people had suggestions for what would be appropriate
hardware requirements, but 3 of them made it clear that their suggestions
were just rough guidelines, and that it really depended on the game.
What follows are the questions I asked and the results:
What level of computer power, if any, is appropriate for an IF game?
*5 people indicated that it depended on the game, and no one level was
appropriate.
*3 people said indicated that it depended on the game, and that no one
level was appropriate, but nonetheless stated what sort of computer they
thought was a reasonable demand for most of today's IF games.
One of these three suggested "a machine no more than (say) 5
years
old. Or a PDA or equivalent."
One suggested "an average, affordable PC--something like
386/low-end
486."
One suggested a 286.
*1 person said that he only plays inform games, although "anybody, in my
opinion, can write IF games for any minimal system they choose.
________
The second question asked, "When is it OK for an IF game to require more
than X, where X is your answer to the first question?"
*7 people answered, "I can't generalize about the hardware requirements
of IF--it just depends on the game."
*2 people answered, "I've never seen an IF game that requires hardware
more sophisticated than X, but it could happen."
(note that only 8 people indicated responses to this question, but one
person gave two responses.)
___________
The last question asked people to complete the following sentence: "IF
games shouldn't require more than X because..."
Since most people had indicated that there was no hard and fast rule
about how much computing power an IF game should require, few answered
this question. Of the 3 who did answer:
*2 said, "IF games right now just aren't complicated enough to justify
it." (One of the two said that he doesn't believe there's a limit on what
an IF game should require--but if he did, this would be the reason he would.)
*1 said, "There are people out there who are still quite happy with C-64s
and don't want to go out and get anything higher. (I know a couple of
them.)"
_____________
Thanks to everybody who responded. As I said, it's hardly a scientific
survey--but it does seem to indicate that people have an open mind about
hardware requirements for IF.
Matt Ackeret
Bruce Stephens <br...@liverpool.ac.uk> wrote:
>>>>>> "Matt" == Matt Ackeret <mat...@eskimo.com> writes:
>> o) Optionally removing the VM-ish paging. (This was done by
>> Stefan Jokisch but isn't in the main ZIP distribution.) This of
>> course helps speed things up on machines with 24 or 32 bit
>> addressing and enough memory to hold the whole datafile in memory at
>> once. Optionally (at compile time) since it's obviously preferable
>> to leave it in for those that want it (willing to trade time for RAM
>> usage) or need it.
>most machines, 256K or so is nothing.
Yes, remember, these games still play on machines with 64K of
memory. (Maybe less, but 8 bit Apple IIs, Commodore 64s, etc., is what I'm
thinking of..)
>For the Psion Series 3a, however, it's a large amount of memory, and I
>imagine there are other small machines still out there, so I'd like to
>keep it as an option. On this particular machine, it probably doesn't
Yes, that's what I said above. It definitely should remain an
option, but be optional (at compile time), since machines with more memory
don't need it, and there are many machines out there (including mine)
where the increased memory usage -> game speedup tradeoff is well worth it.