[Inform] Extensions poll...
Jim Fisher
standardized library extensions. This won't be a set of extensions to
replace all extensions, you understand; rather, it will be something in the
spirit of menu.h, giving a little more credibility to the extensions by
virtue of endorsement.
At least that's the way I imagine it.
In trying to identify candidate extensions, we've reviewed a plethora of
pre-existing works, both old and new, using Emily's site and the official
Inform extensions page as guides. Progress, is being made, albeit slowly.
Having said that, since opinions differ as to which extensions warrant
inclusion and which do not, I thought it would worth while taking a poll to
see what developers in general would like to see included in such a
collection.
So here are the questions:
1) Which pre-existing extensions, assuming author approval, would you like
to see included in an official set of standardized extensions for Inform?
2) What types of extensions, which may not already exist, would you like to
see included as well?
Consider carefully, extra points will be awarded for useful answers.
--
--
Jim Fisher
Jim[AT]OnyxRing[DOT]Com
Peer Schaefer
Ad 1):
- "pname.h" is IMHO essential.
- Something to make standard to-way-doors a little nicer to program
would be nice (something like "easydoors.h" or the like)
Ad 2):
- Is there an extension that allows an object to be both a container
AND a supporter? (Like a box: you can put things in it AND you can put
things on it)
- It would be nice to have containers that take care of size and
weight (to prevent the player from putting a vacuum cleaner into a
purse). There is already an extension for that (recept.h), but it's by
me (sorry for advertising here) and it's IMHO not good enough (sorry
again). Some GOOD programmers out there ;-) ?
Peer
Jan Thorsby
> to see included in an official set of standardized extensions for Inform?
pname
> 2) What types of extensions, which may not already exist, would you like
to
> see included as well?
An easier way of deciding what happens first. So that you easily can make a
"before" happen before a "react before" or a "react before" happen before an
"order". And also a way of deciding which "react before" happens first.
Maybe one could put numbers on them, so that number 1 happens before number
2 etc.
Similar one should be able to decide what deamon, timer, each_turn happens
first.
An attribute that makes it so that you can see the long description of an
object when typing look, even when the object is on/in another object.
Maybe there could be a line first saying: "On the table you see:" followed
by the descriptions of all objects on the table. This should also happen if
the player is on the table. Useful when writing a game without the examine
command.
An easier way of deciding it what order the described items occur in the
room description. For instance say a room contains a lion. The lion will
never be in any other rooms. But at some point it will disappear from the
room. So I give it "describe", but the description of the lion is meant to
still feel as part of the room description, even if it isn't technically.
The problem comes if a player drops an item with "describe". The description
of the item will then come before the description of the lion. So maybe one
could put numbers on the descriptions, so that the game first describes
number 1 and then number 2 and so on.
Michael
> An easier way of deciding what happens first. So that you easily can make a
> "before" happen before a "react before" or a "react before" happen before an
> "order". And also a way of deciding which "react before" happens first.
> Maybe one could put numbers on them, so that number 1 happens before number
> 2 etc.
> Similar one should be able to decide what deamon, timer, each_turn happens
> first.
Seconded.
Michael
> to see included in an official set of standardized extensions for Inform?
>
- flags.h (or that rework that bypasses the multiplication (can't
remember name))
- compass.h
- debuglib.h
- info.h (Perhaps? Or at least some other conversation extention to
make them easier)
> 2) What types of extensions, which may not already exist, would you like to
> see included as well?
>
I already seconded the suggestion for a way to order the execution of
react_before's, etc. Beyond that... Maybe I'll think of something
later.
Michael
Andrew Plotkin
Let's distinguish between the question of "what extensions would you
like to see for Inform?" and "what *existing* extensions (or small
modifications thereof) would you like to see standardized and
supported?"
They're both valuable discussions. But the latter is going to happen
first. :)
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
Michael
> see included as well?
>
I think it would be good to include a help subroutine written for
complete newbies on how to play IF, something to warm them up to some
of the IF conventions, etc. There are already some good extentions by
Emily (NewbieGrammar.h, HelpRoutines.h), but maybe this needs to be a
collaborative effort, maybe some documentation pieced together from
some of the existing help guides out on the net.
It could be even more than a simle help command. Maybe "help" could
put them in a separate help menu system by default, but overidable, of
course.
Michael
Paul Jack
> see included as well?
An easy way to change the status line; the ability to change the
status line without knowing Z code. My WIP occurs in three acts, and
I want the status line to display the act as well as the score and
move count. It's driving me crazy figuring out how to do this, mostly
because there are several different versions of the
DrawStatusLineRoutine depending on which output you select (z5 vs z8
vs Glulx) -- which is also a problem because I don't know yet which
I'm going to use (I started with z5 but I'm fast approaching the 64K
code barrier).
I'm thinking of two routines that can be replaced, say:
DrawStatusLineLeft
DrawStatusLineRight
The Left routine would print the current location name, the right
routine would print score & moves, but the point is:
Replace DrawStatusLineRight;
! ...
[ DrawStatusLineRight ;
print "Act: ", act, " Score: ", score, " Moves: ", moves;
];
I'd like it to be that easy: Just print what you want to appear, and
the library extension would set up the output stream to use and figure
out where to position the text. Not sure if it's possible, an
alternative would be to replace the "print" statement with a "return"
statement that returns the string to display--of course, then I'd want
a standard string composition library to be included.
Actually including a standard way to manipulate strings would probably
be useful in and of itself. Also, is there a regular expression
library for Inform? Standardizing these things should lead to fairly
robust tools over time...
-Paul
Andrew Plotkin
> > 2) What types of extensions, which may not already exist, would you like to
> > see included as well?
>
> An easy way to change the status line; the ability to change the
> status line without knowing Z code. My WIP occurs in three acts, and
> I want the status line to display the act as well as the score and
> move count. It's driving me crazy figuring out how to do this, mostly
> because there are several different versions of the
> DrawStatusLineRoutine depending on which output you select (z5 vs z8
> vs Glulx) -- which is also a problem because I don't know yet which
> I'm going to use (I started with z5 but I'm fast approaching the 64K
> code barrier).
Actually, z5 and z8 handle the status line exactly the same. It was
different in z3, but Inform doesn't really support z3 any more.
If you're looking at the "#IfV5;" section of the library, be assured
that it applies to version 8 also. (But not V6.)
> I'm thinking of two routines that can be replaced, say:
>
> DrawStatusLineLeft
> DrawStatusLineRight
>
> The Left routine would print the current location name, the right
> routine would print score & moves
This is a nice idea. However, the library would want to pass the
current window-width in to each routine, so that it could squeeze the
text for narrow screens. (The current standard DrawStatusLine prints
"75/100" if there's no room for "Score: 75 Moves: 100".)
> Also, is there a regular expression library for Inform?
Unfortunately, this is hard given the limitations of Inform and the
Z-machine. (Not really any easier in Glulx, unless I add it as a
built-in VM capability.)
Greg Boettcher
"Jim Fisher" <Jim(At)OnyxRing(Dot)c...@nospam.com> wrote in message news:<dnNzc.50853$%T.35019@okepread05>...
> 1) Which pre-existing extensions, assuming author approval, would you like
> to see included in an official set of standardized extensions for Inform?
ExpertGrammar.h.
> 2) What types of extensions, which may not already exist, would you like to
> see included as well?
"Connect" and "disconnect" should be synonymous with "attach" and "detach."
Greg
Adam Thornton
Jan Thorsby <no_jthor...@broadpark.no> wrote:
>Similar one should be able to decide what deamon, timer, each_turn happens
>first.
FWIW, I get around this by having a master_daemon object, which in turn
fires off all the other daemons that may be running at any given time.
Yes, I have to handle the dispatch based on state I maintain, but it
gives me an easy way to control the order in which programmed events
happen.
Adam
Jayzee
> At Graham's request, some of us are looking into creating a set of
> standardized library extensions. This won't be a set of extensions to
> replace all extensions, you understand; rather, it will be something in the
> spirit of menu.h, giving a little more credibility to the extensions by
> virtue of endorsement.
>
>
>
> At least that's the way I imagine it.
>
>
>
> In trying to identify candidate extensions, we've reviewed a plethora of
> pre-existing works, both old and new, using Emily's site and the official
> Inform extensions page as guides. Progress, is being made, albeit slowly.
> Having said that, since opinions differ as to which extensions warrant
> inclusion and which do not, I thought it would worth while taking a poll to
> see what developers in general would like to see included in such a
> collection.
>
>
>
> So here are the questions:
>
>
>
> 1) Which pre-existing extensions, assuming author approval, would you like
> to see included in an official set of standardized extensions for Inform?
>
Top of the list of "can't live without" for me
calyx_adjectives.h
(had problems getting pname.h to work, but theoretically that too)
Actually I'd like to see the 'name' property replaced by something like
'noun' and 'adjective' properties as standard Inform.
style.h
(I've been meaning to check out the version that uses faux html markup,
but not got round to it yet.)
smart_cant_go
shuffle.h
(I also feel a noble mention should go to writelist.h although that's
been absorbed into the library with 611)
>
>
> 2) What types of extensions, which may not already exist, would you like to
> see included as well?
>
---
Comment control
When the parser makes an assumption, it prints a note in parentheses. e.g.
> POUR WATER IN BUCKET
(the bucket)
You pour the water in the bucket.
in this case the parser is probably disambiguating "water" and "water
bucket" - harmless but annoying.
It can be much more of a pest when I have something that in the game
world is one thing, but is coded up out of several sub-parts; to me (and
presumably to other Informants) it just shouts "aaa-HOOOO-gaaa!
Bodge-type-fakery going on here!"
I'd like to be able to say: when disambiguating THISOBJECT from
THATOBJECT, suppress the parenthetical comments.
---
margin.h
To allow the author to specify a left/right margin width (in ems) to
improve legibility in a standard game.
---
S
> fires off all the other daemons that may be running at any given time.
> Yes, I have to handle the dispatch based on state I maintain, but it
> gives me an easy way to control the order in which programmed events
> happen.
And effectively removes any limit on the number of daemons.
S.
S
> Actually I'd like to see the 'name' property replaced by something like
> 'noun' and 'adjective' properties as standard Inform.
Wouldn't this break old source code? Unless you let "name" and
"noun/adjective" co-exist... which I can see being a nightmare for the
parser.
S.
samwyse
> 2) What types of extensions, which may not already exist, would you like to
> see included as well?
I vote for extensions that implement the following:
"This is just one of a number of neat features either built into T3 or
added for this particular occasion: most of the traditional aspects of
IF are handled so smoothly that you almost miss realizing how slick it
all is. NPCs can be followed. Keys work as they ought to, unlocking
things by default whenever you want them to. The inventory manages
itself nicely, not only by stowing items in your tote bag but by taking
care of any other business before you put something away (e.g., "You
close your wallet and put it in your pocket."). In fact, the game almost
never refuses to let you do something just because you haven't completed
another trivial action first, but almost always does your accounting for
you. These may seem like minor features individually, but they
collectively leave the playing experience remarkably smooth and free of
frustration, allowing the player to get on with the fun parts."
(Shamelessly stolen from http://www.ministryofpeace.com/if-review/,
Emily Short's review of Michael Roberts' new game 'Return to Ditch Day',
written in TADS-3.)
Andrew Plotkin
>
> Top of the list of "can't live without" for me
> calyx_adjectives.h
> (had problems getting pname.h to work, but theoretically that too)
> Actually I'd like to see the 'name' property replaced by something like
> 'noun' and 'adjective' properties as standard Inform.
Extensions to the standard library, not changes to it. I want to keep
using the standard Inform "name" semantics in my own games. There's
definitely enough interest in name/adjective separation to warrant
making it a supported alternative.
> > 2) What types of extensions, which may not already exist, would you like to
> > see included as well?
>
> margin.h
> To allow the author to specify a left/right margin width (in ems) to
> improve legibility in a standard game.
Easy in Glulx -- doesn't require an extension, just a GGInitialise()
routine which adds style hints. But it's more likely that, if the
player things margins are legible, he'll have set them himself.
It's not possible in Z-code; the Z-machine view model doesn't allow
it. (You could probably do it in V6.) Again, the player may be using
an interpreter that allows it as a display preference. MaxZip/XZip
have always had a margin option.
Magnus Olsson
Andrew Plotkin <erky...@eblong.com> wrote:
>Here, Jayzee <non...@nowhere.com> wrote:
>>
>> Top of the list of "can't live without" for me
>> calyx_adjectives.h
>> (had problems getting pname.h to work, but theoretically that too)
>> Actually I'd like to see the 'name' property replaced by something like
>> 'noun' and 'adjective' properties as standard Inform.
>
>Extensions to the standard library, not changes to it. I want to keep
>using the standard Inform "name" semantics in my own games. There's
>definitely enough interest in name/adjective separation to warrant
>making it a supported alternative.
Hmmm - why not 'name', 'adjective' *and* 'noun'?
--
Magnus Olsson (m...@df.lth.se)
PGP Public Key available at http://www.df.lth.se/~mol
S
That depends. Are you suggesting "adjective" and "noun" simply be
synonyms for "name", or that they operate differently? I'm assuming the
latter, because the former seems fairly pointless, so --
Somewhere along the way the library would have to decide whether to work
with noun/adjective-based rules, or name-based rules. (For example, when
disambiguating objects). I can see this getting really ugly if someone
wrote source that alternated between the two. I can't think of a clean way
to do disambiguation if only *some* objects can be referred to by adjective,
and others only by noun (with preceding adjectives optional).
Plus, it's just weird.
I think some sort of optional .h-file is a better idea than changing the
existing guts of the library, at least in this particular case.
S.
Thomas Insel
S <do...@spam.com> wrote:
>> Hmmm - why not 'name', 'adjective' *and* 'noun'?
> Somewhere along the way the library would have to decide whether to work
>with noun/adjective-based rules, or name-based rules. (For example, when
>disambiguating objects). I can see this getting really ugly if someone
>wrote source that alternated between the two. I can't think of a clean way
>to do disambiguation if only *some* objects can be referred to by adjective,
>and others only by noun (with preceding adjectives optional).
I don't think it's that bad.
When parsing a particular object's name, if there is an adjective property,
use 'noun' and 'adjective'. If not, use 'name'.
Or, just treat 'name' and 'noun' as synonyms. Better still, just use 'adjective'
and 'name' and forget about 'noun' entirely. If there's no adjective specified,
then it's backwards compatible.
Tom
S
> Better still, just use 'adjective' and 'name' and forget
> about 'noun' entirely. If there's no adjective specified,
> then it's backwards compatible.
That may be the answer to the original question. :^)
S.
Axel Toelke
the canon should be:
a) How it impacts the standard library's behaviour.
A successful candidate should 'extend' not 'replace'
or 'alter' existing behaviour.
So, for example, given this criterion, I think dirs_2.h
would be a good contender, while NewList might not be.
b) The extension should be consistently bi-platform, meaning
that it should support both Z-Code and Glux, without the
writer's attention or maintenance need.
c) The extension should provide the writer with a tool that
he would have otherwise been unlikely to produce himself.
I know this point is a bit vague. What I am trying to say
is, that most writers will be able to emulate a lot of the
existing extensions, given enough time and thought. Some of
them will, however, most likely be beyond their reach because
they deal with rather complicated programming challenges,
that a casual writer will not be able to reproduce, and or
even want to spend the time on understanding.
Out of the existing extensions, I would vote for selecting
things that make screeen manipulation and presentation easier
for authors, because, I assume, many casual writers like me,
simply do not want to delve into implementing those things
ourselves.
Unfortunately, the existing code is often mutually exclusive.
So, for example, while I believe that GWindows is an amazing
contribution and really makes Glux game writing much, much
easier. However, at the same time, adopting the GWindows
framework will rule out using any other contributions that
also only marginally deal with screeen manipulation (menus,
etc.). Like Magnus Olsson's menu conversation system, for
example.
Therefore, I believe Inform could at this stage really benefit
from a standard set of presentation extensions, that will provide
the writer with a set of (extensible) tools, to affect screen
layout, menus, colours, etc.
On a smaller scale, I would include the various parsing enhancements,
as well as things on the scale of dirs_2.h, which simply 'enhance'
and do not replace.
I am particularily fond of 'scenery.h' which allows the author to
provide for a much richer gaming experience, without actually
having to code all the scenery objects themselves. If this were
included, I believe we would see richer games in return.
Unfortunately,
scenery.h, does interfere with some standard behaviour, and in
particular
does not seem to co-exist well with Jim Fisher's ORLIB (in particular
the various extensions to the 'look' and 'examine' behaviour). I would
dearly love to see an updated version of scenery.h.
Finally, I would vote for inclusion of compass.h. This was already
partially done with the latest library release. Let's finish this
job and make it possible, to selectively define rooms with and
without walls, based on whether they are inside or outside
respectively.
On that token, two-way doors which can be referred to as 'x south
door' or 'x north door', based on location would also really be
a valuable enhancement.
In terms of what I would like to see in future (more broad)
enhancements,
I believe the community could benefit from standard extensions dealing
with NPC interaction and conversation. I believe that Jim Fisher's
ORLIB offers exciting possibilities here, however, this would be a
bigger
step, as most of the extensions he provides actually do replace
standard
behaviour (in an impressively elegant way however).
I hope this has been helpful, and a hearty thank to everybody who
took the time to provide these amazing extensions for us in the
first place. I learned so much about Inform by just trying to
understand how they all work :) (and no, menus and screen manipulation
I will never understand, I think *g*)
Axel
L. Ross Raszewski
>
>Out of the existing extensions, I would vote for selecting
>things that make screeen manipulation and presentation easier
>for authors, because, I assume, many casual writers like me,
>simply do not want to delve into implementing those things
>ourselves.
See, I think screen manipulation is something that can't meet the
criteria you specify in the bit I snipped. Much as I'd like to see
more folks use GWindows, there's no way in hell it's going to work in
Z-code, for example (it may be theorhetically possible to port
GWindows to v6, but there are certain people who would hunt me down
and kill me if I tried).
I do more or less agree with the criteria you give (though I might be
inclined to relax the Glulx/Z-machine restrictions, given that, for
instance, PrintAnyToArray, is already in the library and isn't
biplatform, I think).
Off the top of my head, I'd vote for an adjective library (I always
write my own, but I appreciate that I'm bizarre), flyweight scenery
non-objects, footnotes, and some utility functions (I'm thinking of
utility.h, excluding the bits that aren't very cross-platformy,
ordinal numbers, date/time calculations, and perhaps some more
hardcore math functions. I could get behind
including istring, but it's awfully heavyweight and, um, touchy.).
There are also some things that I think should *not* be bundled with
the library for Serious Reasons:
* Conversation handling
- I know that what's built into the library is primitive. There's a
*reason* for that. There are many many mutually exclusive ways of
modeling conversation. Trying to impose one paradigm on authors is
going to Go Badly.
* Help/Instructions
- One thing that bothers me much more than a game not having
instructions is a game having inaccurate instructions. A good 50% of
AGT games out there have comically inaccurate instructions because
they were copied verbatum from 'Gothic', a sample AGT game.
If we added an instruction mechanism to the library, we would need to
either (1) not include the actual instruction text, in which case the
extention is a *really trivial* bit of coding or (B) Make the
instruction text so vague and general as to be of no help to the
player. In either case, I don't think it's warranted.
* Model world extentions
- Fluid modeling, ropes, fire, etc. I think we need more and better add-on
libraries for these, yes, but I think model world extentions of this
sort are best left to the authors to pick and choose as suit their
own *specific* needs. Inform is not WorldClass nor should it be.
I will grant that at least two of these are probably the most *useful*
kind of extention, whereas my own list is mostly tiny little
trivialities. But I strongly feel that the "big stuff" should
continue to be stuff that folks "option for", not that somes included.
Gene Wirchenko
>At Graham's request, some of us are looking into creating a set of
>standardized library extensions. This won't be a set of extensions to
>replace all extensions, you understand; rather, it will be something in the
>spirit of menu.h, giving a little more credibility to the extensions by
>virtue of endorsement.
[snip]
>Consider carefully, extra points will be awarded for useful answers.
I do not use Inform. I have never used it. One of the things
that has kept me away is all the mention about string handling, that
is, the lack of handling for strings. I would like to see good string
handling, something along the lines of many BASICs or of C++'s string
type.
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Paxelius
> Off the top of my head, I'd vote for an adjective library (I always
> write my own, but I appreciate that I'm bizarre), flyweight scenery
> non-objects, footnotes, and some utility functions (I'm thinking of
> utility.h, excluding the bits that aren't very cross-platformy,
> ordinal numbers, date/time calculations, and perhaps some more
> hardcore math functions. I could get behind
> including istring, but it's awfully heavyweight and, um, touchy.).
These are great ideas, why haven't you uploaded the adjective library ?.
> But I strongly feel that the "big stuff" should
> continue to be stuff that folks "option for", not that somes included.
Sure.
Michael
<snip>
> * Help/Instructions
> - One thing that bothers me much more than a game not having
> instructions is a game having inaccurate instructions. A good 50% of
> AGT games out there have comically inaccurate instructions because
> they were copied verbatum from 'Gothic', a sample AGT game.
> If we added an instruction mechanism to the library, we would need to
> either (1) not include the actual instruction text, in which case the
> extention is a *really trivial* bit of coding or (B) Make the
> instruction text so vague and general as to be of no help to the
> player. In either case, I don't think it's warranted.
>
I have to disagree. Consider that alot of IF games out there don't
really have specialized help instructions. Now consider how useful a
default set of instructions on how to play if in general would be to a
newbie. The help wouldn't necessarily have to show them how to play
that PARTICULAR game; rather, it could get them acquainted with IF
conventions, put them on the same ground that regular IF players are
on. Besides, it's not like we'd make it unreplaceable. If an author
has a different idea for their help system, then by all means we
should allow them to replace the default instructions. But having a
helpful default for "help" would certainly, erm... help.
Michael
L. Ross Raszewski
>I have to disagree. Consider that alot of IF games out there don't
>really have specialized help instructions. Now consider how useful a
>default set of instructions on how to play if in general would be to a
>newbie. The help wouldn't necessarily have to show them how to play
>that PARTICULAR game; rather, it could get them acquainted with IF
>conventions, put them on the same ground that regular IF players are
>on. Besides, it's not like we'd make it unreplaceable. If an author
>has a different idea for their help system, then by all means we
>should allow them to replace the default instructions. But having a
>helpful default for "help" would certainly, erm... help.
>
>Michael
If the instructions are wrong on even *one* point, then, IMHO, the
instructions have failed. So that means not documenting ASK/TELL (not
all games use them), NORTHWEST (ditto), hell, I've even seen games
which disabled DROP.
If the instructions suggest the player try certain kinds of action,
like 'take everything that isn't nailed down', they're going to be
wrong for some games. Instructions for playing IF in general have a
place in this world, but "Here are instructions that apply to most IF
games, but not the one you're actually playing" have no place *in
that game*. Instructions that can't possibly be inaccurate would be
so general as to be useless: "You type some commands as short
imperative sentences. Read what happens and react."
Of course authors can override. But authors *won't*. They won't even
*disable it because they don't feel like fixing it*, they'll just
leave in the inaccurate form-letter instructions, telling me that I
will get a nice gothic novella if I type 'SCRIPT' before I start
playing.
You might as well say (well, have said ten years ago) "Most games are
set in a dungeon, so let's make all the default messages assume
that. After all, the author can change them if they don't work for his
game." (Okay, that's a bunch more drastic and silly, but cf. AGT's
assumption that the author is writing a Zork-clone, and the result
that hardly any AGT authors ever expent *quite* enough effort to
suppress this assumption).
Cedric Knight
> I do not use Inform. I have never used it. One of the things
> that has kept me away is all the mention about string handling, that
> is, the lack of handling for strings. I would like to see good string
> handling, something along the lines of many BASICs or of C++'s string
> type.
Then maybe Inform should have a standard string library, if only for the
sake of appearances.
It is a misapprehension that Inform cannot handle strings. The one Inform
string problem I've seen on this newsgroup had a very simple solution. The
most sophisticated bit of string processing I've seen in a work of IF is in
Inform, _Large Machine_. Inform 6/11 includes new inbuilt string functions
(Length(), Capitalise()). And I've written an automatic spelling corrector
in Inform.
Inform already has a String class, used for compressed strings. What isn't
inbuilt is dynamic memory allocation for uncompressed strings. In the case
of the Z-machine any heap array is limited to 60K and adds to the story file
size. This is not true in Glulx.
CK
Michael
> If the instructions are wrong on even *one* point, then, IMHO, the
> instructions have failed.
> If the instructions suggest the player try certain kinds of action,
> like 'take everything that isn't nailed down', they're going to be
> wrong for some games. Instructions for playing IF in general have a
> place in this world, but "Here are instructions that apply to most IF
> games, but not the one you're actually playing" have no place *in
> that game*.
Why not? I don't think instructions like "take everything you can" and
"examine everything" are useless, even if they're in a game like Lock
and Key. At least it puts the newbie on the same level of
understanding that an experienced IF player is on, so they can try all
the same things we would before figuring out that Lock and Key is a
bit different from your standard IF. I think as long as it was made
clear that said instructions pertain to MOST IF games, but not all,
then that is perfectly fine, and at least the newbie can try other
games with a better understanding of how they should be played.
Michael
Stephen Granade
> lrasz...@loyola.edu (L. Ross Raszewski) wrote in message news:<cKNCc.30310$Yb1....@nwrddc02.gnilink.net>...
> > If the instructions are wrong on even *one* point, then, IMHO, the
> > instructions have failed.
> <snip>
> > If the instructions suggest the player try certain kinds of action,
> > like 'take everything that isn't nailed down', they're going to be
> > wrong for some games. Instructions for playing IF in general have a
> > place in this world, but "Here are instructions that apply to most IF
> > games, but not the one you're actually playing" have no place *in
> > that game*.
>
> Why not? I don't think instructions like "take everything you can" and
> "examine everything" are useless, even if they're in a game like Lock
> and Key. At least it puts the newbie on the same level of
> understanding that an experienced IF player is on, so they can try all
> the same things we would before figuring out that Lock and Key is a
> bit different from your standard IF.
You're assuming that these theoretical new players are interested in
playing IF in general, rather than the specific game they may have
downloaded. I don't see why a specific work of IF should give
non-applicable instructions any more than instructions for the game
Chutes and Ladders should talk about rolling dice to move around a
board just because many board games use dice instead of a spinner.
Stephen
--
Stephen Granade
ste...@granades.com
Michael
If an IF game DOESN'T follow regular conventions, isn't the onus on
the author to provide accurate documentation anyway? In which case
they would (should) replace the included primer?
Michael
Stephen Granade
> If an IF game DOESN'T follow regular conventions, isn't the onus on
> the author to provide accurate documentation anyway? In which case
> they would (should) replace the included primer?
Sure, but that's not the point I was addressing. Above you said
I don't think instructions like "take everything you can" and
"examine everything" are useless, even if they're in a game like
Lock and Key.
Why should any game have instructions that don't apply to it?