So, getting to my point, I've been trying to develop a few alternative
user interfaces for interactive fiction. But I'm one guy with my own
(often atypical) set of things I like and dislike. Here comes the
Set your imagination to work. Come up with a conceptual sketch -- a
fake screenshot if you like, of a user interface for a game that's a
little more radical.
To get an idea of the range of possiblities I'm considering, have a
look at such games as City of Secrets, Narcolepsy, the Glulx port of
Moments out of Time (Renegade Version:
pie-in-the-sky ideal would be an interface where the same layout could
(with minor tweaking) be used in a variety of games, using
interchangable sets of artwork.
My goal here is to take your concepts and translate them into GWindows
source for public release (so if you wouldn't like that, well, there'd
not be much point in participating.).
So, what does your imagination have in it?
Sure enough, I'm in love with the minimalist status line. Personally to
me, it doesn't seem like a good idea to turn the interface into a
"point and click" thing entirely, but here, the claim about "my own
(often atypical) set of things I like and dislike" is applicable, as
well. However, I've got a general suggestion: it wouldn't do any harm
if this interface could be customized by the player (in particular, any
and all parts of it could be switched on/off, colours, sizes and fonts
could be adjusted, the user could switch back and forth between icons
and plain text descriptions of the objects in her inventory, etc.).
Sorry if this wasn't particularly helpful - I realize those are very
generalized things I'm speaking about, and an experienced programmer
like yourself probably considered them anyway.
The reason I mention this is because (like many others) I sometimes suffer
from hand ailments due to over-use of the mouse. Typing is less damaging,
for reasons I won't bore you with.
Also, having to reach back and forth between the mouse and the keyboard
takes extra time. It's intrusive.
I second this.
On the other hand, I did get some positive feedback on the compass
display in City of Secrets, which both showed what exits were available
and let the player click to move if he wanted (without overriding the
main movement controls at all). This is one element I could see being
turned into a module with interchangeable artwork.
I'm going to go out on a limb here and admit that I really liked the
Scott Adams style split-screen display. It seemed logical somehow to
always have the room description displayed and automatically updated.
It's almost interesting to me that this didn't go without saying.
Somehow, when someone says "You're going to be able to click on
things", everyone hears "You're going to have to click on things". If
you take a look at Moments out of Time, Balances, or City of Secrets
(I think), you'll find that you can click on things, but you don't
have to -- in fact, in GWindows, it's actually a lot *harder* to write
things that can only be clicked on (Because the interface and the
world model are so orthagonal, that the easiest way to communicate
between the two is by shoving something into the command line --
though I do tell a slight lie; in Moments, you have to click conversation
menus unless you've got the graphical interface turned off, but these
But it worries me that this notion may be poisoning the dialogue; are
people reluctant to experiment with new UIs *because* they fear that
if you *can* click, you *must* click? Of those of you dedicated to
the traditional UI, how would your objections differ if it was really
assured that clicking would be purely optional?
(And for the record, I'm one of those folks who finds the clickable
compass incredibly handy)
fit the bill here, if only as a way of adding new stuff but keeping all
of the old?
I never played any of the Scott Adams games, but I could see this being
useful. Particularly when I'm hopelessly stuck I find myself looking
and taking inventory every few moves to see if I've missed something
(or scrolling back if I think I have some time limit), so it might be
nice to have this information easily available in certain games.
Sorry if I didn't express myself clear enough. My point wasn't "You
shouldn't disallow traditional text input in your interface" (this
REALLY goes without saying) - I just meant the interface elements
should be switchable and customizable.
What I meant was this: I took a look at the interface for Balances and
found it somewhat confusing, because all the "secondary" (from my point
of view) interface elements were so huge they overshadowed the fulcrum
of any text adventure - the text input/output window. I'd rather have
them smaller, and some of the less frequently used (like the button for
VERBOSE mode, which really is employed one time for a game session at
best in most cases) I'd be glad to be able to switch off.
Now, I think there would be as many different or even opposite opinions
about that. The same goes for fonts, colours, etc. etc. Therefore, I
don't think you can make a really universal interface (which you strive
for, as far as I understand your original post) without making it fully
I'm reluctant to experiment mostly because I have a hard time thinking
of interesting UI additions that would improve matters. You have to
have a game with *just* the right size of inventory for a graphical
representation to be any help at all: too few and it's pointless, too
many and you can't fit it all in. And even then, I don't know that I
wouldn't prefer a list.
I also have mixed feelings about a standard graphical window that
always displays an image of the current location. Usually that image
doesn't reflect changes to the game world; it's also hard to get
consistent imagery. There are a handful of recent games that I think
have made this work -- Necrotic Drift to an extent (but it's a game
whose atmosphere is best served by a certain grunginess, so the
occasional flaw in the photographs is fine) and Ekphrasis come to mind.
Ekphrasis splits the screen left and right, incidentally, which I like
better than the classic top/bottom split because it means that the text
area of the screen is a nicer shape on a modern computer. But still.
Mixed feelings about this.
There are various single cases (Narcolepsy, Lock and Key, Words of
Power) where there was something genuinely worth displaying with an
unusual UI. I can imagine other possible twists: for instance, a game
where the player's appearance/equipment matters a lot, so we always
have a little paper-doll self in the corner showing what we're
wearing/wielding; a game where your interlocutor's face is visible with
changing expressions (Shattertown Sky has given this idea a bad rep,
but I think if handled more deftly it could actually work, maybe even
Still, mostly what I imagine is interesting ways to *display*
information, rather than new ways to let the player interact with it. I
might particularly like a pretty frame that suits the particular game
I'm playing, and maybe, if appropriate, a few custom widgets
representing what might otherwise go in the status line: the compass
rose, a small map of my immediate area, a turn counter, a clock. My
mental image at the moment: a steam-punkish sort of frame with, in one
corner, a slightly rusty compass, and, in another, a grungy analog
clock slowly advancing.
I wouldn't have wanted this a few years ago, I think, but I now usually
play IF on a computer screen considerably bigger than my ideal text
window, so I wouldn't mind (and would indeed positively welcome) a
frame that dominated the screen but left plenty of margin space around
the text itself.
But I'm equally sure that there are people who would find this
cluttering and distracting and would prefer the simple elegant look of,
say, a Spatterlight text window.
> So, what does your imagination have in it?
'tis a pity it's not cross-platform.
www.intaligo.com Building, INFORM, Seasons (upcoming!)
You need two command lines, one for actions and the other for speech to NPCs
(or other players).
If you display objects, clicking on the objects should bring up a context
menu with the most commonly-used commands or things to say to the object.
Clicking on the room's 360 image should move in a new direction, or examine,
or whatever is appropriate, like Myst.
Which specifically did you mean? I recall that Beyond Zork had three
viewport system, one of which was a local piece of a map.
If televison's a babysitter, the Internet is a drunk librarian who
won't shut up.
-- Dorothy Gambrell (http://catandgirl.com)
I like the compass rose a lot -- as an on-screen option, not as a device
that must be used. Same with TADS 3's hyperlinks in the "you can go" error
message. It's nice if you like using the mouse, but can be ignored if you
I personally think the UI is hampered by the currently available
methods for developing alternate UI's.
A more open approach might be to have a basic interpreter written in a
friendlier language than C, like Java, VB.NET, or C#, and then develop
variations in code. The Z-Machine allows for extensions using your own
opcodes, so it's small leap to then completely redoing the UI to do
If this were available to the hackers in this community, different UI's
might pop up for every game. That would be cool.
This thread so far can be summarised as "reimplement the Magnetic
Windows interface by Magnetic Scrolls (Wonderland) in GWindows".
I'd second that because I love the interface, it is configurable
by the user, there is a point and click interface with a compass
rose, a graphics/animation window, graphical map, player inventory
and room inventory, all interactive and nicely connected and you can
switch all that off and do barebone typing (almost forgot the text
Well, I'm one of those atypical guys who likes what's
beautiful, whatever the medium (or media). I've seen
at least one parser-based game that would have worked
much better as a multiple choice adventure, and a MCA
that would have been better served by a parser. I still
have to finish Ekphrasis, and I positively love it. And
because I've been (briefly) involved in video game creation,
I know that designing a game to work equally well with
two different interfaces (say, first person point'n'click
and text-based with parser) is almost impossible. Those
would be two different games entirely.
My point is, one standard interface is not enough. Authors
should use whatever works best for their creation. The
major authoring systems are flexible enough to let one's
imagination run free, so why don't we do just that.
I would hope an interface paradigm shift would do away with compass
roses completely, unless the game is specifically about orienteering..
I know you have your reasons for wanting to go this way, but, frankly,
your point of view reflects that you haven't actually looked all that
hard at what's available.
I am fully aware of what you can do with the current tools. None of it
comes close to what I envision.
> It's almost interesting to me that this didn't go without saying.
> Somehow, when someone says "You're going to be able to click on
> things", everyone hears "You're going to have to click on things".
Yes. This is because in a large number of cases today, GUI interfaces
do just that - they fail to make sure that all their elements are not
just text-accessible, but equally easy and pleasant to use via
keyboard. This may not be the case for Glulx IF, but it certainly is
for a lot of Windows software (for example, a recent version of
Symantec Antivirus had a console where dumping a log - something you'd
think would be a fairly common, scriptable action - was only possible
by navigating a tree widget and clicking on a graphical toolbar icon).
It is also even the case for OSX in its default settings, unless you
have swotted up on a lot of cryptic undocumented command-key
So it is natural that someone who likes using the keyboard, who hears
that a GUI will be implemented, will have as their first instinct to
flinch and prepare for the worst.
This sounds sweet. But as you point out, it's about information output, not
User input is always going to be either point-and-click or type commands,
isn't it? I mean, voice recognition technology is available, but it's pretty
much going to map either to text or to point-and-click hotspots.
Here's the thing, though: My abilities as a graphic artist are close to
nonexistent. To have a UI with "a slightly rusty compass" in it, I'd have to
hire a graphic artist to create the image. Or try to scrounge some pathetic
clip art, I suppose.
However, I'm an accomplished composer, with a powerful recording/synthesis
environment on the same computer as my IF stuff. I don't believe anybody in
this thread has yet mentioned sound output.
This concerns me because I'm hoping to include underscore for some of the
scenes in my next game. I'm planning to use TADS 3 for various reasons, and
it has sound output, complete with mp3 playback, which is good because it
will keep the file size manageable.
But: TADS won't do fadeouts. (I emailed Mike Roberts about this last week. I
guess he's busy with other things that have higher priorities. Can't say I
The result is, when the player leaves a location that has underscore, the
music will either shut off in an abrupt, unnatural, intrusive way rather
than gently fading to silence, or continue playing blithely even though it's
no longer appropriate for the new location/scene/mood. Either way -- ugh.
So if we're going to discuss interface enhancements, I guess I'd like to put
in a good word for audio output enhancements.
i believe the legend entertainment guis they developed for the pc text
adventures Gateway, Gateway 2, Timequest, Eric the Unready etc are
still the state-of-the-art to satisfy everybody (graphics and mouse
lovers, text maniacs).
every element on that screen can be removed just leaving the standard
text window and nothing else. at the opposite end, you can play pretty
much the whole game just by clicking on the verb and noun lists, and
even by clicking on objects in the graphical display.
> On Fri, 15 Dec 2006 17:01:43 GMT, Jim Aikin <rai...@musicwords.net> wrote:
> >Good question. My numbah one request would be, don't force the user to point
> >and click! Typing should always be available as an input method.
> >The reason I mention this is because (like many others) I sometimes suffer
> >from hand ailments due to over-use of the mouse. Typing is less damaging,
> >for reasons I won't bore you with.
> >Also, having to reach back and forth between the mouse and the keyboard
> >takes extra time. It's intrusive.
> It's almost interesting to me that this didn't go without saying.
> Somehow, when someone says "You're going to be able to click on
> things", everyone hears "You're going to have to click on things".
Painful experience, I fear. Not, perhaps, with IF, but in general, every
OS, every office suite, every program which introduced more options to
use the mouse has also either removed or hidden options to use the
keyboard. Keyboard shortcuts get removed, menus don't get designed for
easy keyboard access, shortcuts that do exist get hidden far away in the
back end of a helpfile, not in the index. One telling example, IMO, is
the way in which it's now the default in MS Windows for the underline
for alt-key shortcuts to be hidden.
I, for one, don't object to mouse control. I think it must be done
carefully, but I'm not against it. Over the last few years I have
protested against too many graphics in IF, though, and that's related to
this fear. One of the reasons I don't like them much is the suspicion
that IF authors will start to rely too much on hints hidden in the
graphics - that something which was once an optional extra pretty bit
will turn into an essential information-carrying part of the game.
Duh! They're designed for the common user, the one who doesn't want
to remember anything. The one who jumps in surprise when you press
Control-C Control-V in front of her. The one who backs away in terror
at the mere sight of a command line. Are you forgetting we're all geeks
around here? :-)
> Over the last few years I have
> protested against too many graphics in IF, though, and that's related to
> this fear. One of the reasons I don't like them much is the suspicion
> that IF authors will start to rely too much on hints hidden in the
> graphics - that something which was once an optional extra pretty bit
> will turn into an essential information-carrying part of the game.
I'm not so sure about the 'optional' part. Sometimes a picture is worth
a thousand words. Consider a puzzle based on constellation shapes.
How would you do it in text? Or would you dismiss the idea outright?
Trying not to be an island,
Tangent: I usually get stock art and photography from istockphoto.com;
some of it's really quite good, and for IF-related purposes you usually
don't need anything larger than the smallest size, for $1 an image.
Making a pretty UI out of such elements would probably still require
some graphic artistry with photoshop or illustrator, though. I see your
Hey, easy, there! I realize there are many people who can't play a game
with pictures because, well, they can't see. But you're overreacting. I
don't think anyone in this thread suggested making graphics mandatory
in IF. There are plenty of text-only games and there always will be.
All I want is a little diversity from time to time. Besides, we were
just talking. I fail to see how this is aggressive or offensive...
I don't think it's so much overreaction. I think this was more in response
to when you said: "I'm not so sure about the 'optional' part. Sometimes a
picture is worth a thousand words."
When you're not sure about the "optional" part that means a suggestion for
making them mandatory.
Where the confusion maybe stems is that you're referring to a *specific
game* that may utilize graphics as a non-optional aspect while the thread as
a whole is referring to the ability of a system to accomodate graphics (but
not making them mandatory for any given game).
I think the happy compromise is that if a game utilizes graphics *and* those
graphics are a fundamental part of the gameplay (meaning you must view them
to be able to solve the game), that simply needs to be made clear by the
game as soon as possible -- i.e., right at the start or in the accompanying
documentation. That way someone who dislikes such games (or who cannot see
them due to blindness or other sight impairments) will know to avoid that
Beyond that, however, you're talking about a specific puzzle in a game that
requires a graphic. The thread as a whole is about a graphical user
interface that supports the game (regardless of whether the game has
graphics or not). That interface itself is another concern for
> However, I'm an accomplished composer, with a powerful recording/synthesis
> environment on the same computer as my IF stuff. I don't believe anybody in
> this thread has yet mentioned sound output.
> This concerns me because I'm hoping to include underscore for some of the
> scenes in my next game. I'm planning to use TADS 3 for various reasons, and
> it has sound output, complete with mp3 playback, which is good because it
> will keep the file size manageable.
> But: TADS won't do fadeouts. (I emailed Mike Roberts about this last week. I
> guess he's busy with other things that have higher priorities. Can't say I
> blame him.)
> The result is, when the player leaves a location that has underscore, the
> music will either shut off in an abrupt, unnatural, intrusive way rather
> than gently fading to silence, or continue playing blithely even though it's
> no longer appropriate for the new location/scene/mood. Either way -- ugh.
Since you are an accomplished composer, maybe you can do something
close to what LucasArts did with their iMuse system ?
Meaning that you have a music loop in room 1, and when exiting room 2
to go to room 2, you stop sounds and play a special transition sound of
3-4 secondes that ends with a fade out ?
When I added short sounds sequence in my game, I "forced" the fade out
in the mp3 itself.
I would be very interressed in any progress about this.
"Jeff Nyman" <jeffnyman_nospam@nospam_gmail.com> wrote in message
Well, I think the key word here is "sometimes". When a picture can be
made optional, by all means, it should be. But who can decide what
"optional" means in the context of a particular game? I think it's the
author - and so we come to the compromise you suggest. Which, by
the way, I consider more than fair enough. But there has to be a
> Beyond that, however, you're talking about a specific puzzle in a game that
> requires a graphic. The thread as a whole is about a graphical user
> interface that supports the game (regardless of whether the game has
> graphics or not). That interface itself is another concern for
> vision-impaired users.
Then the two issues are related, and I wasn't too much off-topic, if at
I ran into a similar problem with Moments out of Time (2). I had
wanted the background music to cross-fade when moving between
areas. While that's technically legal, I found that actually trying to
do it caused most of the common interpreters to explode in a
moderately unpredictable way. I settled for a simple fade-out and
fade-in, which, thankfully, you can do in Glulx.
For the project I'm working on now, I've got a notion of composing the
background music on the fly, as it were, by stitching together
separate musical elements based on the state of play. Inthis, though,
I think the technological support is going to be the least of my
But at any rate, the reason I didn't speak much to audio output is
that there's not much I can do on this front. If someone says, "Gee,
I'd think it was neat if there was a Legend Entertainment-like user
interface", I can just bugger off and write one (Actually, I *did*
about five years ago, it's part of the GWindows demo kit); there's not
much I can actually write that will produce new paradigms for using
audio in IF (Beyond the API I've already written)
> Then the two issues are related, and I wasn't too much off-topic, if at
I just want to make sure that people who do post a dissenting or cautionary
viewpoint are not considered to be "overreacting" necessarily. That's all I
was speaking to.
Personally, speaking to this thread as a whole, the simple inclusion of
graphics in a game seems to be beside the point in one sense because you can
do that *now* with most systems. (Interpreter support is another matter.)
The key point here seems to be how those graphics are presented in terms of
these alternative UI interfaces that Ross is looking into.
I'm very interested to see what comes of this because, like you, I agree
about the option for diversity in terms of interface formats, as long as the
diversity is ... you know, optional.
Sounds are also a good suggestion. While sometimes they can be cool and
bring another demention of reality to the player, in some other games,
on the other hand, they can be poor or even bring down the quality of
the game. (Like in GNA, as you can see in all reviews). However, I
think if sounds are going to be added, putting a toggle would be
And about the graphics, I also am a blind user and know how it feels if
the puzzles in the games were graphic-based. First of all, reading
something as a text is completely different than seeing it in a
picture; One might call a plant "rose" while other might call it a "red
plant" and so on. Other than that, the programmer cannot release 2
versions of the same thing (with and without graphic) so that would be
a huge work without a real result. On the other hand, I guess using
images and pictures just to give a bit of reality to the user (like
having a picture of a place as it is described in the description)
would be good for the sighted, and blinds can easily move the files
which store the pictures in themselves away to another folder and have
fun with it.
Here's my issue with that: Loops suck.
My music is not loop-based. Even if it were, I would have different elements
starting and stopping every two bars, so the aggregate texture would never
loop. It would move forward in a composed manner. Music that fails to move
forward in a composed manner bores the snot out of me, and I would never
torture a listener with such tripe.
There's no way to program a fadeout into a composed mp3, because you have no
idea how long the player is going to remain in a given environment. Could be
five seconds, could be five minutes. Or anywhere in between. So where do you
put the fadeout?
There are good examples of looping music. Unless we don't speak of the
same thing, it's only recently (Half Life 2 being the only example
coming to my mind) that music actually doesn't loop. Any
lucasarts-sierra adventure had a looping music for each screen, even if
sometimes the loop was several minutes long.
I was thinking something like :
but a lot more amateurish, since
a) player enters room 1. Music 1 starts playing, with a fadein effect
embedded in the mp3.
b) player exits room 1. Music 1 stops. Music 2 starts playing : it's a
2-3 seconds long theme which is a transition between Music 1 and Music
3 that ends with a fadeout. Music 3 starts playing with a fadein
If a loop is several minutes long, it doesn't solve the problem I'm trying
to solve. The problem is, how do you make a pleasant, non-intrusive
transition when the player leaves a room where there's music?
The method that was proposed, looping one bit until the player leaves and
then cuing up another bit that has a fadeout recorded into it, only works if
the loop is less than five seconds in length, because if the loop keeps
going any longer than that, it's out of place.
This method also relies on the ability of the playback system to make a
glitch-free transition between the loop and the tag. I would be VERY
surprised if any of the existing IF engines have single-sample audio timing
resolution, which is what would be required. LucasArts can do it, no
question. Inform and TADS authors cannot.
All too often we think of text against graphics, and don't consider so
much the ways that text itself can be alternatively framed. The form of
text-only IF is not as simple and obvious as it looks.
I'd just like to share one experience. I've recently created an odd
command line, which sits at the bottom of the screen, subtley separated
from the output.
This would seem a very minor change, but it has major aesthetic
effects. It makes disambiguation questions look particularly different,
and wonders whether the player's command should be echoed into the main
output text at the top.
But more generally there's a really different "feel." The conventional
command line makes the game feel sort of like a direct terminal. A
separated command line makes the text interface seem like a layer, a
more "intentioned" interface. I think it allows significantly different
narrative and characterization.
I'm sure there will be much more interesting things said about this
stuff, and I'm just starting to figure this out myself. I just wanted
to mention that a little thing like the position of the inputline, and
the relation and separation of input and output, all have significant
aesthetic impact. There may yet be some "play" within the bounds of
Speaking of which, it's funny that hyperlinks aren't used more in TADS
games. They could be used, for example, to build verb and noun menus.
Or the room description could appear in its own window and have links
on all nouns, with the command "examine [whatever]". It would remove
the tedium from x-ing the tall yellow carved-stone door and the narrow
chromed metal column and the carvings on each, if you see what I mean.
I'm referring specifically to TADS 3 because AFAIK it makes it
particularly easy to insert links and define windows and these
degrade gracefully to boot.
I show modern IF to new players (read: young kids) and the first
reaction is "I'd hate to do all that reading and typing".
Now while the laziness to read or type is something I'd like to do away
with, I know it's enough to make many people NEVER touch IF.
If there was an interface where movement could be done via clicks and
even some actions, and only more complex actions actually required
commands, then maybe we could create a bridge that would make people
more open to classic IF styles.
The status line isn't for looks, it's a basic function. I think you
should try to add more functionality and see that that looks like
before too radical a change would work.
Good points. Note that this would not get around the reading issue,
necessarily. The typing might be mitigated by the click interface, but not
What about an interface that supports voice input and output as well?
I know the emphasis here is on graphical user interfaces but it seems to be
that a voice user interface is just as much a valid paradigm as a graphical
one, particularly if people don't want to read (but might want to be read
to) and don't want to type (but might want to speak).
I could see a form of interactive fiction that was sort of like an
interactive audio book, as an example of what I'm sort of talking about
(An issue with this -- and an important one -- would be accessibility for
those that are impaired in their hearing, so clearly a sound interface of
this sort would have to be optional.)
On Dec 19, 2:21 pm, "Jeff Nyman" <jeffnyman_nospam@nospam_gmail.com>
> What about an interface that supports voice input and output as well?
To my mind voice input and output is just the same as text. Except
that text is feasible today, voice probably not quite. But soon.
_sound_ output, not just voice, however... is potentially very
interesting. No need to mention the distant waterfall or nearby birds
if you can hear them.
I agree: voice input and output is the same as text: it's just spoken. As
far as how feasible, that's where I think a bigger effort would come in.
Clearly there are good speech API's out there. That said, how effectively
they can be utilized is another question particularly since they require
ancillary technology (either microphones -- for input -- or speakers -- for
> _sound_ output, not just voice, however... is potentially very
> interesting. No need to mention the distant waterfall or nearby birds
> if you can hear them.
Well, again -- accessibility. If you have someone hearing impaired or
someone playing on a system without sound (or someone who just wants sound
off), you have to provide descriptions of the waterfall or the birds. That's
the problem with media in a text realm: if it starts to get used as the
*sole* means of conveying information, that can become problematic. In a
graphic game that's not such a problem because the expectation is that if
you're playing a graphic adventure, you can probably see and hear it (and,
further, *want* to see and hear it). Text games are, by definition,
predicated upon text and the expectations are not necessarily there for a
graphic and sound requirement.
As far as sound output, you can do that now with most systems, in terms of
including background sounds. Glulx, TADS and Hugo all seem to support
various sound abilities. Voice text could potentially be interesting in that
you could vary who is speaking, as some audio books do. Each character could
be given some personality.
For example, in graphic adventure games (like "The Longest Journey" and
"Broken Sword", etc.) a lot of the emphasis on spoken text is to give the
characters individual voices but also to keep people from having to read so
much. (To be sure, in those games you can usually turn off speech output.)
There are a lot of implementation hurdles to this, I agree, but it might be
something worth looking into when discussing user interface paradigm
I'm so torn about this one change. On the one hand, it simplifies the
main output window tremendously. On the other hand it can (doesn't have
to) detract from the interactive experience.
The one thing I like about having the commands in the output window is
when you scroll through your transcript, you can see what you've typed
before. It's possible this is a preference I personally maintain from
my days using paper terminals in the early eighties, but I think it's
more that I like to see what I've already tried.
I think in any forward-thinking UI, we should allow this to be an
option. Allow the UI user to set an option that says input line is
embedded in output window or as Steve has experimented, having the
command line entirely separate.
I can see either of these options being used for different effective
reasons and I can see how different people would appreciate either or
Every time the player reaches a hyperlink it's as though a big klaxon
sounds (a-HOO-gaa!! Significant Word!!) and this completely disrupts the
carefully crafted emphases that paragraphing and word positioning impart.
I'd be all for hyperlinks if they only became visible when, say, the
player held down the SHIFT key. (I realise this is probably infeasible.)
Conversely, when I have shown IF to 3rd graders at my eldest daughters
school, they have all thought it was the greatest thing in the world.
Even the Xbox boys. Of course this depends on the school. Our school
forces kids to start writing stories in first grade on a daily basis,
focusing on content and penmanship. By the time they reach third grade,
they are relatively experienced readers and writers.
Add to this that every classroom in our school as two computers, they
have a computer lab with 40 PC's, and the library also has half a dozen
PC's, the kids all are very familiar with typing. My eight year old
already touch types (slowly).
Depends on the environment, but kids will gravitate to anything
artistic if they are given a real chance to understand its value.
The command text is echoed to the output screen, doofus. (As I
If you're interested in this sort of thing, it's probably worth having
a look at "My Angel", which can be played either in Novel Mode (with a
separate command line window) or in a more traditional format. It's
been a while since I played with it, but as I recall it does some
inventive things with translating the player's commands into
interesting in-game narration.
I quote you:
Breslin said, "This would seem a very minor change, but it has major
effects. It makes disambiguation questions look particularly different,
and wonders whether the player's command should be echoed into the main
output text at the top."
This seems to suggest that echoing the command in the output window is
questionable. You are not stating that is still should be done.
I was only pointing out that I'm not sure if I personally like that
paradigm. And Emily points out in her reply about a game that rewrites
the command entirely into a more narrative style. This too is an
I'm saying I'm not sure if I like it or not. But I might. I guess it's
an option that we haven't explored a great deal.
Altering the UI has always been taboo, but mostly for reasons that have
nothing to do with art. It's usually been because of standards and
about mimicing older (trraditional) styles.
I think we can open the entire discussion up and say if we were to toss
out the entire standard and visual expectation, what would we come up
It's a very interesting question.
I'll second that! The first games I ever played were Scott's. When I
moved on to Adventure and Zork, I was a little frustrated and lost at
first without the guidance provided by the upper half of the screen
(hey, I was 8!).
At the time I quite liked the Scott Adams split screen display as well.
I think it was very suited to the often very small displays of the
time. The Spectrum was 32x24, the VIC-20 was 22x23 (apparently). I
remember playing Pirate Adventure on a VIC-20.
For those that haven't seen this, the top portion of the display is
permanently giving over to display the location description (locations
didn't have names and descriptions, just descriptions), the available
(obvious) exits, and the objects (obviously) in the room. It expanded
if needed (for rooms containing many objects). In Pirate, which I
happen to have extensively played recently, "I'm outside an open window
on the ledge of a very tall building" is about as long as the location
Having used (a kind of emulated version of) it recently, there are two
reasons why this style would tend not to work so well these days. The
first is the length of the location description. Scott Adams games
were very terse. I'm convinced in fact that the games were designed
around the interface, and the interface designed around the common
capabilities of the machines of the era. It could definitely work with
longer room descriptions, but probably not with an already published
work. I think text would need editing to be a more consistent length
for each location. Also the very common habit of giving a location an
initial description different from its subsequent description would
need to be managed very carefully. The second reason is that our
typical displays are much bigger. It's a long way for the eye to
travel from the point where we're typing (at the bottom) to the point
where the description is (at the top). When I was playing Pirate I
made my window much much shorter than usual to make this easier for me.
I had a similar problem using the compass rose in Carmen Devine:
Hasn't Adrift been doing this for some years already? For example (and
ignoring for a moment the terrifying color scheme used in this
Yup, that's what I had in mind. I initially thought more from zMud,
mIRC, and other online "chat" clients, but the Adrift screenshot shows
the same thing at work. Also, I really like Ingold's use of the same
basic idea, in "My Angel": not echoing the command text produces a
really striking and quite different effect. I hadn't seen that before
-- it's really good.
> I'd be all for hyperlinks if they only became visible when, say, the
> player held down the SHIFT key. (I realise this is probably infeasible.)
It would have to be implemented by the interpreter, but it is feasible
and sounds like a good idea. As long as it's optional, he he he.
How did you do it, if I may ask? I remember playing My Angel, being
struck by its interface, and noticing soon afterwards an email to the
newsgroups about how to do the same sort of thing in TADS 3. I seem to
remember that it was agreed there was no clean way of shifting the
command prompt into a banner. The neatest suggestion given in that
thread was creating a banner that took up 99% of the window, capturing
all game output and printing in this large banner. What did you come up
There are two choices for customizing the inputline's behavior. One is
to use the normal inputline but figure out some way to suppress any
unwanted built-in behavior (e.g., cover up the game window where it
automatically echoes input). The other is to use inputEvent, which is
much simpler and effectively much more customizable, but fails to
recognize OS-specific meta- or "accelerator" keys -- the keys assigned
to menu commands -- like [crtl]-v (paste), or whatever.
Either way probably works, if all we want to do is take the input line
out of the output stream.
But I went with the latter, because it's much more powerful and much
easier for the user to work with. One of my main goals was to separate
mouse-input from keyboard-input, so it can be handled differently if
that's what's wanted. Only an "event" based commandline can override
how mouse-events are interpreted. The occasion for the thing was to
enable authors (particularly Ken) to customize the game's
interpretation of special keys (such as arrow keys). Again, only an
"event" based commandline can override how specific keys are
Also, now that we can actually interpret commandline input while it's
happening, it's possible (in principle) to do a lot of neat things
during the input cycle: spelling/typo notification or correction,
auto-completion, sound effects (or visual effects, such as our blinking
cursor, which comes standard in this extension), and probably a few
other things that haven't yet been thought of. But this is all on the
level of technique, and says almost nothing of the fascinating
aesthetic questions raised by Ingold and other genre-stretchers on this
thread and elsewhere.
What you said was:
"It .... wonders whether the player's command should be echoed into the
output text at the top."
Even assuming this isn't a typo (I assume by "it" you mean the separate
command line, but I'm not sure how a command line "wonders" something),
it's not clear whether the command line is in fact echoed in the game
text, or whether the command line only wonders whether it should be.
The separated commandline *poses the question* whether the command
should be echoed to the screen. This question will be answered
differently by different authors, based on what they're trying to
achieve. I was thinking more of an Adrift setup, but something like
Ingold's "My Angel" is just as easy to achieve: the commandline's
behavior on this count can be switched by flipping a boolean.
When I look back at transcripts of games I've beta tested, the LOOK
command usually makes up a good quarter of all the commands I enter.
The Scott Adams display eliminates the need to keep typing LOOK, but
you still need to take inventory.
J. J. Guest