Future Interpreters

17 views
Skip to first unread message

Jim Aikin

unread,
Nov 27, 2008, 1:40:00 AM11/27/08
to
The game development tools we have available today for IF are
phenomenally powerful. Just about anything an author could ever envision
doing in the model world, both Inform 7 and TADS 3 will do it without
breaking a sweat.

And yet ... the interpreters used to play the games have progressed very
little since the 1970s. Even when enhanced a bit so they can display
graphics or include hyperlinks, today's terps are essentially wrappers
for a teletype/terminal console.

Is it maybe time to rethink the teletype metaphor?

I, for one, would like my game to be able to do anything that a modern
Windows or Mac app can do.

I'd like to be able to open a second window (not just a pane within the
main window, thank you) to display ... oh, any of a number of things. A
dynamically updated inventory list, a dynamically updated map, the hints
menu, a notepad in which the player can keep track of things to try, an
image that continues to be visible even while the text scrolls -- I'm
sure many game authors could expand this list.

Maybe you'd like to put certain kinds of game options in a main-window
menu rather than force the player to type commands. Maybe you'd like to
redesign the frame of the main window itself so that it looks like an
ancient parchment scroll instead of a productivity app from Microsoft!
Or maybe you're just tired of the Scrollback button in the standard
Z-machine terp. Hey, how about letting a player click the left margin to
bookmark a passage she wants to scroll back to later and re-read?
There's an idea.

Of course, many authors will still want to write traditional text games,
the kind of thing that can run happily in the Z-machine or on a small
hand-held. I'm not suggesting that those folks should be compelled to
learn a new and complicated programming paradigm! What I _am_ suggesting
is that a modern IF interpreter can and should make a whole array of
features available to the author who wants or needs to use them.

Needless to say, we'd like the behavior of the game to degrade
gracefully if it's run on a more limited terp. Or else allow authors do
do various kinds of compiles -- one for a full-featured interpreter,
another for a teletype-only interpreter.

Please understand -- I'm not trying to disrespect the authors of the
current interpreters. Their work has been and continues to be an
invaluable public service. But maybe it's time to start talking about
what features we'd like to see in the all-new cross-platform GRUE
(GRaphic User Environment) in 2010.

I'll toss one other idea out: Just as programmers can use (or at least
this is my ignorance-based impression) pretty much the same API for
Windows apps whether they're writing in C, Java, or whatever language,
it seems to me that the same set of messages, to be sent by the game
code to the interpreter, ought to be available whether you're writing in
Inform, TADS, or some other language.

Your choice of authoring system, that is, should not dictate or limit
the features that are available to you in the interpreter.

As a writer, I would certainly want to keep the text front and center in
the UI; I'm not suggesting that we should all start writing graphic
adventures! But if someone who has more graphic talents than I possess
wants to put clickable hotspots in their graphic window for a Myst-style
game in which text is secondary, it seems to me they should be able to
do so without having to learn full-bore Win/Mac/Linux programming and
write their own parser. There's no reason at all why the ability to
process mouse events shouldn't be built into the interpreter, for use by
any game that needs it.

Okay, break out the whiffle bats and flail away.

--Jim Aikin

vaporware

unread,
Nov 27, 2008, 2:14:26 AM11/27/08
to
On Nov 26, 10:40 pm, Jim Aikin <midigur...@gmail.com> wrote:
[...]

> I'll toss one other idea out: Just as programmers can use (or at least
> this is my ignorance-based impression) pretty much the same API for
> Windows apps whether they're writing in C, Java, or whatever language,
> it seems to me that the same set of messages, to be sent by the game
> code to the interpreter, ought to be available whether you're writing in
> Inform, TADS, or some other language.
>
> Your choice of authoring system, that is, should not dictate or limit
> the features that are available to you in the interpreter.

This is the basic idea behind Glk, and it seems like most of the
specifics you're asking for (e.g. opening new windows, handling mouse
input) can already be done with Glk, more or less. Perhaps the problem
is just that Glk is missing some features, or Glk interpreters and VM-
level libraries aren't taking full advantage.

vw

ChicagoDave

unread,
Nov 27, 2008, 11:20:36 AM11/27/08
to
On Nov 27, 12:40 am, Jim Aikin <midigur...@gmail.com> wrote:
> The game development tools we have available today for IF are
> phenomenally powerful. Just about anything an author could ever envision
> doing in the model world, both Inform 7 and TADS 3 will do it without
> breaking a sweat.
>
> And yet ... the interpreters used to play the games have progressed very
> little since the 1970s. Even when enhanced a bit so they can display
> graphics or include hyperlinks, today's terps are essentially wrappers
> for a teletype/terminal console.
>
> Is it maybe time to rethink the teletype metaphor?

Yes!

That's the entire purpose of FyreVM and Channel IO. To remove the
display rules from the IF game and allow the interpreter to be created
for a specific game with its own display rules. For Secret Letter we
have seventeen channels of data including Main, Location, Score, Time,
Help, Hints, Conversation, Theme, Progress, Prompt, Title, Prologue,
Chapter, Map, Credits, Sound, and GameOver. We've built a user
interface that traps the text from those channels and displays it
exactly how we want it displayed and not dependent on any windowing
scheme.

When Secret Letter gets closer to being fully functional, I was
planning to create a FyreVM sample project that can be downloaded.
Silverlight is cross-platform and works on most of the browsers. (It
seems not to have a solution for PowerPC Macs and Linux support is
probably several months out based on the Mono Moonlight project).

I recently built a terp tool that allows me to play a FyreVM/Channel
IO game and see which channels are being loaded every turn and then I
can click a button to see the different text for each channel. I'll
make that available eventually as well.

David C.

Jim Aikin

unread,
Nov 27, 2008, 12:00:08 PM11/27/08
to
vaporware wrote:
>
> This is the basic idea behind Glk, and it seems like most of the
> specifics you're asking for (e.g. opening new windows, handling mouse
> input) can already be done with Glk, more or less. Perhaps the problem
> is just that Glk is missing some features, or Glk interpreters and VM-
> level libraries aren't taking full advantage.

I'm not nearly as familiar with the details of Glk as I'd like to be,
and as we all know, the devil is in the details. So please feel free to
correct my misunderstandings, if any. But here's how it looks to me.

First, Glk is not an interpreter. It's a specification. It's up to
someone else (not Zarf) to implement whatever portions of the
specification they have time for or feel can't be omitted. This division
of labor, while basically desirable since all of the labor is being done
by unpaid volunteers, has the downside that sometimes stuff doesn't get
implemented.

One of my basic contentions is that when an author writes a game, he or
she should _know_, not just hope, that the end user will be able to
encounter the game with its intended presentation. (Okay, we don't know
whether the user has speakers hooked up. And of course they may be
blind. But aside from that....)

Today, the interpreter scene is a patchwork. Even before we start
talking about the details, that's clearly not desirable for the author
who hopes to go beyond the teletype metaphor.

Second, I think there's a philosophical divide between those who feel
that the player should be in control of the appearance and behavior of
the terp and those who feel that the author should be in charge. I have
the impression that Glk takes the former view: it insulates the author
from the details of the presentation.

I take, very firmly, the latter view. I want to write a game that looks
professional, in my own terms. In a specific game, that might mean
almost anything, up to and including creating an entirely new graphic
design for the main text window. If an author feels that Olde English
font is suitable for the text, and that nothing else will do, the author
should have the option of removing font choices from the delivery
mechanism. I don't want to be insulated from control over the look and
feel by the specification.

I think your qualifying phrase, "more or less," is very telling. "More
or less" is a way of saying, "Oh, it's just hobbyist software. Who cares
if it doesn't look or respond quite the way I want it to?"

Here's my benchmark: When I finish my next game, I want to be able to
send it to my literary agent in New York and ask him if he'd like to
present it to, like, Warner New Media and people like that. Now, with
apologies to my agent, literary agents are not, in general, known for
being highly imaginative. They do not, in my experience, indulge in
fantasies such as what something _might_ look like after the coders at
Warner New Media get done polishing it. My agent is going to launch the
program, look at it for about fifteen seconds, and make a snap decision
about whether it looks _completely_ professional. No excuses. If it
doesn't, he won't even bother trying to learn how to read the story.

Whether or not anyone else has such grandiose ambitions for their work,
I'm hoping most people will agree that it would be highly desirable to
give the author a decent suite of smoothly functioning software tools
suitable to the 21st century. The parsers and libraries work
beautifully! Why should we be satisfied that the interpreters lag so far
behind?

--JA

Jon Ingold

unread,
Nov 27, 2008, 12:09:43 PM11/27/08
to

> This is the basic idea behind Glk, and it seems like most of the
> specifics you're asking for (e.g. opening new windows, handling mouse
> input) can already be done with Glk, more or less. Perhaps the problem
> is just that Glk is missing some features, or Glk interpreters and VM-
> level libraries aren't taking full advantage.

I don't know: Glk has some pretty fundamental limitations, like not
being able to access/vary text on the main screen after it's been
output (which sounds a lot like the teletype metaphor). It's also -
and I don't know why this is, exactly, whether it's in the spec or the
interpreter implementations or the way all the error messages don't
tell you what's gone wrong! - incredibly clunky to use. Things which
should be easy, like varying the font or the alignment, are
implemented in such a restricted way as to be pretty useless (I know
the spec says that fonts should be user-varied, not author varied; but
I do think this is bizarre), and the business of opening, resizing and
closing windows is painfully slow, involves several unnecessary
refreshes. New windows can only be created as divisions of old ones,
which is fine for opening a status line, but no good for any type of
inset or if you want to flip/choose between few different sub-windows
in a flexible way. (Even the old quote-boxes are badly rendered by
this scheme.)

