[Inform] Superbrief
Brian Uri!
Out of curiousity, how often is SUPERBRIEF ever used? Subtle
things might change in my room descriptions, and if people actually
use this, they might miss them.
Cheers,
BU
Andrew Plotkin
I removed the command in _Hunter_. Nobody complained.
> Subtle
> things might change in my room descriptions, and if people actually
> use this, they might miss them.
Anyone who uses superbrief (or even brief) accepts this.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Adam Cadre
> Out of curiousity, how often is SUPERBRIEF ever used?
Andrew Plotkin replied:
> I removed the command in _Hunter_. Nobody complained.
Not only has no one complained (or indeed even noticed) that
superbrief has been removed from my last three games (I think it's
three, anyway), but I've even taken to rigging games to start in
verbose mode, removing both superbrief *and* brief, and again, no
one's complained or even asked me about it.
-----
Adam Cadre, Sammamish, WA
http://adamcadre.ac
Brian Uri!
wrote:
>Brian Uri wrote:
>> Out of curiousity, how often is SUPERBRIEF ever used?
>
>Andrew Plotkin replied:
>> I removed the command in _Hunter_. Nobody complained.
>
>verbose mode, removing both superbrief *and* brief, and again, no
>one's complained or even asked me about it.
Wow, that's actually what I was considering doing, but I wasn't sure
if there'd be an uproar. I'd never noticed it in your recent games at
all...it just seems so natural when it's done.
Cheers,
BU
Stephen Granade
> Brian Uri wrote:
> > Out of curiousity, how often is SUPERBRIEF ever used?
>
> Andrew Plotkin replied:
> > I removed the command in _Hunter_. Nobody complained.
>
> Not only has no one complained (or indeed even noticed) that
> superbrief has been removed from my last three games (I think it's
> three, anyway), but I've even taken to rigging games to start in
> verbose mode, removing both superbrief *and* brief, and again, no
> one's complained or even asked me about it.
As a third data point, the last three of my games default to verbose;
no one has said anything to me, either.
Stephen
--
Stephen Granade | Interested in adventure games?
sgra...@phy.duke.edu | Visit About.com's IF Page
Duke University, Physics Dept | http://interactfiction.about.com
Dan Schmidt
| Brian Uri wrote:
| > Out of curiousity, how often is SUPERBRIEF ever used?
|
| Andrew Plotkin replied:
| > I removed the command in _Hunter_. Nobody complained.
|
| Not only has no one complained (or indeed even noticed) that
| superbrief has been removed from my last three games (I think it's
| three, anyway), but I've even taken to rigging games to start in
| verbose mode, removing both superbrief *and* brief, and again, no
| one's complained or even asked me about it.
My upcoming game for Sycamora Tree starts in SUPERVERBOSE mode.
--
Dan Schmidt | http://www.dfan.org
jer...@mupwi.demon.co.uk
> As a third data point, the last three of my games default to verbose;
> no one has said anything to me, either.
Personally, I like the idea of having constant access to all the
available exits in the description without having to turn on Verbose
manually.
But that may just be my opinion.
Jeremy Silver
Sent via Deja.com http://www.deja.com/
Before you buy.
Daryl McCullough
>
>Howdy,
>
> Out of curiousity, how often is SUPERBRIEF ever used? Subtle
>things might change in my room descriptions, and if people actually
>use this, they might miss them.
I wonder how difficult it would be to implement a brief mode (I'm not
sure what the difference between brief and superbrief is) that only
gives the detailed description of a room in case that description has
changed since the last time it was given?
That would seem to have the advantages of brief mode without causing
the player to miss crucial information.
Daryl McCullough
CoGenTex, Inc.
Ithaca, NY
Andrew Plotkin
> In article <38c51845...@news.vt.edu>, bu...@SPAM.vt.edu says...
>
> sure what the difference between brief and superbrief is) that only
> gives the detailed description of a room in case that description has
> changed since the last time it was given?
You could do it, but it will always be a nuisance to maintain...
pretty much whenever you added code to a room that might change the
description, you'd have to write another piece of code to set a flag
under the same conditions.
Aquarius
> Daryl McCullough <da...@cogentex.com> wrote:
>> In article <38c51845...@news.vt.edu>, bu...@SPAM.vt.edu says...
>>
>> I wonder how difficult it would be to implement a brief mode (I'm not
>> sure what the difference between brief and superbrief is) that only
>> gives the detailed description of a room in case that description has
>> changed since the last time it was given?
>
> You could do it, but it will always be a nuisance to maintain...
> pretty much whenever you added code to a room that might change the
> description, you'd have to write another piece of code to set a flag
> under the same conditions.
Can you not trap the output routine to stash the displayed description of
a room in a variable somewhere, and then compare that with the new
"displayed" description of the room every time you go in? Of course, this
means holding a full copy of the description for every room in the game,
which is conceivably horribly inefficient :-)
Aquarius
--
Tact is just not saying true stuff
-- Cordelia, "Buffy the Vampire Slayer"
Plant Kingdom
wrote:
>Brian Uri wrote:
>> Out of curiousity, how often is SUPERBRIEF ever used?
>
>Andrew Plotkin replied:
>> I removed the command in _Hunter_. Nobody complained.
>
>Not only has no one complained (or indeed even noticed) that
>superbrief has been removed from my last three games (I think it's
>three, anyway), but I've even taken to rigging games to start in
>verbose mode, removing both superbrief *and* brief, and again, no
>one's complained or even asked me about it.
>
> -----
> Adam Cadre, Sammamish, WA
> http://adamcadre.ac
I loathe BRIEF mode. My opinion of SUPERBRIEF can be safely
extrapolated from that one datum. I could consider BRIEF marginally
justifiable if, say, the adventure is running on a very slow computer,
or if the author has the protagonist running endlessly from one side
of the map to the other.
Verbose is good. Adam, I approve strongly of VERBOSE as default. In
my opinion, it helps maintain mimesis.
An twist on this is an imperfect-knowledge game, such as Suspended,
where one must explictly request information about the environment
(and obtaining such information has a cost, at least of time).
Sb. Plant Kingdom
"You, Sir, talk like a Rosicrucian who will love nothing but a sylph, who
does not believe in a sylph, and who yet quarrels with the universe for
not containing a sylph."
--Thomas Love Peacock, _Nightmare Abbey_
Gareth Rees
> I wonder how difficult it would be to implement a mode that only gives
> the detailed description of a room in case that description has
> changed since the last time it was given?
Andrew Plotkin wrote:
> You could do it, but it will always be a nuisance to maintain...
Aquarius wrote:
> Can you not trap the output routine to stash the displayed description
> of a room in a variable somewhere, and then compare that with the new
> "displayed" description of the room every time you go in? Of course,
> this means holding a full copy of the description for every room in
> the game, which is conceivably horribly inefficient :-)
This won't work on the Z-machine, which has only 64kb of writable
memory, and it would be horrible to implement since you have to worry
about all the memory management for these variable-length strings.
However, what you could do instead is to store away for each room, not
the full text of the description, but a hash of the description. As
long as your hash is good at collision-avoiding, you can make the
possibility of a false negative (i.e., the description changes but the
new description hashes to the same value as the old) acceptably low. I
guess 32 bits would be plenty for this purpose; you wouldn't need to go
for a real cryptographic hash like MD5 or SHA.
I think that a good candidate algorithm would be a cyclic redundancy
check (CRC) with some appropriate polynomial. (This uses roughly one
shift and one xor per bit of message text, although it might be
expensive to emulate 32-bit operations using the Z-machine's 16-bit
integers. Probably not prohibitively expensive, though.)
(You would of course still have to worry about adding code to room
description routines that actually changed things in the game, since
descriptions would now need to be idempotent. But changing the state of
the game in description code is a bad idea anyway.)
--
Gareth Rees
Andrew Plotkin
>
> Aquarius wrote:
>> Can you not trap the output routine to stash the displayed description
>> of a room in a variable somewhere, and then compare that with the new
>> "displayed" description of the room every time you go in?
>
> memory, and it would be horrible to implement since you have to worry
> about all the memory management for these variable-length strings.
>
> However, what you could do instead is to store away for each room, not
> the full text of the description, but a hash of the description.
Is there a good way to do that? Divert text output in such a way that you
can compute a hash of the result? I can't think of any way.
Daniele A. Gewurz
> I wonder how difficult it would be to implement a mode that only gives
> the detailed description of a room in case that description has
> changed since the last time it was given?
I have no experience as an IF programmer, only as a player (I-reader?),
but wouldn't this, apart from its technical feasibility or difficulty,
make things a bit too easy for players? I mean, you have to _notice_
changes: if you are warned each time they occur, whether major ones or
not, isn't part of the point in let them happen lost?
Bye,
Daniele
Iain Merrick
Without wanting to start yet another language flamewar, I have to point
out that this would be pretty easy to do in TADS. You could capture the
room's sdesc property as a string, or install a hook to capture the
description as it's printed.
Is there any way of filtering output in Glulx (or Glk)? Maybe this would
be the best approach to solving this problem in Inform. I've found
output-filtering a _really_ useful feature in TADS.
--
Iain Merrick
i...@cs.york.ac.uk
Andrew Plotkin
> Andrew Plotkin wrote:
>
>> Gareth Rees <garet...@pobox.com> wrote:
>>
>> > However, what you could do instead is to store away for each room, not
>> > the full text of the description, but a hash of the description.
>>
>> Is there a good way to do that? Divert text output in such a way that you
>> can compute a hash of the result? I can't think of any way.
>
> Without wanting to start yet another language flamewar, I have to point
> out that this would be pretty easy to do in TADS.
Well, TADS has a VM that can allocate memory dynamically. There you go.
> Is there any way of filtering output in Glulx (or Glk)?
Not really. You *can* allocate memory in the VM, although some
interpreters won't provide it. You can divert text to a buffer reliably,
but it's a fixed-size buffer anyhow, so the Glulx memory allocation
is irrelevant.
(I.e.: you could get a hash of the first 1000 bytes of a room description,
or whatever. That might be sufficient. You can do the same thing in the
Z-machine, except the Z-machine has no guard against buffer overflow, so
you risk crashes if your room description runs long.)
I thought hard about true output filtering in Glk -- but it would require
interrupts or callbacks, which means dependence between the I/O and VM
systems. I *really* wanted to avoid that.
Iain Merrick
[...]
> I thought hard about true output filtering in Glk -- but it would require
> interrupts or callbacks, which means dependence between the I/O and VM
> systems. I *really* wanted to avoid that.
Yeah, I think that was a good decision. That would have been ugly.
Wouldn't it be possible to do output-filtering purely in Glulx, though?
I see there are 'streamchar', 'streamnum' and 'streamstr' opcodes, which
are basically shortcuts for the equivalent Glk calls. Couldn't the
strings produced by those opcodes be passed through some user function
before Glk gets to see them?
It'd be harder to filter the general Glk opcode, of course, but I don't
think that'd be necessary.
Or it could be done in Inform without touching Glulx at all. Just have
the built-in 'print' command call a veneer function rather than going
straight for an opcode. Or would that be a hideous performance hit?
--
Iain Merrick
i...@cs.york.ac.uk
Sean T Barrett
>Or it could be done in Inform without touching Glulx at all. Just have
>the built-in 'print' command call a veneer function rather than going
>straight for an opcode. Or would that be a hideous performance hit?
This is a good way to solve the problem in theory, and I guess it could be
done on the Z-machine too, but in both cases there's a bit of a nightmare
with having to decode compressed strings in the interpreted language. As
long as the veneer function doesn't do anything if it's not redirected, It
would only be a hideous performance hit if, say, somebody printed a lot of
empty strings or one-character strings. Per-*actually-printed-output-string*
overhead is affordable, since there can only be so many of those
per user input. Now, once you start redirecting them, so they're
no longer being output, and then you start writing Tads-style
verb verification routines that redirect output before running
them, then maybe you'd have to wonder if the performance overhead
was too great.
Of course, this would require altering Inform, which is probably
a significant barrier to most people who aren't Zarf (if not because
of the complexity of modifying Inform then for the difficulty of
getting Graham to answer mail about whether it's ok to alter Inform).
An entirely different approach to the room description problem
would be to stick to a programming style in which the code that
alters the room description looks at a known pool of variables;
e.g. restrict yourself to making the room description refer to
variables stored on the room object itself as opposed to in the
world at large. Then checking if the room description has
changed requires checking only those variables for changes,
although this could generate false positives if there are
visible changes dependent on multiple variables. Of course,
if you want to make something dependent on some non-local-to-the-room
state, it could get annoying to have to go make the remote object
update the room's variables in sync, which suggests a rather
baroque scheme in which each room description has a "cache my
state dependencies into this state vector (set of variables)"
function, which you run first, check to see if it's the same
as before, and if not, run the description (and in verbose or
on look you always have to call it before running the description).
Certainly the above solution is simpler, more predictable, less
buggy, and much less efficient, and when all is said and done,
it's probably the better approach.
SeanB
Aquarius
>>
>> Aquarius wrote:
>>> Can you not trap the output routine to stash the displayed description
>>> of a room in a variable somewhere, and then compare that with the new
>>> "displayed" description of the room every time you go in?
>>
>> This won't work on the Z-machine, which has only 64kb of writable
>> memory, and it would be horrible to implement since you have to worry
>> about all the memory management for these variable-length strings.
>>
>> the full text of the description, but a hash of the description.
>
> Is there a good way to do that? Divert text output in such a way that you
> can compute a hash of the result? I can't think of any way.
TADS has the outcapture() function, which does exactly that; captures
outputted text into a variable. I implicitly assume that anythng TADS can
do, Inform can do as well; obviously not :-)
Aquarius
--
Well *done*, Aquarius -- a phrase we love typing because it makes us feel
like the boss-character from a 1980s Glen A Larson action series...
NTK, http://www.ntk.net/index.cgi?back=archive99/now0618.txt&line=292#l
J. Robinson Wheeler
> Is there any way of filtering output in Glulx (or Glk)? Maybe this would
> be the best approach to solving this problem in Inform. I've found
> output-filtering a _really_ useful feature in TADS.
Really? What do you use it for? Also, if it's been so useful to
you, where are all your games? eh?
--
J. Robinson Wheeler http://raddial.com/
whe...@jump.net
Gareth Rees
> Is there a good way to do that? Divert text output in such a way that
> you can compute a hash of the result? I can't think of any way.
Switch the output stream to a buffer in memory, call the description
routine, switch the output stream back again. Then you have the output
as characters in memory, which can be hashed. (Obviously you have to
allocate a buffer big enough for the longest room description that you
will ever generate.)
--
Gareth Rees
Kevin Forchione
news:8a9c4i$6ls$1...@news.jump.net...
> Iain Merrick <i...@cs.york.ac.uk> wrote:
>
> > Is there any way of filtering output in Glulx (or Glk)? Maybe this would
> > be the best approach to solving this problem in Inform. I've found
> > output-filtering a _really_ useful feature in TADS.
>
> Really? What do you use it for? Also, if it's been so useful to
> you, where are all your games? eh?
Actually tmorph.t uses it for its 'text-morphing', allowing the author to
code the morphing syntax as part of the string, instead of making function
calls embedded within the string.
The output filtering can also be used for other text conversions. I've used
it in my library-in-development (alt.t) as a short-hand conversion for
various parts of the command elements embedded within a string, for example,
most TADS authors are familiar with this:
"%You% find nothing unexpected."
But the output filter can be used for more complex sentences, such as:
"%You% give the ball to _him_."
The _him_ in the string can then be translated into "him" or "her" or "it",
simply by capturing the output string via the output filter and doing the
conversion at that point. This is easier to read than:
"%You% give the ball to <<iobj.thedesc>>."
And would allow you to do things such as:
'He puts the ball in the box.' // result
"%You% put%s% _dobj_ in _iobj_" // shorthand
"%You% put%s% <<dobj.thedesc>> in <<iobj.thedesc>>."
or any other syntax arrangment that is easier for the author to read as
code. The biggest advantage to this kind of manipulation comes when doing
aggregation, such as:
>take coins
three gold coins and one silver coin taken.
which is what alt.t is all about. This kind of text manipulation can be
handled through the output filter, so that the aggregation string need only
look like:
"_Dobj_ taken."
The output filter simply needs to know what _Dobj_ represents. In this case
its a direct object list in which we don't want articles displayed, but we
do want prefix counts. Thus we take the aggregated direct object list and
pass it to a slightly modified listcont() function and viola.
But as for games... no, I've not had time. Too many little projects!
--Kevin
Iain Merrick
> Iain Merrick <i...@cs.york.ac.uk> wrote:
>
> > Is there any way of filtering output in Glulx (or Glk)? Maybe this would
> > be the best approach to solving this problem in Inform. I've found
> > output-filtering a _really_ useful feature in TADS.
>
> Really? What do you use it for?
Well, besides checking for changes in the room description, and the
obvious potential for easter eggs, it's essential for HTML-ising
quotation marks and so on. And if you want to allow the player to change
the formatting style on the fly, output filtering is easily the most
elegant way to do it.
> Also, if it's been so useful to
> you, where are all your games? eh?
Uh... I consider them all too good for general release at this time.
Sorry.
--
Iain Merrick
i...@cs.york.ac.uk
Stephen Granade
Ah, but I have used output filtering in my games (seeing as how I'm
the one who bothered Mike about adding it to TADS), specifically to
change standard quotes to HTMLized curly quotes. To see the difference
it makes, download the source to "Arrival" (which didn't use it) and
"Common Ground" (which did) and compare the two.
Andrew Plotkin
> Andrew Plotkin wrote:
> [...]
>> I thought hard about true output filtering in Glk -- but it would require
>> interrupts or callbacks, which means dependence between the I/O and VM
>> systems. I *really* wanted to avoid that.
>
> Yeah, I think that was a good decision. That would have been ugly.
>
> Wouldn't it be possible to do output-filtering purely in Glulx, though?
Good suggestion.
> I see there are 'streamchar', 'streamnum' and 'streamstr' opcodes, which
> are basically shortcuts for the equivalent Glk calls. Couldn't the
> strings produced by those opcodes be passed through some user function
> before Glk gets to see them?
Yeah. In fact, that effectively forms a complete separate output
system. (I always intended the output system in Glulx to be replaceable,
but I haven't thought about the mechanism, since Glk is the only option
now. But this isn't a bad reason to work out the details.)
> It'd be harder to filter the general Glk opcode, of course, but I don't
> think that'd be necessary.
I wouldn't want to get into that.
> Or it could be done in Inform without touching Glulx at all. Just have
> the built-in 'print' command call a veneer function rather than going
> straight for an opcode. Or would that be a hideous performance hit?
The performance hit comes in *decoding* Glulx strings in user code --
that's fairly ugly, and shouldn't be the right answer in any situation.
Daryl McCullough
>
>J. Robinson Wheeler wrote:
>
>> Iain Merrick <i...@cs.york.ac.uk> wrote:
>>
>> > Is there any way of filtering output in Glulx (or Glk)? Maybe this would
>> > be the best approach to solving this problem in Inform. I've found
>> > output-filtering a _really_ useful feature in TADS.
>>
>> Really? What do you use it for?
>
>Well, besides checking for changes in the room description, and the
What's an "easter egg"? I mean, other than colored eggs given to
children at Easter?
Brent VanFossen
<sgra...@login2.phy.duke.edu> wrote:
>> Brian Uri wrote:
>> > Out of curiousity, how often is SUPERBRIEF ever used?
>>
>> Andrew Plotkin replied:
>> > I removed the command in _Hunter_. Nobody complained.
>>
>> Not only has no one complained (or indeed even noticed) that
>> superbrief has been removed from my last three games (I think it's
>> three, anyway), but I've even taken to rigging games to start in
>> verbose mode, removing both superbrief *and* brief, and again, no
>> one's complained or even asked me about it.
>
>As a third data point, the last three of my games default to verbose;
>no one has said anything to me, either.
I got one complaint about "She's Got a Thing for a Spring" because it
only worked in verbose mode.
Brent VanFossen
Matthew T. Russotto
Daryl McCullough <da...@cogentex.com> wrote:
}In article <38c51845...@news.vt.edu>, bu...@SPAM.vt.edu says...
}>
}>
}> Out of curiousity, how often is SUPERBRIEF ever used? Subtle
}>things might change in my room descriptions, and if people actually
}>use this, they might miss them.
}
}gives the detailed description of a room in case that description has
}changed since the last time it was given?
Same as brief, only reset the visited attribute (or whatever its name
is) each time you change the description. Won't work if you're using
that attribute for other things (traps, etc) however.
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
John W. Kennedy
> What's an "easter egg"? I mean, other than colored eggs given to
> children at Easter?
A silly surprise hidden in a program if you do some strange particular
thing. Sometimes they are simply lists of all the programmers who
worked on the project. Sometimes they may be as extreme as an entire
videogame concealed within a word processor, which only turns up if you
hit Ctrl-Shift-Backspace or something.
In the text-adventure field, they are usually quite minor. Some Infocom
games, for example, had a second copyright statement carved in some
piece of scenery. "Spellbreaker" calls itself "Mage" approximately 1
out of a thousand times. (Dave Lebling wanted to call it "Mage", but
the marketing consultants said that no-one knew what a "mage" was. It
must have been a long struggle, because the trick was even in the beta.)
A sillier example, in a not-quite-text game, is the occasional
appearance of the Batmobile (with the 60's TV music) in "Kings Quest
II," zooming out of a "bat cave."
Called "Easter egg", of course, from the tradition of hiding said eggs
about the house for the kiddy-winks to find.
--
-John W. Kennedy
-rri...@ibm.net
Compact is becoming contract
Man only earns and pays. -- Charles Williams