Is HTML TADS A Bad Idea?

LucFrench

unread,

Aug 5, 1998, 3:00:00 AM8/5/98

to

[This was writen a few days ago. I've decided to post it, in an attempt to get
some disscussion about the status of "improvements" to IF. Please forgive the
bad style, and poor backing up of arguements; I wrote this at three in the
morning. I know I'm making a fool out of myself, but WTH, you only live twice.
-LF]

WHY I THINK HTML
TADS IS A STEP
IN THE WRONG DIRECTION

A RANT

BY
LUC FRENCH

My rant breaks down as follows:

1. MIDI (HTML and HTADS main device in the way of music) isn't as versitile as
MODules.
2. HTML is a poor, crockish "language".
3. TADS is a poor "future of IF" design anyway. (Not that I'm claiming Inform
would be a better choice.)
4. Sound, not visuals, is a better way to head towards the "future of IF".
[This is intended to lead to point 5.]
5. HTML and the WWW are visual mediums, rather then textual or sound-based
ones.

Point 1 is the most difficult to explain for its value. If people are truely
interested, I'll explain it elsewhere. Suffice it to say that a MODule (no
matter if it is a XM, IT, S3M, WOW, or plain ol' MOD) is guarenteed to sound
*roughly* like what it does on your system (some loss of quality due to
inferior sound systems is inevitable), while a MIDI is not.

Point 2 is argued for me, by a method as simple as looking at HTML's revision
history. >BLOCKQUOTE< anyone? (As a secondary point, go to
http://www.stev0.com, and select the "Tribute to NetScape and Internet
Explorer. Prepare to be horrified.)

Point 3 centers around the status line. A bad status line model is inherent in
TADS (especially if you're going for backwords compatability with plain ol'
TADS...)

Point 4 is an old arguement. It goes something like this: sound is closer to
the emotion circuts then the eye. And most story telling is about emotion.

Point 5 can be argued by looking at Cool Links from Yahoo!, NetScape, Cool Site
of The Day, etc.; most are selected for 'looking cool', rather then the
content.

My final, and most important point, is that hypertext model was designed for
static texts, while a good piece of Interactive Fiction is a dynamic, changing
text.

Ah well.

Thanks
Luc "Overly Prone To Ranting" French

Jonadab the Unsightly One

unread,

Aug 5, 1998, 3:00:00 AM8/5/98

to

LucFrench <lucf...@aol.com> wrote in article

> My rant breaks down as follows:
>
> 1. MIDI (HTML and HTADS main device in the way of music) isn't as
versitile as
> MODules.

I would not know.

> 2. HTML is a poor, crockish "language".

True.

> 3. TADS is a poor "future of IF" design anyway. (Not that I'm claiming
Inform
> would be a better choice.)

Just because of a status line?

> 4. Sound, not visuals, is a better way to head towards the "future of
IF".
> [This is intended to lead to point 5.]

See below!

> 5. HTML and the WWW are visual mediums, rather then textual or
sound-based
> ones.

Of course.

I had already been thinking that what would be *really* cool would be a
version of
Frotz (or whatever) that had an option to read the text aloud as it
displayed it.

Input will still need to be typed until voice recognition is a bit better
and cheaper...

Yr. Obd't & Humble Servant,
Jonadab the Unsightly One

----------------

Different expectations. Crash my Windoze laptop and I'll shrug, reboot
and carry on. Crash my Unix desktop and I'll dig out the debugger.
Crash my palmtop and I'll delete every application you've written from
my machines and *hate* you.

-- Bryan Scattergood

----------------

Send replies to username@isp, where username is jonadab
and isp is bright.net

The zerospam.com address works, but you get an ugly confirmation.

LysseusD

unread,

Aug 5, 1998, 3:00:00 AM8/5/98

to

>Point 4 is an old arguement. It goes something like this: sound is closer to
>the emotion circuts then the eye. And most story telling is about emotion.
>

There does seem to be a distinct lack of emotion in IF. One certainly doesn't
identify with characters, probably due to its simplified narrative.

But what you're suggesting is a parser that recognises spoken words, or at the
very least a system that talks back to you, eh?

The problem is that sound is a very linear way of gathering information,
whereas sight is not as tightly bound.

Hmmmm.

Kev

Magnus Olsson

unread,

Aug 5, 1998, 3:00:00 AM8/5/98

to

In article <199808050654...@ladder03.news.aol.com>,
LucFrench <lucf...@aol.com> wrote:

> 1. MIDI (HTML and HTADS main device in the way of music) isn't as versitile as
> MODules.

> 2. HTML is a poor, crockish "language".

> 3. TADS is a poor "future of IF" design anyway. (Not that I'm claiming Inform
> would be a better choice.)

> 4. Sound, not visuals, is a better way to head towards the "future of IF".
> [This is intended to lead to point 5.]

> 5. HTML and the WWW are visual mediums, rather then textual or sound-based
> ones.
>

> Point 1 is the most difficult to explain for its value. If people are truely
> interested, I'll explain it elsewhere. Suffice it to say that a MODule (no
> matter if it is a XM, IT, S3M, WOW, or plain ol' MOD) is guarenteed to sound
> *roughly* like what it does on your system (some loss of quality due to
> inferior sound systems is inevitable), while a MIDI is not.

This is a valid point that has been raised in the discussions of
extended Z-machine formats (BLORB, IIRC). But it can hardly be used as
an argument that HTADS is a "step in the wrong direction" - surely
HTADS can be modified to use MOD rather than (or in addition to) MIDI?

> Point 2 is argued for me, by a method as simple as looking at HTML's revision
> history. >BLOCKQUOTE< anyone? (As a secondary point, go to
> http://www.stev0.com, and select the "Tribute to NetScape and Internet
> Explorer. Prepare to be horrified.)