Glulx does a lot of good stuff and these days I'm commited to it over
the z-machine for size/stack space. And, as always needs to be added,
there's no way in hell I could have written it, and I'm glad someone
did! But that said, I do often find myself thinking about all the
things which would improve the user experience, and the only way to do
them is on the interpreter side (and maybe that's where they should
be, but I can't write interpreters...)

And I do think that the lack of interactivity between the interface
and the player - the static teletype prompt - does a lot to put users
off playing.

jon

Jim Aikin

unread,
Nov 27, 2008, 12:14:11 PM11/27/08
to
ChicagoDave wrote:
>
> That's the entire purpose of FyreVM and Channel IO. To remove the
> display rules from the IF game and allow the interpreter to be created
> for a specific game with its own display rules.

I wasn't aware of this design. It looks very promising, and I'll want to
learn more about it.

For your "large shop" projects, separating the text layer from the
interpreter makes sense, but most IF is still done by one or at most two
people. As an author, I would hope to be able to embed those channel
commands directly in my code.

The licensing issues also concern me. It would be better if the author
who had serious aspirations could be reasonably certain in advance what
sort of limitations there might be on licensing and distribution of a
commercially distributed game.

But of course, that might also be true of I7, T3, and the existing
terps, for all I know. I haven't researched that.

--JA


Woolyloach

unread,
Nov 27, 2008, 12:17:52 PM11/27/08
to
I'll just throw out my two cents worth, since developing various
interpreters has been something I've done as part of my software
engineering career (heh).

Writing a decent cross-platform high-performance, flexible, powerful
interpreter is no small matter. Especially if you want multimedia,
your choices are somewhat limited: raw OpenGL for graphics, or maybe
SDL (Simple DirectMedia Layer), or some other lesser-known toolkit.
It would be an interesting project, but the development of a decent
authoring environment should likely end up being part and parcel of
such a project... everything should integrate together, running the
story in the target interpreter so you see exactly what the player/
reader will see.

I'd also be on the side of the author determining and controlling
presentation. If I say "do it THIS way" then by golly I want it done
"THAT way", not some second-guess of the presentation system! It's MY
story and MY world, don't mess with it!! Ok, sorry, rant over... :-/

It might make an interesting project, though, especially if the
development were open source. Wish I owned a Mac, I'd almost take a
shot at it - Winter is setting in and I need something to keep me busy
while I'm stuck indoors. ;-p

Aaron A. Reed

unread,
Nov 27, 2008, 12:50:57 PM11/27/08
to

I just want to say that I agree with 100% of what Jim is saying here.
Part of why I was trying to update Zag (the Java Glulx interpreter) to
the latest spec, so it can play Inform 7 Glulx games, is because I
wanted to use that as a basis for a new cross-platform interpreter
with more advanced features.

On the one hand I agree that IF should remain accessible; on the other
hand I want to typeset and present my game the same way I would
typeset and present a book.

As an example of what I think a modern IF terp should be shooting for:
go find and download a game called DROD (Deadly Rooms of Death). It's
basically one of those old ASCII games where you move a little @ sign
around a map, but the presentation is so beautifully polished
(including full color graphics, sound, animated menus, voice acting,
etc.) that it makes the whole experience much more satisfying. I
wouldn't play one of these games for very long in a terminal window;
but the designers did such a good job at making the experience seem
fresh and fun that I got sucked in for a while when I first
encountered it. *We need this for IF.*

A more recent example is Little Big Planet. All of the attention to
details of presentation make the experience more enjoyable than a
physics-based side-scroller strictly has any right to be.

--Aaron

S. John Ross

unread,
Nov 27, 2008, 1:30:50 PM11/27/08
to

> Second, I think there's a philosophical divide between those who feel
> that the player should be in control of the appearance and behavior of
> the terp and those who feel that the author should be in charge.

Yes. I'd love for the author to have the ability to (for example) code
games to call up changes in things like background or border imagery,
or fonts, etc ... but I think such power should always be
counterbalanced by the player's ability to refuse the frippery and/or
replace it with their own preferences. I too consider this a 21st-
century issue, and here in the 21st century, webpage authors (for
example) can specify fonts and colors and background images and
embedded sounds ... and I can (with any decent browser) choose to
_override_ those choices and replace them with those my eyes (or
sensibilities) find more pleasing or appropriate. Speaking more
theoretically, it might be cool to have an mp3 that could
automatically re-skin my copy of WinAmp to suit the song ... but it
would NOT be cool if I couldn't shut that feature off.


OKB (not okblacke)

unread,
Nov 27, 2008, 1:44:18 PM11/27/08
to
vaporware wrote:

> Perhaps the problem
> is just that Glk is missing some features, or Glk interpreters and VM-
> level libraries aren't taking full advantage.

I'd agree with that. Or, to put it a bit more strongly, the Glk
spec makes too many features optional, so a lot of terps don't support
them, so almost no features are actually usable in a straightforward way
by a game. You have to query the terp at every step to see if what you
want to do is possible.

Also, as Jon Ingold noted, a lot of operations that are essentially
atomic from the game programmer's point of view (to say nothing of the
game PLAYER's point of view) require a laborious sequence of steps to
achieve. I think this is less damaging, since it can be dealt with by
libraries. All it takes is one person with enough savvy to wrap all the
ugly Glk stuff into functions that are relevant to writing a game.

But, precisely because of this, I think Glk as such is almost
irrelevant to game authors. Saying "you can do this with Glk" when
someone wants to do it with TADS 3 is like saying "you can do this with
assembly language" when someone wants to do it with Python. Glk is much
lower-level than IF programming languages, and the API doesn't expose
things in the way people actually want to use them when writing games.

--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown

steve....@gmail.com

unread,
Nov 27, 2008, 2:23:01 PM11/27/08
to
Jim Aikin wrote:
> The game development tools we have available today for IF are
> phenomenally powerful. Just about anything an author could ever envision
> doing in the model world, both Inform 7 and TADS 3 will do it without
> breaking a sweat.

I disagree with that, or at least, I would say it differently. There's
a lot that we can imagine doing which is prohibitively difficult.
Naturally, we're used to thinking in terms of (current) limitations,
so it doesn't really occur to us to worry about complex relational
location, for example, or object state transformations, or making the
space continuous rather than monadic, etc.

Perhaps you mean that you personally feel like these wouldn't be
particularly interesting or rewarding developments?

(As a side-note: I was under the impression that TADS-3 is still way
ahead of I7 in the world-modeling department.)

Also, please note that world modeling is just a small piece of the
pie. There's command resolution, action and overrides, reporting, not
to mention NPC AI, etc. I am not at all satisfied (in a final sense)
with TADS-3 on most of this stuff (and again my understanding is that
it's even harder in I7, but please feel free to correct me!).

So, I would recommend more time spent on the area which you seem to
imply is mostly finished. I think that's where all the interesting
potential is buried.

On the other hand, I agree that more graphical handling would be a
nice luxury. Note that HTML TADS is already capable of doing most of
the stuff you requested. (The two problems: you can't open separate
windows; and I think bookmarking would be prohibitively tricky, though
probably doable.) Mike has always been understandably reluctant to add
further complexity to osifc.

Jim Aikin

unread,
Nov 27, 2008, 2:31:58 PM11/27/08
to
Jon Ingold wrote:
>
> Glk has some pretty fundamental limitations, like not
> being able to access/vary text on the main screen after it's been
> output (which sounds a lot like the teletype metaphor).

Exactly. On the one hand, it would be silly to expect the player to keep
re-reading a paragraph that was printed earlier and has now scrolled
upward, just to make sure the game hasn't changed it. But I can easily
imagine a game in which the author might want a few words in an already
printed paragraph (which is presumably still in view) to suddenly start
flashing in red. The words "emergency shutoff valve," for instance.

> New windows can only be created as divisions of old ones,
> which is fine for opening a status line, but no good for any type of
> inset or if you want to flip/choose between few different sub-windows
> in a flexible way.

Window splitting is, in my opinion, a very poor implementation compared
to almost any modern software. I can understand why it was done that way
-- to extend the terp's capabilities without breaking anything. But even
a tabbed interface would be a big improvement over window splitting, and
a tabbed interface is not really very attractive for entertainment software.

If a game wants or needs to open half a dozen independent, floating
windows, it should be able to do so. The main reason being, when the
windows are independent, the shape of the text window (the "page")
doesn't need to change.

> Glulx does a lot of good stuff and these days I'm commited to it over
> the z-machine for size/stack space. And, as always needs to be added,
> there's no way in hell I could have written it, and I'm glad someone
> did!

I concur heartily.

> And I do think that the lack of interactivity between the interface
> and the player - the static teletype prompt - does a lot to put users
> off playing.

A redesigned prompt (input line) would help, but I'm inclined to think
that all of the main text, including the player's input and the game's
output, should be kept in one window, in a continuously scrolling
manner. To me, that looks more like a traditional book, and I like it.
It's immersive.

That said, it shouldn't be _required_ of authors! If an author wants to
put the command line in a separate window, so that the output text
appears seamless, without the frequent intrusion of >i and >g, the
system should allow it.

For that matter, the author should be able to choose what window to
display the output text in. Maybe a particular game would benefit from
having three parallel text windows, one for physical description and
action, one for npc conversation, and one for inventory management. I
could probably concoct a story in which it would be useful for all of
those to be visible on the screen at once.

--JA

David Fletcher

unread,
Nov 27, 2008, 2:35:59 PM11/27/08
to

Just picking on one point:

Jon Ingold <jon.i...@gmail.com> writes:

> the business of opening, resizing and
> closing windows is painfully slow, involves several unnecessary
> refreshes.

Why is this? The way I read the spec, a Glk implementation isn't
required to refresh anything until glk_select or glk_select_poll is
called. It should be possible to do as much opening and closing and
resizing as you like without anything needing to be drawn more than
once.

--
David Fletcher.

ChicagoDave

unread,
Nov 27, 2008, 2:40:01 PM11/27/08
to
On Nov 27, 11:14 am, Jim Aikin <midigur...@gmail.com> wrote:
> ChicagoDave wrote:
>
> > That's the entire purpose of FyreVM and Channel IO. To remove the
> > display rules from the IF game and allow the interpreter to be created
> > for a specific game with its own display rules.
>
> I wasn't aware of this design. It looks very promising, and I'll want to
> learn more about it.
>
> For your "large shop" projects, separating the text layer from the
> interpreter makes sense, but most IF is still done by one or at most two
> people. As an author, I would hope to be able to embed those channel
> commands directly in my code.

The channel system is entirely "soft". We put the infrastructure
together to create channels and we just happened to implement that
list. If you decided you wanted the foo, bar, and xyzzy channels,
that's entirely up to you and it's entirely up to you how to implement
them in your game code.

The Inform 7 usage is as simple as:

select the main channel;
say "This is text in the main channel.";
select the help channel;
say "This is text in the help channel.";
select the main channel.

Of course the Main, Location, Score, Time, Prompt, Title, Chapter, and
Credits channels are sort of ubiquitous, so I don't think you'd want
to alter their default behavior. There is one alteration I've
considered and that's to have the main output have sub-channels for
"before-text", "location-name", "location-text", "scenery-text", and
"after-text" which makes up all of the text for a general turn. I'm
not entirely sure what I would do with this, but it seems there might
be some interesting things you could do UI-wise if you had it broken
down to this level. (I see a UI with a spiral flip notebook maybe).

> The licensing issues also concern me. It would be better if the author
> who had serious aspirations could be reasonably certain in advance what
> sort of limitations there might be on licensing and distribution of a
> commercially distributed game.

I would never have a license that prevented hobbyist use or individual
commercial sales. I've considered making the code entirely open, but
until Textfyre is more established, I don't feel comfortable doing
that. That said, there is nothing stopping anyone from re-implementing
the channel system on their own.

Note that this system is not strictly for Inform 7. It's possible to
implement a similar IO layer in T3.

As for what you use to create the user interface, that's dependent on
the implementation of FyreVM. Currently we make it easy for a .NET
developer to build their game. It's also possible you could do it in
Java, a web client, Flash, or anything else.

David C.

Jim Aikin

unread,
Nov 27, 2008, 2:49:59 PM11/27/08
to
steve....@gmail.com wrote:
> Jim Aikin wrote:
>> The game development tools we have available today for IF are
>> phenomenally powerful. Just about anything an author could ever envision
>> doing in the model world, both Inform 7 and TADS 3 will do it without
>> breaking a sweat.
>
> I disagree with that, or at least, I would say it differently. There's
> a lot that we can imagine doing which is prohibitively difficult.
> Naturally, we're used to thinking in terms of (current) limitations,
> so it doesn't really occur to us to worry about complex relational
> location, for example, or object state transformations, or making the
> space continuous rather than monadic, etc.

You're making an important point, Steve. I was being too glib. I do
think, though I can't prove it, that with a little clever code an author
create the _impression_ of an object state transformation or a
continuous space. The player only cares about what's actually printed to
the screen, not about the underlying mechanics. And we can print
anything to the screen!

> Perhaps you mean that you personally feel like these wouldn't be
> particularly interesting or rewarding developments?

That's a different discussion. Having recently written a game that was
set in a large open area, I'm not satisfied with the way it reads, and
will probably return to the monadic "cave metaphor" of separate rooms
for my next project. I would always use fake scenery objects in a cave
room in order to simulate the view of distant objects in other rooms.
That's not hard to do.

> Also, please note that world modeling is just a small piece of the
> pie. There's command resolution, action and overrides, reporting, not
> to mention NPC AI, etc. I am not at all satisfied (in a final sense)
> with TADS-3 on most of this stuff (and again my understanding is that
> it's even harder in I7, but please feel free to correct me!).

I'm not going to get into the T vs. I argument. There's certainly lots
of room for further development in these areas, in both systems.
Absolutely. But if it's all being filtered through the teletype
metaphor, it won't look or feel professional no matter how sophisticated
the library is.

> On the other hand, I agree that more graphical handling would be a
> nice luxury. Note that HTML TADS is already capable of doing most of
> the stuff you requested. (The two problems: you can't open separate
> windows; and I think bookmarking would be prohibitively tricky, though
> probably doable.)

HTML TADS has some nice tools. But of course, it's not available on OS
X, so there's a wee gap between the conception and the realization. This
is not a trivial or incidental fact; it's part and parcel of the problem
with today's approach to interpreters.

I don't think the ability to open separate windows is a frill; I think
it's a necessity for a professional presentation. I also think the
author needs access to the main menu, so that common utility commands
such as "verbose" and "brief" don't have to be typed at the prompt. I
feel strongly that the terp window needs to be "skinnable" by the author
to present absolutely any graphic appearance that the author feels will
enhance the experience of the game.

I'm a text-oriented guy; I would probably use tools of this sort in a
fairly minimal way (other than possibly tinkering with the appearance of
the main window to make it look more like a book). Other authors may
have very different ideas. Ideally, a modern IF delivery system should
be able to accommodate as many types of presentation as possible, within
reason. And the primary way to do that, it seems to me, is to let the
author open windows and manage their contents.

--JA

David Fletcher

unread,
Nov 27, 2008, 3:44:34 PM11/27/08
to
Jim Aikin <midig...@gmail.com> writes:

[snip]


>
> I'll toss one other idea out: Just as programmers can use (or at least
> this is my ignorance-based impression) pretty much the same API for
> Windows apps whether they're writing in C, Java, or whatever language,
> it seems to me that the same set of messages, to be sent by the game
> code to the interpreter, ought to be available whether you're writing
> in Inform, TADS, or some other language.
>
> Your choice of authoring system, that is, should not dictate or limit
> the features that are available to you in the interpreter.
>

UI toolkits are big. If you wanted to get somewhere near complete
control of the UI from Tads or Inform, you'd be looking at a set of
bindings to a large subset of a UI toolkit. I can just about imagine
this being done in Tads 3. I would have thought it would probably be
horrific in Inform 7, although I haven't looked at that language since
its early releases.

I could be wrong, but I would guess that for most people it would be
easier to learn enough Java or Python or Flash or C++ to do their UI
than to have to deal with a monster UI interface in an IF language
which wasn't really designed to cope with one.

> As a writer, I would certainly want to keep the text front and center
> in the UI; I'm not suggesting that we should all start writing graphic
> adventures! But if someone who has more graphic talents than I possess
> wants to put clickable hotspots in their graphic window for a
> Myst-style game in which text is secondary, it seems to me they should
> be able to do so without having to learn full-bore Win/Mac/Linux
> programming and write their own parser. There's no reason at all why
> the ability to process mouse events shouldn't be built into the
> interpreter, for use by any game that needs it.
>
> Okay, break out the whiffle bats and flail away.

There's no reason why writing UI code in a UI toolkit would mean you
would have to rewrite a parser. The FyreVM way sounds like a good
loosely-coupled way to combine interpreted game code with UI code in a
different language, or you could do a more tightly-coupled thing where
you would slightly extend (say) Glulx to let it call your code that
did UI stuff natively.

--
David Fletcher.

Jim Aikin

unread,
Nov 27, 2008, 4:09:09 PM11/27/08
to
David Fletcher wrote:
>
> UI toolkits are big.

True. And it's rather difficult to anticipate all of the things that
authors are likely to want to do. ("Likely" is, of course, pure
guesswork, up to the point where a new interpreter is up and running and
people are writing games for it.)

> If you wanted to get somewhere near complete
> control of the UI from Tads or Inform, you'd be looking at a set of
> bindings to a large subset of a UI toolkit. I can just about imagine
> this being done in Tads 3. I would have thought it would probably be
> horrific in Inform 7, although I haven't looked at that language since
> its early releases.

One question I have about this (being, by the most generous estimate, a
hobbyist programmer) is whether it would be easy in I7 to do exactly
what HTML TADS does already -- simply fire off <> tags (some of them not
standard HTML at all) within a quoted string. The output mechanism then
strips the tags from whatever is to be printed to the screen (if
anything) and routes them elsewhere.

> I could be wrong, but I would guess that for most people it would be
> easier to learn enough Java or Python or Flash or C++ to do their UI
> than to have to deal with a monster UI interface in an IF language
> which wasn't really designed to cope with one.

You may be right ... but on the other hand, if 20 authors want this type
of delivery system, why should they all have to dig in and write their
own UI? Why not develop one modern, open-ended interpreter that
everybody can use? Seems to me that would be more efficient ... assuming
anybody has the bandwidth to do it.

> There's no reason why writing UI code in a UI toolkit would mean you
> would have to rewrite a parser.

True -- I suppose you could write your own VM that would run the
underlying game code, which would be written in Inform or TADS. Would
writing a VM be easier or harder? I haven't a clue.

--JA

James Jolley

unread,
Nov 27, 2008, 4:44:58 PM11/27/08
to


Hi folks,

The only worry here is accessibility. If all these types of suggestions
are added in, there could be quite difficult access issues for blind
players. For instance, if we start relying on fancy fonts with JPeg
images and all that good stuff, the blind may be out. Personally, the
way Zoom handles IF is superb on OS X. The text is seen as one window
to the VoiceOver API, and any other windows that relate (Status lines,
conversation choices) etc under Glulx are interacted with as different
windows.

If we start making the IF systems more complicated to navigate, this
"may" not saying will of course, cause difficulties. I've worked with
Andrew on a lot of this within Zoom and his knowledge of VoiceOver's
internals is impressive. Works like City of Secrets and the Idles of
war demo project are fully accessible with the zoom application.
Naturally, if changes are afoot, i'll certainly work with Andrew and
any other developers on access.

Spatterlight is fairly good as well, except that the status line is
invisible to VoiceOver as mentioned a while ago. Andrew seems to have
solved this under Zoom but Mr. Anderson's unsure spatterlight will
interface with the games in the same way. Here's hoping.

Change is good, don't think I am out to whine. We just need to keep
existing options open, that is all really.

--
Best

-James-

James Jolley

unread,
Nov 27, 2008, 5:06:36 PM11/27/08
to


My partner has that on our PS3. As an aside, the content creation ideas
in that are rather impressive. She likes it, I tend to stick to
"Smackdown VS Raw 2009" on it as the commentary makes it more
accessible.--
Best

-James-

Nikos Chantziaras

unread,
Nov 27, 2008, 5:20:00 PM11/27/08
to
Jim Aikin wrote:
> The game development tools we have available today for IF are
> phenomenally powerful. Just about anything an author could ever envision
> doing in the model world, both Inform 7 and TADS 3 will do it without
> breaking a sweat.
>
> And yet ... the interpreters used to play the games have progressed very
> little since the 1970s. Even when enhanced a bit so they can display
> graphics or include hyperlinks, today's terps are essentially wrappers
> for a teletype/terminal console.
>
> Is it maybe time to rethink the teletype metaphor?
>
> I, for one, would like my game to be able to do anything that a modern
> Windows or Mac app can do.

I once raised the question on the T3 list to include a DSP (think of it
as a virtual sound card) and framebuffer (a virtual graphics card) in
the T3VM. There was no interest, but if anyone is actually going to
implement a modern interpreter, a DSP and framebuffer (or even better,
draw primitives) is probably the best way to get all bases covered.
Higher level APIs (like Channel IO) could be implemented on top of it.

David Fletcher

unread,
Nov 27, 2008, 5:46:14 PM11/27/08
to
Jim Aikin <midig...@gmail.com> writes:

> David Fletcher wrote:
>> UI toolkits are big.
>
> True. And it's rather difficult to anticipate all of the things that
> authors are likely to want to do. ("Likely" is, of course, pure
> guesswork, up to the point where a new interpreter is up and running
> and people are writing games for it.)
>
>> If you wanted to get somewhere near complete
>> control of the UI from Tads or Inform, you'd be looking at a set of
>> bindings to a large subset of a UI toolkit. I can just about imagine
>> this being done in Tads 3. I would have thought it would probably be
>> horrific in Inform 7, although I haven't looked at that language since
>> its early releases.
>
> One question I have about this (being, by the most generous estimate,
> a hobbyist programmer) is whether it would be easy in I7 to do exactly
> what HTML TADS does already -- simply fire off <> tags (some of them
> not standard HTML at all) within a quoted string. The output mechanism
> then strips the tags from whatever is to be printed to the screen (if
> anything) and routes them elsewhere.
>

Easy enough to add this as a mechanism that an interpreter can
recognize, yes. Possibly not really any easier than adding new
opcodes to the VM, or extending glk with extra calls (and wrapping
them in an I7 extension in either case).

Adding tags to output would only give you one-way communication - for
example it wouldn't give you a way for the interpreter to tell the
Inform code that a menu item had been selected. I suppose you might
do that along the same lines by returning magic tags to the game when
it requested line input.

>> I could be wrong, but I would guess that for most people it would be
>> easier to learn enough Java or Python or Flash or C++ to do their UI
>> than to have to deal with a monster UI interface in an IF language
>> which wasn't really designed to cope with one.
>
> You may be right ... but on the other hand, if 20 authors want this
> type of delivery system, why should they all have to dig in and write
> their own UI? Why not develop one modern, open-ended interpreter that
> everybody can use? Seems to me that would be more efficient
> ... assuming anybody has the bandwidth to do it.
>

So there are a few possibilities:

1. Define a limited set of extensions to Glk (or some new UI standard)
which covers the stuff authors mostly want.

Thinking of things I've seen people mention so far: toolbar menus,
top-level windows, access to text in text buffer windows, mouse hover,
font control. Adding that lot might already be doubling the size of
Glk.

2. Make bindings in Tads or Inform for (most of) an existing UI
toolkit. Then there can be libraries written in Tads/Inform for
common things, e.g. controlling an inventory window or adding a
"brief/verbose" menu option. But if you need it you have complete UI
control, as long as enough of the UI toolkit is made available.

3. Introduce a way to call from the VM into some other language and
use that for UI. (Or alternatively talk to the other language in some
looser way like FyreVM does). In this case there can be libraries in
that language to do the common things, and you also have complete
access to the OS.

>> There's no reason why writing UI code in a UI toolkit would mean you
>> would have to rewrite a parser.
>
> True -- I suppose you could write your own VM that would run the
> underlying game code, which would be written in Inform or TADS. Would
> writing a VM be easier or harder? I haven't a clue.

Hopefully you'd be able to find an existing VM core in the language
you were planning to use. Then you'd have to tweak it a bit to add a
way for VM code to talk to your UI code. Then you'd need the basics
of the UI - things like file access and basic text input and output -
possibly using a Glk implementation or possibly starting from scratch.

The first person to do all this for any given combination of VM plus
UI library would have to get the all this stuff working and invent
sensible ways for extensions to the UI to work. Then they would
(ideally) be able to make it available as a basis so that further
users would only need to write the code for their new and exciting
bits of UI.

--
David Fletcher.

Stuart Allen

unread,
Nov 27, 2008, 6:00:41 PM11/27/08
to
On Nov 28, 5:44 am, "OKB (not okblacke)"

<brenNOSPAMb...@NObrenSPAMbarn.net> wrote:
> vaporware wrote:
> > Perhaps the problem
> > is just that Glk is missing some features, or Glk interpreters and VM-
> > level libraries aren't taking full advantage.
>
>         I'd agree with that.  Or, to put it a bit more strongly, the Glk
> spec makes too many features optional, so a lot of terps don't support
> them, so almost no features are actually usable in a straightforward way
> by a game.  You have to query the terp at every step to see if what you
> want to do is possible.

This is very much a feature of Glk to make sure that your game can be
run on everything from a Sun Workstation to a mobile phone, and I
think it is a good idea.

I do feel that authors currently have a fair amount of control over
presentation - take a look at this year's One Room Comp and you'll
find at least one game with very controlled presentation that seems to
work nicely under a standard Glk interpreter (I hope that didn't break
any comp rules...)

I guess what I'm trying to say is that most games only use a small
percentage of what is already currently available, which probably
reduces the incentive for interpreter authors to keep adding more.
Having said that though, I would be interested to see how difficult it
would be to modify an interpreter to allow a normal Glk window to be
docked and undocked. I don't think this would require any change to
the games or Glk spec, so it might be a good way to start
experimenting without breaking compatibility. Down the track, though,
it might be nice to have a boolean flag to indicate whether a window
should be undockable (so border images can be forced to stay in place,
etc), and perhaps another to indicate that the window should start
free floating.

Another feature I'm surprised isn't more common is auto-mapping like
in Nitfol (as I've just learned). Given a location-based game map is a
universal enough concept in IF, I am wondering if it would be
possible/ appropriate to expand the Glk spec to allow the game to
communicate information about the map to an interpreter that supported
an auto-mapping feature.

Stuart

steve....@gmail.com

unread,
Nov 27, 2008, 6:59:14 PM11/27/08
to
Jim Aikin wrote:
> You're making an important point, Steve. I was being too glib.

Ah, heh. Well I certainly didn't mean to correct you for being glib! I
just thought you might have meant it! I guess that also explains the
equal-comparison of TADS 3's powers with those of I7, which was weird.
But enough of that!

> [A] little clever code an author


> create the _impression_ of an object state transformation or a
> continuous space. The player only cares about what's actually printed to
> the screen, not about the underlying mechanics. And we can print
> anything to the screen!

Yes, sometimes a quicko hack works fine. Sometimes a shallow
implementation feels really clumsy, and players won't be able to do
what they want, and what is natural to expect from the story.

> Having recently written a game that was

> set in a large open area, I'm not satisfied with the way it reads[.]
> [...]


> I would always use fake scenery objects in a cave
> room in order to simulate the view of distant objects in other rooms.
> That's not hard to do.

Here's an example where a shallow implementation runs into trouble.
It's hard to give the impression of open space, since you want to make
those distant objects interact-able, so you need implicit movement,
etc. -- I'd recommend you take a look at ConSpace if you haven't
already done so.

> [I]f it's all being filtered through the teletype


> metaphor, it won't look or feel professional no matter how sophisticated
> the library is.

I think you're right on one level. On another level, the genre can get
a *lot* more sophisticated than it is right now, without developing
the interface in this way. (One could develop the interface in a lot
of purely textual ways, and make many other sophistications, some of
which I mentioned.)

> HTML TADS has some nice tools. But of course, it's not available on OS
> X, so there's a wee gap between the conception and the realization.

An interpreter written in a multi-platform GUI might be a good
development. There are many such systems. wxWidgets is my favorite,
but there's also Juice, GTK+, TrollTech QT, and probably some others.

ChicagoDave

unread,
Nov 27, 2008, 8:50:38 PM11/27/08
to
On Nov 27, 4:20 pm, Nikos Chantziaras <rea...@arcor.de> wrote:
> I once raised the question on the T3 list to include a DSP (think of it
> as a virtual sound card) and framebuffer (a virtual graphics card) in
> the T3VM.  There was no interest, but if anyone is actually going to
> implement a modern interpreter, a DSP and framebuffer (or even better,
> draw primitives) is probably the best way to get all bases covered.
> Higher level APIs (like Channel IO) could be implemented on top of it.

Gah, this is one of the things I would think you'd want to avoid.

Just leave the display/sound implementation completely out of the game
code and use a "soft" interface to enable display/sound. Channel IO is
not a "high" level API. It's a functional API that strips all of the
implementation details away from the game code. The game author
doesn't need to know how a window is created or displayed, only that
something will take the output and do the right thing with it.

When building an interpreter, you use the IO stripped VM and the game
file and develop the interface as you need it at that time.

I see sound working entirely in an abstract manner:

select the sound channel;
say "sequence: horn.wav;5s,siren.wav;3s";

or for simultaneous sounds:

select the sound channel;
say "simultaneous: ambient-water.wav;5s,ambient-birds.wav;5s";

The author need know nothing of _how_ the sound happens...the
interpreter will do the right thing with those commands using whatever
sound system (DirectSound, other) is available on whichever platforms
they intend to direct the interpreter to.

David C.

steve....@gmail.com

unread,
Nov 27, 2008, 9:17:51 PM11/27/08
to
ChicagoDave wrote:

> Nikos Chantziaras wrote:
>
> > I once raised the question on the T3 list to include a DSP (think of it
> > as a virtual sound card) and framebuffer (a virtual graphics card) in
> > the T3VM.  There was no interest, but if anyone is actually going to
> > implement a modern interpreter, a DSP and framebuffer (or even better,
> > draw primitives) is probably the best way to get all bases covered.
> > Higher level APIs (like Channel IO) could be implemented on top of it.
>
> Gah, this is one of the things I would think you'd want to avoid.
>
> Just leave the display/sound implementation completely out of the game
> code and use a "soft" interface to enable display/sound.

It sounds like what you're saying, Dave, is that you want a highly
abstracted API for the IF writer. That's a good idea, and I think
everyone agrees in general. Nikos is talking about how a lower-level
API can be designed to bring this about, in a way which is both
abstract and OS-independent.

I think this will make a lot better sense if we clarify what "API"
means. An "API" is a set of instructions which a program can
understand. Your OS is a program, and your interpreter is a program
that runs within the OS. Thus, we can say that there are several
levels of API. You can even have multiple APIs within a single
program.

Nikos wasn't saying that regular IF authors will want to do a lot of
channel IO management, of course! He was talking about a lower-level
API, on top of which library writers could produce higher-level APIs
along the lines you're describing.

Jeffrey McArthur

unread,
Nov 27, 2008, 9:43:56 PM11/27/08
to
On Wed, 26 Nov 2008 22:40:00 -0800, Jim Aikin <midig...@gmail.com> wrote:

>The game development tools we have available today for IF are
>phenomenally powerful. Just about anything an author could ever envision
>doing in the model world, both Inform 7 and TADS 3 will do it without
>breaking a sweat.
>
>And yet ... the interpreters used to play the games have progressed very
>little since the 1970s. Even when enhanced a bit so they can display
>graphics or include hyperlinks, today's terps are essentially wrappers
>for a teletype/terminal console.
>
>Is it maybe time to rethink the teletype metaphor?

For about the last month I have been doing a lot of research on a variety of
IF programming systems and interpreters. I agree we need to move beyond the
teletype metaphor.

I have a background in publishing. I have developed programs that generated
hundreds of thousands of pages from customer databases that ended up in
print. Because of my background I have a very strong bias toward reusable
content. The core of IF is text. It is not sound or video. It is text. But
if you want to do something else with the text in an I7 or TADS 3 file you
are in trouble. Both have complex syntax and neither supports Unicode very
well.

For me, the solution is to use XML. XML is a standard that is used
throughout most modern software. With XML it is easy to separate form from
content. How something is displayed can be controlled by external style
sheets.

Let me give you a concrete example of why it is important that the source be
in XML. Lets assume the author has created a masterpiece of IF. How the
author wants to select some great examples from program and put them on a
web page. How do you do that with I7 or TADS 3? If the source was XML, all
you need to do is write up an XSLT to extract the appropriate sections. XML
comes with a huge selection of tools that allow you to manipulate and
process the data.

The current standard for the web is XHTML 1.1. XHTML is actually XML.
Support for graphics, sound, and so on are relatively easy, since all the
hard work has already been done and all you need to do is steal those ideas
and link them into the program.

I highly recommend visiting the site: http://www.csszengarden.com/
CSS Zen Garden shows you what is possible with a variety of style sheets. I
want that capability in the next interpreter.

Now for the kicker. There is an interpreter that actually uses XML as the
basis of the game: AAS. I know AAS was created as a hoax (Google AAS and
hoax for more on this). But I feel there was a hidden gem in that.

Here is what I have done so far. I have tried to locate the sources to AAS.
No luck. :-(

Since AAS was written in Java, I decompiled the Java. After hacking on the
output from two different Java decompilers I managed to get a version of AAS
to compile and run. Of course I have some nasty source code with awful
identifier names and no comments. I have been here before.

I took all the existing AAS games (11 of them) and "fixed them". I have some
notes about the problems with the XML in several of them. Then I developed a
schema. This pointed out some other issues with the XML. My next step was to
create a much tighter schema and an XSLT to convert the "fixed" XML to the
new schema. As a result the games all still run under the existing AAS
interpreter, but the XML is much cleaner.

I read through the documentation for Adrift. Adrift is much more polished
than the AASIde. Adrift also support sound, color, and such. But Adrift is
not open source.

Now lets talk about the authoring environment. One of the challenges with IF
is that none of the authoring environments give you the support you find in
Microsoft Word. But consider this: the Word 2007 file format is actually a
zip file and the content is actually XML. This means it would not be that
complicated (not easy, but not impossible) to have an import and export
program for the IF into and out of Word. Obviously there would be some
limitations, but it technically possible. Think about what that would mean.
You could sit down and write up all the room and object descriptions in Word
with full spelling and grammar checking. Then move those descriptions into a
base program a game.

Here is something to consider. The video game The Elder Scrolls IV: Oblivion
had a couple of megabytes of text. There were many small books you could
read. Some of them quite funny. Interaction with many of the characters in
the game was via menu selection (not command line parsing). That gives you
an idea how far you could actually take IF.

Microsoft has used XML for some interesting tools, for example XAML:
http://en.wikipedia.org/wiki/Extensible_Application_Markup_Language
XAML supports CSS and a whole lot of features.

While I have some free time, (I have more time on my hand than I really
want.) I am working on creating a new interpreter based on some of the ideas
of AAS: basically XML.

Let the flames start. I don't care. I am having fun trying to
create/recreate an interpreter that uses XML as the source for the game.

Jeffrey McArthur
cell: 610-389-0734
home: 610-450-6115
email: jeffmc...@comcast.net
http://www.jeffreymcarthur.com

steve....@gmail.com

unread,
Nov 27, 2008, 10:25:35 PM11/27/08
to
Jeffrey McArthur wrote:
> if you want to do something else with the text in an I7 or TADS 3 file you
> are in trouble. Both have complex syntax and neither supports Unicode very
> well.

I can't comment on I7, but TADS 3 provides full unicode. A lot of work
went into this, so I honestly don't understand your point.

> For me, the solution is to use XML. XML is a standard that is used
> throughout most modern software.

I've thought a lot about XML as a IF tool, and I collaborated on a
project which used XML for procedural story generation. My experience
leads me to feel pretty strongly that it's verbose, messy, and clumsy.
It's good as an *intermediary* or internal format, but it's no fun
working with it directly.

> With XML it is easy to separate form from content.

You'd think this is a good thing! But a lot of IF writing involves
very precise overrides and customized procedures. In a lot of cases,
we're talking about procedurally building a sentence. It makes good
sense to combine the text with procedure.

Of course you're right when it comes to standard (graphical) games,
where all the sentences are pre-constructed, and it's just a matter of
presenting them in the right order.

Jim Aikin

unread,
Nov 27, 2008, 10:39:02 PM11/27/08
to
steve....@gmail.com wrote:
>
>> [A] little clever code an author
>> create the _impression_ of an object state transformation or a
>> continuous space. The player only cares about what's actually printed to
>> the screen, not about the underlying mechanics. And we can print
>> anything to the screen!
>
> Yes, sometimes a quicko hack works fine. Sometimes a shallow
> implementation feels really clumsy, and players won't be able to do
> what they want, and what is natural to expect from the story.

This is off-topic, but can you give a concrete example of an action that
a player actually _can't_ take because T3 won't allow it?

>> Having recently written a game that was
>> set in a large open area, I'm not satisfied with the way it reads[.]
>> [...]
>> I would always use fake scenery objects in a cave
>> room in order to simulate the view of distant objects in other rooms.
>> That's not hard to do.
>
> Here's an example where a shallow implementation runs into trouble.
> It's hard to give the impression of open space, since you want to make
> those distant objects interact-able, so you need implicit movement,
> etc. -- I'd recommend you take a look at ConSpace if you haven't
> already done so.

Urrrr, that was what I used, actually, in "April in Paris." The large
open space felt rather incoherent and cluttered with output, because an
NPC or two was usually running around, not in your immediate vicinity
but nearby. The second problem was that I had to hack the sightSize of a
number of objects to prevent silly problems with disambiguation; so in
essence I was "slicing" the large space into isolated small spaces in
order to get the right output. I also had to write manual "you move into
the area" messages, if memory serves, because the absence of a Room Name
following movement made the whole thing look too vague when the player
was moving around.

>> [I]f it's all being filtered through the teletype
>> metaphor, it won't look or feel professional no matter how sophisticated
>> the library is.
>
> I think you're right on one level. On another level, the genre can get
> a *lot* more sophisticated than it is right now, without developing
> the interface in this way.

A lot depends on how we define "sophisticated." I'm only peripherally
interested in the kind of in-game model world sophistication that seems
to fascinate you. I'm a lot more interested in what I would call a
professional look, professional being a somewhat different beast from
sophisticated.

>> HTML TADS has some nice tools. But of course, it's not available on OS
>> X, so there's a wee gap between the conception and the realization.
>
> An interpreter written in a multi-platform GUI might be a good
> development. There are many such systems. wxWidgets is my favorite,
> but there's also Juice, GTK+, TrollTech QT, and probably some others.

I wish I was a real programmer....

--JA

Mike Rozak

unread,
Nov 27, 2008, 10:55:10 PM11/27/08
to
On Nov 27, 3:40 pm, Jim Aikin <midigur...@gmail.com> wrote:
> Is it maybe time to rethink the teletype metaphor?

I agree with the general idea, except that I like graphics and sound.
(My engine/UI would do much of what you want, except for the additonal
graphics/sound, and Windows.)

Ignoring the graphics/sound part, I'd like to point this out:

In parallel univere to IF-land, is the world of text MUDs. Many MUD
developers are talking about exactly the same thing. They're still
stuck in the teletype days, and many of them would like fancier UIs as
discussed here.

Anyone interested in this idea might also wish to talk to their
counterparts in the parallel universe.

By the way, MUD developers are stuck in a paradigm-shift rut: MUDs
want to attract the most players so they write to the lowest common
denominator, basically Teletype. Many-many MUD clients are written
every year, but they're all written by hobbyists who run out of time,
so very few MUD clients ever progress beyond Teletype machines. (Those
that do get further specialize into complex macro-playback devices to
reduce typing in MUDs.) No one has the time to write a good client,
and if they did, it wouldn't matter because no MUD would use the nice
UI. Add to that the fact that, just like IF, MUD players want to play
their favorite MUDs on any of umpteen million platforms, which makes a
MUD client with a nice UI virtually impossible.

Jim Aikin

unread,
Nov 27, 2008, 11:03:51 PM11/27/08
to
Jeffrey McArthur wrote:
>
> For me, the solution is to use XML. XML is a standard that is used
> throughout most modern software. With XML it is easy to separate form from
> content.

I guess I don't understand why separating form from content is a good
thing. I think the whole thrust of my vision here (insofar as it can be
said to have a coherent thrust) is that form and content ought to be
_more_ tightly linked. That is, if by "form" you mean "the appearance of
the presentation".

What I'm suggesting is that the author ought to have the tools with
which to write a game in which the content (a particular paragraph of
output, for instance) would include embedded controls that would also
alter the presentation in some arbitrary manner (such as altering the
text or images displayed in a secondary floating window).

> How something is displayed can be controlled by external style
> sheets.

External to what? As the author, I would want to include them in my
game! So in what sense would they be "external"?

> Let me give you a concrete example of why it is important that the source be
> in XML. Lets assume the author has created a masterpiece of IF. How the
> author wants to select some great examples from program and put them on a
> web page. How do you do that with I7 or TADS 3?

It's called "cut and paste". It's not difficult. It's a technique I use
all the time. I'll bet you do too.

> If the source was XML, all
> you need to do is write up an XSLT to extract the appropriate sections. XML
> comes with a huge selection of tools that allow you to manipulate and
> process the data.

Hate to be a wet blanket, but I don't even know what an XSLT is, let
alone how to write one up. Speaking as an author, I would need you to
explain to me why that would be something I should want to learn. Sorry.

> I read through the documentation for Adrift. Adrift is much more polished
> than the AASIde. Adrift also support sound, color, and such. But Adrift is
> not open source.

Given the other difficulties that I've heard mentioned with respect to
Adrift authoring (in the command parsing department, if memory serves),
the fact that you're touting something less polished than Adrift does
not fill me with confidence. Quite likely I'm being too negative,
though, or jumping to unjustified conclusions. Does Adrift support
multiple windowing? Does it support audio fadeouts? Does it support the
author's redesign of the main window? Does it support mouse hover tooltips?

> Now lets talk about the authoring environment. One of the challenges with IF
> is that none of the authoring environments give you the support you find in
> Microsoft Word.

The connection is breaking up. Can you define what you mean by "support"
in this context?

> But consider this: the Word 2007 file format is actually a
> zip file and the content is actually XML. This means it would not be that
> complicated (not easy, but not impossible) to have an import and export
> program for the IF into and out of Word. Obviously there would be some
> limitations, but it technically possible. Think about what that would mean.
> You could sit down and write up all the room and object descriptions in Word
> with full spelling and grammar checking. Then move those descriptions into a
> base program a game.

Well, no, I couldn't, actually. More than 50% of my room and object
descriptions are assembled on the fly using various kinds of if-tests.
And even if that weren't true, moving them would be a multi-stage
process, since the software that did the moving wouldn't know where in
the source code anything belonged!

> Let the flames start. I don't care. I am having fun trying to
> create/recreate an interpreter that uses XML as the source for the game.

I'm not going to flame you for having a vision and striving to implement
it! You may indeed be onto something. I don't know enough about XML to
know, one way or the other.

What I do know is that we already have I7 and T3, both of which are
perfectly swell coding systems for designing games. What we need, in my
opinion, is a better front end -- the thing the user actually sees. Will
XML move us in that direction? If so, I'd love to hear how you would use
it toward that end.

--JA

Jim Aikin

unread,
Nov 27, 2008, 11:16:46 PM11/27/08
to
steve....@gmail.com wrote:
>
> It sounds like what you're saying, Dave, is that you want a highly
> abstracted API for the IF writer. That's a good idea, and I think
> everyone agrees in general. Nikos is talking about how a lower-level
> API can be designed to bring this about, in a way which is both
> abstract and OS-independent.

This is one of those places where I start to feel like the poor dumb
clod-kicker from a farm town in Illinois. What does "highly abstracted"
mean? What is "a lower-level API"?

> I think this will make a lot better sense if we clarify what "API"
> means. An "API" is a set of instructions which a program can
> understand. Your OS is a program, and your interpreter is a program
> that runs within the OS. Thus, we can say that there are several
> levels of API. You can even have multiple APIs within a single
> program.

I wish I could see how that explains what "lower-level API" means, but
I'm still not getting it.

> Nikos wasn't saying that regular IF authors will want to do a lot of
> channel IO management, of course!

And ... what does "channel IO management" mean? I'm not trying to be
obtuse, honestly. Maybe it's just that I ate a big Thanksgiving dinner
and right now my stomach is using most of the available blood supply,
leaving less for my brain. But I tend to think about these things in
more concrete terms.

For instance: I might want to have the PC's current inventory list
displayed in a separate window (not in a pane within the main window, as
required by Glk). I might want each item in the inventory list to
display its current description text in a tooltip when you hover the
mouse over the name. In a game designed for newbies, I might also want
the player to be able to right-click on an inventory item and see a
partial (or complete) list of the verbs that can be meaningfully used
with this particular object. Another item in the right-click pop-up menu
might open a set of hints (in yet another window, which might or might
not be open before the menu item is selected) that would suggest how and
where that object might be used.

Am I describing a highly abstracted API or a lower-level API? Am I
describing "a lot of channel IO management"? Can you help me understand
this?

--JA

steve....@gmail.com

unread,
Nov 27, 2008, 11:22:36 PM11/27/08
to
Jim Aikin wrote:
> >> [A] little clever code an author
> >> create the _impression_ of an object state transformation or a
> >> continuous space. The player only cares about what's actually printed to
> >> the screen, not about the underlying mechanics. And we can print
> >> anything to the screen!
>
> > Yes, sometimes a quicko hack works fine. Sometimes a shallow
> > implementation feels really clumsy, and players won't be able to do
> > what they want, and what is natural to expect from the story.
>
> This is off-topic, but can you give a concrete example of an action that
> a player actually _can't_ take because T3 won't allow it?

No, it's not a matter of TADS-3 making a limitation. The point was
that complex scenarios often cannot be adequately presented with
simple hacks.

> > I'd recommend you take a look at ConSpace if you haven't
> > already done so.
>
> Urrrr, that was what I used, actually, in "April in Paris." The large
> open space felt rather incoherent and cluttered with output, because an
> NPC or two was usually running around, not in your immediate vicinity
> but nearby.

Yes, you'd want to add an output filter for remote NPC travel reports.

> The second problem was that I had to hack the sightSize of a

> number of objects to prevent silly problems with disambiguation[.]

Really? Disambiguation should favor nearby objects... I'd like to see
the scenario, so I could correct ConSpace if necessary.

> I also had to write manual "you move into
> the area" messages, if memory serves, because the absence of a Room Name
> following movement made the whole thing look too vague when the player
> was moving around.

There's two types of connection provided by ConSpace. Sounds like
maybe you were using the wrong type (some of the time). It would be
interesting to hear about your experience with the extension, but
better to discuss this in a different thread. :)

Jim Aikin

unread,
Nov 27, 2008, 11:30:59 PM11/27/08
to
ChicagoDave wrote:
>
> The channel system is entirely "soft". We put the infrastructure
> together to create channels and we just happened to implement that
> list. If you decided you wanted the foo, bar, and xyzzy channels,
> that's entirely up to you and it's entirely up to you how to implement
> them in your game code.

In which case, how exactly would I define what happens when I use the
foo channel? I mean, what if I want the foo channel to, for instance,
gray out the Undo command in the main menu because I'm writing a
randomized combat scene? (Not that I would do that, but some other
author might want to.) How would this syntax --

> select the main channel;
> say "This is text in the main channel.";
> select the help channel;
> say "This is text in the help channel.";
> select the main channel.

-- tell the interpreter to gray out a top-level menu item?

> Of course the Main, Location, Score, Time, Prompt, Title, Chapter, and
> Credits channels are sort of ubiquitous, so I don't think you'd want
> to alter their default behavior.

Well, you and I might not want to, but it's a reasonable bet that
somewhere along the line some author or other might want to. So I'm
disinclined to want to make too many features "hard-wired".

> I would never have a license that prevented hobbyist use or individual
> commercial sales.

Reading between the lines, I think what you're saying is that if I were
using the Textfyre system in some way, as long as I was selling my game
from my own website you wouldn't care, but if I were to manage (against
overwhelming odds) to interest Del Rey in publishing my science fiction
game, you would want a royalty.

That would be entirely appropriate, of course, I'm not complaining ...
but unless you have a set royalty schedule that you can present to an
author before game development begins, an author who is even mildly
interested in pursuing that type of publishing deal would be very
ill-advised to use your system. Because it could absolutely kill the
deal when the publisher learns that some other party has to be cut a
slice of the pie.

> Note that this system is not strictly for Inform 7. It's possible to
> implement a similar IO layer in T3.

Can you say more about this? How exactly would that happen? I mean,
given that T3 games are played by the HTML TADS terp in Windows and in
dumb teletype mode by Zoom in the MacOS, what exactly would need to
change in those terps in order for your IO layer to do anything?

> As for what you use to create the user interface, that's dependent on
> the implementation of FyreVM. Currently we make it easy for a .NET
> developer to build their game. It's also possible you could do it in
> Java, a web client, Flash, or anything else.

Your faith in my coding abilities is ... oh, you didn't mean me
personally, you meant "you" meaning "someone." Sorry.

But since you mentioned it ... how exactly do you "make it easy for a
.NET developer to build their game"? No, wait -- I need to ask another
question first: What is a .NET developer?

Sorry to be so dumb. I'm just a writer. I'm trying to educate myself
about this stuff, but it's very much a tangled ball of string to me.

--JA

steve....@gmail.com

unread,
Nov 27, 2008, 11:37:37 PM11/27/08
to
Jim Aikin wrote:
> > It sounds like what you're saying, Dave, is that you want a highly
> > abstracted API for the IF writer. That's a good idea, and I think
> > everyone agrees in general. Nikos is talking about how a lower-level
> > API can be designed to bring this about, in a way which is both
> > abstract and OS-independent.
>
> This is one of those places where I start to feel like the poor dumb
> clod-kicker from a farm town in Illinois. What does "highly abstracted"
> mean? What is "a lower-level API"?

Ha, don't worry. It's not too hard. "Highly abstracted" means that you
don't need to know how the computer does it; you just tell it to play
a sound file, and it figures out how to send the right signals down
the line, to the speakers.

Down this line, the set of instructions will pass through several API
levels. For example, the IF game's interpreter will tell the OS to
play the file, using the OS's API. Then, the OS will tell the sound
card to play the file, using the sound card's API. (When you install a
"sound card driver", you're telling your OS how to deal with your
sound card's API.)

Unless you've made a major study of this stuff, you shouldn't expect
yourself to be able to contribute greatly to the discussion. (I'm not
in that boat either! Nikos is way ahead of me!)

But basically we're talking about a set of instructions which get re-
interpreted and more specific, the closer we get to the specific
hardware which will carry out the instruction.

Jeffrey McArthur

unread,
Nov 27, 2008, 11:55:00 PM11/27/08
to
On Thu, 27 Nov 2008 19:25:35 -0800 (PST), steve....@gmail.com wrote:

>Jeffrey McArthur wrote:
>> if you want to do something else with the text in an I7 or TADS 3 file you
>> are in trouble. Both have complex syntax and neither supports Unicode very
>> well.
>
>I can't comment on I7, but TADS 3 provides full unicode. A lot of work
>went into this, so I honestly don't understand your point.

I stand corrected on TADS 3. But TADS 3 still is rather backward in its
support of fonts, colors, and styles. Reading from page 48 of Learning T3:

]Another special kind of thing we can put inside strings is HTML markup (or
that
]version of HTML markup that TADS 3 recognize). For a full account, see
Introduction
]to HTML TADS (which is part of the standard TADS 3 documentation set). Some
]commonly used HTML tags are:
]* <b> ... </b> - display text in bold
]* <i> ... </i> - display text in italics
]* <u> ... </u> display text underlined
]* <FONT COLOR=RED> ... </FONT> - display text in red.
]* <a> ... </a> display text as a hyperlink.

