Hugo vs. TADS/Inform
Sandsquish
card...@earthlink.net (Cardinal Teulbachs) wrote:
>if anyone has any questions about Hugo, or any
>challenges to my claims, or if anyone would simply like to punch me in
>the face for daring to suggest that Hugo needn't scrape the floor like
>some dishonoured supplicant, reply here please.
I'm not responding to this to bash Hugo. As far as I'm able to tell,
it is a perfectly competent development system for text adventures.
But, it disappointed me.
>[Hugo is] As powerful as either Inform
>or TADS (perhaps more)
Even though I have a Mac, and Hugo isn't available for Macs, I
was able to get a copy of it (version 2.1) running on my DOS emulator.
One of the first things I noticed was that Hugo couldn't handle
commands where the indirect object is given before the direct object,
like "GIVE GRADY THE GUN," and I couldn't make it understand
statements like that through Hugo's "verb" construct.
I also noticed that Hugo, unlike Inform or ALan, doesn't know how to
deal with commands that have three or more "noun phrases," like
the example in that AGT thread, "PRY THE CHIP OUT OF THE MOTHER
BOARD WITH THE SCREWDRIVER."
Perhaps these things have been fixed in the latest version of Hugo, but
I didn't see any mention of them in Hugo's "new release" announcements.
>Hugo represents in many
>ways an advance on those languages [TADS and Inform]
In what way? (This is a sincere question. I'm curious, because I really
couldn't find anything that would lead me to believe Hugo was any
more sophisticated than TADS or Inform.) If you're talking about
the scripting feature, both ALan and TADS: Worldclass have that.
>Hugo is also (relatively, of course) easy to use.
Mr. Tessman does advertise Hugo this way. I have very, very little
programming experience, and so, after about a month and a half of
frustration with Inform and TADS, I gave Hugo a try.
Hugo looked like Inform to me, with just a dash of TADS tossed in
for flavoring. I didn't think it was any easier to use than either of
those systems. Actually, I got much farther with Inform than Hugo.
>[Hugo] deserves
>better than the complete silent treatment it receives in this
>newsgroup.
I've only been lurking around here for about a year or so, but as far
as I can tell, Hugo hasn't been around for much longer than I have.
ALan, on the other hand, has been around for quite awhile. The first
version was written in the '80s and I've found source code that was
written four years ago.
Hugo is mentioned quite a bit more often than ALan is. I think it just
takes time for a system to catch on, and sometimes a system never will
become popular, often through no fault of its own.
In short, Hugo isn't the victim of some sort of snobbish conspiracy. It
just isn't popular.
>there *is* another choice, and I'm not talking
>about AGT or Alan, either
Why not? Although AGT fights flare up around here on a seasonal
basis, and people do mention ALan as a good choice for beginners
(and as someone without much programming experience, I can assure
you that it IS a much better choice than Hugo) both AGT and ALan
garner fewer (constuctive) posts than Hugo. You seem to be a little
sensitive about using an unpopular language, so I'm surprised you
wouldn't show a little more compassion for the rest of us that use
one of those "other" languages.
Walt,
(Sands...@aol.com)
Cardinal Teulbachs
Why is it when a visitor here
Asks the experts to opine,
It's "TADS and Inform," "Inform/TADS" and
Never a movement from that line?
-- Song from A Never-Ending Story
Why, indeed? Is it because TADS and Inform are prima facie the best
authoring systems available? I think not. I've been at this business
in a serious way for a few years now, and I do not think either TADS
or Inform are necessarily the best choice in a text-adventure system.
This is not to say that either of them are bad systems--far from
it--but merely that there *is* another choice, and I'm not talking
about AGT or Alan, either. There is Hugo. As powerful as either Inform
or TADS (perhaps more) and simpler to use, Hugo represents in many
ways an advance on those languages and for that reason alone deserves
better than the complete silent treatment it receives in this
newsgroup. Thus, I would like to say a few words in defense of Hugo
and (hopefully) initiate a polite discussion among knowledgeable i-f
programmers about its relative merits and demerits as an authoring
system.
Hugo is an object-oriented language. As such, it is very powerful and
ideally suited to i-f programming. Moreover, it is mature and
seemingly well-thought-out. Hugo is neither some hack thrown together
by a know-nothing, nor an Inform wannabe playing catch-up. It's a
contender in its own right.
Hugo is also (relatively, of course) easy to use. While one must
certainly know how to program, there is a minimum of bother about
punctuation and the like and, once one understands how the system
works, much greater accessibility in the library.
Hugo does Infocom. For all those who worship at the altar of Infocom,
it may be surprising to learn that Inform is not the only system that
yields an "Infocom look and feel" (not to mention Infocom
sophistication) game. Hugo can look and act like an Infocom game or
not; that's up to the programmer.
Hugo has a really cool name. It stands for "Heuristic Underground
Object-Orientation". It was originally abbreviated Hugoo, but that
sounded too much like Mr. Magoo, so the name was shortened to Hugo
(which sounds very masculine and strong, like a hurricane). Of course,
this is bullshit, too, and I'm making it up as I type. I really have
no idea what Hugo stands for.
Anyway, I'll stop there, as the bulk of the plaudits for TADS seem to
be in the "power" and "sophistication" departments, while the bulk for
Inform are in the "power", "sophistication", and "Infocom-like"
categories. I've alluded to all of these briefly as they relate to
Hugo. In closing, then, if anyone has any questions about Hugo, or any
challenges to my claims, or if anyone would simply like to punch me in
the face for daring to suggest that Hugo needn't scrape the floor like
some dishonoured supplicant, reply here please.
--Cardinal T
I mean, what the hell kind of villain thwarts the hero's
progress with soup cans in the kitchen pantry?
--Russ Bryan
Cardinal, I follow up your post in the hopes that some
day I too will be quoted in your sig.
--Matthew Amster-Burton
Hey! This isn't what I said! What'd you do with my
quote?
--Bonni Mierzejewska
Gord Jeoffroy
card...@earthlink.net (Cardinal Teulbachs) wrote:
>In closing, then, if anyone has any questions about Hugo, or any
>challenges to my claims, or if anyone would simply like to punch me in
>the face for daring to suggest that Hugo needn't scrape the floor like
>some dishonoured supplicant, reply here please.
I looked at all three systems when I decided to try my hand at IF
programming, and I have to admit it was Hugo that looked the most
appealing to my needs and style. But Inform has a strong base: there
are lots of code samples to glean from and lots of seasoned brains to
pick. Hugo, I think, is still too new to score points in these
categories.
However, I'm open minded. And if Hugo has some amazing capabilities
that are less easy or impossible to implement in Inform, I'd certainly
be interested in hearing about them.
For example, can Hugo handle dynamic object creation, or does every
coin and dust mote have to be anticipated by the programmer, as with
Inform?
--Gord
Andrew Plotkin
Cardinal Teulbachs (card...@earthlink.net) wrote:
> Why, indeed? Is it because TADS and Inform are prima facie the best
> authoring systems available? I think not. I've been at this business
> in a serious way for a few years now, and I do not think either TADS
> or Inform are necessarily the best choice in a text-adventure system.
> This is not to say that either of them are bad systems--far from
> it--but merely that there *is* another choice, and I'm not talking
> about AGT or Alan, either. There is Hugo.
Boost though you may, Hugo is under-represented because it's newer. That's
the long and short of it. And what you're doing is exactly the right
response (along with writing more Hugo games, which I assume you're doing
also.)
> As powerful as either Inform
> or TADS (perhaps more)
Ok, here's my one cent. I downloaded the Hugo source to see if I could do
a half-hour Mac port. (I couldn't -- no surprise -- no programming
project takes half an hour on the Mac.) But when I was looking through
the source, I noted that the parser resides in the Hugo run-time, not the
game file.
This gets right to the basic claim of the Inform boosters (like me :-),
which is that the Z-machine has an order of magnitude less hard-wiring
than any other portable IF format. (And I'm not just talking about Tetris.
Note the post, earlier in this thread, which mentions three-noun verb
constructs. Note the fact that even though the standard Inform library
doesn't support real adjectives, there's source code to put them in.
Ditto for daemons that execute in a specified order each turn.)
On a related note, how hard would it be to get the Hugo compiler to
generate Z-machine files instead of Hugo runtime files?
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Cardinal Teulbachs
sands...@aol.com (Sandsquish) wrote:
>But, it disappointed me.
Fair enough. Certain things about Hugo disappointed me too, at first,
until I figured out that the things that disappointed me weren't, for
the most part, written in stone. I could make it work the way I wanted
it to work, which is really the bottom line for me. I want a certain
product from my work and I can get it with Hugo. With the more
iron-fisted systems, I often couldn't (or couldn't at a reasonable
price, anyway).
>>[Hugo is] As powerful as either Inform
>>or TADS (perhaps more)
>Even though I have a Mac, and Hugo isn't available for Macs, I
>was able to get a copy of it (version 2.1) running on my DOS emulator.
>One of the first things I noticed was that Hugo couldn't handle
>commands where the indirect object is given before the direct object,
>like "GIVE GRADY THE GUN," and I couldn't make it understand
>statements like that through Hugo's "verb" construct.
>I also noticed that Hugo, unlike Inform or ALan, doesn't know how to
>deal with commands that have three or more "noun phrases," like
>the example in that AGT thread, "PRY THE CHIP OUT OF THE MOTHER
>BOARD WITH THE SCREWDRIVER."
The first example can be done, but you're right about the second one.
In Hugo you're limited to one direct object and one indirect object
per command line (I'm pretty sure; I've never actually tried using
more than that). It might be possible, though, for the user to write a
parsing routine to allow for the extra noun phrase. This will not be,
of course, particularly wonderful news to anyone who doesn't want to
do that work, though, so mark yourself a point for the criticism.
>>Hugo represents in many
>>ways an advance on those languages [TADS and Inform]
>In what way? (This is a sincere question. I'm curious, because I really
>couldn't find anything that would lead me to believe Hugo was any
>more sophisticated than TADS or Inform.) If you're talking about
>the scripting feature, both ALan and TADS: Worldclass have that.
No, I'm not talking about the scripting. In fact, I'm not really clear
about what I *am* talking about. It occurred to me after I hit the
"send" button on my post that I wouldn't be able to defend this
statement in any very articulate way, but by then it was too late. I
think I may have been mixing up the fact that I happen to prefer Hugo
(after using the others) with the notion of technical advancement, as
if my preferences were the measure of advancement. They're not, so I
hereby retract this little bit of stupidity.
>>Hugo is also (relatively, of course) easy to use.
>Mr. Tessman does advertise Hugo this way. I have very, very little
>programming experience, and so, after about a month and a half of
>frustration with Inform and TADS, I gave Hugo a try.
>Hugo looked like Inform to me, with just a dash of TADS tossed in
>for flavoring. I didn't think it was any easier to use than either of
>those systems. Actually, I got much farther with Inform than Hugo.
I began with TADS (a short run, mostly educational--I was too cheap to
shell out for the full package), and then switched to Inform. I used
Inform quite a lot and got good enough with it to to do some fairly
complicated programming tricks. This took far longer than a month and
a half, though, I assure you--not through any fault of Inform's, mind
you, but because it takes time to really get to know a language/system
and to learn its ins and outs. Then I found Hugo and I was won over by
the relative simplicity (notice, I said "relative"; there's no getting
around the fact that it's a programming language) of its syntax and
the accessibility of its library. With Inform, if I ran up against
something I didn't understand fully, I was often left scratching my
head since I was half-unable and half-unwilling to try to decipher the
library--by which I mostly mean parse.h). With Hugo, if I run into a
problem, I can usually hack my way to success.
I have to say, though, that if you're looking for a system that you
can learn in one-and-a-half-months with little or no previous
programming experience and then churn out complicated, sophisticated
games with no effort, I think you're looking in vain. Let's suppose
that a language like you're talking about existed. What would it be?
It would be a very lengthy and complex system of routines which the
user could call instead of having to code everything in the
lower-level, symbolic way. Many might prefer this method, but I would
argue that there comes a point when the difficulty in sorting out and
understanding how all those routines work together with respect to the
whole, and in understanding what they can do and what they can't do
and why--the difficulty becomes as great or greater then the
difficulty involved in simply being able to write them for oneself as
the need arises.
>>[Hugo] deserves
>>better than the complete silent treatment it receives in this
>>newsgroup.
>I've only been lurking around here for about a year or so, but as far
>as I can tell, Hugo hasn't been around for much longer than I have.
>ALan, on the other hand, has been around for quite awhile. The first
>version was written in the '80s and I've found source code that was
>written four years ago.
>Hugo is mentioned quite a bit more often than ALan is. I think it just
>takes time for a system to catch on, and sometimes a system never will
>become popular, often through no fault of its own.
My complaint isn't that there aren't enough people jabbering about
Hugo. It's that when someone pops up here asking what authoring
systems they ought to take a look at, the common mantra is "TADS and
Inform." Now, I have no problem with this if the people chanting the
mantra have an honest, informed (ha ha) opinion about it. But I feel
that many don't. They're simply aping what they themselves have been
told or what they see the mob saying. No, I can't prove this, and no,
I don't know for a fact that everyone here hasn't tried and compared
all the available languages to come up with a reasoned opinion on the
subject. Yet I have to tell you I'd find it hard to believe they have.
>In short, Hugo isn't the victim of some sort of snobbish conspiracy. It
>just isn't popular.
Yes, I realize there's no conspiracy. But at the same time, I have to
wonder why Hugo isn't popular. Is it because Hugo is a piece of crap?
If so, where are the posts warning people to steer clear of it? In
fact, where are the posts asking how to accomplish this or that task
in Hugo, since it is never immediately clear what is a bug and what is
simply a lack of understanding on the user's part? The answer, or so
it seems to me, is that the posts aren't here because few people are
moved to ever even take a look at Hugo, much less put out the effort
to learn enough of how it works to decide whether it appeals to them
or not.
>>there *is* another choice, and I'm not talking
>>about AGT or Alan, either
>Why not?
Because I'm talking about Hugo :).
>Although AGT fights flare up around here on a seasonal
>basis, and people do mention ALan as a good choice for beginners
>(and as someone without much programming experience, I can assure
>you that it IS a much better choice than Hugo) both AGT and ALan
>garner fewer (constuctive) posts than Hugo. You seem to be a little
>sensitive about using an unpopular language, so I'm surprised you
>wouldn't show a little more compassion for the rest of us that use
>one of those "other" languages.
Sorry. Didn't mean to slight AGT and Alan. I'm glad to see them being
recommended to potential users, actually. Anything that smacks less of
the party line than what we've been accustomed to around here is a
victory, as far as I'm concerned. Don't misunderstand, though. I don't
mean to badmouth Inform or TADS, either. Their good reputations are
deserved. I'm simply arguing for a little less, well, idol-worship
among the converts (where "idol" is meant here not in a negative
sense).
As for my sensitivity about using an unpopular language, that's not
really the case at all. I use Hugo by choice, and I know that if I
ever turn out a game that's worth a damn, the system I use won't be an
issue for players. It's not as if I'm some resentful prisoner, after
all, slaving away in the dark, smelly Hugo cave while my more
fortunate peers bask in the sun of TADS and Inform. I could go back to
Inform or TADS tomorrow if I chose to...and that's the point. I choose
not to, and even if I can't quite put my finger on every reason why, I
have to wonder why there isn't at least one other person in the world
who has something even mildly positive to say about Hugo. Am I just an
idiot? Wait, don't answer that...:)
Andrew Clover
erky...@netcom.com (Andrew Plotkin) wrote:
> Boost though you may, Hugo is under-represented because it's newer.
> That's the long and short of it.
The two reasons I don't use it are derived from this:
1. The Acorn port is a bog-standard command-line C port, rather than
something as smart as Zip 2000.
2. I've already learned Inform. I'm loathe to learn another similar
adventure language: I don't have the time, and I already have trouble
trying to keep track of which syntax I have to use for C, Inform, ML,
Perl, Pascal...
This is, I suspect, the case for a lot of others here, and their adherence
to Inform or TADS can only give beginners to start with these languages. To
break out of this vicious circle, Hugo needs to offer something radically
better than either, more than just a slightly more elegant grammar.
(I haven't actually checked Hugo's grammar, but presumably it *is* more
elegant than Inform. ;-) )
The common areas of complaint in Inform and TADS that might reasonably be
improved on are disambiguation and conversation, both big and hard projects.
If Hugo can make great advances in these areas it may gain more popularity;
otherwise it is probably destined to be but an also-ran in the adventure
system stakes, regardless of its relative quality.
BCNU, AjC
Sandsquish
card...@earthlink.net (Cardinal Teulbachs) wrote:
>
>>sands...@aol.com (Sandsquish) wrote:
>>
>>But, it disappointed me.
>
>Fair enough.
See? We CAN discuss programming languages without getting
into fights! :-)
>I have to say, though, that if you're looking for a system that you
>can learn in one-and-a-half-months with little or no previous
>programming experience and then churn out complicated, sophisticated
>games with no effort, I think you're looking in vain.
I'm not sure what you mean by complicated games, but I did find
a language that satisfied my needs. I'm under no illusions that I
will be able to push the "technological envelope" with the language
I chose (ALan). I won't be able to create real-time puzzles, like
those in "Border Zone," and I won't be able to hack my way to a
"conversational" parser, like "Shogun's."
All I was looking for was a system that could produce games that
had the same sort of feel that the better retail text games, like
Infocom's, Legend's, and Magnetic Scroll's, had, and that I could use
without having to go back to school and get a programming degree.
>Let's suppose
>that a language like you're talking about existed. What would it be?
>It would be a very lengthy and complex system of routines which the
>user could call instead of having to code everything in the
>lower-level, symbolic way.
I think most experienced programmers don't understand what non-
programmers are talking about when we say that a language is
cryptic or difficult to use. It doesn't have anything to do with whether
or not we will have to expend some effort in coding. (And ALan, not
to steal your thunder here, does not have a complex system of
routines you have to figure out, and yes, you do have to do coding.)
What we, or at least what I, mean is something that looks more like
some obscure dialect of calculus, instead of English.
I am not going to argue that the systems that use an English-like syntax
are as flexable as those that use the the more standard progamming-
language syntax. For some reason, the more cryptic systems do seem
to be more flexable. I also have no desire to see experienced programmers
use the more English-like systems (unless they just like higher-level
languages). I'm sure they would be much happier using the "shorthand"
they are comfortable with.
All I was really trying to say was that I don't think it's a good idea to
advertise Hugo as a "simple" language. Hugo, like Inform and TADS, is
based on C, a language that most programmers will concede is somewhat
cryptic. Telling novice programmers that this is a good language to start
with will probably frustrate them to the degree that they will, most
likely, give up on writing IF and not get around to trying out the systems
that novices can make sense of.
>Didn't mean to slight AGT and Alan [and] I don't mean to badmouth
>Inform or TADS
And I am not trying to badmouth Hugo, like I said, it looks like a
perfectly
competent system to me. It just didn't match my background or needs.
Walt,
(Sands...@aol.com)
Nulldogma
Andrew sort of already said this, but it's worth repeating: Regardless of
their power or ease-of-use, Hugo and Alan will only start being mentioned
in the same breath as TADS and Inform when 1) they've been ported to as
many platforms; and 2) they've had more games written in them. (And *good*
games -- look at what sloppy authorship has done to AGT's rep.)
From the sound of it, people are working on (2). As for (1) ... I hear
tell there's this kingdom available in exchange for a Mac Hugo....
Neil
---------------------------------------------------------
Neil deMause ne...@echonyc.com
http://www.echonyc.com/~wham/neild.html
---------------------------------------------------------
Cardinal Teulbachs
crs...@inforamp.net (Gord Jeoffroy) wrote:
>I looked at all three systems when I decided to try my hand at IF
>programming, and I have to admit it was Hugo that looked the most
>appealing to my needs and style.
That's good enough for me. You evidently gave it a fair look, whether
you ultimately decided to go with it or not.
>But Inform has a strong base: there
>are lots of code samples to glean from and lots of seasoned brains to
>pick. Hugo, I think, is still too new to score points in these
>categories.
Yep. I think you're absolutely right about all of this.
>However, I'm open minded. And if Hugo has some amazing capabilities
>that are less easy or impossible to implement in Inform, I'd certainly
>be interested in hearing about them.
Hmm. I don't know about "amazing" :) It won't mow your lawn for you,
and in fact I can't really answer your question since I'm really
dealing from a position of ignorance with respect to "modern" Inform.
I haven't looked at it since version 5.4, so I don't know what has
changed since then, what new abilities have been added, etc. I can
tell you this, though: I've never had to write one of those horrid
parse_name routines in Hugo :)
>For example, can Hugo handle dynamic object creation, or does every
>coin and dust mote have to be anticipated by the programmer, as with
>Inform?
Every coin and dust mote has to be anticipated by the programmer. You
can reserve memory space for new dictionary words so that the player
can, for example, write things on cubes and whatnot, but if there's
any way to use that space for dynamic object creation, I don't know
how to do it.
I guess my main defense of Hugo is simply this, and it's a personal
one: I can use Hugo to get done the things I want done and do them in
the way, for the most part, that I want to do them. This was true of
Inform, too, to an extent, but I always had the feeling with it that
the tail was wagging the dog rather than the other way around. With
Hugo, I just feel freer somehow. This is not to say that Hugo is
perfect. Lord knows, I load Kent up with gripes and suggestions all
the time. But it is more flexible, in the sense that there's not so
much of a "Hugo way of doing things" as there is in Inform, and I
finally just have a lot more fun poking around and experimenting with
Hugo than I ever did with Inform. This may not sound like it has much
to do with writing games, but it really has a lot to do with it, since
it's from such fiddling around that fresh ideas come and from which
games/stories that break from the prescribed mold are born (in my
experience, anyway).
Carl Muckenhoupt
card...@earthlink.net (Cardinal Teulbachs) writes:
>>In short, Hugo isn't the victim of some sort of snobbish conspiracy. It
>>just isn't popular.
>Yes, I realize there's no conspiracy. But at the same time, I have to
>wonder why Hugo isn't popular. Is it because Hugo is a piece of crap?
>If so, where are the posts warning people to steer clear of it? In
>fact, where are the posts asking how to accomplish this or that task
>in Hugo, since it is never immediately clear what is a bug and what is
>simply a lack of understanding on the user's part? The answer, or so
>it seems to me, is that the posts aren't here because few people are
>moved to ever even take a look at Hugo, much less put out the effort
>to learn enough of how it works to decide whether it appeals to them
>or not.
Why isn't Hugo popular? To answer this, we must first ask:
Why are TADS and Inform popular?
TADS is popular chiefly because it had a head start. It wasn't the
first adventure system, but considering its competition (AGT, Advsys,
and lesser systems), it may as well have been. It may have been the
first object-oriented adventure language, and that counts for a lot.
(Is AdvSys OO? I played with it ages ago, but all I remember is the
LISP-like syntax, which is probably enough in itself to scare off a
lot of potential authors.)
Once TADS was established, Inform had something of a struggle
breaking into the limelight. It won through chiefly through its
primary gimmick: that it compiled to Z-code, a format for which
there were already many interpreters on many platforms (although
there are certainly a great many more Z-code interpreters out, now
that they're useful for something other than playing old Infocom
games.) This is not to imply that Inform isn't a fine system in
its own right, but were it not for the Infocom connection, I doubt
it would have caught on as quickly as it did.
There is one other factor in the success of these systems: the games
they produced. Tads has its Unnkuulia, Inform its Curses, both much
beloved. Once word-of-net has it that a particular game is worth
playing, people will download whatever it takes to play it - and,
once that's done, down goes the largest barrier to playing other
games that use the same runtime. This has given TADS and Inform an
audience that Hugo has not yet achieved.
In summary, TADS and Inform are popular because:
a) They both stood out from their competition (when released)
b) They both had popular games written in them early on
Now, if Hugo is to gain in popularity, it seems to me that it will
have to achieve one of these two things, possibly both. Writing a
Hugo game that will capture the hearts and minds of the IF
community is really up to Hugo's proponents, of course. But what
about part a? What is Hugo's hook? What does it give us that other
systems do not?
Well, okay, this question was covered in the post that started this
thread. The fact that I've largely forgotten the answer shows
something, though. Hugo is apparently just as good as TADS and
Inform, but easier to use and better at some things. This is
insufficient to get the old-timers interested, and since they aren't
learning it, they can't recommend it to newcomers.
In short, you face the same problems as everyone else who tries to
compete with an established product. But the obstacles are not
insurmountable - the success of Inform against the once-monolithic
TADS proves that.
--
Carl Muckenhoupt | Text Adventures are not dead!
b...@tiac.net | Read rec.[arts|games].int-fiction to see
http://www.tiac.net/users/baf | what you're missing!
Greg Falcon
card...@earthlink.net (Cardinal Teulbachs) wrote:
>>I also noticed that Hugo, unlike Inform or ALan, doesn't know how to
>>deal with commands that have three or more "noun phrases," like
>>the example in that AGT thread, "PRY THE CHIP OUT OF THE MOTHER
>>BOARD WITH THE SCREWDRIVER."
>The first example can be done, but you're right about the second one.
>In Hugo you're limited to one direct object and one indirect object
>per command line (I'm pretty sure; I've never actually tried using
>more than that). It might be possible, though, for the user to write a
>parsing routine to allow for the extra noun phrase. This will not be,
>of course, particularly wonderful news to anyone who doesn't want to
>do that work, though, so mark yourself a point for the criticism.
Actually, if it makes you feel any better, this is not easily done with the
standard Inform libraries, either. Sure, it CAN be done. You could parse
anything you wished to in Inform if you put your heart and soul into it.
>I have to say, though, that if you're looking for a system that you
>can learn in one-and-a-half-months with little or no previous
>programming experience and then churn out complicated, sophisticated
>games with no effort, I think you're looking in vain. Let's suppose
>that a language like you're talking about existed. What would it be?
Interesting.
Game THID;
[
I want the player to start in a spaceship. Give it two rooms with really
futuristic descriptions. After the player starts the engine, have the ship
crash on an alien planet. Place about 30 or 40 rooms on the planet and
several puzzles. Give it a nice ending. And be sure to have an Infocom
"feel".
]
end;
>My complaint isn't that there aren't enough people jabbering about
>Hugo. It's that when someone pops up here asking what authoring
>systems they ought to take a look at, the common mantra is "TADS and
>Inform." Now, I have no problem with this if the people chanting the
>mantra have an honest, informed (ha ha) opinion about it.
Perhaps r.a.i-f. people suggest these systems because these are the ones
they know well. I really don't think that every person here has a duty to
try every authoring system out there. (If we all did, we'd never have time
to write any games.)
>>In short, Hugo isn't the victim of some sort of snobbish conspiracy. It
>>just isn't popular.
>Yes, I realize there's no conspiracy. But at the same time, I have to
>wonder why Hugo isn't popular. Is it because Hugo is a piece of crap?
>If so, where are the posts warning people to steer clear of it? In
>fact, where are the posts asking how to accomplish this or that task
>in Hugo, since it is never immediately clear what is a bug and what is
>simply a lack of understanding on the user's part? The answer, or so
>it seems to me, is that the posts aren't here because few people are
>moved to ever even take a look at Hugo, much less put out the effort
>to learn enough of how it works to decide whether it appeals to them
>or not.
You said yourself that really getting to know any of these languages takes
a few months. Why spend that time learning a new system when you are quite
happy with what you use? I would guess that Hugo could make games as nice
as Inform could. (I "guess" because I've never used Hugo. I'm not ashamed
to admit it. That's the whole basis to my argument.) But as long as Hugo
doesn't do anything that makes Inform or TADS pale in comparison, is there
really a need to exert the effort?
This all reminds me of a program I used to use. While everyone else was
using Windows 3, I did all of my word processing tasks in a different
system. It was called Geoworks Ensemble. (You may have heard of Geoworks;
they're still around today, making OSs for PDAs.) It was a great system.
The whole package cost less than a hundred dollars. You got a spreadsheet,
word processor, database, and drawing program. Everything was true
WYSIWYG. Fonts were scalable to any number of sizes. And it ran so much
faster, with much less overhead. You could easily run it on a 386/33 with
two megs of ram and not feel any delay pains. I sure loved Ensemble. What
happened? Well, no one ever said anything about it. Support was
relatively hard to find. And eventually, Microsoft Windows completely
wiped Ensemble off the map.
The moral of the story? A program can be incredibly popular without it
necessicarily being the best choice. It's frustrating when you have what
is (or what you think is) the best option, and you can't get anyone to
listen. But that is life.
> Am I just an idiot? Wait, don't answer that...:)
Now let's not get unreasonable. There's room enough on this newsgroup for
many different opinions. No one here thinks you're an idiot. I mean, it's
not as if you've announced that your e-mail address is changing to
"card...@aol.com", right? (Hehehehe... sorry, all; I couldn't resist.)
Greg Falcon
-----
$$$$ GET ME RICH QUICK $$$$
Send me $5.00 in a brown envelope. Do nothing else! Since you are
not crossing out any names or receiving any money, it's not a pyramid
scheme. It's perfectly legal!
Matthew Amster-Burton
I think the key barriers to Hugo acceptance at this point are time and
luck. At one point not long ago at all, the only systems of note were
TADS and AGT. (Yes, I know someone's going to argue this.) Then the
previously forgettable Inform began to show real promise, and AGT died
a deserved death (I thought), and suddenly the gamescape--pun
intended--had changed within a couple of years.
Give Hugo a couple, as well, and by all means keep proselytizing. I
may d/l a copy myself and try it out, although TADS still keeps me
happy.
card...@earthlink.net (Cardinal Teulbachs) wrote:
> Cardinal, I follow up your post in the hopes that some
> day I too will be quoted in your sig.
> --Matthew Amster-Burton
You know, thanks to this guy, I come up in DejaNews far more often
than I deserve.
Matthew
Ben Chalmers
In article <n0EC...@puppy.demon.co.uk>
a...@puppy.demon.co.uk (Andrew Clover) wrote:
> erky...@netcom.com (Andrew Plotkin) wrote:
>
> > Boost though you may, Hugo is under-represented because it's newer.
> > That's the long and short of it.
>
> The two reasons I don't use it are derived from this:
>
> 1. The Acorn port is a bog-standard command-line C port, rather than
> something as smart as Zip 2000.
I should point out, this is being worked on (albeit slowly, given other 'more
important' projects, mainly involving money being offered my way). Suffice
to say, what alreasdy exists on my system will be nearer Zip2000 than the
current system.
It will:
Multitask
Conform to the latest Hugo Standard
It wont
Use proportional fonts
Make coffee
Ever be released (unless people stop offering me money)
ttfn
Ben
--
Name :Ben Chalmers. The Anti-Hedgehog(tm) Taking hedgehogs away
Email:b...@bench.demon.co.uk from the common folk
csap PROTO-FAQ: csa...@bench.demon.co.uk since 1996
Cardinal Teulbachs
b...@max.tiac.net (Carl Muckenhoupt) wrote:
I can't disagree with anything you say here, Carl. The point about
there not being a showcase game for Hugo is especially pertinent, I
think. Also, your point about the need for a "hook" is probably
accurate, although unfortunate, too, in my opinion.
But the bottom line is that I'm really only howling at the wind,
aren't I? I mean, how does one overcome statements like that made in
the review of "Spur" (in XYZZY or SPAG--I can't remember which or
which edition), wherein the reviewer, upon encountering a command the
game parser didn't understand, immediately faulted the language/system
and not the author? Hugo's grammar table design is practically
identical to Inform's; any command of the sort he was complaining
about could have been implemented with it. But there was just this
immediate assumption that Hugo is a leper and nothing clean could
possibly come from it, which turned around--illogically--means that
every shortcoming in a Hugo game must be due to the
parser/engine/whatever. I realize that this was due to ignorance and
not to ill will on the reviewer's part, but then that's my point.
Cardinal Teulbachs
mam...@u.washington.edu (Matthew Amster-Burton) wrote:
>I think the key barriers to Hugo acceptance at this point are time and
>luck. At one point not long ago at all, the only systems of note were
>TADS and AGT. (Yes, I know someone's going to argue this.)
Not me :)
>Then the
>previously forgettable Inform began to show real promise, and AGT died
>a deserved death (I thought), and suddenly the gamescape--pun
>intended--had changed within a couple of years.
Yep. Well, like I've said, I'm not really looking to change the
gamescape, as if I'm on some mission to set Hugo up as a king over
TADS or Inform or AGT or etc. I don't have any particular stake in
Hugo's success or failure as an i-f system. I just don't like seeing
it so loudly ignored, since I feel it's at least worthy of a serious
look. That's all.
>Give Hugo a couple, as well, and by all means keep proselytizing. I
>may d/l a copy myself and try it out, although TADS still keeps me
>happy.
Great, although, as you imply, I don't expect Hugo to tear you away
from TADS. You already know TADS and you're apparently comfortable
with it. No problem there. I'm more concerned with what's being told
or not told to new arrivals.
Anyhow, on to much more important matters: I'm thinking of updating my
sig soon, so you people had better watch what you say :) I'm lurking
out here. I could snatch at any moment...:)
Cardinal Teulbachs
erky...@netcom.com (Andrew Plotkin) wrote:
>Boost though you may, Hugo is under-represented because it's newer. That's
>the long and short of it. And what you're doing is exactly the right
>response (along with writing more Hugo games, which I assume you're doing
>also.)
I've got more games than you can shake a stick at. I just don't have
any game endings :)
>Ok, here's my one cent. I downloaded the Hugo source to see if I could do
>a half-hour Mac port. (I couldn't -- no surprise -- no programming
>project takes half an hour on the Mac.) But when I was looking through
>the source, I noted that the parser resides in the Hugo run-time, not the
>game file.
Well, it's half in and half out, but yes, you're right. The most basic
parsing activity is hard-wired in. There is an up-side, though, for a
certain class of user: it makes the library much easier to understand.
I suppose one could argue that the library should be easy to
understand *and* that the whole parser should be in it, but since a
language offering that doesn't exist (IMO) I've made a judgment that
the trade-off in that particular kind of flexibility is worth the gain
in productivity. I won't sit here and tell you that it hasn't caused
me frustration at times, though--and I'm sure it would drive you nuts
:)
>This gets right to the basic claim of the Inform boosters (like me :-),
>which is that the Z-machine has an order of magnitude less hard-wiring
>than any other portable IF format. (And I'm not just talking about Tetris.
>Note the post, earlier in this thread, which mentions three-noun verb
>constructs. Note the fact that even though the standard Inform library
>doesn't support real adjectives, there's source code to put them in.
>Ditto for daemons that execute in a specified order each turn.)
Yep. I've got nothing bad to say about Inform other than that it's too
burdensome to use (for me). I don't really know how to express
it--it's not that it's too hard, really, but just that writing in it
was sometimes like slogging through mud. Of course, it's been awhile
since I used it, too, so I may be exaggerating somewhat, but the fact
remains that when I started in with Hugo I picked it up pretty quickly
and could actually just sit down and type without having to stare at
the manual every five minutes. I'll admit this had a lot to do with my
previous Inform experience, but still, there was a noticeable
difference in the amount of effort expended. That, for me, turned out
to be the bottom line. Sure, I miss some of the whiz-bang Inform
gizmos, but most of the ones Hugo lacks are being added in bit by bit
just like they were to Inform, so maybe someday soon I'll be in the
happy position of having roughly the best of both worlds. Or maybe
not. Time will tell, I guess.
>On a related note, how hard would it be to get the Hugo compiler to
>generate Z-machine files instead of Hugo runtime files?
Hmm. That's a question better put to Kent. I'll ask him.
Russ Bryan
Cardinal Teulbachs wrote:
> Anyhow, on to much more important matters: I'm thinking of updating my
> sig soon, so you people had better watch what you say :) I'm lurking
> out here. I could snatch at any moment...:)
Say it ain't so! The months of immortality I've enjoyed in your .sig,
gone forever? Aaargh!
> --Cardinal T
>
> I mean, what the hell kind of villain thwarts the hero's
> progress with soup cans in the kitchen pantry?
> --Russ Bryan
Ok, Russ, calm down. Think witty. Chickens crossing the road... no,
that won't do it. "I knew this guy who so fat ..." No, that won't do
it. How about... ummm... oh, narf it all anyway.
You'll be hearing from my lawyer.
-- Russ
ct
In article <n0EC...@puppy.demon.co.uk>,
Andrew Clover <es...@csv.warwick.ac.uk> wrote:
> The two reasons I don't use [hugo] are derived from this:
>
> 1. The Acorn port is a bog-standard command-line C port, rather than
> something as smart as Zip 2000.
This will be rectified just as soon as I get the time. So after my
dissertation is complete. I have such wonderful plans, but no time...
regards, ct
Nulldogma
> Great, although, as you imply, I don't expect Hugo to tear > you away
from TADS. You already know TADS and you're
> apparently comfortable with it. No problem there. I'm
> more concerned with what's being told
> or not told to new arrivals.
Probably most important, then, is to make sure that Hugo is fairly
represented in the "Which System?" FAQ. (It may be already; I forget.)
That's where all newbies wind up getting steered anyway.
Julian Arnold
In article <51o49q$p...@ecuador.earthlink.net>, Cardinal Teulbachs> [...]
> I've got more games than you can shake a stick at. I just don't have
> any game endings :)
I can vouch for this. (Eastwood?) :)
> [Cardinal T finds Hugo more productive than Inform]
I know what you mean, and it is difficult to express. To me (after
using Hugo 2.1 a little, and 2.2 less) it seems that, as well as Hugo's
source being a mite "cleaner" than Inform's, Hugo is the language more
geared to its specific task-- writing IF. By the same token though,
Inform is a much more flexible language, and, as I've argued before,
this is relevant-- the techniques used to write Tetris or Game of Life
can be of use in an IF program. I think I *prefer* writing Hugo code,
but can ultimately do more with Inform (this is partly due to my greater
experience with Inform than Hugo, but also something inherently to do
with the two systems).
> >On a related note, how hard would it be to get the Hugo compiler to
> >generate Z-machine files instead of Hugo runtime files?
>
> Hmm. That's a question better put to Kent. I'll ask him.
Hmm, maybe this isn't a question Kent wants to hear. :)
Jools
--
Roger Plowman
>TADS is popular chiefly because it had a head start. It wasn't the
>first adventure system, but considering its competition (AGT, Advsys,
>and lesser systems), it may as well have been. It may have been the
>first object-oriented adventure language, and that counts for a lot.
>(Is AdvSys OO? I played with it ages ago, but all I remember is the
>LISP-like syntax, which is probably enough in itself to scare off a
>lot of potential authors.)
Hey! <g>
ADVSYS was my *third* IF language, and despite the "Land of Infinite
Parentheses" syntax it is in many ways very flexible and (gasp)
elegant. (And I say that, despite being lukewarm at best about Lisp).
ADVSYS 1.2 (the version I have) is indeed object oriented. It has its
limits but I always found the parser (for example) to be equal to that
of Zork, and it lacks many of the inherit limits of z-code (for
example the limited number of attributes).
Of course ADVSYS was a *big* step up from the first two languages I
wrote Quest in, the first was PDP-11's Basic-Plus in 1979, the second
was CP/M S-Basic in 1982 (with 64k of memory for program, data *and*
operating system... <g> Made a Kaypro creak it did!).
I'm dusting off Quest again, this time to finish and release as
Thief's Quest. My language of choice after looking at TADS, Inform,
ADVSYS, and Hugo is (drumroll, please): Hugo.
Why? Because Hugo's easier to read, the syntax more forgiving, and it
feels more natural to me. I'm a programmer by trade, and collect
languages like some people collect stamps. Over the years I've learned
everything from RPG II and Cobol to a score of Basics to FoxPro,
Access and PowerBuilder. Including Logo and Lisp. <g>
After dealing with TADS and Inform and (trying) to learn them I
decided Hugo was decidedly a better "fit" for me.
Is it a better language? Ask me again after Thief's Quest is finished!
<g>
Oh, If Hugo's author is listening, I'd sure like a manual on
HUGOLIB.H! The one that came with Hugo's more than a little light on
the library...
BTW, if anyone cares anymore I wrote a pretty complete tutorial on
ADVSYS, using the (incomplete) game of Quest as a commented example.
Roger Plowman (no fancy signature file, sorry)
Greg Falcon
card...@earthlink.net (Cardinal Teulbachs) wrote:
>I suppose one could argue that the library should be easy to
>understand *and* that the whole parser should be in it, but since a
>language offering that doesn't exist (IMO)...
Funny, I would have given this as one of my favorite traits of Inform.
(The way I see it, the parser is completely invisible to the writer unless
he wants to delve into it.)
Greg
Cardinal Teulbachs
Russ Bryan <cle...@javanet.com> wrote:
>> Anyhow, on to much more important matters: I'm thinking of updating my
>> sig soon, so you people had better watch what you say :) I'm lurking
>> out here. I could snatch at any moment...:)
>Say it ain't so! The months of immortality I've enjoyed in your .sig,
>gone forever? Aaargh!
Down, boy! I didn't say I was dumping your quote :) Thou, Russ Bryan,
shalt forever lead the Cardinal's sig as having uttered in his opinion
the single most amusing line ever recorded in the annals of raif.
--Cardinal T
I mean, what the hell kind of villain thwarts the hero's
progress with soup cans in the kitchen pantry?
--Russ Bryan
Cardinal Teulbachs
null...@aol.com (Nulldogma) wrote:
>Andrew sort of already said this, but it's worth repeating: Regardless of
>their power or ease-of-use, Hugo and Alan will only start being mentioned
>in the same breath as TADS and Inform when 1) they've been ported to as
>many platforms; and 2) they've had more games written in them. (And *good*
>games -- look at what sloppy authorship has done to AGT's rep.)
I agree with you about #2, but I think the platform issue is largely a
red herring. Acorn, DOS, Mac, Unix. Those pretty much cover the core
audience, as near as I can tell. Perhaps you can correct me on this,
but I don't think anyone's pulling in huge numbers from other
platforms. Hence, I don't see that this is what will make or break
Hugo, Alan, etc.
Anyhow, this is my own view and not Kent Tessman's, so I hope you
won't attribute my coldhearted attitude to him. I'm sure he'd like to
see every platform in existence supported.
>From the sound of it, people are working on (2). As for (1) ... I hear
>tell there's this kingdom available in exchange for a Mac Hugo....
Yep. We need this one. Do I hear an offer? Pretty please? :)
Cardinal Teulbachs
Julian Arnold <jo...@arnod.demon.co.uk> wrote:
>>[blah blah blah]
>> I've got more games than you can shake a stick at. I just don't have
>> any game endings :)
>I can vouch for this. (Eastwood?) :)
What's that? Never heard of it. I'll tell you what, though: I'll get
back to work on Eastwood when hell freez--I mean, when Avalon is
released. How's that? :)
>> [Cardinal T finds Hugo more productive than Inform]
>I know what you mean, and it is difficult to express. To me (after
>using Hugo 2.1 a little, and 2.2 less) it seems that, as well as Hugo's
>source being a mite "cleaner" than Inform's, Hugo is the language more
>geared to its specific task-- writing IF. By the same token though,
>Inform is a much more flexible language, and, as I've argued before,
>this is relevant-- the techniques used to write Tetris or Game of Life
>can be of use in an IF program. I think I *prefer* writing Hugo code,
>but can ultimately do more with Inform (this is partly due to my greater
>experience with Inform than Hugo, but also something inherently to do
>with the two systems).
I think this is a fair expression of my own view, too. I'd have to
admit that in the sense you're talking about, Inform is currently more
powerful than Hugo. However, I don't see any inherent reason why Hugo
can't be made to do some, most, or all of these things in the future,
either, and since I'm not in any rush to use them right now, waiting
isn't an issue with me.
>> >On a related note, how hard would it be to get the Hugo compiler to
>> >generate Z-machine files instead of Hugo runtime files?
>>
>> Hmm. That's a question better put to Kent. I'll ask him.
>Hmm, maybe this isn't a question Kent wants to hear. :)
Maybe, maybe not, but in any case I'm assuming Andrew has noble
motives in asking :)
Cardinal Teulbachs
professo...@pnx.com (Greg Falcon) wrote:
>card...@earthlink.net (Cardinal Teulbachs) wrote:
>>I suppose one could argue that the library should be easy to
>>understand *and* that the whole parser should be in it, but since a
>>language offering that doesn't exist (IMO)...
>Funny, I would have given this as one of my favorite traits of Inform.
>(The way I see it, the parser is completely invisible to the writer unless
>he wants to delve into it.)
I think you've misunderstood me. I agree completely that Inform's
parser is invisible if you don't need/want to do anything special or
different. I'm talking about the obstacle presented if you *do* want
or need to fuss around with it, or even just to look at it for clues
to this or that problem or question you may have. I mean, presumably
this was at least one reason why it was implemented as a library in
the first place, rather than just being kept away out of sight of the
user altogether. I'm not saying, either, that Inform's parser is
defective; only that because of its particular nature, it's difficult
(for me) to decipher.
Andrew Plotkin
Cardinal Teulbachs (card...@earthlink.net) wrote:
> >> >On a related note, how hard would it be to get the Hugo compiler to
> >> >generate Z-machine files instead of Hugo runtime files?
> >>
> >> Hmm. That's a question better put to Kent. I'll ask him.
> >Hmm, maybe this isn't a question Kent wants to hear. :)
> Maybe, maybe not, but in any case I'm assuming Andrew has noble
> motives in asking :)
Not only noble, but serious. One hidden drawback of the hardwired parser
is that when the parser is updated, it's work for the interpreter author
*and* the interpreter porters *and* the game players (who have to download
the new interpreter version.) And if there are backward incompatibilities,
the players have to keep two versions of the interpreter, etc, etc...
In contrast, when Inform 6 came out -- a total rewrite -- it generated
game files that run on all existing interpreters.
If the Hugo compiler generated Z-machine files, it would pick up this
advantage. Furthermore, it would obviously have to drop the "hard-wired"
part of the parser into the Z-program. Presumably, just as a block of
code. But if that code is *also* compiled from source, and the source is
supplied with the compiler, it also deals with my other complaint. Game
authors *could* hack around with it, if necessary, and they'd still be
producing runnable Z-machine files in the end.
In fact, I wonder if you shouldn't just write a Hugo-to-Inform source
file translator... if you avoid all the IF-specific parts of Inform, and
just generate more-or-less C code, you wouldn't be stuck with any of the
quirks of Inform as an IF system.
Greg Falcon
card...@earthlink.net (Cardinal Teulbachs) wrote:
>professo...@pnx.com (Greg Falcon) wrote:
>>card...@earthlink.net (Cardinal Teulbachs) wrote:
>>>I suppose one could argue that the library should be easy to
>>>understand *and* that the whole parser should be in it, but since a
>>>language offering that doesn't exist (IMO)...
>>Funny, I would have given this as one of my favorite traits of Inform.
>>(The way I see it, the parser is completely invisible to the writer unless
>>he wants to delve into it.)
>I think you've misunderstood me.
Sheesh, I did. (Ugh.) Sorry about that.
Re-reading your message, I have to agree with you. Somehow, I think that
any GOOD parser will have relatively difficult code. Trying to make a
library with extremely easy-to-understand code that contains the parser
would cripple the parser so badly that it wouldn't be worth it. I
personally like the Inform approach better; if anything (literally anything
at all) bugs me about the parser or game handling routines, I can simply
rewrite them. (Of course, the Inform library is so expertly done that such
a need has never arisen.) But, like you've said, it's a matter of personal
preference.
What's more, I'm really starting to get interested in Hugo. I wouldn't
want to leave Inform myself -- Hugo sounds not to be as powerful -- but
judging from what you have been saying, it sounds like it has the makings
for an excellent "first language" in IF writing.
I had the misfortune of downloading AGT from a bulletin board years back.
I'm sorry if I'm offending any die-hard AGT fans out there, but I was very
disappointed with AGT. All of the games I was able to find for AGT were
laughable at best, and the language was not nearly powerful enough for my
tastes. The parser was too rigid. The whole "every noun must have one
adjective" philosophy bugged me. All in all, the games I found for AGT
were far inferior to what I expected in a text adventure game. I gave up
trying to write in AGT, instead focusing my energy on writing my own parser
for a game. (That was nightmarish. It was a good while back, and my
programming skills were just barely sufficient.) After that, I gave up
writing "Planet Thid" for a few years. Luckily, Inform came into my life,
and Thid is coming along nicely. :-)
If Hugo is really that much easier to use than languages like Inform or
TADS (sorry for my relative silence about TADS; I know little about it),
then I think that Hugo *should* be the language we point first time users
toward. I would hate to think that some young talent might be turned off
of the whole IF-writing scene. The question is: IS Hugo really that much
easier to use? You've pointed out yourself that you may have found Hugo
easy to use because you had already dabbled in Inform.
Oh, well. Just my $0.02
Cardinal Teulbachs
professo...@pnx.com (Greg Falcon) wrote:
>What's more, I'm really starting to get interested in Hugo. I wouldn't
>want to leave Inform myself -- Hugo sounds not to be as powerful -- but
>judging from what you have been saying, it sounds like it has the makings
>for an excellent "first language" in IF writing.
I think there are certain senses in which it's right to say that
Inform is more powerful than Hugo and certain senses in which it
isn't. For one thing, what does "powerful" mean, exactly? One class of
user will say that a language is powerful if it will warm his socks in
the morning, no matter how difficult that is to accomplish. Another
will say that a language he can use to accomplish a wide range of
tasks with relative ease--though lacking in the ability to toast his
socks--is powerful. There are strong elements of truth in both of
these views, it seems to me, and neither one can be ignored. I would
call Inform more powerful in the first sense and Hugo more powerful in
the second sense.
But two points about that: first, Hugo is not a dead letter. That is,
it's not a completed work frozen in time for once and evermore. It's a
work in progress, just like the others, and new abilities are being
added to it regularly. As such, I want to avoid giving the
impression, since I'm playing the partisan here. that a person who
takes up Hugo will only ever be able to do what it currently does.
Second, Hugo as it currently exists can do some fairly nifty things.
For one, did you read the post here from the person asking about
Dynamic Object Creation? Personally, I'm skeptical as to its practical
value in i-f, but in any case Hugo has the ability to do the next best
thing: so long as the number is not *indefinite*, Hugo can deal with
any number of identical objects in a game. Say you want a hundred and
fifty bread crumbs for the player to scatter around the map. There are
probably better ways to implement this, but the player can, if he
chooses to, create one hundred and fifty totally identical bread crumb
objects in his game and expect the parser to handle them properly. Is
this a gee-whiz, stop-the-presses thing? I don't know, but I've found
it extremely useful and a million times more pleasant than writing
parse_name routines and the like, which I used to have to write in
Inform.
Leaving aside identical objects, Hugo also does simple plurals. Say
you have a room full of people. You can simply create as many
plural_class objects as needed to deal with them. For example, you can
create a "boys" and a "girls" class, a "blondes" and "brunettes"
class, a "lieutenants" and "colonels" class, etc. These are really
just simple, short object definitions (not true classes, actually) and
the player can then refer to, say, the colonels and have the action be
routed to the appropriate member objects. No fuss, no muss, no writing
a bunch of code to see whether any colonels are present, how many and
who they are, etc. Inform may be able to do this, too, I don't know,
but in any case it's not a worthless or ho-hum ability for an i-f
system to have, IMO. The identical_class and plural_class are
implemented from the user's perspective as objects, and not as pre- or
postparsing routines, so they're simple to understand and to use. If
you want to see what one of these looks like on paper, download
SPELLSYS.ZIP from the hugo/library/contributions (I think that's where
Volker said he was putting it) and browse the source. Both the spells
and the scrolls have been implemented as plural objects in it.
>I had the misfortune of downloading AGT from a bulletin board years back.
>I'm sorry if I'm offending any die-hard AGT fans out there, but I was very
>disappointed with AGT. All of the games I was able to find for AGT were
>laughable at best, and the language was not nearly powerful enough for my
>tastes. The parser was too rigid. The whole "every noun must have one
>adjective" philosophy bugged me. All in all, the games I found for AGT
>were far inferior to what I expected in a text adventure game. I gave up
>trying to write in AGT, instead focusing my energy on writing my own parser
>for a game. (That was nightmarish. It was a good while back, and my
>programming skills were just barely sufficient.) After that, I gave up
>writing "Planet Thid" for a few years. Luckily, Inform came into my life,
>and Thid is coming along nicely. :-)
I think we need to be careful about confusing the language or system
with the game author. It's true that a bad game will tend to give the
language it's written in a bad reputation, but those who consider the
matter more seriously ought to realize that no system can save a poor
author from himself. It seems as if people think that when they run up
against a poorly-crafted vocabulary in a game, the ability to type in
just a few more words would have solved their problem as players.
Perhaps this is right in the case of shared adjectives and other
special instances like that in certain systems, but overall it
wouldn't have made any difference whatsoever. The game understands
only what the author tells it to understand, and if he's able to rely
on a library to provide default behaviors for unforeseen commands,
that is still only slightly less maddening to the player than seeing
"I don't understand x." Attention to detail on the part of the author
is what makes or breaks a game, in my opinion, regardless of the
language--although I understand your point. If the language won't even
allow enough elbow-room for the author to work in, there's little he
can do about it but go elsewhere.
>If Hugo is really that much easier to use than languages like Inform or
>TADS (sorry for my relative silence about TADS; I know little about it),
>then I think that Hugo *should* be the language we point first time users
>toward. I would hate to think that some young talent might be turned off
>of the whole IF-writing scene. The question is: IS Hugo really that much
>easier to use? You've pointed out yourself that you may have found Hugo
>easy to use because you had already dabbled in Inform.
Well, as I've intimated, I'm not prepared to concede that Hugo is only
good as a primer-language that people can use before they're ready to
move on up to "the real thing." It's not perfect, but it doesn't need
to hide its head, either. I would say at this point that it's a good
language to grow along with if one has the inclination.
As for its ease-of-use, I think it *is* easier to learn and use, but
the lack of documentation aimed at beginners tends to obscure that
fact. I tell people to read Graham's stuff first before they start in
with Hugo, so they'll have some idea of the basics. Then it's mostly
Code, Compile, and Curse until Hugo's design starts to sink in.
Hopefully soon I'll find some time to write a designer's manual of my
own for Hugo, but for now the lack of beginner-friendly documentation
is a sticking point.
Kent Tessman
Looks like the good Cardinal has gone and stirred up a little bit of
debate with his suggestion that Hugo is getting less
attention/endorsement than it deserves, as compared to TADS or Inform.
As the author of the first system, I thought I'd pipe up at some point.
I think most of the comments made by way of response to the Cardinal's
post(s) are fairly accurate. I wanted to respond to a few of them, in
particular (apologizing at the same time for not making precise
attributions of the original comments, since some of them are paraphrased
and others are combined):
1. Hugo doesn't bring anything new to the IF landscape.
This is true only so far as "new" means "revolutionary". Interactive
fiction design tends, at this point, anyway, to revolve around a number
of common elements regardless of the language being used. What I wanted
to do with Hugo was to write a system from scratch that took advantage of
a body of thought about how IF should work, and which in its coherence
and focus would be easier to use. Less punctuation, clearer syntax,
you've heard me say it before.
2. Hugo is very C-ish. Hugo is just like Inform with bits of TADS
thrown in for good measure.
This first part I sort of agree with. Hugo _looks_ quite a bit like C by
virtue of the fact that it uses curly brackets to separate sections of
code. And the reason that it shares something in terms of design and
approach with Inform is that Inform (and the Z-machine) were, as they
perhaps were for many, my first glimpse of IF programming. I'm not sure
what the observation of a TADS influence refers to.
It's also interesting to note (to me, at least), that Hugo was designed
_before_ I knew C. It was originally written--in a "draft" form--in
Microsoft QuickBasic. So I always find it interesting when Hugo gets
called C-ish. Maybe C is more intuitive than people give it credit for :).
3. Parser power.
Andrew pointed out that the parser is hard-coded, with perhaps the
implication that it is less flexible because of that. I, in turn, would
point out that the library is quite capable of doing a great deal of
parsing on its own--witness the plural/identical objects system in Hugo,
which is (I think, anyway) probably the simplest and most straightforward
plural system going, and coded entirely in Hugo itself. The library
allows a Hugo programmer to make whatever assessment of an input he or
she likes, modifying it in any number of ways, before handing it over to
the parser for the speed-and-efficiency-required dirty work.
A couple of points have been raised along the lines of: "You can't do X
in Hugo." A couple of these have also been right--at least for the time
being. The truth is that you can't do them _now_, because, more likely
than anything, I just didn't think of them at the time I wrote the
library parsing routines or the game grammar. (And the
grammar-definition style used by Hugo is very similar to Inform's for the
reason that Graham Nelson devised a format that is very nice to work
with. I've said that at least once or twice before.)
4. Could the Hugo Compiler be modified to generated Z-code?
Well, I guess. But Graham Nelson would probably tell you that writing a
Z-code compiler (the guts, I mean) is anything but a trivial task. For
the sake of efficiency, economy, and performance, the function of the
Hugo Engine and the syntax of the language are fairly closely tied. This
also begs the question: why would you want to? There are an awful lot
of reasons why you would _not_ want to run Z-code--Inform is one of the
good arguments in favor of it.
Which ultimately means, of course, that we're talking about languages,
anyway. It doesn't really matter which language you're working in so
long as the finished product measurs up. You don't know if your home
computer applications were written in C, Pascal, C++, assembler, or some
combination of these or others. And likely you don't care, so long as
the finished product works for you. Which means that what matters to
this debate--is it a debate?--is how well the language works for the
programmer. Which is the reason I wrote Hugo in the first place. Which
is what I (and a lot of other people) have already said, so I'll stop
here for now.
--Kent Tessman
<as40...@orion.yorku.ca>
Andrew Clover
c...@ecs.ox.ac.uk (ct) wrote:
>> 1. The Acorn port is a bog-standard command-line C port, rather than
>> something as smart as Zip 2000.
> This will be rectified just as soon as I get the time. So after my
> dissertation is complete. I have such wonderful plans, but no time...
Coo... well, if you can make it as good as ZIP2K, I shall be very
impressed.
BCNU, AjC
Julian Arnold
In article <erkyrathD...@netcom.com>, Andrew Plotkin
<URL:mailto:erky...@netcom.com> wrote:
>
>
> > >> >On a related note, how hard would it be to get the Hugo compiler to
> > >> >generate Z-machine files instead of Hugo runtime files?
>
> Not only noble, but serious. One hidden drawback of the hardwired parser
> is that when the parser is updated, it's work for the interpreter author
> *and* the interpreter porters *and* the game players (who have to download
> the new interpreter version.) And if there are backward incompatibilities,
> the players have to keep two versions of the interpreter, etc, etc...
>
> In contrast, when Inform 6 came out -- a total rewrite -- it generated
> game files that run on all existing interpreters.
>
> If the Hugo compiler generated Z-machine files, it would pick up this
> advantage. Furthermore, it would obviously have to drop the "hard-wired"
> part of the parser into the Z-program. Presumably, just as a block of
> code. But if that code is *also* compiled from source, and the source is
> supplied with the compiler, it also deals with my other complaint. Game
> authors *could* hack around with it, if necessary, and they'd still be
> producing runnable Z-machine files in the end.
>
> In fact, I wonder if you shouldn't just write a Hugo-to-Inform source
> file translator... if you avoid all the IF-specific parts of Inform, and
> just generate more-or-less C code, you wouldn't be stuck with any of the
> quirks of Inform as an IF system.
But, this all assumes we want to adopt the Z-machine as the "ultimate"
standard for portable IF gamefiles. While I agree that a standard is
desirable, the Z-machine is not it.
I realise it would be a lot easier to use a format that is already well
documented and defined, and from this point of view, the Z-machine is
probably the best choice. But, the format itself imposes strict limits
on such things as numbers of properties and attributes, and gamefile
size. Hugo's gamefiles are limited too, I think, but not to such a
degree. AFAIK (not especially far) TADS' .GAM file would be the best
existing format to choose as a standard.
What I'm saying is that while it would be nice if Hugo could ultimately
produce Z-code, in that this would allow Hugo authors to reach as wide
an audience as Inform authors, and, as Andrew says above, would make
things easier for all concerned regarding backwards compatibility and
"staying up-to-date", it's probably more worthwhile to spend the effort
that would be required to convert Hugo (and others?) to produce Z-code,
to define a new format, which takes advantage of modern hardware, and
convert everything to use that. Of course, this would take
significantly more effort, but in the long term would be worth it.
And no, I'm not offering to take the job on (for a start, I can't).
Jools
--
ct
In article <n102...@puppy.demon.co.uk>,
Now _that_ shouldn't be too hard. (Of course, Hugo doesn't do all that
Z-machines do, so it not so hard to catch up...)
regards, ct
Magnus Olsson
In article <baf.84...@max.tiac.net>,
Carl Muckenhoupt <b...@max.tiac.net> wrote:
>Why isn't Hugo popular? To answer this, we must first ask:
>Why are TADS and Inform popular?
>
>first adventure system, but considering its competition (AGT, Advsys,
>and lesser systems), it may as well have been.
I sense oncoming flames from the AGT devotees... :-)
Honestly, even though I remain firmly entrenched in the TADS/Inform
camp :-), I must object to this: AGT enjoyed *enormous* popularity in
the 80's.
>It may have been the
>first object-oriented adventure language, and that counts for a lot.
>(Is AdvSys OO? I played with it ages ago, but all I remember is the
>LISP-like syntax, which is probably enough in itself to scare off a
>lot of potential authors.)
Advsys is OO, and was probably the first fully OO adventure language,
with a nice, clean syntax. Lisp *looks* different from most other
languages, while TADS looks very much like a mixture of Pascal and C,
but once you get used to the syntax I daresay Advsys is easier. The
bane of Advsys was that the author stopped development before he had a
viable product; there are too many things you can't do in the original
Advsys, the library is a bit too primitive, and the docs are a bit too
thin, for it to be a viable alternative to TADS or Inform.
>Once TADS was established, Inform had something of a struggle
>breaking into the limelight. It won through chiefly through its
>primary gimmick: that it compiled to Z-code, a format for which
>there were already many interpreters on many platforms (although
>there are certainly a great many more Z-code interpreters out, now
>that they're useful for something other than playing old Infocom
>games.) This is not to imply that Inform isn't a fine system in
>its own right, but were it not for the Infocom connection, I doubt
>it would have caught on as quickly as it did.
Indeed. With all due respect to Graham, the early versions of Inform
were pretty awful as a programming language: weird, inconsistent
syntax, low-level semantics, lots of strange exceptions and
limitations. Of course, today Inform is remarkably mature and polished
product, but it wasn't alwyas like that. To be fair, the first
releases of TADS weren't too great either.
--
Magnus Olsson (m...@df.lth.se)
Magnus Olsson
In article <51kvnr$k...@argentina.earthlink.net>,
Cardinal Teulbachs <card...@earthlink.net> wrote:
>Yes, I realize there's no conspiracy. But at the same time, I have to
>wonder why Hugo isn't popular. Is it because Hugo is a piece of crap?
>If so, where are the posts warning people to steer clear of it? In
>fact, where are the posts asking how to accomplish this or that task
>in Hugo, since it is never immediately clear what is a bug and what is
>simply a lack of understanding on the user's part? The answer, or so
>it seems to me, is that the posts aren't here because few people are
>moved to ever even take a look at Hugo, much less put out the effort
>to learn enough of how it works to decide whether it appeals to them
>or not.
...which of course leads to the question: Why don't people bother to
learn Hugo?
I think the reason for this is that Inform and TADS have gathered an
awful lot of momentum. Especially Inform has had a tremendous lot of
good publicity in this newsgroup and other places; this naturally makes
a lot of people want to jump on the bandwagon, which generates even
more publicity, and so on. Now, Hugo is challenging Inform from an
inferior position (in the sense of public relations, not in the sense
of being in any way an inferior language). Most people who are
new to writing IF will probaby try Inform before they try Hugo, if only
because they'll hear a lot more about Inform.
Now, suppose somebody tries Inform first. What would it take to make
him or her switch to Hugo? My feeling is that Hugo would have to be
considerably superior to Inform in some aspect, or at least
sufficiently different to feel like a real change.
In short: I think Hugo's problem is that it is too similar to Inform
(and TADS) without being markedly superior to any of them. People who
start with Inform or TADS, and are satisfied with those languages,
will not have sufficient incentive to switch. People who are
dissatisfied with Inform or TADS (probably because they consider those
languages too difficult) will not find Hugo sufficiently different.
So what is there to do? I'd suggest all Hugo fans continue plugging it,
trying to start a bandwagon of their own. But until Hugo really gets
an edge on Inform I'm afraid it will continue to be everybody's
second or third alternative choice.
Mind you: there *are* opportunities for considerable improvements over
the way Inform and TADS handle certain things, like NPC interaction,
for Hugo and other languages to have a good chance of gaining that
edge.
--
Magnus Olsson (m...@df.lth.se)
Andrew Plotkin
Kent Tessman (by...@torfree.net) wrote:
> 4. Could the Hugo Compiler be modified to generated Z-code?
> Well, I guess. But Graham Nelson would probably tell you that writing a
> Z-code compiler (the guts, I mean) is anything but a trivial task. For
> the sake of efficiency, economy, and performance, the function of the
> Hugo Engine and the syntax of the language are fairly closely tied. This
> also begs the question: why would you want to? There are an awful lot
> of reasons why you would _not_ want to run Z-code--Inform is one of the
> good arguments in favor of it.
I posted a middlin-short article about why you would want to; you've
probably read it already. And the limitations can be avoided.
> Which ultimately means, of course, that we're talking about languages,
> anyway. It doesn't really matter which language you're working in so
> long as the finished product measurs up. You don't know if your home
> computer applications were written in C, Pascal, C++, assembler, or some
> combination of these or others. And likely you don't care, so long as
> the finished product works for you. Which means that what matters to
> this debate--is it a debate?--is how well the language works for the
> programmer.
I *strongly* disagree. The first principle of programming for real people
is: It is better for the programmer to suffer for an hour than for the
user to suffer for a minute. (And it is better for the compiler-writer to
suffer for a week than for the programmer to suffer for an hour. And so
on.) Langauge differences only matter when all other things are equal
*for the user*.
In your example, C, Pascal, C++, and assembler *are* all equal to the
user -- because they all generate the same binary format, which the user
runs in the same way on the same set of machines. This situation is so
common that it's easy to ignore user-impact entirely in selecting a
language. But it's a mistake. (I am just getting into Java, and so far I
like it a lot more than C++. But that doesn't mean I can switch my next
C++ project to Java without asking "What does this mean for the user?" At
the moment, it means a hell of a lot. Maybe in three years every desktop
machine will run Java, and then the answer will be different.)
Obviously, this is precisely why I brought up the question of compiling to
Z-machine format.
Andrew Plotkin
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Julian Arnold (jo...@arnod.demon.co.uk) wrote:
> > In fact, I wonder if you shouldn't just write a Hugo-to-Inform source
> > file translator... if you avoid all the IF-specific parts of Inform, and
> > just generate more-or-less C code, you wouldn't be stuck with any of the
> > quirks of Inform as an IF system.
> But, this all assumes we want to adopt the Z-machine as the "ultimate"
> standard for portable IF gamefiles. While I agree that a standard is
> desirable, the Z-machine is not it.
> I realise it would be a lot easier to use a format that is already well
> documented and defined, and from this point of view, the Z-machine is
> probably the best choice. But, the format itself imposes strict limits
> on such things as numbers of properties and attributes, and gamefile
> size. Hugo's gamefiles are limited too, I think, but not to such a
> degree. AFAIK (not especially far) TADS' .GAM file would be the best
> existing format to choose as a standard.
Except that nobody knows what it is. :-)
> What I'm saying is that while it would be nice if Hugo could ultimately
> produce Z-code, in that this would allow Hugo authors to reach as wide
> an audience as Inform authors, and, as Andrew says above, would make
> things easier for all concerned regarding backwards compatibility and
> "staying up-to-date", it's probably more worthwhile to spend the effort
> that would be required to convert Hugo (and others?) to produce Z-code,
> to define a new format, which takes advantage of modern hardware, and
> convert everything to use that. Of course, this would take
> significantly more effort, but in the long term would be worth it.
> And no, I'm not offering to take the job on (for a start, I can't).
Ok, I shall pre-emptively come clean. I have plans for such a thing. (My
last standards proposal fell flat, but this one shall take over the
world! Mwa ha ha ha <wheeze>!)
Obviously I can't start spending serious time on it until the GUA CD is
finished (or at least into its final downhill run.) But it's something I
think about in scraps of spare time. Yesterday, for example, I missed my
highway exit while contemplating how to arrange addressing modes, and had
to pay an extra $1 toll and get lost for half an hour in downtown
Baltimore trying to get back. See? I *do* make sacrifices for IF.
It's a shitload of work. I will not count such a thing as "ready for
release" until I have:
(1) A complete spec document
(2) Portable interpreter source for a terminal-style interface
(3) A working Mac interpreter with a MaxZip-style interface
(4) Source code for a new back end to Inform, which will allow Inform to
compile to this new format from existing .inf files.
So don't hold your breath.
By the way, I strongly recommend that any compiler authors read the new
inform604_technical_manual.txt. (The tech manual, not the designer's
manual.) It has a great deal of lucid commentary on exactly how Inform
works, both front end and back end. Before I read it, (4) was a pipe
dream of mine. Now it's a serious possibility.
--Z
(Just for the record: yes, I have *really strong opinions* about how this
thing will be designed. So don't bother emailing me with suggestions.
It's too early anyway; I would forget them all before I seriously started
working on the project. Which, as I said, won't be until after the GUA
project.)
Cardinal Teulbachs
professo...@pnx.com (Greg Falcon) wrote:
>Actually, if it makes you feel any better, this is not easily done with the
>standard Inform libraries, either. Sure, it CAN be done. You could parse
>anything you wished to in Inform if you put your heart and soul into it.
This is the case with Hugo as well. Though the game engine does the
actual interpretation of the command line, there's a pre-parsing pass
done in the library that allows the user to manipulate the input line
in any way he wants before delivering it up to the engine. And since
there isn't much to know about what the input line consists of other
than that it's an array of significant words, the whole problem
amounts to figuring out how to get that array into a form acceptable
to the engine. In the case of the third-noun-phrase problem, what you
would probably want to do is trap the third phrases, decipher them,
store the significant data in globals for use elsewhere, and then lop
the whole concluding phrase off the command line before giving it back
to the engine. Then you would have to code all your before routines
and whatnot with the possibility in mind of there being
third-noun-phrases, making use of the globals you set up before. This
is what occurs to me off the top of my head, anyway, and it is not a
simple task by any means. But as you say in the case of Inform, it can
be done.
>>I have to say, though, that if you're looking for a system that you
>>can learn in one-and-a-half-months with little or no previous
>>programming experience and then churn out complicated, sophisticated
>>games with no effort, I think you're looking in vain. Let's suppose
>>that a language like you're talking about existed. What would it be?
>Interesting.
>Game THID;
>[
>I want the player to start in a spaceship. Give it two rooms with really
>futuristic descriptions. After the player starts the engine, have the ship
>crash on an alien planet. Place about 30 or 40 rooms on the planet and
>several puzzles. Give it a nice ending. And be sure to have an Infocom
>"feel".
>]
>end;
Ok. Well, I wouldn't call this a complicated game, at least as it's
described here. Any language should give you the ability to do this
(depending upon what your puzzles consist of, of course) with a month
and a half's worth of knowledge or less. This is standard,
bread-and-butter text adventure fare. Don't misunderstand; there's
nothing wrong with it; it's just not what I was thinking of when I
wrote my remarks. I had in mind those people who appear to feel that
the programming language should somehow completely deliver them from
the necessity of knowing how to program. They want something like
Graham's map-reversal example in the old Inform manual to be
anticipated by him and provided for in Inform by a routine or
something they can call with "plain English" to just get the job over
and done with. My argument is that not only is it impossible for
Graham or anyone else to anticipate every Cute Programming Trick some
programmer might want to try, but that even if it were possible the
language or collection of routines or whatever it would consist of
would end up being quite the monster in its own right.
>>My complaint isn't that there aren't enough people jabbering about
>>Hugo. It's that when someone pops up here asking what authoring
>>systems they ought to take a look at, the common mantra is "TADS and
>>Inform." Now, I have no problem with this if the people chanting the
>>mantra have an honest, informed (ha ha) opinion about it.
>Perhaps r.a.i-f. people suggest these systems because these are the ones
>they know well. I really don't think that every person here has a duty to
>try every authoring system out there. (If we all did, we'd never have time
>to write any games.)
That's not what I'm saying. I'm saying that there is a certain species
of person who pipes in with the mantra simply because it is the common
mantra. For instance, if Nelson or Rees or any of a number of others
hand out their opinion it doesn't bother me because I think it has a
foundation, whether or not they've even looked at Hugo. But there are
others I have doubts about, and who I feel are simply saying all the
right things because it's safe and it will ingratiate them with the
in-crowd. There's nothing I can do about it, of course, and the same
thing happens in every other sphere of life, but I'm trying to punch a
hole in that balloon for Hugo and so that's why I'm here. If those
people read this discussion and see that the whole world won't come
crashing down on them if they utter the name "Hugo" (or AGT, or
whatever else they might have some favorable opinion about), then
maybe it will get uttered more. Obviously, this presumes that these
people exist--and I may in fact be wrong about it--but even if they
don't exist I'll hopefully have still managed to create a small forum
for Hugo here where people can learn something about it without having
to make that investment in time you object to.
>The moral of the story? A program can be incredibly popular without it
>necessicarily being the best choice. It's frustrating when you have what
>is (or what you think is) the best option, and you can't get anyone to
>listen. But that is life.
True, but there's a chance for it to draw an audience if people are
talking about it--that is, if someone speaks in its defense--and
that's why I'm out here flapping my gums :)
>> Am I just an idiot? Wait, don't answer that...:)
>Now let's not get unreasonable. There's room enough on this newsgroup for
>many different opinions. No one here thinks you're an idiot. I mean, it's
>not as if you've announced that your e-mail address is changing to
>"card...@aol.com", right? (Hehehehe... sorry, all; I couldn't resist.)
You took me the wrong way. It's because I don't think I'm an
idiot--well, a little buggy maybe--that I wonder why no one else sees
what I see in Hugo.
P.S. The Cardinal would like to announce his new email address. It is
being changed to "card...@aol.com", effective never.
Mark Musante
Kent Tessman (by...@torfree.net) wrote:
> 3. Parser power.
>
> Andrew pointed out that the parser is hard-coded, with perhaps the
> implication that it is less flexible because of that. I, in turn, would
> point out that the library is quite capable of doing a great deal of
> parsing on its own--witness the plural/identical objects system in Hugo,
> which is (I think, anyway) probably the simplest and most straightforward
> plural system going, and coded entirely in Hugo itself.
I feel I have to interject here -- this is the second time I've read someone
praising Hugo's handling of plurals. I have nothing against Hugo; it may well
be a terrific system in which to code, but I've been using TADS for quite
some time, and it has a great plural system too.
Given the following objects:
red_box: item
noun = 'box'
adjective = 'red'
plural = 'boxes'
sdesc = "red box"
location = startroom
;
blue_box: item
noun = 'box'
adjective = 'blue'
plural = 'boxes'
sdesc = "blue box"
location = startroom
;
l_green_box: item
noun = 'box'
adjective = 'large' 'green'
plural = 'boxes'
sdesc = "large green box"
location = startroom
;
s_green_box: item
noun = 'box'
adjective = 'small' 'green'
plural = 'boxes'
sdesc = "small green box"
location = startroom
;
The following transcript is possible:
>GET BOXES
red box: Taken.
blue box: Taken.
large green box: Taken.
small green box: Taken.
>DROP BOX
Which box do you mean, the red box, the blue box, the large green box, or
the small green box?
>ALL OF THEM
red box: Dropped.
blue box: Dropped.
large green box: Dropped.
small green box: Dropped.
>GET GREEN BOXES
large green box: Taken.
small green box: Taken.
>GET BOX
Which box do you mean, the red box, or the blue box?
>BOTH
red box: Taken.
blue box: Taken.
>DROP 2 BOXES
large green box: Dropped.
small green box: Dropped.
>DROP BOTH BOXES
red box: Dropped.
blue box: Dropped.
>GET BOTH GREEN BOXES
large green box: Taken.
small green box: Taken.
I think a legitimate question is: what does Hugo offer in addition
to this that makes it praiseworthy?
- Mark
George Caswell
On 20 Sep 1996, Magnus Olsson wrote:
> ...which of course leads to the question: Why don't people bother to
> learn Hugo?
>
Wasn't that interested. I'm one of those who learned Inform first...
And even if I didn't have a specific interest in compiling to Z-machine
code, I wouldn't see much point in switching, there's not that great a
difference in the level of technology of the systems, as far as I've
seen...
> Now, suppose somebody tries Inform first. What would it take to make
> him or her switch to Hugo? My feeling is that Hugo would have to be
> considerably superior to Inform in some aspect, or at least
> sufficiently different to feel like a real change.
>
Well, first off it would have to be source distributed (I don't know if
it is or not) including compiler, interpreter, miscellaneous other tools
and complete specification of the language and system. Freeware, of
course. Those are just things I would need from the system before I
install it, because that's just how I am. <g> To get me to actually
-switch- I think I would need to see some ways in which it was decidedly
superior to Inform. In my case that most often means a more powerful or
more comprehensive parser. But I also tend to stick to Z-code anyway,
because it's a much more universally supported binary format.
> Mind you: there *are* opportunities for considerable improvements over
> the way Inform and TADS handle certain things, like NPC interaction,
> for Hugo and other languages to have a good chance of gaining that
> edge.
That would be excellent. One other minor thing that is always good to
see is a GUI-environment interpreter. (Note I am not talking about a GUI
adventure here, but an interpreter that lives in a window system.)
Proportional fonts, text attributes, possibly even some integral text
formatting routines (to avoid kludges like checking the window size and
insering x spaces or whatnot...)
....T...I...M...B...U...K...T...U... ____________________________________
.________________ _/>_ _______......[George Caswell, CS '99. 4 more info ]
<___ ___________// __/<___ /......[ http://www.wpi.edu/~timbuktu ]
...//.<>._____..<_ >./ ____/.......[ Member LnL+SOMA, sometimes artist, ]
..//./>./ /.__/ /./ <___________.[writer, builder. Sysadmin of adamant]
.//.</.</</</.<_ _/.<_____________/.[____________________________________]
</.............</...................
Mark Musante
Andrew Plotkin (erky...@netcom.com) wrote:
> (Just for the record: yes, I have *really strong opinions* about how this
> thing will be designed. So don't bother emailing me with suggestions.
> It's too early anyway; I would forget them all before I seriously started
> working on the project. Which, as I said, won't be until after the GUA
> project.)
Whew. The way this comes across is that you're going to re-write the
Z-Machine spec without taking any input from anyone else. I'm sure you
don't mean that.
- Mark
Dan Shiovitz
In article <51uabb$8...@lex.zippo.com>,
Mark Musante <olo...@world.std.com> wrote:
[..]
>I feel I have to interject here -- this is the second time I've read someone
>praising Hugo's handling of plurals. I have nothing against Hugo; it may well
>be a terrific system in which to code, but I've been using TADS for quite
>some time, and it has a great plural system too.
>
>Given the following objects:
>red_box: item
> noun = 'box'
> adjective = 'red'
> plural = 'boxes'
>l_green_box: item
> noun = 'box'
> adjective = 'large' 'green'
> plural = 'boxes'
>The following transcript is possible:
>
>>GET BOXES
>red box: Taken.
>blue box: Taken.
>large green box: Taken.
>small green box: Taken.
>I think a legitimate question is: what does Hugo offer in addition
>to this that makes it praiseworthy?
One advantage Hugo might have (pure speculation .. I use TADS m'self)
is, if the plurals handling is indeed coded in Hugo, not hard-coded like
TADS's is, then you could conceivably modify which items "boxes" refers
to, depending on the situation. Another thing Hugo might offer is the
ability to do something like this, which can't be done in TADS, AFAIK:
>EXAMINE BOXES
There's a whole bunch of boxes here, all shapes and sizes. Ok, actually
there's just two.
>GET BOXES
red box: Taken.
blue box: Taken.
(that is, to have an item "boxes" to give a description of the group, as
well as being able to manipulate individual members.)
> - Mark
--
dan shiovitz scy...@u.washington.edu sh...@cs.washington.edu
slightly lost author/programmer in a world of more creative or more sensible
people ... remember to speak up for freedom because no one else will do it
for you: use it or lose it ... carpe diem -- be proactive.
my web site: http://weber.u.washington.edu/~scythe/home.html some ok stuff.
Dan Shiovitz
In article <erkyrathD...@netcom.com>,
Andrew Plotkin <erky...@netcom.com> wrote:
>Kent Tessman (by...@torfree.net) wrote:
[..]
>> the finished product works for you. Which means that what matters to
>> this debate--is it a debate?--is how well the language works for the
>> programmer.
>
>is: It is better for the programmer to suffer for an hour than for the
>user to suffer for a minute. (And it is better for the compiler-writer to
>suffer for a week than for the programmer to suffer for an hour. And so
>on.) Langauge differences only matter when all other things are equal
>*for the user*.
Though it might be nice if I had the energy to make this statement true,
I do not. Neither do you, I expect. Although in the first stages of
game-writing this is true, as time drags on, the ratio of how much time
I'm willing to spend programming a feature to how much time the user will
save by it gets smaller and smaller, until I call it quits and declare it
a more-or-less finished game. Agreed, it is better that I take the time
to write a response for "EAT THE ROCK" and thus prevent the poor user from
not seeing a funny message when they try this. But, at least in my cost-
benefit analysis, it's not worth it to do a new and humorous response for
every verb-noun combination in the game. YMMV, of course.
(Also, I guess if I really wanted to sacrifice for the user, I'd use
Inform, which I don't like as much as TADS, but is more ported. Oh well.)
>--Z
Julian Arnold
>
> Julian Arnold (jo...@arnod.demon.co.uk) wrote:
> > [...]
> > degree. AFAIK (not especially far) TADS' .GAM file would be the best
> > existing format to choose as a standard.
>
> Except that nobody knows what it is. :-)
Oh yeah. Is that a problem then?
> Ok, I shall pre-emptively come clean. I have plans for such a thing. (My
> last standards proposal fell flat, but this one shall take over the
> world! Mwa ha ha ha <wheeze>!)
Hurrah to your second sentence. To your first, it's always good to stay
clean. To your third, I'm sure the name didn't help-- try calling this
new format "<some alphabetical character>-code", A and Z are taken,
maybe P-code? Don't name it CaBbAGE, whatever you do. As for your
fourth sentence, ten deep breaths.
> [...]
> (Just for the record: yes, I have *really strong opinions* about how this
> thing will be designed. So don't bother emailing me with suggestions.
> It's too early anyway; I would forget them all before I seriously started
> working on the project. Which, as I said, won't be until after the GUA
> project.)
Alright, you won't hear any suggestions from me.
Jools
--
Andrew Plotkin
Mark Musante (olo...@roundlake.baxter.com) wrote:
> Andrew Plotkin (erky...@netcom.com) wrote:
> > (Just for the record: yes, I have *really strong opinions* about how this
> > thing will be designed. So don't bother emailing me with suggestions.
> > It's too early anyway; I would forget them all before I seriously started
> > working on the project. Which, as I said, won't be until after the GUA
> > project.)
> Whew. The way this comes across is that you're going to re-write the
> Z-Machine spec without taking any input from anyone else. I'm sure you
> don't mean that.
Only halfway. What I mean is that I will write a new machine spec, the
way I like it; then I'll post it and ask for comments. *But* I have not
yet seriously started phase 1 of this plan, much less reached phase 2, so
hold off a few months, please.
That's all.
(Well, I'll still have strong opinions when we reach phase 2, but worry
about that later.)
--Z
Andrew Plotkin
Dan Shiovitz (scy...@u.washington.edu) wrote:
> >I *strongly* disagree. The first principle of programming for real people
> >is: It is better for the programmer to suffer for an hour than for the
> >user to suffer for a minute. (And it is better for the compiler-writer to
> >suffer for a week than for the programmer to suffer for an hour. And so
> >on.) Langauge differences only matter when all other things are equal
> >*for the user*.
> Though it might be nice if I had the energy to make this statement true,
> I do not. Neither do you, I expect. Although in the first stages of
> game-writing this is true, as time drags on, the ratio of how much time
> I'm willing to spend programming a feature to how much time the user will
> save by it gets smaller and smaller, until I call it quits and declare it
> a more-or-less finished game.
I did say "an hour", not "any amount of time."
Cardinal Teulbachs
scy...@u.washington.edu (Dan Shiovitz) wrote:
>One advantage Hugo might have (pure speculation .. I use TADS m'self)
>is, if the plurals handling is indeed coded in Hugo, not hard-coded like
>TADS's is, then you could conceivably modify which items "boxes" refers
>to, depending on the situation. Another thing Hugo might offer is the
>ability to do something like this, which can't be done in TADS, AFAIK:
>>EXAMINE BOXES
>There's a whole bunch of boxes here, all shapes and sizes. Ok, actually
>there's just two.
>>GET BOXES
>red box: Taken.
>blue box: Taken.
>(that is, to have an item "boxes" to give a description of the group, as
>well as being able to manipulate individual members.)
Right on both counts. And as I mentioned before, you're not just
limited to one plural category for an object, either. Say you have
four boxes, and two of them are packages. All four boxes could belong
to the "boxes" plural_class, with two of them also belonging to a
"packages" class. All you need are two short object definitions: one
for "boxes" and one for "packages".
Cardinal Teulbachs
wo...@one.net (Roger Plowman) wrote:
>I'm dusting off Quest again, this time to finish and release as
>Thief's Quest. My language of choice after looking at TADS, Inform,
>ADVSYS, and Hugo is (drumroll, please): Hugo.
Woo woo!
>Oh, If Hugo's author is listening, I'd sure like a manual on
>HUGOLIB.H! The one that came with Hugo's more than a little light on
>the library...
I'm sure he is, but in case he's not I'll bring it to his attention
anyway, because you're right. What you can do, though, in the meantime
is make use of the notes in HUGOLIB itself and scan the code there.
>Roger Plowman (no fancy signature file, sorry)
Sorry, you MUST have a fancy signature file if you expect anyone to
take you seriously. Are you sure you're not from AOL? :)
Julian Arnold
In article <323f38e...@news.one.net>, Roger Plowman
<URL:mailto:wo...@one.net> wrote:
>
> [...]
> I'm dusting off Quest again, this time to finish and release as
> Thief's Quest. My language of choice after looking at TADS, Inform,
> ADVSYS, and Hugo is (drumroll, please): Hugo.
You heard it here first folks. :)
Jools
--
Andrew Clover
Julian Arnold <jo...@arnod.demon.co.uk> wrote:
> To your third, I'm sure the name didn't help-- try calling this new
> format "<some alphabetical character>-code", A and Z are taken, maybe
> P-code?
S'been done. It's a bytecode compiled from Pascal, or summat.
IF-code?
BCNU, AjC
Matthew Russotto
In article <erkyrathD...@netcom.com>,
Andrew Plotkin <erky...@netcom.com> wrote:
}Julian Arnold (jo...@arnod.demon.co.uk) wrote:
}> I realise it would be a lot easier to use a format that is already well
}> documented and defined, and from this point of view, the Z-machine is
}> probably the best choice. But, the format itself imposes strict limits
}> on such things as numbers of properties and attributes, and gamefile
}> size. Hugo's gamefiles are limited too, I think, but not to such a
}> degree. AFAIK (not especially far) TADS' .GAM file would be the best
}> existing format to choose as a standard.
}
}Except that nobody knows what it is. :-)
And those who do, ain't telling. Looks like some sort of stack-based
assembly language, though.
Roger Plowman
card...@earthlink.net (Cardinal Teulbachs) wrote:
>I'm sure he is, but in case he's not I'll bring it to his attention
>anyway, because you're right. What you can do, though, in the meantime
>is make use of the notes in HUGOLIB itself and scan the code there.
I'm actually in the (very slow!) process of learning Hugo while
writing TQ while also creating a novice's guide to Hugo, including the
library. I figure I did it for ADVSYS, so why not Hugo? :)
Wolf
Day Evan
In article <n11B...@puppy.demon.co.uk>,
Or, alternately, psuedo-code, like in CS textbooks.
-Evan
--
i have no .sig - wait, i guess i do
Cardinal Teulbachs
olo...@roundlake.baxter.com (Mark Musante) wrote:
>I feel I have to interject here -- this is the second time I've read someone
>praising Hugo's handling of plurals. I have nothing against Hugo; it may well
>be a terrific system in which to code, but I've been using TADS for quite
>some time, and it has a great plural system too.
>I think a legitimate question is: what does Hugo offer in addition
>to this that makes it praiseworthy?
What does TADS do with, say, three green boxes that are identical in
every way, including having no distinctive adjectives to identify them
with? Hugo can handle this (and maybe TADS can, too; I don't know,
which is why I'm asking).
--Cardinal T
I mean, what the hell kind of villain thwarts the hero's
progress with soup cans in the kitchen pantry?
--Russ Bryan
Honorable Mention: Jean-Henri Duteau
Isn't this .sig a little long? I hope *I* never
contribute to such a tremendous waste of bandwidth.
--Jools the Whiney
Stephen Granade
In article <527had$j...@guyana.earthlink.net> card...@earthlink.net
> What does TADS do with, say, three green boxes that are identical in
> every way, including having no distinctive adjectives to identify them
> with? Hugo can handle this (and maybe TADS can, too; I don't know,
> which is why I'm asking).
You can flag the items as isEquivalent. This works for getting/dropping
items--I'm not sure how things work for, say, opening a box. I haven't
done extensive isEquivalent testing. Anyone else tried this?
Stephen
--
Stephen Granade | "It takes character to withstand the
sgra...@phy.duke.edu | rigors of indolence."
Duke University, Physics Dept | -- from _The Madness of King George_
Nulldogma
> > What does TADS do with, say, three green boxes that are identical in
> > every way, including having no distinctive adjectives to identify them
> > with? Hugo can handle this (and maybe TADS can, too; I don't know,
> > which is why I'm asking).
>
> You can flag the items as isEquivalent. This works for getting/dropping
> items--I'm not sure how things work for, say, opening a box. I haven't
> done extensive isEquivalent testing. Anyone else tried this?
isEquivalent makes the items, uh, equivalent. So the parser won't try to
disambiguate -- it'll just pick one at random. So you'd have:
> L
Green Box Storeroom
You see three green boxes here.
> TAKE BOX
You take a green box.
> G
You take a green box.
> G
You take a green box.
> OPEN BOX
You open the box, revealing a small slip of paper reading, "DO NOT OPEN
THIS BOX."
If you want to play around with equivalent objects, go into the snack bar
at the opening of Lost New York and take a couple dozen napkins from the
dispenser, and see how they behave. (This is a good example of a place
where TADS' run-time object creation comes in handy, as well, BTW.)
Neil
---------------------------------------------------------
Neil deMause ne...@echonyc.com
http://www.echonyc.com/~wham/neild.html
---------------------------------------------------------
Mark Musante
Cardinal Teulbachs (card...@earthlink.net) wrote:
> olo...@roundlake.baxter.com (Mark Musante) wrote:
> >I think a legitimate question is: what does Hugo offer in addition
> >to this that makes it praiseworthy?
> every way, including having no distinctive adjectives to identify them
> with? Hugo can handle this (and maybe TADS can, too; I don't know,
> which is why I'm asking).
The adv.t library uses the flag "isEquivalent" to determine if you've
got more than one of the same item. I'm sure that WorldClass has
something similar (if not, ahem, equivalent). For example:
coin1: item
noun = 'zorkmid'
location = wherever
isEquivalent = true
sdesc = "zorkmid"
;
coin2: item
noun = 'zorkmid'
location = wherever
isEquivalent = true
sdesc = "zorkmid"
;
coin3: item
noun = 'zorkmid'
location = wherever
isEquivalent = true
sdesc = "zorkmid"
;
Will be listed, when the player enteres "wherever", as "You see three zorkmids
here." The player can then say "get 2 coins" or whatever.
As far as having objects which can be maipulated in ways other than being
picked up & dropped, the game structure breaks down. If, for example, these
were three green boxes, you'd have a hard time getting the right one to open.
If you said "open box", the game would just pick one to open, and the rest
would remain closed. You can then move them to different locations (including
the player object) in order to try to distinguish them, and allow the
disambiguation functions to take over, but that gets awkward for the player.
How does Hugo handle this case?
- Mark
BPD
card...@earthlink.net (Cardinal Teulbachs) wrote:
>What does TADS do with, say, three green boxes that are identical in
>every way, including having no distinctive adjectives to identify them
>with? Hugo can handle this (and maybe TADS can, too; I don't know,
>which is why I'm asking).
If I understand what you are talking about, TADS handles that with the
isEquivalant method. Items that have that quality set to true and
that are of the same immediate class(es) are considered interchangable
to the parser. So, if you have 3 identical boxes and say TAKE BOX,
the parser will just select one of the three at random.
Cardinal Teulbachs
olo...@roundlake.baxter.com (Mark Musante) wrote:
>Will be listed, when the player enteres "wherever", as "You see three zorkmids
>here." The player can then say "get 2 coins" or whatever.
>As far as having objects which can be maipulated in ways other than being
>picked up & dropped, the game structure breaks down. If, for example, these
>were three green boxes, you'd have a hard time getting the right one to open.
>If you said "open box", the game would just pick one to open, and the rest
>would remain closed. You can then move them to different locations (including
>the player object) in order to try to distinguish them, and allow the
>disambiguation functions to take over, but that gets awkward for the player.
>How does Hugo handle this case?
Exactly the same, I think. I'm a little confused, though, by what you
say about the difference between opening (or whatever) and picking up
and dropping equivalent objects. The same disambiguation problem
arises in every case, doesn't it? If you say "get 2 coins", the engine
will just have to get the first two (nonheld ones) it sees or pick two
at random, since it has no idea which two boxes the player might mean,
right? The only difference is that in the case of "get" and "drop" the
engine knows for sure that the player is talking about nonheld and
held objects, respectively, whereas with other verbs there's often no
way to determine which group it ought to be looking at, so it just
makes a guess. This is the way Hugo currently behaves, too, but there
may be a way around the problem.
I assume when you say that in the case of "open box" the game will
pick one to open, you also mean that "open two boxes" will get two
boxes opened? And "open boxes" will open all the available boxes? I'd
imagine it must if the authors have gone to the trouble of
implementing plurals-handling in the first place. It would be kind of
silly to have "open boxes" only open one box.
Lastly, is isEquivalent a user-modifiable routine of some sort? IOW,
can the rules for equivalent-object handling (or even simple plurals
handling) be changed and manipulated by the game author, or are those
hard-wired? I wouldn't count it a huge minus if it is hard-wired,
since who really wants to change the behavior anyway, but that's
really the only potential difference I see right now in the way Hugo
and TADS handle identical objects (and plurals in general).
Glad to know this about TADS. I didn't realize the old gal could do
this.
Kent Tessman
Dan Shiovitz (scy...@u.washington.edu) wrote:
: One advantage Hugo might have (pure speculation .. I use TADS m'self)
: is, if the plurals handling is indeed coded in Hugo, not hard-coded like
: TADS's is, then you could conceivably modify which items "boxes" refers
: to, depending on the situation. Another thing Hugo might offer is the
: ability to do something like this, which can't be done in TADS, AFAIK:
: >EXAMINE BOXES
: There's a whole bunch of boxes here, all shapes and sizes. Ok, actually
: there's just two.
: >GET BOXES
: red box: Taken.
: blue box: Taken.
: (that is, to have an item "boxes" to give a description of the group, as
: well as being able to manipulate individual members.)
:
: --
: dan shiovitz scy...@u.washington.edu sh...@cs.washington.edu
This is true. The default reaction for a plural/identical object or
group of objects is modifiable (and will become more so) through the
object library.
One reason I got so into coding the plural/identical objects skeleton was
because even I was impressed with the flexibility of non-hard-wired
parsing capable. The parser is coded into the engine (the basic parser,
anyway) for reasons of speed, efficiency, and neatness. It would be
possible to rewrite all or part of the parser as a front-end if the need
ever arose--with less or more difficulty, of course, depending on how
gymnastic the parsing was to get.
--Kent
Mark Musante
Cardinal Teulbachs (card...@earthlink.net) wrote:
> Exactly the same, I think. I'm a little confused, though, by what you
> say about the difference between opening (or whatever) and picking up
> and dropping equivalent objects. The same disambiguation problem
> arises in every case, doesn't it? If you say "get 2 coins", the engine
> will just have to get the first two (nonheld ones) it sees or pick two
It will get the first two nonheld coins.
> I assume when you say that in the case of "open box" the game will
> pick one to open, you also mean that "open two boxes" will get two
> boxes opened?
Yes, but you have to use the numeral "2".
> And "open boxes" will open all the available boxes?
All available closed boxes.
> Lastly, is isEquivalent a user-modifiable routine of some sort? IOW,
> can the rules for equivalent-object handling (or even simple plurals
> handling) be changed and manipulated by the game author, or are those
> hard-wired?
isEquivalent is part of the user-modifyable adv.t library; but general
plural handling is done within the parser.
- Mark
Den of Iniquity
On Sat, 21 Sep 1996, Cardinal Teulbachs wrote:
> Sorry, you MUST have a fancy signature file if you expect anyone to
> take you seriously
Oh. So that's where I usually go wrong. Sporadic .sig statements aren't
good enough?
Cardinal, you're the only person whose .sig I keep reading with interest
- just in case there's a new quote tacked on the end. Honestly.
--
Den
Den of Iniquity
Andrew! You're thinking of doing work on a new z-machine spec? I suppose
we're to believe it's acually named after you then?
--
Den - it'll fool newbies but you won't get it past me...
Andrew Plotkin
Den of Iniquity (dms...@york.ac.uk) wrote:
> Andrew! You're thinking of doing work on a new z-machine spec? I suppose
> we're to believe it's acually named after you then?
It won't be called that, because it will have little to do with the
existing Z-machine. (An early draft was labelled "Z-machine Infinity", but
it's really not a fair name, much like the parallel case of "Ultimate
AGT." This was before Matt released "Zip Infinity" for the Mac, which
tripled the confusion value.)
> [how do I pronounce my Z?]
The American way. (It has nothing to do with the Z-machine either.)
Now, what I want to know is, what's a Z bed? I recently bought an album
from a delightful British a capella folk group -- Artisan. One of their
songs was something about a "zed bed". I looked at the lyrics sheet and
saw that it was "Z bed", which is consistent, but doesn't tell me what the
thing is.
They were making fun of it. Apparently you have to inflate it.
Don Blaheta
Quoth Den of Iniquity:
> Oh. So that's where I usually go wrong. Sporadic .sig statements aren't
> good enough?
>
> Cardinal, you're the only person whose .sig I keep reading with interest
> - just in case there's a new quote tacked on the end. Honestly.
*sniff* I even have a random one...
Don
-=-=-=-Don Blaheta-=-=-=-bla...@quincy.edu-=-=-=-dbl...@aol.com-=-=-=-
And on the seventh day, He exited from append mode.
Rhodri James
erky...@netcom.com (Andrew Plotkin) wrote:
> Now, what I want to know is, what's a Z bed? I recently bought an album
> from a delightful British a capella folk group -- Artisan. One of their
> songs was something about a "zed bed". I looked at the lyrics sheet and
> saw that it was "Z bed", which is consistent, but doesn't tell me what
> the thing is.
> They were making fun of it. Apparently you have to inflate it.
Then they were confusing it with an airbed, I would guess. Z beds are
actually a variety of camp bed (I think), the sort that has three hinged
sections to the base and so folds up into a Z shape.
--
Rhodri James *-* Wildebeeste herder to the masses
If you don't know who I work for, you can't misattribute my words to them
... Intel Outside
Snaps
erky...@netcom.com (Andrew Plotkin) wrote an interesting piece,
here's my twopennyworth:
>> [how do I pronounce my Z?]
As in "wait", I'd always assumed.
>Now, what I want to know is, what's a Z bed? I recently bought an album
>from a delightful British a capella folk group -- Artisan. One of their
>songs was something about a "zed bed". I looked at the lyrics sheet and
>saw that it was "Z bed", which is consistent, but doesn't tell me what the
>thing is.
>They were making fun of it. Apparently you have to inflate it.
I don't think so, it's a folding bed, where the metal frame folds into
a 'Z' shape, see?
-- Si
Opinions expressed are those of every right thinking person.
Don Blaheta
Quoth Snaps:
> >from a delightful British a capella folk group -- Artisan. One of their
> >songs was something about a "zed bed". I looked at the lyrics sheet and
> >saw that it was "Z bed", which is consistent, but doesn't tell me what the
> >thing is.
> >
> >They were making fun of it. Apparently you have to inflate it.
>
> I don't think so, it's a folding bed, where the metal frame folds into
> a 'Z' shape, see?
Hm, sounds like your typical hideabed. I must say "zedbed" sounds
cooler, though. :)
Don
-=-=-=-Don Blaheta-=-=-=-bla...@quincy.edu-=-=-=-dbl...@aol.com-=-=-=-
Il brilgue: les toeves libricilleux
Se gyrent et frillant dans le guave,
Enmimes sont les gougebosquex,
Et le moemerade horgrave.
-- Lewis Carrol, "Through the Looking Glass"
Guido Lenz
ajc schrieb folgendes/wrote the following:
> Julian Arnold <jo...@arnod.demon.co.uk> wrote:
>
> > To your third, I'm sure the name didn't help-- try calling this new
> > format "<some alphabetical character>-code", A and Z are taken, maybe
> > P-code?
>
> S'been done. It's a bytecode compiled from Pascal, or summat.
Well, and in Geomatics P-Code is Precise Code, C/A Code is Coarse
Acquisition.
>
> IF-code?
>
> BCNU, AjC
Den of Iniquity
On 27 Sep 1996, Don Blaheta wrote:
> Quoth Den of Iniquity:
> > Cardinal, you're the only person whose .sig I keep reading with interest
> > - just in case there's a new quote tacked on the end.
>
> *sniff* I even have a random one...
Sorry Don... when I get to the bottoms of posts I scan the .sig and if
it's clearly got some 'random' element I'll have a look; sometimes I need
the sig to see who's written the message (I never seem to read the address
at the top) but the Cardinal's is the only one for which I think "Oh, the
Cardinal; let's see if he's quoting me (fat chance)".
--
Den
Francis Irving
On Thu, 26 Sep 1996 18:16:34 GMT, erky...@netcom.com (Andrew Plotkin)
wrote:
>> [how do I pronounce my Z?]
>
>The American way. (It has nothing to do with the Z-machine either.)
>
So what _does_ it have to do with?
(Or would that ruin it?)
Francis.
Andrew Plotkin
Rhodri James (rho...@wildebst.demon.co.uk) wrote:
> erky...@netcom.com (Andrew Plotkin) wrote:
> > Now, what I want to know is, what's a Z bed? I recently bought an album
> > from a delightful British a capella folk group -- Artisan. One of their
> > songs was something about a "zed bed". I looked at the lyrics sheet and
> > saw that it was "Z bed", which is consistent, but doesn't tell me what
> > the thing is.
> > They were making fun of it. Apparently you have to inflate it.
> Then they were confusing it with an airbed, I would guess. Z beds are
> actually a variety of camp bed (I think), the sort that has three hinged
> sections to the base and so folds up into a Z shape.
Ok. No, I was misunderstanding their lyrics. (It's folk music, not an RFC.)
It wasn't one of the better songs, anyway.
Don Blaheta
Quoth Den of Iniquity:
> Sorry Don... when I get to the bottoms of posts I scan the .sig and if
> it's clearly got some 'random' element I'll have a look; sometimes I need
> the sig to see who's written the message (I never seem to read the address
> at the top) but the Cardinal's is the only one for which I think "Oh, the
> Cardinal; let's see if he's quoting me (fat chance)".
*chuckle* That's ok, my sig is mostly for my own personal enjoyment
anyway.
Don
PS: It's not _entirely_ random. :)
-=-=-=-Don Blaheta-=-=-=-bla...@quincy.edu-=-=-=-dbl...@aol.com-=-=-=-
"Let's see if he's quoting me (fat chance)."