I think this point will have to rest until people have been using
HTADS for a while. My suspicion is that a typical HTADS program would
use HTML in quite a different way from a typical Web page design, and
that the HTADS author may not encounter the "crockishness" of HTML in
the ways that a web designer does.

> Point 3 centers around the status line. A bad status line model is inherent in
> TADS (especially if you're going for backwords compatability with plain ol'
> TADS...)

When I read the first part of your point 3 - that TADS is a poor
"future of IF design" - I expected a reopening of the "current IF
languages can't do what I want; I want a visual do-what-I-mean
development system" debate, to which I would have replied that sure,
we all know that, but those ideal "future of IF" languages don't
exist, while TADS does, and has a proven record.

But then I read the sentence about the status line, and I'm
confused. Sure, TADS's status line model is a bit rigid, but is that
really reason enough to condemn the entire HTADS project? If you want
to do fancy things with the status line, can't you use the HTML
features instead? But I'm afraid I don't know enough about what you
want to do with the status line, and why this point (which to me seems
very minor) is so central to your argument.

> Point 4 is an old arguement. It goes something like this: sound is closer to
> the emotion circuts then the eye. And most story telling is about emotion.

Says you.

OK, more people than you say it. But there is no consensus on
this. I'd like to sharpen my point a bit: to me, there seems to be
far more interest in - and actual demand for - enhancing text
adventures with fancy visual formatting and images than for enhancing
them with sounds. HTADS addresses this demand.

Furthermore, even granted your point (and I'm not saying that you're
wrong, just that different people want to do different things: some
want to use pictures, others want sounds), you seem to be saying that
"The future of IF is in sound; therefore any addition of graphic
capabilities is a step in the wrong direction". This, to put it
bluntly, is an extremely narrow-minded way of looking at things.

> Point 5 can be argued by looking at Cool Links from Yahoo!, NetScape, Cool Site
> of The Day, etc.; most are selected for 'looking cool', rather then the
> content.

I'd say that point 5 is utterly irrelevant; you're barking up the
wrong tree. HTADS is not about the web. The web and HTADS are two
entirely different universes that just happen to share a common markup
language.

And HTML is not a medium - it's a language. The Web is a medium. IF is
a different medium. That doesn't mean that they can't both use the
same markup language. Of course, that may mean that the language is
sub-optimal for one - or both - of the media. But if that's your
point, you'll need to back it up with concrete evidence.

> My final, and most important point, is that hypertext model was designed for
> static texts, while a good piece of Interactive Fiction is a dynamic, changing
> text.

Again, you're barking up the wrong tree. Who said anything about
hypertext? HTML was designed for hypertext, just as C was designed for
writing operating systems. That doesn't mean you can't use those
languages for IF. It seems to me that a good piece of HTML IF can use
HTML for *formatting* its output, while remaining a "dynamic, changing
text".

That said, some people may very well find it convenient to add some
hypertext features to IF. For example, in the Gold Skull Demo, you can
click on the names of objects and get the same effect as if you typed
"examine object" (personally, I find this feature of that particular
demo rather clunky, but that may be the implementation), but that does
*not* turn the entire game into a hypertext.

--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------

Iain Merrick

unread,

Aug 5, 1998, 3:00:00 AM8/5/98

to

LucFrench wrote:

> 1. MIDI (HTML and HTADS main device in the way of music) isn't as versitile as
> MODules.

One big advantage of MIDI is that music files are very, very small,
since they don't include any sampled sounds.

Of course, this means that they sound different on every platform; but
they don't necessarily sound _worse_ than, say, MODs. I use QuickTime 3
to play MIDI files on my mac, and the quality is rather good.

MIDI is better (IMHO) for simulating orchestral instruments, which in
turn are better suited (IMHO) to the sort of atmosphere you might want
to invoke in an IF game. Note that the incidental music in films is
usually orchestral (although the actual them tune could be a pop song or
whatever.)

For a fast-paced, violent game, an exciting, rhythmic MOD might well be
more effective than MIDI music. But that's not IF.

Anyway, as someone already pointed out, HTML-TADS could easily be
extended to handle MODs without breaking anything in the process.

Den of Iniquity

unread,

Aug 5, 1998, 3:00:00 AM8/5/98

to

[This was written a few moments hence. I've decided to post it in an
attempt to inject some 'humour' into rai-f. Please forgive the obvious
derivation from another letter and poor arguments but I'm constrained by
the format and this is not intended to be any slight against Luc himself.
I just thought it would be funny, though I admit that it is about one in
the afternoon. I know I'm making a fool out of hisself but WTH, he only
lives twice. -DS]

WHY I THINK LUC
FRENCH IS A STEP
IN THE WRONG DIRECTION

A SHAMELESS LAMPOON

My rant breaks down as follows:

1. LUCFRENCH isn't as versitile as GRAHam NELson, for example.

2. LUCFRENCH uses poor, crockish "language".