the <FONT> tag was deprecated in HTML 4.0 which was recommended in 1998. Ten
years later, TADS 3 is using something that was considered harmful back in
1998: http://www.w3schools.com/HTML/html_fonts.asp


>> For me, the solution is to use XML. XML is a standard that is used
>> throughout most modern software.
>
>I've thought a lot about XML as a IF tool, and I collaborated on a
>project which used XML for procedural story generation. My experience
>leads me to feel pretty strongly that it's verbose, messy, and clumsy.
>It's good as an *intermediary* or internal format, but it's no fun
>working with it directly.

I agree XML is verbose. There is a reason XML is verbose, it is in response
to the lack of verbosity in the predecessor to XML: SGML. I have a copy of
the SGML standard on my bookshelf. There are chapters on how to avoid adding
a single extra character, e.g. a trailing less than ">". Having worked with
SGML, I welcome XML's verbosity.

Not sure about messy. It works. You could argue that all XHTML web pages are
messy. Ok. But they work.

Again, not sure about clumsy. XHTML web pages work. XHTML Mobile works on
cell phones.

Having spent over a decade working with XML, to me, it is easy. On the other
hand, I understand your difficulty. Today is Thanksgiving. I made dinner. I
was unhappy how my turkey gravy turned out. I know that people who have been
making gravy for many years could have done a better job, not because they
are smarter or better, but because they have been doing it longer than I
have. I can cook, but I am not a chef. On the other hand, I do know XML. My
last boss once commented that I may know too much about XML.

>> With XML it is easy to separate form from content.
>
>You'd think this is a good thing! But a lot of IF writing involves
>very precise overrides and customized procedures. In a lot of cases,
>we're talking about procedurally building a sentence. It makes good
>sense to combine the text with procedure.

You are missing the point. A well designed web page could pull data from a
database, process it, and use Javascript to tag it (DHTML and AJAX). But the
style of the page is contained in a separate file: the cascading style sheet
or CSS. You can put the style sheet in the HTML, but in general that is not
a good idea. The best practice is to put all your styles into a {set?} of
style sheet{s?}. This allows the author/creator to define the styles and
reuse them over and over without refering to specific colors and fonts each
time. For example, if I am creating an IF game and I want the word FooBar to
come out in a red bold font every time it appears do I really want to
scatter all those commands to make it red and bold throughout all the code?
Instead I want to specify a style and name it "foobarstyle" and then specify
that the word must use the "foobarstyle". The advantage is if I later want
to change the shade of red I have to change it in one and only one place
rather than search through all my code.

>Of course you're right when it comes to standard (graphical) games,
>where all the sentences are pre-constructed, and it's just a matter of
>presenting them in the right order.

I am suggesting that future interpreters take ideas from the best practices
in web site development (in addition to best practices for programming
style, documentation, and so on).