3. LUCFRENCH is a poor "future of humankind" design anyway. (Not that I'm
claiming Graham Nelson would be a better choice.

4. Science, not spirituality, is a better way to head towards the "future
of humankind". [This is intended to lead to point 5.]

5. LUCFRENCH is a spiritual medium.

Point 1 is the most difficult to explain for its value. If people are
truely interested, I'll explain it elsewhere. Suffice it to say that

Graham Nelson, whether mathematician, poet, mountain-climber, computer
scientist or plain ol' 'Nellie') is guarenteed to meet some of your
expectations (some loss of quality due to inferior imaginations is
inevitable), while Luc French's behaviour is more erratic and less likely
to conform to your standards.

Point 2 is argued for me, by a method as simple as looking at LucFrench's
revision history. The 'Babylon 5 incident' anyone? Narn Bat Squads? (As a

secondary point, go to http://www.stev0.com, and select the "Tribute to

LucFrench". Prepare to be horrified.)

Point 3 centers around his status line. A bad status line model
is inherent in LucFrench (especially if you're going for backwords
compatability with plain ol' Luc, the kindergarten kid...)

Point 4 is an old arguement. It goes something like this: science and
reason and philosophical advancement cover the whole spiritual thing and
more besides. Spirituality alone can only advance us so far.

Point 5 can be argued by looking at mediums. Mediums are chosen for their
looks as much as anything and not on inherent abilities. Yeah, I'm
definitely losing it at this point. But hey, would you go to a medium who
looked like, say, Jim Carrey?

My final, and most important point, is that 'LucFrench' was designed
for static visual media emission interception, while a good piece of human
being is a dynamic, changing conception engineer.

>Thanks
>Luc "Overly Prone To Ranting" French

Sorry Luc. I'm overly prone to ribbing. Smileys all round.

--
Den

Iain Merrick

unread,

Aug 5, 1998, 3:00:00 AM8/5/98

to

Den of Iniquity wrote:

[...]
> Smileys all round.

Maybe he needs more exercise.

Den of Iniquity

unread,

Aug 5, 1998, 3:00:00 AM8/5/98

to

On Wed, 5 Aug 1998, Iain Merrick wrote:

>> Smileys all round.
>
>Maybe he needs more exercise.

I can't believe you did that pun.

{rubs eyes, looks again, still amazed}

Iain Merrick

unread,

Aug 5, 1998, 3:00:00 AM8/5/98

to

Den of Iniquity wrote:

Um. I'm not sure it deserved _that_ reaction, though.

I'm still not sure whether it's a _Hitchhiker's Guide_ allusion [1] or a
_Yes, Minister_ allusion [2]. Not to mention _Smiley's People_.

[1] "Eddies in the wash." "And this is his sofa, is it?"
[2] "Who is Round and to what does he object?"

Allen Garvin

unread,

Aug 5, 1998, 3:00:00 AM8/5/98

to

1. MIDI (HTML and HTADS main device in the way of music) isn't as
versitile as MODules.

I find both of them rather "dry". They're not performances, just notes
played literally. I'm sure mod-capabilities could be added without much
difficulty, anyway.

5. HTML and the WWW are visual mediums, rather then textual or
sound-based ones.

When HTML was first designed and the web was young, a darned lot of things
were not nearly as visual as they are today. Mosaic didn't even support jpegs
at first. There are still a small cadre of people around that design web
pages to be viewable with lynx, and make pretty effective pages.

The nice thing about HTML instead of some new, alternate way of formatting
text and including pictures and stuff, is that nearly everyone today knows
how to write HTML, or at least use an HTML editor. And HTML viewers are
ubiquitous. I think it does the required job reasonably well.
--
Allen Garvin I think I'll
--------------------------------------------- Let the mystery be
eare...@faeryland.tamu-commerce.edu
http://faeryland.tamu-commerce.edu/~earendil Iris Dement

Erik Max Francis

unread,

Aug 5, 1998, 3:00:00 AM8/5/98

to

LucFrench wrote:

> My rant breaks down as follows:

...

> 2. HTML is a poor, crockish "language".

...

> 5. HTML and the WWW are visual mediums, rather then textual or
> sound-based
> ones.

...

> Point 2 is argued for me, by a method as simple as looking at HTML's
> revision
> history. >BLOCKQUOTE< anyone?

What is your argument with the BLOCKQUOTE tag? That's the best argument
against HTML you could come up with?

HTML is a simple markup language. It is very simple, easy-to-use, and
uncomplicated.

> (As a secondary point, go to

> http://www.stev0.com, and select the "Tribute to NetScape and Internet
> Explorer. Prepare to be horrified.)

This is hardly a good example of why HTML itself is a bad markup
language. You can make an awful looking document in _any_ markup
language.

> Point 5 can be argued by looking at Cool Links from Yahoo!, NetScape,
> Cool Site
> of The Day, etc.; most are selected for 'looking cool', rather then
> the
> content.

That doesn't follow. Certainly, I will agree that the Web is not for
sound (and shouldn't be, because it's only nonstandard HTML extensions
that allow support for automatically-played sound), but how you conclude
that the Web is not for text because of Yahoo! is beyond me.

Yahoo! is among the simpler large web sites out there. It's not
embellished too much, and its only purpose is to present the categories.
You may not like it, but the emphasis is more on its content than on its
appearance.

Want to deemphasize the appearance of a page and draw more attention to
its textual context? Only use text. Seems pretty obvious to me.

--
Erik Max Francis / email m...@alcyone.com / whois mf303 / icq 16063900
Alcyone Systems / irc maxxon (efnet) / finger m...@sade.alcyone.com
San Jose, CA / languages En, Eo / web http://www.alcyone.com/max/
USA / icbm 37 20 07 N 121 53 38 W / &tSftDotIotE
\
/ I've got the fever for the flavor of a cracker
/ Ice Cube

Den of Iniquity

unread,

Aug 5, 1998, 3:00:00 AM8/5/98

to

On 5 Aug 1998, LucFrench wrote:
>1. MIDI (HTML and HTADS main device in the way of music) isn't as versitile as
>MODules.

OK. This one is the strongest part of your argument. There are fairly
clear advantages and disadvantages to both forms.

MODs will indeed sound more like the originally intended music. But
they're big. MIDI files are small. Admittedly, most of the size of MODs is
instrument data, so once that's accounted for, the rest of the module
won't be that much bigger than a corresponding MIDI file.

I've got a module - Maple Leaf Rag - perhaps appropriate for some classier
joint with some guy rattling out Joplin numbers on the old ivories. It's
one and a half minutes, and 200k. A midi file version of the same would be
8k or so. OK, now if you had 30 minutes of piano music, the two formats
are going to increase by about the same amount - say another 50k, allowing
some repetition - the midi is still far preferable in size but now the
difference isn't quite so great.

Then of course Luc's right to consider the sound card. Perhaps you've got
a non-midi card, with just a few voices and no real processing power of
its own (maybe like me you've got a 4-voice 14-bit sound chip called
'Paula' from the mid-eighties in your computer. Love her to bits,
honestly). Not only will the music sound much tinnier, but mixing the
waveforms together to squeeze them out of your sound output is also
hogging your processor (thank heavens for hardware preemptive
multitasking. Phew! Paula need not retire just yet). Of course in such
cases those 16 channel XM's and S3M's are going to be just as problematic
- not quite as tinny and chip-music-like but just as processor intensive.

So basically I can't for the life of me choose between the two
different systems. And as has been said already, it wouldn't be so hard to
implement MOD playing at some future date.

But are you going to play music throughout the game? Think about it. A
'short' game is going to have someone playing it for over an hour,
possibly two hours. If music is involved throughout, then you've either
got to produce a heck of a lot of it, or you're going to irritate the
player with repetition. I'm pretty sure sound-effects would play a bigger
role in HTML-TADS sound production than music - apart from anything else
they require a lot less musical talent on the part of the author. How
about a heavy heart-beat track for those horror moments, the odd crack of
thunder, heavy steps as you hide from your adversary - or ambient
background noise whether it be standing by the interstate (cars rushing
past), or the dull conversational throb of a bar. The rasp of your scuba
gear as you dive to find treasures on the sea bed. Perhaps you've just
entered your apartment, you might hear your phone ringing and that'd give
you a much stronger impulsion to answer the damned thing than a text
message (though you'd still need the text, I suppose, in case your
audience isn't getting the sound).

I can't remember the HTML-TADS specifications but I'd
be surprised if there wasn't a WAV or AIFF compatability in there
somewhere.

Mind you, let's suppose you wanted your ambient 'interstate background
noises' track to have the occasional 'Buckaw!' of a chicken thrust into it
at irregular intervals. Now there's a good case for a MOD format. Easier
to do that way, and I don't think I remember 'chicken call' as being in
amongst my midi wave-files (then again, I do seem to remember 'helicopter'
so I suppose it isn't _that_ unlikely, though I suspect that 'helicopter'
is only included so people can write midi versions of the Airwolf theme
tune).

I'd be interested to see the way Guilty Bastards uses the media of
graphics and sound. But I'm still awaiting that Amiga port of the Hugo
engine. Is anyone working on that?

--
Den

TenthStone

unread,

Aug 5, 1998, 3:00:00 AM8/5/98

to

lucf...@aol.com (LucFrench) caused this to appear in our collective minds on 5 Aug 1998 06:54:45 GMT:

>1. MIDI (HTML and HTADS main device in the way of music) isn't as versitile as
>MODules.

No. Because of the smaller size of MIDI modules, they are far more versatile. What
they are not is especially good-sounding. Case in point, the piano. But they are more
versatile, as they can be used nearly anywhere without inspiring extreme pain to the
listener.

>2. HTML is a poor, crockish "language".

If you mean as a programming language, yes. If you mean as a document-formatting
language, no. It is not as efficient as, say, WordPerfect; it is not as adaptable as the
same; it is not as elegant as the same. But it is an easily writable markup language
allowing a sizable range of design choices, provided that the author has at least some
degree of taste. And that is not something that can be handled by an easier language.

Well, no. I think that any poor Joe on the planet could type something into WordPerfect
and it would probably come out looking good. The problem is that formatting for a screen
is much harder than formatting for the printed page.

>3. TADS is a poor "future of IF" design anyway. (Not that I'm claiming Inform
>would be a better choice.)

No; I think TADS has the potential to be elegantly simple enough for anyone, yet complex
enough to make room for extensive customization. I do not think HTML TADS has been
implemented very well; I think that MJR has taken some steps in the wrong direction
by pushing on us things that we shouldn't need to deal with, such as character encoding, and
I think the TADS source code should consist entirely of objects, functions and a small
family of directives (#include). I do not believe that #IFDEF is the right way to go. I,
personally, will continue to program what little output I make in TADS 2.2.3, keeping a
minimalist copy of 2.2.4 in a directory on the disk should I need it someday.

>4. Sound, not visuals, is a better way to head towards the "future of IF".

>[This is intended to lead to point 5.]

I disagree completely. I read much faster than I listen. To me, the future of IF will be
a long series of consistently superior parsers, as the artistic side holds almost nothing that
we cannot accomplish already (outside of the development of said superior parsers).

>5. HTML and the WWW are visual mediums, rather then textual or sound-based
>ones.

This is matter of opinion, completely defined by one's usage of the web. If you are
performing research, that is (largely) a textual matter, and the parts of the internet
that you chance upon will be so. If you are idly browsing, you will probably find a
great deal of pictures -- but I find that even then, my attention is held by the text, not
the flashy graphics. But you are right in that the web is not sound-based.

>Point 1 is the most difficult to explain for its value. If people are truely

>interested, I'll explain it elsewhere. Suffice it to say that a MODule (no
>matter if it is a XM, IT, S3M, WOW, or plain ol' MOD) is guarenteed to sound
>*roughly* like what it does on your system (some loss of quality due to
>inferior sound systems is inevitable), while a MIDI is not.

Except that MODs do not support speech very well. MIDI, of course, doesn't support
it at all, but the lack of speech support casts doubt on the ability of a MOD to 'advance'
the IF medium to a auditory focus.

>Point 2 is argued for me, by a method as simple as looking at HTML's revision

>history. >BLOCKQUOTE< anyone? (As a secondary point, go to

>http://www.stev0.com, and select the "Tribute to NetScape and Internet
>Explorer. Prepare to be horrified.)

I use blockquote; in fact, I find it often one of the most useful tags. And I find frames
to be quite helpful in site formatting (the use of frames being one of the things stev0 berated).
I also find that even such things as JavaScript can be an enormous boon to a site
(see www.odu.edu for an especially attractive page).

>Point 3 centers around the status line. A bad status line model is inherent in
>TADS (especially if you're going for backwords compatability with plain ol'
>TADS...)

The only problems I see with the status line are that the TADS status line can
only be one line, and that line is always defined in two sections. Either side
is completely customizable.

>Point 4 is an old arguement. It goes something like this: sound is closer to
>the emotion circuts then the eye. And most story telling is about emotion.

Proximity defines magnitude and thus effect? That's questionable.
Additionally, which segments of the 'emotion circuits'? I'm certain that
seperate emotions are handled differently, in one section of the brain versus
another. Intellectual emotions? Fear, love, and jealousy seem, to me, to come
from another portion entirely than desire and calm.

>Point 5 can be argued by looking at Cool Links from Yahoo!, NetScape, Cool Site
>of The Day, etc.; most are selected for 'looking cool', rather then the
>content.

It can be, but not very well. I wouldn't say that the "most popular" sites are by any
means representative of the whole. If they were, wouldn't we be playing Quake II
right now?

>My final, and most important point, is that hypertext model was designed for
>static texts, while a good piece of Interactive Fiction is a dynamic, changing
>text.

That's an interesting point. I haven't actually played HTML-TADS, not having the
required Windows 95 (I felt comfortable arguing the point since I have looked at
the libraries for 2.2.4, and I have experienced both TADS and HTML in their glory
and their lack thereof), but would you care to inform me how it handles output?
I was under the impression that it was a long, scrollable document, much like current
TADS, except with fancier formatting and audio/visual support. Perhaps it's not.

Promising I won't hold the rant against you, I am always,
-- TenthStone

-----------

The inperturbable TenthStone
tenth...@hotmail.com mcc...@erols.com mcc...@gsgis.k12.va.us

Bill

unread,

Aug 6, 1998, 3:00:00 AM8/6/98

to

LucFrench wrote in

> WHY I THINK HTML
> TADS IS A STEP
> IN THE WRONG DIRECTION

>

>1. MIDI (HTML and HTADS main device in the way of music) isn't as versitile
as
>MODules.

I love MOD files. I used to be a "hot shot" Amiga programmer (co-founded
AEGIS development). But hey, MIDI's a lot more accepted, and it's smaller
to boot.

>2. HTML is a poor, crockish "language".

Yes, it can be abused. BUT it's also as good as standard as we've got.
Lots of tools support it.

>3. TADS is a poor "future of IF" design anyway. (Not that I'm claiming
Inform
>would be a better choice.)

Beats me. I Like Lisp.

>4. Sound, not visuals, is a better way to head towards the "future of IF".
>[This is intended to lead to point 5.]

HTML-TADS should support sampled sounds ...

>5. HTML and the WWW are visual mediums, rather then textual or sound-based
>ones.

Not if Real Networks and others have their way.

>Point 1 is the most difficult to explain for its value. If people are
truely
>interested, I'll explain it elsewhere. Suffice it to say that a MODule (no
>matter if it is a XM, IT, S3M, WOW, or plain ol' MOD) is guarenteed to
sound
>*roughly* like what it does on your system (some loss of quality due to
>inferior sound systems is inevitable), while a MIDI is not.

The latest MIDI stuff under Windows and the Mac (General MIDI) is pretty
good.

>
>Point 2 is argued for me, by a method as simple as looking at HTML's
revision
>history. >BLOCKQUOTE< anyone? (As a secondary point, go to
>http://www.stev0.com, and select the "Tribute to NetScape and Internet
>Explorer. Prepare to be horrified.)

Frames are terrible ... perhaps only usefull used for a menu bar. I love
that sample page .... truly horrific.

>Point 4 is an old arguement. It goes something like this: sound is closer
to
>the emotion circuts then the eye. And most story telling is about emotion.

Yep.

>Point 5 can be argued by looking at Cool Links from Yahoo!, NetScape, Cool
Site
>of The Day, etc.; most are selected for 'looking cool', rather then the
>content.

Bad Taste is contagious.

However Flash Animation might be a good way of supporting Internet Delivered
IF with a ANIME look.

>My final, and most important point, is that hypertext model was designed
for
>static texts, while a good piece of Interactive Fiction is a dynamic,
changing
>text.

Most WWW sites (at least the good ones) are using CGI scripts, Java Servets,
ASP's, Databases, or whatever to generate that HTML dynamically. The HTML
you see didn't even "exist" until you navigated to that page.

Bill

L. Ross Raszewski

unread,

Aug 6, 1998, 3:00:00 AM8/6/98

to

In article <Pine.SGI.3.95L.98080...@ebor.york.ac.uk>,

Den of Iniquity <dms...@york.ac.uk> wrote:
> Then of course Luc's right to consider the sound card. Perhaps you've got
> a non-midi card, with just a few voices and no real processing power of
> its own (maybe like me you've got a 4-voice 14-bit sound chip called
> 'Paula' from the mid-eighties in your computer. Love her to bits,
> honestly). Not only will the music sound much tinnier, but mixing the
> waveforms together to squeeze them out of your sound output is also
> hogging your processor (thank heavens for hardware preemptive
> multitasking. Phew! Paula need not retire just yet). Of course in such
> cases those 16 channel XM's and S3M's are going to be just as problematic
> - not quite as tinny and chip-music-like but just as processor intensive.
>

THough, as a side-note, My minimal research tells me that a 4-channel MOD
(the early formats before XM s3m and whatnot) will play better on Paula than
a lot of other systems, and, in fact, MOD was _developed_ on/for Paula.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum

Neil K.

unread,

Aug 6, 1998, 3:00:00 AM8/6/98

to

Den of Iniquity <dms...@york.ac.uk> wrote:

> I can't remember the HTML-TADS specifications but I'd
> be surprised if there wasn't a WAV or AIFF compatability in there
> somewhere.

It does indeed support WAV format digitized sound. At least, it does if
your computer has such audio capabilities.

> Mind you, let's suppose you wanted your ambient 'interstate background
> noises' track to have the occasional 'Buckaw!' of a chicken thrust into it

> at irregular intervals. Now there's a good case for a MOD format. [...]

Actually, HTML TADS has a terrific way of addressing this case. You can
specify a sound to be played in a background ambient layer with a
randomness value set. I use this in my "Golden Skull" demo game. I have
the looped sound of crickets that repeats constantly at a low volume, with
a bird call being repeated over top at random intervals.

The idea is you can have a moderately small looping background sound
(naturally you choose and edit the sound such that there are no obvious
looping points for the ear to catch) with a random layer over top. This
means you don't have to have a gigantic sample; the only other way to get
a good background sound that doesn't repeat in an obvious and annoying
fashion. Another example would be to have a loop of waves crashing on a
beach and then sticking in the sound of a seagull over top at a low random
interval.

Done well, this kind of ambient sound can be very evocative thing. Done
poorly, and you simply turn the interpreter's sound option off. :)

- Neil K.

--
t e l a computer consulting + design * Vancouver, BC, Canada
web: http://www.tela.bc.ca/tela/ * email: tela @ tela.bc.ca

Den of Iniquity

unread,

Aug 6, 1998, 3:00:00 AM8/6/98

to

On Thu, 6 Aug 1998, Neil K. wrote:

> Den of Iniquity <dms...@york.ac.uk> wrote:

>> Mind you, let's suppose you wanted your ambient 'interstate background
>> noises' track to have the occasional 'Buckaw!' of a chicken thrust into it
>> at irregular intervals. Now there's a good case for a MOD format. [...]
>
> Actually, HTML TADS has a terrific way of addressing this case. You can
>specify a sound to be played in a background ambient layer with a
>randomness value set.

Excellent! Top marks to Mike!

--
Den

Trevor Barrie

unread,

Aug 6, 1998, 3:00:00 AM8/6/98

to

On 5 Aug 98 13:17:38 GMT, Allen Garvin <eare...@faeryland.tamu-commerce.edu>
wrote:

>When HTML was first designed and the web was young, a darned lot of things
>were not nearly as visual as they are today. Mosaic didn't even support jpegs
>at first. There are still a small cadre of people around that design web
>pages to be viewable with lynx, and make pretty effective pages.

This small cadre is known as the "competent web designers".

(No, I'm not saying all competent web designers make text-only attractiveness
a primary concern. But the amount of effort needed to make a web page at
least viewable under Lynx is insignificant enough that a failure to do so
is indicative of complete ineptitude. And yes, there are a healthy number
of completely inept people passing themselves off as professional web
designers out there.)

Kevin Bracey

unread,

Aug 6, 1998, 3:00:00 AM8/6/98

to

In message <35c85...@news.tamu-commerce.edu>
eare...@faeryland.tamu-commerce.edu (Allen Garvin) wrote:

>
> 5. HTML and the WWW are visual mediums, rather then textual or
> sound-based ones.
>

> When HTML was first designed and the web was young, a darned lot of things
> were not nearly as visual as they are today. Mosaic didn't even support
> jpegs at first. There are still a small cadre of people around that design
> web pages to be viewable with lynx, and make pretty effective pages.
>

> The nice thing about HTML instead of some new, alternate way of formatting
> text and including pictures and stuff, is that nearly everyone today knows
> how to write HTML, or at least use an HTML editor. And HTML viewers are
> ubiquitous. I think it does the required job reasonably well.

My personal feeling is that HTML, while being pragmatically an understandable
choice, is philosophically wrong.

HTML is a markup language designed to show the structure of a document.
In HTML-TADS you seem to want a style markup language to enable you to
change text style, colour, etc. This is exactly what HTML should not
be and what the W3C are pushing hard to get it away from. All of
<FONT>, <xxx BGCOLOR>, <BODY BACKGROUND>, <U>, <IMG BORDER> etc are
deprecated in the current HTML specification.

Much of HTML-TADS' syntax isn't HTML anyway (<SOUND>, <ABOUTBOX>?).
If that's the case, why not stop pretending that it is a subset of deprecated
HTML and define it as a new specfic SGML implementation, with its own DTD?

--
Kevin Bracey, Senior Software Engineer
Acorn Computers Ltd Tel: +44 (0) 1223 725228
Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/

Darin Johnson

unread,

Aug 6, 1998, 3:00:00 AM8/6/98

to

tba...@ibm.net (Trevor Barrie) writes:

> (No, I'm not saying all competent web designers make text-only attractiveness
> a primary concern. But the amount of effort needed to make a web page at
> least viewable under Lynx is insignificant enough that a failure to do so
> is indicative of complete ineptitude. And yes, there are a healthy number
> of completely inept people passing themselves off as professional web
> designers out there.)

I don't think it's ineptitude, I think it's plain ignorance.
Ignorance that other people will have different types of browsers and
machines and monitors. I suspect a lot of them know the rules about
how to add image labels, but they have never personally run across a
situation where they were needed (despite the fact that it's trivial
in Netscape to tell it to not load images).

Ineptitude is the guy that designed the web site for a company I used
to be at (and was paid nicely for it), that turned out to be one
single 640x480 image map. When viewed from Lynx it said "<image>".
When viewed under normal resolution, the text was too small to be
easily viewed.

--
Darin Johnson
da...@usa.net.delete_me

TenthStone

unread,

Aug 6, 1998, 3:00:00 AM8/6/98

to

Darin Johnson <da...@usa.net.removethis> caused this to appear in our collective minds on 06 Aug 1998 13:22:33 -0700:

>tba...@ibm.net (Trevor Barrie) writes:
>I don't think it's ineptitude, I think it's plain ignorance.
>Ignorance that other people will have different types of browsers and
>machines and monitors. I suspect a lot of them know the rules about
>how to add image labels, but they have never personally run across a
>situation where they were needed (despite the fact that it's trivial
>in Netscape to tell it to not load images).

Or even monitor resolutions... ZDNet, typically very good at things like this, has
a horribly inefficient web-page design that uses about one-half of my screen.
These are hte people that consistently praise and advise the use of large monitors
for web browsing.

Of course, I don't actually have a large monitor; I just squint a lot.

Neil K.

unread,

Aug 7, 1998, 3:00:00 AM8/7/98

to

Kevin Bracey <kbr...@acorn.co.uk> wrote:

> Much of HTML-TADS' syntax isn't HTML anyway (<SOUND>, <ABOUTBOX>?).

I wouldn't say "much". HTML TADS supports two or three new custom tags to
support several new functions. And a handful of new tag attributes. But
everything else it supports is fairly normal HTML.

> If that's the case, why not stop pretending that it is a subset of deprecated
> HTML and define it as a new specfic SGML implementation, with its own DTD?

Well... what would that give us? Mike would have to expend a lot of time
and energy writing up a DTD, and I really don't think it'd be of any
utility whatsoever to the typical TADS author. It might be ideologically
satisfying to do, but strikes me as having relatively low practical value.
How many people use SGML editors and load up DTDs in real life?

Magnus Olsson

unread,

Aug 7, 1998, 3:00:00 AM8/7/98

to

In article <fake-mail-070...@van-52-0208.direct.ca>,
Neil K. <fake...@anti-spam.address> wrote:

> Kevin Bracey <kbr...@acorn.co.uk> wrote:
>> If that's the case, why not stop pretending that it is a subset of deprecated
>> HTML and define it as a new specfic SGML implementation, with its own DTD?
>
> Well... what would that give us? Mike would have to expend a lot of time
>and energy writing up a DTD, and I really don't think it'd be of any
>utility whatsoever to the typical TADS author. It might be ideologically
>satisfying to do, but strikes me as having relatively low practical value.
>How many people use SGML editors and load up DTDs in real life?

I think the ideological issue is of at least _some_ importance:
as long as HTML TADS uses the word "HTML", then

a) a lot of people will jump to conclusions like HTADS being somehow
connected with the WWW, or HTADS only being fit for writing hypertext
IF, or HTADS requiring a web browser to run.

and

b) there is the question (which I think is Kevin's "philosophical"
objection, right?) whether the future development and philosophy of
HTADS will be tied up to that of HTML-as-used-for-Web design.

This could be avoided by not ussing the word HTML, but just saying,
for example, that "HTADS uses a markup language very similar to HTML".

On the other hand, there's great "publicity value" in the name "HTML
TADS" - people will think "OK, I know some HTML already, so I'll be
able to learn this quickly", or "I'll be able to use my HTML editor to
write TADS games". Calling it something else would require explaining
this to people...

Matt Ackeret

unread,

Aug 7, 1998, 3:00:00 AM8/7/98

to

In article <199808050654...@ladder03.news.aol.com>,

LucFrench <lucf...@aol.com> wrote:
>My rant breaks down as follows:
>

>1. MIDI (HTML and HTADS main device in the way of music) isn't as versitile as
>MODules.

Really? I was under the impression that MODs are *very very very*
simplistic, and are based upon some limited IBM PC sound card's original
formats. (Or was it something on the Amiga? I admittedly can't remember..)

But they're like limited to 4 channels, *in the format itself*.. So then to
get past that limit, there kept being new hacked versions of MOD players, and
MOD files, so some players would play some sounds, but not all.. not at all
well designed like the MIDI format.

>2. HTML is a poor, crockish "language".

Really? It works pretty damn well at what it was _intended_ for.. More on
that later.

>3. TADS is a poor "future of IF" design anyway. (Not that I'm claiming Inform
>would be a better choice.)

I don't know much about TADS so can't comment..

>4. Sound, not visuals, is a better way to head towards the "future of IF".
>[This is intended to lead to point 5.]

Arguable either way.

>5. HTML and the WWW are visual mediums, rather then textual or sound-based
>ones.

That is absolutely a crock, using your own terminology.

HTML is a *markup language* for text, and was simply designed for
display-independant rendering of the same *static* documents. The WWW is just
a collective term for the HTML pages and HTTP servers that dish up the stuff.

The fact that people have bastardized web pages into being page layout
programs, with lots of live pictures and programs and such, does not mean
that HTML is a "visual medium". The fact that you can still use the
vast majority of web pages at least adequately with Lynx (a completely text-
based web browser, that (1) doesn't crash [like IE keeps doing today] and
(2) is fast [like none of the GUI ones are]) puts up one point in favor of
this argument.
--
mat...@area.com

L. Ross Raszewski

unread,

Aug 8, 1998, 3:00:00 AM8/8/98

to

In article <6qfvhq$kvd$1...@vax.area.com>,

mat...@area.com (Matt Ackeret) wrote:
> In article <199808050654...@ladder03.news.aol.com>,
> LucFrench <lucf...@aol.com> wrote:
> >My rant breaks down as follows:
> >
> >1. MIDI (HTML and HTADS main device in the way of music) isn't as versitile
as
> >MODules.
>
> Really? I was under the impression that MODs are *very very very*
> simplistic, and are based upon some limited IBM PC sound card's original
> formats. (Or was it something on the Amiga? I admittedly can't remember..)
>
> But they're like limited to 4 channels, *in the format itself*.. So then to
> get past that limit, there kept being new hacked versions of MOD players, and
> MOD files, so some players would play some sounds, but not all.. not at all
> well designed like the MIDI format.
>

Well...... kinda...sorta.... maybe. MOD was designed for Paula, the Amiga's
sound chip. And yes, it's primitive, but it's also a completely different
sort of beast from midi. MIDI music is "generated" by the sound card; it's
akin to having an orchestra (the sound card) and giving it some sheet music
(the midi file) A MOD is more like beign given both the sheet music, and the
orchestra. Now, MIDI is more elegant, _but_ two different sound cards, or
even two different configuatations on the same sound card, can lead to a midi
file sounding very, very different. A MOD will sound the same on any piece of
equipment capable of playing it properly (in theory; YMMV) MOD is also more
versitile; you could include a lyric track in a MOD file (this would lead to
an awfuly huge mod, but you could do it. Actually, you could do it without
bloating the size topo much for certain effects; I have a very cool mod which
occasionally features the famous Terminator quote "I'll be back" in the
background. ALso, An X-files remix which features several quotes from the
series. Very Cool) MOD and MIDI are suited to different things. It would be
nice to support both, and a sample format as well -- WAV, AIF,MP3,whatnot (in
the running analogy, this would be like a recording of the orchestra, and
owuld have roughly ther same benefits and weaknesses - you can record any
sound, but a recording hte same quality as the orchestra requires expensive
(ie large) equipment (filesize), though hiring an orchestra every time you
want ot hear a song is also expensive(CPU intensive)), but if you haver to
cut one of these, I personally would cut MIDI (as the sort of music _I
personally_ want to do sounds better in MOD. YMMV)

What I want ot know is why no one's discussed the important issue: Which FMV
format are we gonna adopt :-) (Actually, I'd kind of like to be able to do
animations on occasion. Really. I'm serious.)

Neil K.

unread,

Aug 8, 1998, 3:00:00 AM8/8/98

to

lyss...@aol.com (LysseusD) wrote:

> The problem is that sound is a very linear way of gathering information,
> whereas sight is not as tightly bound.

This is an interesting point. Not just in terms of sound input but also
output. For example, I'm working on an audio component to my game. For
things like background sound effects, the non real-time nature of TADS
games isn't an issue. You just have your waves washing on the beach and
your crickets chirping ad nauseum. The brief scrape of a door opening or
whatever isn't a big deal either.

But if you have stuff like dialogue spoken in real-time or longer sound
effects it becomes a problem connecting audio with the text output. Since
text adventures work on a sort of quantum basis - you get a packet of
information, then nothing happens until the player types in a command -
and audio output just sort of spools continuously. How can you convey a
sense of urgency in such a medium with audio? Do you have the sound play
out spoken dialogue or whatever until the player presses return? Do you
avoid dialogue altogether? It's an interesting problem.

At this point I'm sort of inclined simply to avoid audio dialogue. Partly
because of the difficulty of getting it to work with the textual medium,
partly because you need really good actors to avoid the cheesiness factor
and largely because it seems a bit redundant to have both spoken and
written dialogue appearing simultaneously.

Neil K.

unread,

Aug 8, 1998, 3:00:00 AM8/8/98

to

mcc...@erols.com (TenthStone) wrote:

> I think that MJR has taken some steps in the wrong direction
> by pushing on us things that we shouldn't need to deal with,

> such as character encoding [...]

Er - what's the problem with character encoding? Assuming you mean the
same thing I do. HTML TADS supports ISO entities so you can output text in
non-English languages. What's the problem with that? And what other
terrible mistakes has Mike made?

> I was under the impression that it was a long, scrollable document,
> much like current TADS, except with fancier formatting and audio/visual
> support. Perhaps it's not.

That's basically it. Text stream with embedded textual formatting, images
and also sound playback.

Roger Carbol

unread,

Aug 8, 1998, 3:00:00 AM8/8/98

to

L. Ross Raszewski wrote:

> What I want ot know is why no one's discussed the important issue: Which FMV
> format are we gonna adopt :-) (Actually, I'd kind of like to be able to do
> animations on occasion. Really. I'm serious.)

You can do animation in HyperTADS right now:

Create a banner with a graphic in it. Change the graphic to something
else. Keep doing that. There are some problems with speed, of course,
but heck, it's still animation.

.. Roger Carbol .. r...@shaw.wave.ca .. animated discussion

L. Ross Raszewski

unread,

Aug 9, 1998, 3:00:00 AM8/9/98

to

In article <35CC9E...@shaw.wave.ca>,

r...@shaw.wave.ca wrote:
>
> You can do animation in HyperTADS right now:
>
> Create a banner with a graphic in it. Change the graphic to something
> else. Keep doing that. There are some problems with speed, of course,
> but heck, it's still animation.
>

Touche. You can do this in v6 too (and you 'dn't even have ot create a banner,
because you can locate graphics wherever you like in v6,as it has a More
Advanced Screen Model (tm) (All you have to do is... y'know... invent blorb.)

But, as you say, timing would be ridiculous. Let's maybe consider adding to
our VM support for some video format, quicktime, or fli, or flc, or somesuch.

Magnus Olsson

unread,

Aug 9, 1998, 3:00:00 AM8/9/98

to

[ Reposted, since our news server seems to have been dropping articles on the
floor lately ]