steve....@gmail.com

unread,
Nov 28, 2008, 12:14:47 AM11/28/08
to
Let me just give a very brief explanation of the way "style sheet"
stuff is best handled in TADS 3. Basically, you can define tags which
can be embedded anywhere you have text. During the final output
processing phase, "building the transcript," these tags are processed
and the output is modified as appropriate, so it prints correctly.

In other words, there's a built-in tags interpreter. By the way, it's
possible to add programmatical elements to tags. You can make it so
that when a tag gets passed through the output filter, it sets a
value. It's actually quite smart, powerful and cool.

Gene Wirchenko

unread,
Nov 28, 2008, 12:16:57 AM11/28/08
to
Woolyloach <edav...@hotmail.com> wrote:

[snip]

>I'd also be on the side of the author determining and controlling
>presentation. If I say "do it THIS way" then by golly I want it done
>"THAT way", not some second-guess of the presentation system! It's MY
>story and MY world, don't mess with it!! Ok, sorry, rant over... :-/

OTOH, whose computer is it running on?

[snip]

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Jeffrey McArthur

unread,
Nov 28, 2008, 12:41:07 AM11/28/08
to
On Thu, 27 Nov 2008 20:03:51 -0800, Jim Aikin <midig...@gmail.com> wrote:

>Jeffrey McArthur wrote:
>>
>> For me, the solution is to use XML. XML is a standard that is used
>> throughout most modern software. With XML it is easy to separate form from
>> content.
>
>I guess I don't understand why separating form from content is a good
>thing. I think the whole thrust of my vision here (insofar as it can be
>said to have a coherent thrust) is that form and content ought to be
>_more_ tightly linked. That is, if by "form" you mean "the appearance of
>the presentation".

I am going to make an assumption that you have at some point in your life
used Microsoft Word. If you are entering in a document in word you can
select some text and click on Heading 1 to make that text a larger, bolder
heading. You don't specify the specific font or point size. You say that the
text is a Heading 1. You can then go in and change all the Heading 1 text to
be a different font, or change the point size and so on. You can even change
just one of the Heading 1 to be slightly different, in which case Word
automatically assigns a new style name (which you can later select and
reuse). Microsoft has sold a lot of copies of Word. It is not perfect, but
it works and a lot of people use it. The idea is that the style of the text
is specified separately from the actual text. In web site design, you put
all the styles into a cascading style sheet or CSS.

>What I'm suggesting is that the author ought to have the tools with
>which to write a game in which the content (a particular paragraph of
>output, for instance) would include embedded controls that would also
>alter the presentation in some arbitrary manner (such as altering the
>text or images displayed in a secondary floating window).
>
>> How something is displayed can be controlled by external style
>> sheets.
>
>External to what? As the author, I would want to include them in my
>game! So in what sense would they be "external"?

Of course you would include them in your game. But all the styles, fonts,
and colors are specified in one place and you refer to them by a name you
assign rather than specifically.

From a technical point of view, if you used a cascading style sheet it would
be a separate file. But many applications today distribute a single file
that is actually a compressed archive. For example, a Word 2007 file, a
.docx file, is actually a .Zip file. In the file are several other files.
One of them is the style sheet for the document. A future interpreter could
follow the same approach. For distribution all the files would be put
together into a single zip file. But during development, the files would be
separate and distinct. If you are programming in Java, the .jar file is
actually a .zip file that contains all the separately compiled pieces of
your program. The .jar file can contain things like graphics and sound
files.

>> Let me give you a concrete example of why it is important that the source be
>> in XML. Lets assume the author has created a masterpiece of IF. How the
>> author wants to select some great examples from program and put them on a
>> web page. How do you do that with I7 or TADS 3?
>
>It's called "cut and paste". It's not difficult. It's a technique I use
>all the time. I'll bet you do too.

That works, but if you have a large file it is difficult. For example, I did
some work with the full DMOZ database. At the time, it was 1.6 Gigabyte XML
file. Trying to cut and paste out of a 1.6 Gigabyte file is not easy. The
file is just too big. As IF games get bigger, and they will if you add sound
and graphics, they may become a bit too large to do cut and paste. Referring
back to the video game Oblivion, I heard there were several megabytes of
text in the form of books. Finding them in a single file could be a bit of a
challenge.

That brings up another interesting point. XML has a defined inclusion method
called XInclude. This means I could implement my IF in separate pieces, then
include them all together to form the final project. All using tools that
are available to anyone and not limited to a specific IF programming
language or system.

>> If the source was XML, all
>> you need to do is write up an XSLT to extract the appropriate sections. XML
>> comes with a huge selection of tools that allow you to manipulate and
>> process the data.
>
>Hate to be a wet blanket, but I don't even know what an XSLT is, let
>alone how to write one up. Speaking as an author, I would need you to
>explain to me why that would be something I should want to learn. Sorry.

As an author, you may not need to. However, you can easily find someone who
knows XSLT, it is a standard tool for processing XML. Let me give you an
analogy. If I know I need to have the brakes on my car fixed, I don't know
how and I know I don't have the tools to do it. On the other hand, there are
lots of places I can go that do have the tools and people that know how to
fix them. All I am saying is there are a lot more people who know how to
write and use an XSLT than there are that author IF.

>> I read through the documentation for Adrift. Adrift is much more polished
>> than the AASIde. Adrift also support sound, color, and such. But Adrift is
>> not open source.
>
>Given the other difficulties that I've heard mentioned with respect to
>Adrift authoring (in the command parsing department, if memory serves),
>the fact that you're touting something less polished than Adrift does
>not fill me with confidence. Quite likely I'm being too negative,
>though, or jumping to unjustified conclusions. Does Adrift support
>multiple windowing? Does it support audio fadeouts? Does it support the
>author's redesign of the main window? Does it support mouse hover tooltips?

I mentioned that AAS was a hoax. It works, but is far from complete. There
are bugs; for example the onopen event never triggers (I found that one the
hard way). What I am saying is that AAS is an example of what could be done
in a future interpreter. Someone actually implemented a game interpreter
using XML. It has already been done. The proof of concept already exists.
The finished product has not even been started.

>> Now lets talk about the authoring environment. One of the challenges with IF
>> is that none of the authoring environments give you the support you find in
>> Microsoft Word.
>
>The connection is breaking up. Can you define what you mean by "support"
>in this context?

How about grammar and spell checking? Thesaurus?

>> But consider this: the Word 2007 file format is actually a
>> zip file and the content is actually XML. This means it would not be that
>> complicated (not easy, but not impossible) to have an import and export
>> program for the IF into and out of Word. Obviously there would be some
>> limitations, but it technically possible. Think about what that would mean.
>> You could sit down and write up all the room and object descriptions in Word
>> with full spelling and grammar checking. Then move those descriptions into a
>> base program a game.
>
>Well, no, I couldn't, actually. More than 50% of my room and object
>descriptions are assembled on the fly using various kinds of if-tests.
>And even if that weren't true, moving them would be a multi-stage
>process, since the software that did the moving wouldn't know where in
>the source code anything belonged!
>
>> Let the flames start. I don't care. I am having fun trying to
>> create/recreate an interpreter that uses XML as the source for the game.
>
>I'm not going to flame you for having a vision and striving to implement
>it! You may indeed be onto something. I don't know enough about XML to
>know, one way or the other.
>
>What I do know is that we already have I7 and T3, both of which are
>perfectly swell coding systems for designing games. What we need, in my
>opinion, is a better front end -- the thing the user actually sees. Will
>XML move us in that direction? If so, I'd love to hear how you would use
>it toward that end.

There is an IDE for AAS. Not very polished. It generates XML. As a proof of
concept, it works. I have not installed Adrift. I have been reading the
documentation (reading documentation before actually trying to use the
product, what a concept!).

Right now, I am focused on the back end. I know it will be possible to
create a front end. But to be honest, no front end will ever give the full
capabilities of hand editing the XML. This is true with website design
today. I know graphic designers who use a variety of web design tools to get
the design 90% of the way there, then they jump in and hand tweek the
HTML/XHTML. Of course, there are an amazing number of people who deisgn
their websites and never do the hand tweeking. In that case the web pages
works, but occationally it has a few funny effects in the way it displays.

For me, they key is designing the "language" of the game, which for me will
be XML. I read through the technical notes for Inform 6. The compiler uses
an LALR(4) grammar!!! I found the technical manual for Inform 6 very well
written and informative. But I don't want to create anything that requires
that level of complexity.

I am started on the XML Schema and interpreter first. Then later create a
front end. If I ever get the time for that.

Jeffrey McArthur

unread,
Nov 28, 2008, 12:48:25 AM11/28/08
to

I guess I am just too old and irritable. I find it hard to understand how a
syntax that the W3 declared deprecated more than a decade ago could be
smart, powerful and cool.

Jim Aikin

unread,
Nov 28, 2008, 1:00:53 AM11/28/08
to
Gene Wirchenko wrote:

> Woolyloach <edav...@hotmail.com> wrote:
>
>> I'd also be on the side of the author determining and controlling
>> presentation. If I say "do it THIS way" then by golly I want it done
>> "THAT way", not some second-guess of the presentation system! It's MY
>> story and MY world, don't mess with it!! Ok, sorry, rant over... :-/
>
> OTOH, whose computer is it running on?

I guess my main issue with this line of reasoning is that I don't see it
being followed in any of the professional music apps I use.

Ableton Live, for instance, has a very specific and distinctive graphic
design. You can like it or hate it, but how you feel as the end user
**doesn't matter**. It's what it is. Ableton's software engineers chose
that design for specific reasons that seemed cogent and compelling to
them. And because their program is wildly successful, one would have to
say that on the whole, they probably made pretty good choices.

It would make no sense whatever to the designers of Live for an
individual musician to say, "I want to change the font used on the
buttons," or "I want the clip editor at the top of the main window and
the transport controls at the bottom." Their answer, I'm pretty sure,
would be, "You want a program that looks like that? Go write your own."

--JA

Jim Aikin

unread,
Nov 28, 2008, 1:16:49 AM11/28/08
to
Jeffrey McArthur wrote:
>
> I am going to make an assumption that you have at some point in your life
> used Microsoft Word. If you are entering in a document in word you can
> select some text and click on Heading 1 to make that text a larger, bolder
> heading. You don't specify the specific font or point size.

Actually, you're wrong about that. At the publishing house where I used
to work, we were told never to use Word styles, because they weren't
entirely compatible with the version of QuarkXpress in use at the time.
We were told to leave everything in the default style and add bold to
the headings manually. That's what I still do, simply out of habit.

I'm having to change, now that I'm using Open Office, because it's
buggy. It doesn't handle this sort of manual formatting properly -- it
more or less INSISTS that you use styles. Grrrr.

You say that the
> text is a Heading 1. You can then go in and change all the Heading 1 text to
> be a different font, or change the point size and so on. You can even change
> just one of the Heading 1 to be slightly different, in which case Word
> automatically assigns a new style name (which you can later select and
> reuse). Microsoft has sold a lot of copies of Word. It is not perfect, but
> it works and a lot of people use it. The idea is that the style of the text
> is specified separately from the actual text. In web site design, you put
> all the styles into a cascading style sheet or CSS.

Yes, I understand that this is useful for website layouts, especially
when they span multiple pages. But I don't use Word for desktop
publishing of anything beyond very minimal one-page handouts, for which
manual formatting works really nicely, and is much MORE convenient than
redefining a style.

>>> How something is displayed can be controlled by external style
>>> sheets.
>> External to what? As the author, I would want to include them in my
>> game! So in what sense would they be "external"?
>
> Of course you would include them in your game. But all the styles, fonts,
> and colors are specified in one place and you refer to them by a name you
> assign rather than specifically.

Okay, that makes sense.

>> Hate to be a wet blanket, but I don't even know what an XSLT is, let
>> alone how to write one up. Speaking as an author, I would need you to
>> explain to me why that would be something I should want to learn. Sorry.
>
> As an author, you may not need to. However, you can easily find someone who
> knows XSLT, it is a standard tool for processing XML. Let me give you an
> analogy. If I know I need to have the brakes on my car fixed, I don't know
> how and I know I don't have the tools to do it. On the other hand, there are
> lots of places I can go that do have the tools and people that know how to
> fix them. All I am saying is there are a lot more people who know how to
> write and use an XSLT than there are that author IF.

Undoubtedly true. I wonder how many of them would be willing to work for
free.

>>> Now lets talk about the authoring environment. One of the challenges with IF
>>> is that none of the authoring environments give you the support you find in
>>> Microsoft Word.
>> The connection is breaking up. Can you define what you mean by "support"
>> in this context?
>
> How about grammar and spell checking? Thesaurus?

In my experience, which admittedly is not recent, grammar checking is a
cruel hoax. I wouldn't touch it with a pole -- and of course it would
spit up if you showed it a sentence with embedded tags or if-tests.
Spell checking is genuinely useful, no argument there. I never use a
thesaurus, but that's just me. Others may find it useful. So yes, in
that sense developing the text of a game in OpenOffice would be
genuinely cool.

--JA

Gene Wirchenko

unread,
Nov 28, 2008, 1:42:44 AM11/28/08
to
Jim Aikin <midig...@gmail.com> wrote:

>Gene Wirchenko wrote:
>> Woolyloach <edav...@hotmail.com> wrote:
>>
>>> I'd also be on the side of the author determining and controlling
>>> presentation. If I say "do it THIS way" then by golly I want it done
>>> "THAT way", not some second-guess of the presentation system! It's MY
>>> story and MY world, don't mess with it!! Ok, sorry, rant over... :-/
>>
>> OTOH, whose computer is it running on?
>
>I guess my main issue with this line of reasoning is that I don't see it
>being followed in any of the professional music apps I use.
>
>Ableton Live, for instance, has a very specific and distinctive graphic
>design. You can like it or hate it, but how you feel as the end user
>**doesn't matter**. It's what it is. Ableton's software engineers chose

Oh, but it does. Irritate me too much, and your software gets
deleted.

Mike Tarbert

unread,
Nov 28, 2008, 2:29:10 AM11/28/08
to
Gene Wirchenko wrote:
> Jim Aikin <midig...@gmail.com> wrote:
>
>> Gene Wirchenko wrote:
>>> Woolyloach <edav...@hotmail.com> wrote:
>>>
>>>> I'd also be on the side of the author determining and controlling
>>>> presentation. If I say "do it THIS way" then by golly I want it done
>>>> "THAT way", not some second-guess of the presentation system! It's MY
>>>> story and MY world, don't mess with it!! Ok, sorry, rant over... :-/
>>> OTOH, whose computer is it running on?
>> I guess my main issue with this line of reasoning is that I don't see it
>> being followed in any of the professional music apps I use.
>>
>> Ableton Live, for instance, has a very specific and distinctive graphic
>> design. You can like it or hate it, but how you feel as the end user
>> **doesn't matter**. It's what it is. Ableton's software engineers chose
>
> Oh, but it does. Irritate me too much, and your software gets
> deleted.
>

While I appreciate that *some* customization by the end - user might be
desirable, I imagine my future conversation with "Joe the IFer":

JOE: Skinny Mike's debut game sucks!
ME: I'm sorry. What didn't you like about it?
JOE: First of all, why the hell was the file so big?
ME: Oh, that was all the original music I composed, sorry... didn't you
like it?
JOE: I always keep the sound off. Anyway, why did my character keep
"feeling the urge to run?"
ME: Well, those gunshots --
JOE: What gunshots? I told you, the SOUND was OFF.
ME: Well, yeah, but when you turn the sound off with the "SOUND OFF"
command, the game automatically adds text messages to --
JOE: "SOUND OFF" command? I just turn the speakers off. It's a knob.
ME: Well, didn't you notice on the cover page, the warning --
JOE: I have "skip cover pages" as the default in my 'terp.
ME: Okay, but in the first page of text, just after the banner, I have
printed IN BOLD --
JOE: Bold face? Ugh. I've got that disabled in my 'terp. I must have
missed your "warning." Listen, forget about the gunshots. Your *game*
sucks. It was too hard for me to keep track of all that inventory, for
one thing.
ME: That's why I implemented a second inventory window. The idea was --
JOE: Multiple window? No can do.
ME: Oh, wow, sorry. I though I hit all the platforms. I had some people
on raif working for six months to get that stuff implemented for i-phone
and palmOS 'terps. What are you using?
JOE: My 'terp supports multiple windows, I just don't like 'em. Dis---ABLED!
ME: Okay, when the game first loads up and the interpreter gives you the
warning, "This game has recommended settings, would you like to
temporarily override user defaults?" what did you answer?
JOE: "No." After all, it is MY computer.
ME: Um, in the readme file --
JOE: I don't read "readme" files! I know how to install a text adventure!
ME: In the "ABOUT" text --
JOE: Who the hell reads those before the game? I read that stuff
after... and only if I like your game, which by the way, I didn't.
ME: Yeah, you mentioned that... but to be fair, I don't think you
actually played *my* game at all.
JOE: Alright, your game is fine; *you* suck.
ME: I guess I do :(

Skinny Mike

ChicagoDave

unread,
Nov 28, 2008, 2:44:52 AM11/28/08
to
On Nov 27, 10:16 pm, Jim Aikin <midigur...@gmail.com> wrote:
> For instance: I might want to have the PC's current inventory list
> displayed in a separate window

We haven't done this, but probably will at some point. We could easily
create an inventory channel and send the list of inventory items to
the channel. And without getting too technical, the format of the list
would be clear enough so that the UI developer could see item names,
descriptions, and whatever else you might define (weights, sizes).

> the player to be able to right-click on an inventory item and see a
> partial (or complete) list of the verbs that can be meaningfully used
> with this particular object.

This wouldn't be automatic in I7, not sure about T3. But it would be
simple enough to include in the inventory channel data, the list of
verbs...something like:

<item name="rock"><verblist>throw,drop</verblist></item>

> Another item in the right-click pop-up menu
> might open a set of hints (in yet another window, which might or might
> not be open before the menu item is selected) that would suggest how and
> where that object might be used.

We're implementing a hint channel that will have topics and hints
data. How it's implemented is up to the developer.

> Am I describing a highly abstracted API or a lower-level API? Am I
> describing "a lot of channel IO management"? Can you help me understand
> this?

Highly abstracted in this case means the API is accepting data has no
functional interface.

So a low level API might have:

DisplayText(top, left, height, width, text);

And a high level abstraction API might have:

DisplayText(text);

In the first case we're actually telling the UI there is a window, its
location on the screen, and its size and what text goes in the window.
In the second case we're simply passing text and leaving the use of
that text to the UI development.

In Channel IO, we're defining an API based on the function of the
text:

DisplayMainText(text);
DisplayHintsText(text);
DisplayPrologueText(text);

It's not as highly abstracted as DisplayText(text), but it's only one
step removed.

Hope that makes sense.

David C.

Matthew Wightman

unread,
Nov 28, 2008, 4:37:16 AM11/28/08
to
On 27 Nov, 18:44, "OKB (not okblacke)"

<brenNOSPAMb...@NObrenSPAMbarn.net> wrote:
> vaporware wrote:
> > Perhaps the problem
> > is just that Glk is missing some features, or Glk interpreters and VM-
> > level libraries aren't taking full advantage.
>
> I'd agree with that. Or, to put it a bit more strongly, the Glk
> spec makes too many features optional, so a lot of terps don't support
> them, so almost no features are actually usable in a straightforward way
> by a game. You have to query the terp at every step to see if what you
> want to do is possible.

Which features do you feel shouldn't be optional? Most of the optional
stuff seems to be things that could potentially make implementing Glk
on some of the more ...interesting... platforms out there
significantly more painful.

My own attempt(s) at a port of Glulxe to RISC OS still doesn't
implement a significant number of optional sections of the Glk spec.;
the ability to produce a "partial implementation" and test it with
games that don't require those features has been very useful!

--
Matthew Wightman

Ron Newcomb

unread,
Nov 28, 2008, 5:01:49 AM11/28/08
to
On Nov 27, 10:30 am, "S. John Ross" <sj...@io.com> wrote:
> Yes. I'd love for the author to have the ability to (for example) code
> games to call up changes in things like background or border imagery,
> or fonts, etc ... but I think such power should always be
> counterbalanced by the player's ability to refuse the frippery and/or
> replace it with their own preferences. I too consider this a 21st-
> century issue, and here in the 21st century, webpage authors (for
> example) can specify fonts and colors and background images and
> embedded sounds ... and I can (with any decent browser) choose to
> _override_ those choices and replace them with those my eyes (or
> sensibilities) find more pleasing or appropriate. Speaking more
> theoretically, it might be cool to have an mp3 that could
> automatically re-skin my copy of WinAmp to suit the song ... but it
> would NOT be cool if I couldn't shut that feature off.

I come down on the author's side here. WinAmp and web browsers exist
to augment this world; I-F creates a new world, and transplants or
erodes the reader's sense of self. So skinning WinAmp is like
decorating your apartment's walls, while modifying the author's I-F is
like swapping props in a movie. I don't see anything to be gained
there. I-F interpreters are not web browsers.

But having said that...

On Nov 27, 9:09 am, Jon Ingold <jon.ing...@gmail.com> wrote:
> I don't know: Glk has some pretty fundamental limitations, like not
> being able to access/vary text on the main screen after it's been
> output

That's about the only feature I'd particularly care to use -- and even
then, only to rewrite the command line, such as expanding the player's
abbreviations to full words, or delete the command and the parser
error it caused.

-R

goodbye...@yahoo.dk

unread,
Nov 28, 2008, 6:29:14 AM11/28/08
to
On Nov 28, 7:16 am, Jim Aikin <midigur...@gmail.com> wrote:
> In my experience, which admittedly is not recent, grammar checking is a
> cruel hoax. I wouldn't touch it with a pole -- and of course it would
> spit up if you showed it a sentence with embedded tags or if-tests.

Perhaps it would work best to have the spell checker operating on the
output during testing, rather than on the actual code?

Jeffrey McArthur

unread,
Nov 28, 2008, 6:39:42 AM11/28/08
to

That was great!

I remember the day I fired up my laptop to play a video game and I could not
get any sound. I rebooted. Still no sound. I started checking all the plugs
and such. I am trying a variety of things, and still no sound. Finally my
wife asks what the problem is. I say I can't get any sound. She replies,
that she had had turned the volume all the way down. In marriage, sometimes
YOUR computer gets used by your SPOUSE and they do things to it.

Jeffrey McArthur

unread,
Nov 28, 2008, 6:48:59 AM11/28/08
to

I would suggest a slight modification:

DisplayText(text);
DisplayText(nameOfWindow, text);

By default, you would want the text to go to the main window. Only in those
cases where the author wants to override the default would they have to
specify the actual window.

S. John Ross

unread,
Nov 28, 2008, 8:16:19 AM11/28/08
to

> I come down on the author's side here.  

I'm on neither side; I consider the split nonsensical. The author
should be able to do his thing; the player should be able to do his.

> WinAmp and web browsers exist
> to augment this world;

They present media, same as an interpreter.

> I-F creates a new world, and transplants or
> erodes the reader's sense of self.

So do many songs and web-pages, but my post wasn't about IF; it was
about IF interpreters.

> So skinning WinAmp is like
> decorating your apartment's walls, while modifying the author's I-F is
> like swapping props in a movie.

I never said anything in favor of "modifying the author's I-F" or
anything related to it.

> I don't see anything to be gained
> there.

Nor do I; I'm not talking about gains.

> I-F interpreters are not web browsers.

I didn't suggest that they are.

Conrad

unread,
Nov 28, 2008, 10:43:11 AM11/28/08
to
On Nov 27, 10:55 pm, Mike Rozak <M...@mXac.com.au> wrote:
> On Nov 27, 3:40 pm, Jim Aikin <midigur...@gmail.com> wrote:
>
> > Is it maybe time to rethink the teletype metaphor?
>
> I agree with the general idea, except that I like graphics and sound.
> (My engine/UI would do much of what you want, except for the additonal
> graphics/sound, and Windows.)

Maybe I'm just hopelessly old-fashioned here... but I'm fine with
teletype.

But then again, I also resent the constant efforts to soup-up my
email, my word-processing, etc. I don't want a talking dancing
paperclip with googly eyes to start giving me advice on what I'm
doing: I don't even want to see the pagination. It breaks my line of
thought. I just want to write the damn thing.

No, what I like about text games is that they're *text* games. I
think the user should be able to control the font, and for the most
part I think graphics and sound are extraneous. Graphics I can
tolerate: I really don't like music, for text games or web pages.

In my opinion, the best thing that could happen with IF interpreters
is integration with web browsers. And you're starting to see this, a
bit. But we browsers have a pretty well-standardized way to deal with
text, graphics, and sound: there are a few programming platforms that
are about-universal, Java being to my mind the most standard.

It seems to me that's the way to go -- so that, for example, when ten
years from now someone introduces the Amiga 3000, running Linux on a
Papaya processor, by creating a browser that can run standard web
content they've done all of the structural work for us that needs to
be done.

I understand there's Z-code, and I have played IF on the web --
Vespers, for example, is available in Java -- but it seems to me that
IF engines aren't nearly as cross-compatible as they should be.

But, no, I'm fine with teletype. I prefer it, in fact.


Conrad.

Conrad

unread,
Nov 28, 2008, 10:56:23 AM11/28/08
to
On Nov 28, 1:42 am, Gene Wirchenko <ge...@ocis.net> wrote:

> Jim Aikin <midigur...@gmail.com> wrote:
> >Gene Wirchenko wrote:
> >> Woolyloach <edaver...@hotmail.com> wrote:
>
> >>> I'd also be on the side of the author determining and controlling
> >>> presentation.  If I say "do it THIS way" then by golly I want it done
> >>> "THAT way", not some second-guess of the presentation system!  It's MY
> >>> story and MY world, don't mess with it!!  Ok, sorry, rant over...  :-/
>
> >>      OTOH, whose computer is it running on?
>
> >I guess my main issue with this line of reasoning is that I don't see it
> >being followed in any of the professional music apps I use.
>
> >Ableton Live, for instance, has a very specific and distinctive graphic
> >design. You can like it or hate it, but how you feel as the end user
> >**doesn't matter**. It's what it is. Ableton's software engineers chose
>
>      Oh, but it does.  Irritate me too much, and your software gets
> deleted.

I can attest to the absolute truth, valdity and importance of this
observation. I speak as the author of _LAIR of the CyberCow:_ the
only game in recent history that tried to use text-display pauses to
dramatic effect.

People really, really hated that.

In general, as I say, I'm pro-teletype. Maybe illustrated teletype,
as most interpreters now are, is ok.

But certainly I think it would be a mistake to hobble the ability of
the user to adjust the display to their preferences.


Conrad.

Woolyloach

unread,
Nov 28, 2008, 11:31:25 AM11/28/08
to
Your computer, for sure. But as with a book, how it looks doesn't
depend on who's reading it, right? ;-p

Imagine a comic book that changed depending on the time of day, who
was reading it, etc. etc. - a cool concept but the original idea the
author wanted to impart would likely get lost within minutes!

Being a software engineer in the day, I'm a touch of a control
freak... ;-)

..ed..

On Nov 27, 9:16 pm, Gene Wirchenko <ge...@ocis.net> wrote:

S. John Ross

unread,
Nov 28, 2008, 11:33:29 AM11/28/08
to
> But certainly I think it would be a mistake to hobble the ability of
> the user to adjust the display to their preferences.

And it would be, in simple terms, a step decades backward. Right now,
thanks to spiffy Blorb file thingies, I can play Zork Zero in the
typeface of my choice (Souvenir, as it happens), because I'm running
Zork Zero in an interpreter. Back in Ye Dustye Olden Tymes, Zork Zero
enforced a specific font on me due to the limitations of the machines
it was running on, and due to the nature (then) of standalone
software. I can re-create the old look if I like, or not. And if Joe
hates Souvenir or finds it hard to read, he can do it in Futura. And
if Amy hates Futura she can do it in Bookman Old Style.

Inflexible presentation is a relic of standalone applications, and
even _those_ have been rapidly shedding the limitation, with more and
more applications being skinnable by the user. So, I'm all in favor of
21st century interpreters, but (judging by the 21st century I'm
familiar with, anyway) a 21st century interpreter would offer the user
more choices, not less.

Game designers having the power to provide graphic embellishments is
groovy; more power to those who'd enjoy using that (I probably would,
if I had it) ... but only if the player at the other end of the line
has the power to say "no" to some or all of the offered frippery.

Woolyloach

unread,
Nov 28, 2008, 11:38:34 AM11/28/08
to

Somewhere in all this is a happy medium between crushing the players
ability to customize his experience to make it better for himself, and
the ability to completely trash the story by removing key presentation
states that impart additional information vital to the storyline.

I suspect that line moves depending on the story, the author, and the
player! Likely another case of "you can't make everyone happy at the
same time". :-/

ChicagoDave

unread,
Nov 28, 2008, 11:43:46 AM11/28/08
to
On Nov 28, 5:48 am, Jeffrey McArthur <jeffmcart...@comcast.net> wrote:
> I would suggest a slight modification:
>
> DisplayText(text);
> DisplayText(nameOfWindow, text);
>
> By default, you would want the text to go to the main window. Only in those
> cases where the author wants to override the default would they have to
> specify the actual window.

This is not much different than the Channel IO system except you've
gone back to the technical abstraction called a "window" and Channel
IO focuses on the function of the text. I know this is a fine
distinction, but it's important to me because I could have many types
of data that have multiple uses. So something may by default go to the
main window, but it may also go to other windows. The question of
which window the text goes to should be left to the user interface and
not decided by the game author. The game author is simply identifying
artifacts, sorting them out, and then presenting them to the UI. The
UI takes all of the artifacts and determines their use.

The interfaces I was describing (high/low) were trying to explain to
Jim that you can accomplish the same thing in two different types of
API's. One where the API has an explicit functional definition and one
where there is no definition at all, but in both cases there is no
technical usage information within the API.

Of course one might argue that when the API crosses the functional to
technical barrier, we're heading to a true low-level API, but now we
have to distinguish levels differently. In the prior case, high and
low are within the boundaries of functional information. Compared to a
technical API (which says how the data used), they are both high level
interfaces. Compared to each other though, one is high and one is low.
The technical API could also have high/low distinctions. DirectX is a
high level API because it allows the programmer access to graphics in
a standard that doesn't care about the hardware itself. DirectX
however, talks to the video cards themselves which happens through the
API of the video card manufacturer, which is in this case, the lowest
level. Well, then we get into hardware API's and that's an entirely
different matter. If you move to the hardware, now you're talking
about programming chips and your API is the schematic of the board
itself.

The concept of an API is simply a barrier between two things. What
those two things are and how the API implements communication from one
to the other is up in the air. A good API is one that can grow and
expand without damaging its original uses. The easiest way to have an
API that's always backwards compatible is to make it as abstract as
possible, but where the data is concerned, have a strong and well-
known contract.

Channel IO is actually not an API. It is a contract. The VM and UI are
agreeing on a set of types of data to be transmitted. The API is
simply:

output Text;

David C.

Jon Ingold

unread,
Nov 28, 2008, 11:54:04 AM11/28/08
to

> But, no, I'm fine with teletype.  I prefer it, in fact.

I'm not much into graphics, but I really, really want to be able to
get rid of useless text on the main screen. I want an interpreter
which removes failed commands from the output after the player has
typed something successful, so that the output is one long stream of /
meaningful/ input - to take away the temptation to argue with the
parser (while still allowing it), to prevent useless information
disappearing, to stop immersion-breaking need for scrollback.

I also want to be able to format text after the fact, because keeping
track of quote marks is difficult until afterwards (another nod to T3
with its text-processor: Ron Newcomb has an extension for this but
it's brutally slow).

I want an interpreter that closes up paragraph breaks except when I
tell it to -- so I don't want it to do that itself, *I* want to be
able to do it, in code, and turn it off when I should turn it off.

I want to make a command line in a separate window (possible),
alongside a conversation menu (possible), and be able to switch
windows with the UP/DOWN cursor keys, or with the TAB button
(impossible).

jon


S. John Ross

unread,
Nov 28, 2008, 11:58:33 AM11/28/08
to

> Somewhere in all this is a happy medium between crushing the players
> ability to customize his experience to make it better for himself, and
> the ability to completely trash the story by removing key presentation
> states that impart additional information vital to the storyline.

I agree, hence my confusion about why there has to be an "author's
side" and "player's side" in some imaginary conflict. Both sides, in
an ideal fluffy-bunny uinverse where software development falls like
spring rain and full-featured apps sprout like mushrooms, would be
given more power (the author more power to create as he pleases; the
player more power to play as he pleases).

When the graphics actually matter, just let folks know and be honest
about it. Consider, as a simple example, Photopia, where color is a
part of the game that the author considers important, and the game
simply says so, right up front, when offering the choice of color or
no-color.

> I suspect that line moves depending on the story, the author, and the
> player!  

Absolutely. Exactly.

> Likely another case of "you can't make everyone happy at the
> same time". :-/

And with sufficient customization, you never need to ... people can
choose their own happy and nobody needs to second-guess it.

Jim Aikin

unread,
Nov 28, 2008, 12:05:05 PM11/28/08