Boundlessness & IF
David Fisher
http://www.tads.org/howto/convbkg.htm:
I personally think that the supposed "boundless" quality of text IF is
overrated; I think a big part of the reason that most people don't like text
IF is the stark contrast between the promise of "boundlessness" and the
reality of "I don't know that word." I think most people approach a text
game with that wonderful promise of endless choices in their minds, and
after the fiftieth "you can't do that here" or "I don't know that word" or
"I don't know anything about that" they give up and go play something with
graphics and a sane UI. Even so, a lot of people who do like text IF say
that the illusion of boundlessness is a key reason why, so it's worth
keeping this in mind when designing a game.
For all their good features, menus are a poor fit to the conventional text
IF user interface. To me, this is a bigger drawback than the illusory
reduction in range of action. The fundamental problem is that menus are a
multiple-choice test, and the rest of the interface is an essay contest. To
me, the charm of the free-form command UI isn't its supposed boundlessness
(see rant above); it's the subtle UI transparency, the illusion that you're
not operating a computer program at all but are just carrying on a
conversation with the story's narrator.
(end quote)
How far should IF authors go in creating a sense of "boundlessness" in their
games ? Here are a few (extreme) possibilities:
(1) Realistic conversations
> Say "How would you like to earn a some gold, Fred?"
Fred looks interested. "What'd you have in mind, sir?"
> Smile and say, "Could you go into town and find out if the princess has
> arrived yet?"
Fred slaps you on the back and says, "Ha! I know what yer up to, lad. Back
in two ticks then." He runs down to the hill and enters the village by the
main gate.
(2) Accepting detailed commands
The Guardian approaches you menacingly, forcing you towards the edge of the
cliff. "Return the jewel," he yells, "and you may yet avert my wrath!"
> Hold the jewel over the cliff and threaten to drop it
The creature hesitates, not wanting to lose his precious jewel.
(3) Changing with the environment
> disintegrate north wall
OK, the main passage is now connected to the side tunnel.
(4) Complex interaction with objects
> balance bottle on door knob
OK, the bottle is precariously balanced on top of the door knob.
> go into the bedroom and go to sleep
You enter into a fitful sleep ...
Suddenly you are awakened by a loud "crash" as the bottle you placed on the
door knob falls to the ground. Someone has opened the front door !
[ This example inspired by the movie Conspiracy Theory ]
These are just some wild ideas ... possible one day ? Or even desirable, as
an "ultimate goal" ?
To rephrase the question: Is the ultimate aim to have a better illusion of
boundlessness (see quote from Michael Roberts at the start of this post), or
to turn the illusion into reality (with more and more "unlimited"
interaction inside the game universe) ?
David Fisher
samwyse
[...]
> To rephrase the question: Is the ultimate aim to have a better illusion of
> boundlessness (see quote from Michael Roberts at the start of this post), or
> to turn the illusion into reality (with more and more "unlimited"
> interaction inside the game universe) ?
Well, you start off seeming to talk about conversation, but many of the
examples that you give are more about simulations. A really good
simulation requires a really good physics model, which requires details
3-D models of the environment. Once you've got that, you may as well
add textures to the surfaces and turn the whole thing into something
like a first-person shooter.
In other words, I agree with M.R. that the aim is to have a better
illusion. Much of the research in I-F deals with turning strategy into
tactics. For example, there are periodic posts about "automatic"
movement. Instead of saying "N. E. W. W." to return to the kitchen, the
player can just say "GO TO THE KITCHEN" and the game will generate the
detailed moves and execute them. Once you've got that, you are a very
short step from "FRED, BRING ME THE SHRUBBERY" or "TAKE THE SALTPETER,
THE SULFUR AND THE CHARCOAL TO THE CHEMISTRY LAB", both of which seem
like more reasonable I-F commands than the examples that you give.
Chris Pickett
> On or about 2/28/2005 11:41 PM, David Fisher did proclaim:
> [...]
> > To rephrase the question: Is the ultimate aim to have a better illusion of
> > boundlessness (see quote from Michael Roberts at the start of this post), or
> > to turn the illusion into reality (with more and more "unlimited"
> > interaction inside the game universe) ?
>
> Well, you start off seeming to talk about conversation, but many of the
> examples that you give are more about simulations. A really good
> simulation requires a really good physics model, which requires details
> 3-D models of the environment. Once you've got that, you may as well
> add textures to the surfaces and turn the whole thing into something
> like a first-person shooter.
I think one of the neat things about I-F is that you can do
disconnected and abstract things without needing a full simulation,
and that's really where it starts to get boundless -- you can really
do "anything", all it takes is for the author to write it. I think
reality and the picking up and application of (perhaps somewhat
fantastical) objects and moving of oneself in the cardinal directions
that its simulation often demands is a bit too much of a constraint on
creative process, and I-F is good because it lets you get away from
that (although, most authoring systems still expect you to be moving
objects between rooms...).
Chris
David Fisher
> I agree with M.R. that the aim is to have a better illusion. Much of the
> research in I-F deals with turning strategy into tactics. For example,
> there are periodic posts about "automatic" movement. Instead of saying
> "N. E. W. W." to return to the kitchen, the player can just say "GO TO THE
> KITCHEN" and the game will generate the detailed moves and execute them.
> Once you've got that, you are a very short step from "FRED, BRING ME THE
> SHRUBBERY" or "TAKE THE
> SALTPETER, THE SULFUR AND THE CHARCOAL TO THE
> CHEMISTRY LAB", both of which seem like more reasonable I-F
> commands than the examples that you give.
I was deliberately giving some "extreme" examples of where IF could
potentially go. Maybe I should tone it down a bit ...
The second example may have been the most realistic:
> Hold the jewel over the cliff and threaten to drop it
Ultimately, do IF authors want the players to be able to enter this kind of
thing and be understood ? Are there any disadvantages to having this level
of "understanding" as a goal ? (One potential disadvantage is that if the
player can say just about anything and be understood, then how do IF authors
handle the many situations which can then come up - and potentially ruin or
bypass the careful plot they have planned out ? Is there some way around
this problem - a different way of authoring that takes a very large number
of possible player actions into account - or is this unsolvable ?)
Put another way, I would love to do a lot more of the things the characters
do in movies and novels - clever uses of resources, bowling over the enemy &
running ("push orcs. run." doesn't quite work), etc. Take note of the
actions of the main characters in the stories you watch and read, and see
how many you could express in an Interactive Fiction environment. Imagine
what it would be like if you could.
But is that the right aim for IF ? (As an ultimate future goal, that is ...)
David Fisher
Sands...@yahoo.com
David Fisher wrote:
<< The second example may have been the most realistic:
<< > Hold the jewel over the cliff and threaten to drop it >>
"Hold the jewel over the cliff," seems like a valid, if
unusual, command to me, but "Threaten to drop it," might
be too vauge for these games.
IF requires specific actions, partially so the author can
try to account for what a player might try to do, partially
because trying to set up a multi-action sequence based on a
vague command would be pretty tough, and partially because
that sort of specificity is what allows for gameplay. "Defeat
the villian," is a valid goal for the player, but if that sort
of input were possible, there wouldn't be much interactivity.
("Threaten," for instance, would have to be more specific, and
you've already said how you would do that, so, in this example,
it's also redundant.)
<< Ultimately, do IF authors want the players to be able to
enter this kind of thing and be understood ? Are there any
disadvantages to having this level of "understanding" as a
goal ? (One potential disadvantage is that if the player can
say just about anything and be understood, then how do IF
authors handle the many situations which can then come up -
and potentially ruin or bypass the careful plot they have
planned out ? >>
It seems like this is usually handled by giving the player a
series of very specific, tangible, objectives, which the author
can handle.
<< Put another way, I would love to do a lot more of the things
the characters do in movies and novels - clever uses of
resources, bowling over the enemy & running ("push orcs.
run." doesn't quite work), etc. >>
I think there's a lot of clever uses of resources by the player
in IF. (And I think "Push orc. South," could be implemented in
a game.)
I think one difference is that a lot more can happen in a novel
or even a feature film, because the author doesn't have to deal
with all the specifics. It isn't very interesting to watch a
mechanic prepare an aircraft for flight in a film or novel, but
that might be a element of an IF game, because it allows the
player to interact with the game.
Another difference is that IF doesn't usually handle characters
very well and who a character is and what that character will,
or won't, do, and how that character sees things, is a big part
of fiction and film. This subject is brought up around here, on
occasion, and many people don't seem to feel good about restricting
the player's potential actions because it would be out-of-character
for the player-character. And while some games do depict a paticular
point-of-view well, usually IF descriptions don't seem to be skewed
much to fit in with how a paticular PC might see things.
Ian Haberkorn
conditioning?
As programmers, we are really pretty boundless - we could implement
whatever we wanted! The problem is, it's so much work. The farther an
action is from advancing the score, the less we are likely to
implement it. (See a former discussion of "Should there be toilets in
IF?"*)
As players, we are conditioned by so many "That's not a verb I
recognise"'s (which also discourage the untrained IF-newbie), that we
restrict our thinking to common actions. As a result, "Threaten to
drop jewel" sounds to me like a classic guess-the-verb annoyance,
though logical in a movie or novel plot. Boundless objects (let's
implement a woman's purse realistically!) lead to a massive red
herring disorientation.
So, good, boundless-seeming IF probably needs to spend some time
introducing and encouraging more complex actions before basing puzzles
on them.
If anybody is wondering whether I am entitled to an opinion - I am a
bloody beginner, but stumped on exactly this question on my first IF
in progress. How many appliances should there be in my virtual
kitchen?
Ian
* This was the first thread I encountered on RAIF - what an
introduction!
PJ
Ian Haberkorn wrote:
> Isn't boundlessness in IF about programmer's diligence and player
> conditioning?
I don't think it's mere diligence. It's an intuitive understanding of
the extent you need to go as the God of your game in detailing your
gameworld. The degree of required diligence can vary from game to
game, depending on the objectives of the game.
> As programmers, we are really pretty boundless - we could implement
> whatever we wanted! The problem is, it's so much work. The farther an
> action is from advancing the score, the less we are likely to
> implement it. (See a former discussion of "Should there be toilets in
> IF?"*)
Actually, some people seem to glory in the details of the
implementation and give less thought to the story or the scoring.
Since I like story-based games, I see 4 things as primarily
contributing to the illusion of "boundlessness":
-- every logical action or item that is required to advance the story
MUST be implemented, in as many variations as can reasonably be devised
by the player;
-- every logical action or item that could possibly have advanced the
story, but doesn't, SHOULD have some sort of customized response to let
the player know that they need to try another tack (i.e., not just the
standard library messages).
-- some illogical or non-obvious actions and items should be
implemented just to give the player a thrill in case they try them.
-- over-diligence by the player in the form or repeated <take all>,
<look>, <x object>, etc. should be captured and handled with some sort
of message text that lets the player know they are wasting their time.
> So, good, boundless-seeming IF probably needs to spend some time
> introducing and encouraging more complex actions before basing
puzzles
> on them.
Complex actions should be set up by the story. If I need to threaten
an NPC to get what I want, the preceding text should be leading me to
believe that "threaten" is an allowable/desirable verb. If authors
develop a script before they do the coding, they should be able to go
through and see what verbs and nouns are really necessary for the
"boundless" illusion to be maintained. If there are too many
verbs/nouns, then edit the script a bit! :)
PJ
steve....@gmail.com
in their
> games?
Boundlessness of any flavor is probably not a goal in itself -- not in
IF anyway: IF relies on simulation, but demands narrative. Interesting
narrative is orthogonal to "boundlessness" (that is, the two concerns
appear to be mutually independent).
An interesting narrative will emerge from a perfect simulation with
about the same frequency that an interesting narrative emerges from
"real life." You could imagine a "gamemaster AI" or "drama manager"
that can handle all the "unbounded" actions of the player, and tie
everything back into the narrative, but at this point, we're talking
about boundlessness as running *against* the narrative, and something
to be recuperated -- which suggests boundlessness is a problem for IF
rather than a goal.
There's much more to say on the subject, but instead, I'll address in
particular what I think are your two primary notions of boundlessness:
> (1) Realistic conversations
>
> > Say "How would you like to earn a some gold, Fred?"
You can make some progress towards this with currently available
"natural language understanding" (NLU) technology, though nothing like
this is yet available in any IF authoring system. I think NLU would be
cool for conversation, but not for parsing (see below). -- Cool for
conversation, but problematic, in that this may imply a need for a
highly sophisticated "natural language generation" system.
On a related note, Mateas and Stern are working on _Facade_, which
combines shallow-NLU with pre-coded conversation slices.
http://www-2.cs.cmu.edu/afs/cs.cmu.edu/project/oz/web/papers/CMU-CS-02-198.pdf
> (2) Accepting detailed commands
>
> The Guardian approaches you menacingly, forcing you towards the edge
of the
> cliff. "Return the jewel," he yells, "and you may yet avert my
wrath!"
>
> > Hold the jewel over the cliff and threaten to drop it
>
> The creature hesitates, not wanting to lose his precious jewel.
This reminds me of David Baggett's rejection of NL parsing
(particularly adverb parsing):
http://groups-beta.google.com/group/rec.arts.int-fiction/msg/30ec2a8986b4348b
The upshot: this is a terrible idea in that it would produce
guess-the-adjective puzzles. (Guess-the-verb is already bad enough.)
On the other hand, Mike Roberts has written, "if you really could type
in arbitrary natural-language commands and have them interpreted as
well as a human would interpret them, I can't imagine any way that
could detract from the experience." -- except, I would add, insofar as
the extra range of action might screw up the narrative (as I argue
above).
(http://groups-beta.google.com/group/rec.arts.int-fiction/msg/391a3e449e2f7575)
It's nice to consider ideals, since they, though unreachable, may guide
our projects. Still, NLP-complete questions are terribly speculative.
Brandon J. Van Every
> A quote from "Choosing a Conversation System" by Michael J. Roberts,
> http://www.tads.org/howto/convbkg.htm:
>
> I personally think that the supposed "boundless" quality of text IF is
> overrated; I think a big part of the reason that most people don't
> like text IF is the stark contrast between the promise of
> "boundlessness" and the reality of "I don't know that word."
The problems of boundlessness go quite beyond a dictionary vocabulary, or
the problems of *text* adventure per se. It's a semantic issue. Many
graphical adventures are plagued by the problem of "guessing the author's
mind." It's a sign of bad or user hostile game design when players can't do
it. I don't think the adventure game as a commercial genre will ever get
over the "getting stuck" problem. There just isn't enough commercial
authorship of adventure games anymore, for this to ever change. My
perception is that commercial adventure games repeat the same kinds of "gosh
I'm stuck, where's the walkthrough??!?" mistakes as they always have.
Once upon a time, most people who owned computers were smart and resilient
to their difficult quirks. One had to be, in the early days. The adventure
game market mirrored those people's sensibilities. That is no longer true:
computers are mass market and much easier to use. This is a big part of why
the commercial adventure game has withered.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"Troll" - (n.) Anything you don't like.
Usage: "He's just a troll."
Brandon J. Van Every
>
> Put another way, I would love to do a lot more of the things the
> characters do in movies and novels - clever uses of resources,
> bowling over the enemy & running ("push orcs. run." doesn't quite
> work), etc. Take note of the actions of the main characters in the
> stories you watch and read, and see how many you could express in an
> Interactive Fiction environment. Imagine what it would be like if you
> could.
>
> But is that the right aim for IF ? (As an ultimate future goal, that
> is ...)
You should decide your audience. With commands as sophisticatd as "Bowl
over the orcs," your audience seems to be yourself + your IF author buddies.
I seriously doubt the general public is imaginative enough to type commands
in this manner. Realize that what you enjoy as a writer is not the same
thing as what an average player enjoys or knows to do. So, decide if this
work is for you and your IF buddies, as some kind of "writer's club"
artistic statement, or if it's for a broader audience.
Choosing the narrowness or breadth of one's approach is hardly a unique
problem to interactive fiction. Films and books are filled with these sorts
of tradeoffs. The more obscure, the less often published or paid attention
to.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"witch-hunt" - (noun) (Date: 1885)
1: a searching out for persecution of persons accused
of witchcraft
2: the searching out and deliberate harassment of
those (as political opponents) with unpopular views
- witch-hunter (noun)
- witch-hunting (noun or adjective)
Brandon J. Van Every
>
> As players, we are conditioned by so many "That's not a verb I
> recognise"'s (which also discourage the untrained IF-newbie), that we
> restrict our thinking to common actions. As a result, "Threaten to
> drop jewel" sounds to me like a classic guess-the-verb annoyance,
> though logical in a movie or novel plot. Boundless objects (let's
> implement a woman's purse realistically!) lead to a massive red
> herring disorientation.
Yes, agreed. And in general, 'receiving media' is an audience training
problem. For instance, American film audiences are trained by Hollywood to
expect a Three Act Structure. The audience doesn't know that's the explicit
industry standard structure, but they have an intuitive sense of it from
seeing many movies. These become the default navigational cues. Now, a
filmmaker can certainly do something other than Three Act Structure. But
when they do so, they have the burden of re-educating the audience. If they
fail to, the audience gets lost and the movie probably bombs.
If one had a very big bank account, and 10 years to bombard audiences with
new propaganda, one could re-train audiences to accept any reasonable
structure that one likes. Ancient Greeks generally started their stories in
the middle, after all. But creative work is a financially desperate affair,
so most authors stick to the basics.
"Training and retraining" problems are important for thinking about Game
Design in general. It provides a rationale for why you do or don't need a
tutorial level, how long it needs to be, and what it needs to include. For
instance, it's pretty easy to educate gamers on First Person Shooter
interfaces. So many games have the same interface, that there are
recognizeable conventions.
> If anybody is wondering whether I am entitled to an opinion - I am a
> bloody beginner, but stumped on exactly this question on my first IF
> in progress. How many appliances should there be in my virtual
> kitchen?
How do any of these appliances advance your story? That's the
screenwriter's criterion. If it's irrelevant set dressing, you leave it to
the props dept.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"Trollhunt" - (n.) A searching out for persecution
of persons accused of Trolling. (c.f. witch-hunt)
Brandon J. Van Every
> furthermore, movies and novels aren't usually about common people.
Why should IF titles be? "You are you," is, I believe, a mistake. To be
sure, it is important to secure character buy-in. If the players don't like
the characters they're supposed to be playing, they may very well put the
game down. But one can do things to secure the buy-in. The writing world
is full of devices. People in the IF world often come from a programming /
engineering / simulationist background; they assume the primacy of
statements like "You are you."
> I mean, we might be able to pull
> off thinking of something creative like balancing a bottle on a knob,
> but to think of all the creative things and perform all the
> hyper-dextrous manuevers seen in most movies requires the skill that
> only a good actor, a tight plot, and lots of takes can provide.
As per my other post, the author would have the burden of retraining the
player as to what's possible. It's doable, but risky. Lotta work involved,
good chance of failure. But hey, the same is true for publishing a novel or
getting your screenplay produced, right?
> The question for IF is, "Do we want to code the universe in pursuit of
> modelling the perfect environment or do we want to make a game?" A
> game, by definition, is a restrictive model of some space. D&D, for
> instance, doesn't model starships. Hexen doesn't model Volvos. Are
> they restrictive and unfair? No, they are games.
To poke holes, AD&D *did* model a starship in dungeon module S3? "Expedition
To The Barrier Peaks." A curious similarity between a Mind Flayer and a
certain alien race was suggested. There are no laws in AD&D that say you
cannot cross genres. It's just the overwhelming tendency of AD&D players to
stick to fantasy swords and sorcery, because that's what all the rules and
books and modules are geared towards.
A more relevant question is, "Do you want to tell a story about the entire
universe?" Probably you don't. Even if you do, that's going to take you
awhile. :-)
> Fiction authors do thing the same way -- they model
> only what is necessary to the plot. Otherwise, the main character
> would never make it out of bed in the morning, and the audience would
> fall asleep after page 50 of the character's observation of his
> bedroom after he wakes up.
Exactly.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"Trollhunter" - (n.) A person who habitually accuses
people of being Trolls.
Brandon J. Van Every
>
> On a related note, Mateas and Stern are working on _Facade_, which
> combines shallow-NLU with pre-coded conversation slices.
>
>
http://www-2.cs.cmu.edu/afs/cs.cmu.edu/project/oz/web/papers/CMU-CS-02-198.pdf
Here's the main website:
http://www.quvu.net/interactivestory.net/
I distinctly remember I was supposed to judge it in the Finals of the
Independent Games Festival 2004. Unfortunately it didn't run on my machine,
so I left it to others to decide. Beyond making it to the Finals (which in
and of itself is a respectable achievement), it didn't win a prize. I
notice they still haven't released the game yet, so maybe there were lotsa
bugs to iron out? They still haven't released it yet, but apparently it's
coming a.s.a.p.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"Trollhunt" - (n.) A searching out for persecution
Fredrik Petersson
I was looking at the ifwiki and ended up trying to figure out what to call
things.
There are two ways of getting stuck in a game: one way is when you just don't
know
what to do (guess-the-verb conundrums, just plain illogical solutions, etc),
the other
is when there simply IS no solution - you've managed to destroy the only
key to the
door you have to go through, etc.
Whether these two ways of getting stuck are design flaws or bugs I'd like
to leave
for others to fight out - but, wouldn't it be nice to agree on what to call
them?
I'll propose that "stuck" should mean the first version: there is a solution,
but the
player has a hard time finding it. I couldn't really come up with a concise
way of
saying that there is no solution. Well, except, "there is no solution".
Any suggestions?
---
Fredrik Petersson
pesononline.com
Brandon J. Van Every
>
> There are two ways of getting stuck in a game: one way is when you
> just don't know
> what to do (guess-the-verb conundrums, just plain illogical
> solutions, etc),
I nominate "guessing the author's mind." I've heard others refer to the
problem this way before, and it's very broad, in all adventure games.
> the other
> is when there simply IS no solution - you've managed to destroy the
> only key to the door you have to go through, etc.
I nominate "a deadlock."
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
Daphne Brinkerhoff
news:40806324541...@news.chello.se...
I think that's called "putting the game in an unwinnable state", or
"unwinnable" for short, I guess. Some games have implemented a "winnable"
command to tell you if you've done this.
--
Daphne
Mike Roberts
> On the other hand, Mike Roberts has written, "if you really
> could type in arbitrary natural-language commands and have
> them interpreted as well as a human would interpret them, I
> can't imagine any way that could detract from the experience."
> -- except, I would add, insofar as the extra range of action
> might screw up the narrative (as I argue above).
The range of action can be more limited than the parser's comprehension,
though - just because the parser understands a command doesn't mean that the
game has to carry it out. Given a command-line interface, I'd much rather
have the parser understand what I mean, and tell me that my intended action
isn't allowed, than to have the parser get confused about syntax or
vocabulary. When the parser doesn't understand your input, you're left
wondering whether the problem is the idea or the phrasing. Eliminating that
would be entirely positive, I think.
--Mike
mjr underscore at hotmail dot com
Kevin Forchione
news:KkTUd.16$Le2...@nasal.pacific.net.au...
<snip>
> To rephrase the question: Is the ultimate aim to have a better illusion of
> boundlessness (see quote from Michael Roberts at the start of this post),
> or to turn the illusion into reality (with more and more "unlimited"
> interaction inside the game universe) ?
I believe the "goal" is best summarized by Infocom's statement in their New
Zork Times newsletter as quoted in NickMountfort's Twisty Little Passages:
"Although our gams are interactive fiction, they are more than just stories:
they are also a series of puzzles. It is these puzzles that transform our
text from an hour's worth of reading, to many, many hours worth of thinking
... The value of our games is that they will provide many, many hours of
stimulating mental exercise. (Infocom, Inc. 1984)"
As Mike Roberts has previously pointed out, the command line UI already
provides the "illusion" of boundlessness. The player's imagination will
augment this illusion to the degree that the game's narrative creates a
convincing, consistent and compelling "story world" and the
suspense/mystery/dramatic elements (i.e. "puzzles") engage the players
emotional and analytical faculties.
--Kevin
Christian Odhner
slightly different point of view, in that I don't see any
particular reason for excellent simulationism to detract
from plot.
The original post from David said, in part:
===== cut here ==========
> balance bottle on door knob
OK, the bottle is precariously balanced on top of the door knob.
> go into the bedroom and go to sleep
You enter into a fitful sleep ...
Suddenly you are awakened by a loud "crash" as the bottle you placed
on the door knob falls to the ground. Someone has opened the front
door !
[ This example inspired by the movie Conspiracy Theory ]
These are just some wild ideas ... possible one day ? Or even
desirable, as an "ultimate goal" ?
====== cut here ============
So first of all, I absolutely loved that movie. But, on to your
point...
1) In order to achieve that level of intelligent response, there
would have to be lots and tons and lots more AI. We're talking
some really extreme expert system work going on.
2) However, it's most likely possible today.
2a) If, by "today", you mean "after two or three years of intensive
development effort by a skilled team of programmers with good
project management and an equally skilled team of beta testers and
quality assurance experts".
3) Despite the fact that it's possible, I don't think most players
would end up taking advantage of the system capabilities. Game
players in almost any genre want to play the roles of above-average
actors; that's why you see so many games of various sorts where the
player is a big powerful thing that is fighting a plethora of small
weak nasty things; and why you hardly ever see games where the
player is a plethora of small weak things fighting a big powerful
nasty thing[1].
4) Which brings me to the point that if you put enough work into
making the game smart enough to anticipate and correctly react to
all of the many possible things the player might attempt, you would
need to do so by programming some seriously intelligent agents with
lots of interesting rules of thumb, huge knowledge bases, etc... and
if you did that, the software agents you created would represent
hundreds of thousands of hours of human thought, condensed into a
lean mean game-playing machine.
With all that in mind, it's very likely that the player (who is but
a single human spending a few hours with a game) would be unable to
overcome the condensed intellectual capability of the programatic
opponents, unless it was through some utterly stupid mechanism:
========== cut here ================
> go into the bedroom and go to sleep
You enter into a fitful sleep ...
Suddenly you are awakened by the feeling of cold steel against
your forehead. As you open your eyes, you see the business end
of a nasty-looking pistol, the silencer directly in contact with
your skull.
"Get up and walk slowly to the door", your intruder says, "and
don't try anything stupid, either."
> stand up, walk slowly to the door, pick up the twinkie from
the second shelf of the bookcase and offer it to the intruder.
The man in the ski mask and black bodysuit follows you as you
walk towards the door, the pistol constantly aimed at your
head.
"Twinkie?", you ask, holding the tasty-looking snack cake up
so that the intruder can see it.
"Oh my, I haven't eaten in a long time. Thank you!" he says,
taking the twinkie. He quickly eats the tasty snack.
[ first holstering the pistol ]
[ first taking the twinkie ]
[ first unwraping the twinkie ]
[ first putting the plastic wrapper in his pocket ]
"Mmmmm, that tastes great!" he exclaims.
> punch intruder, trip him, step on his neck and steal his gun.
[ first insulting him ]
...
=========== cut here =============
Happy Hunting,
-Chris
Footnotes:
1) Ok, Ogre (from Steve Jackson Games) is an exception.
Ian Haberkorn
> > How many appliances should there be in my virtual
> > kitchen?
>
> How do any of these appliances advance your story? That's the
> screenwriter's criterion. If it's irrelevant set dressing, you leave it to
> the props dept.
I was planning to do the opposite:
Create a certain, limited setting with a meta goal and code as much
interaction between objects as possible. The beta testers then should
tell me what they'd like to do on top of that.
After improvements I can decide on what will advance the story
(serving the "meta" goal).
I hope it'll work out and won't become a futile shoving around of
things...
Ian
samwyse
> 3) Despite the fact that it's possible, I don't think most players
> would end up taking advantage of the system capabilities. Game
> players in almost any genre want to play the roles of above-average
> actors; that's why you see so many games of various sorts where the
> player is a big powerful thing that is fighting a plethora of small
> weak nasty things; and why you hardly ever see games where the
> player is a plethora of small weak things fighting a big powerful
> nasty thing[1].
[...]
> Footnotes:
>
> 1) Ok, Ogre (from Steve Jackson Games) is an exception.
I have to point out that Ogre, while capable of solitare play, was
designed as a two player game, so the two sides are fairly evenly
matched. The concept of assymmetric sides in a game is under-explored,
probably because ensuring fairness is so hard. Ogre is one of the
better examples of such a game. (For those who haven't encountered it,
one player controls a cybernetic super-tank, the other controls a
plethora of infantry and light-motorized cavalry.)
Orge, like D&D, derives from table-top war games, where each player
controls a number of units. Historical simulations are almost always
asymmetric, but fairness is a less important criteria with them.
Single-player computer games tend to focus on individuals rather than
mobs, IMHO, because of the limited resolution of a computer monitor. A
game played on a table-top can have a large number of small tokens that
are well-dispersed, and the player can still easily view the entire
field of battle. Simulating this form of boundlessness (see, I *am* on
topic!) is difficult on a small monitor.
samwyse
> I was deliberately giving some "extreme" examples of where IF could
> potentially go. Maybe I should tone it down a bit ...
>
> The second example may have been the most realistic:
>
>>Hold the jewel over the cliff and threaten to drop it
>
> Ultimately, do IF authors want the players to be able to enter this kind of
> thing and be understood ? Are there any disadvantages to having this level
> of "understanding" as a goal ? (One potential disadvantage is that if the
> player can say just about anything and be understood, then how do IF authors
> handle the many situations which can then come up - and potentially ruin or
> bypass the careful plot they have planned out ? Is there some way around
> this problem - a different way of authoring that takes a very large number
> of possible player actions into account - or is this unsolvable ?)
Yes, everyone "wants" the player to be able to enter "anything", however
the parsing problem quickly turns into an A.I. research project.
In this case, however, one thing that few posters have noticed is that
the above example *is* fully implementable; Inform would, I think,
interpret it exactly the same as
> HOLD JEWEL OVER CLIFF THEN THREATEN TO DROP IT.
except I'm unsure if the word "and" would be interpreted correctly.
There are still issues with this. First, you'd have to define two new
actions (and a custom token parser, which I call EmbeddedVerb):
Verb 'hold' * held 'over' noun -> HoldOver;
Verb 'threaten' * 'to' EmbeddedVerb noun -> Threaten;
Then, you have to tell the player that these are valid actions. For the
first, you'd probably want a simpler puzzle earlier in the game whose
solution is to hold x over y, maybe HOLD POT OVER FIRE. For the second,
you might have to resort to this:
> HOLD JEWEL OVER CLIFF
Bob begins to sweat visibly. "Please, don't threaten me. Dropping
that jewel would be very bad."
> THREATEN TO DROP IT.
"OK", Bob shouts, "I'll tell you what you want to know!"
Of course, the average player will then want to try holding everything
over everything else in the game, not to mention wanting to threaten
every NPC that they encounter with every possible action. After all, if
you can THREATEN TO DROP JEWEL, then you would expect that you can
THREATEN TO ATTACK BOB, THREATEN TO KISS BOB, THREATEN TO UNLOCK GRATE,
THREATEN TO LOOK IN MAILBOX, THREATEN TO RESTART GAME, etc. This
quickly gives rise to a combinatorial explosion.
Ian Haberkorn
> but the
> player has a hard time finding it. I couldn't really come up with a concise
> way of
> saying that there is no solution. Well, except, "there is no solution".
I guess the first term is "stuck":
http://www.ifwiki.org/index.php/List_of_things_that_may_get_a_player_stuck
Maybe someone can add the term to the glossary - I couldn't find out how...
The second seems to be "Unwinnable": http://www.ifwiki.org/index.php/Unwinnable
Ian
Matthew Russotto
Brandon J. Van Every <try_vanevery_a...@yahoo.com> wrote:
>is full of devices. People in the IF world often come from a programming /
>engineering / simulationist background; they assume the primacy of
>statements like "You are you."
And you wonder why people accuse you of being a troll.
--
There's no such thing as a free lunch, but certain accounting practices can
result in a fully-depreciated one.
samwyse
drove to work, and as I have an hour or so to kill while Office 2003
gets installed, I decided to share with you all. Unfortunately, I
don't really have the time to play with the idea inside an actual game.
Mathematics classifies functions according to their valence, or how
many arguments they take. Niladic functions take no arguments, monadic
take one, and dyadic take two. In I-F, these ideas translate to
commands with zero, one or two objects: LOOK, TAKE BOTTLE, UNLOCK
GRATE WITH KEY. Interestingly enough, that's all that you need:
functions with more arguments can be decomposed into a series of dyadic
functions. For example, the fictious command MOVE THE KNIFE FROM THE
TABLE TO THE SACK can be decomposed into TAKE THE KNIFE FROM THE TABLE
THEN DROP THE KNIFE INTO THE SACK.
Mathematics also recognizes things called operators, which take a
function and return a new function. Interactive fiction already has
one example of this, TELL BOB TO OPEN THE DOOR. Normally, OPEN DOOR
would apply to the PC, but the TELL-TO operator causes it to apply to
an NPC instead.
In the command THREATEN TO DROP THE JEWEL, the words THREATEN TO needs
to be an operator that modifies the DROP action. To mix up some Inform
and TADS, THREATEN-TO needs to verify that an action can be done ("But
you aren't holding the jewel!"), but not actually do it. (Note that in
Inform, verification is mostly done by the parser, while in TADS there
is an explicit 'verify' phase, which means that implementing THREATEN
TO might be easier to do in TADS.) After verification, you do still
want NPCs to react it the threat. In Inform terms, that means doing
these steps (DM4, p. 93):
(1a) The GamePreRoutine is called, if you have written one. If it
returns true, nothing else happens and the action is stopped.
(1b) The orders property of the player is called on the same terms.
(1c) And the react_before of every *animate* object in scope.
(1d) If the action hasn't been stopped yet, print "Nobody cares."
Step 1b stays in because a threat isn't credible if the PC is
restricted from performing the action. Step 1c covers the example from
page 137 of DM4, since just threatening to shot Blofeld should also
result in the loss of your beretta. OTOH, an examination of every
react_before in DM4 indicates that only animate objects should have the
chance to react to threats.
Modifying my earlier example, the NPC Bob would need these methods to
respond to HOLD JEWEL OVER CLIFF THEN THREATEN TO DROP IT:
react_before [;
Drop:
if (noun.held_over == cliff) {
if (noun == jewel) {
self.mood = cooperative;
"~OK~, Bob shouts, ~I'll tell you what you want to know!~";
};
"~Go ahead and drop it,~ Bob says, ~I don't care about that.~";
};
],
react_after [;
if (noun == jewel && noun.held_over == cliff) {
self.mood = angry;
"Bob stares at you. ~Oh, you shouldn't have done that!~";
};
],
As I said, I don't have the time to do much more with this. If anyone
else finds this idea interesting, go ahead and run with it.
Jan Thorsby
"samwyse" <sam...@gmail.com> skrev i melding
news:1109870161.7...@f14g2000cwb.googlegroups.com...
> about threaten command
If one is going to implement such complex conversation, some other ideas
comes to mind. One could have a "promise" command. Or one could have
conversations in this format:
[The person one is talking to], if [the condition for something happening]
then [what is going to happen]
Examples:
informant, if informant tell me about murder then I give informant dollar
bob, if bob push button then bomb explodes
fred, if fred kill me then lisa kill lisa
One could make it even more complex by adding "don't"
Examples:
lady, if lady don't give me lady's wallet then i kill lady
lisa, if lisa kiss fred then I don't marry lisa
boy, if boy don't clean mess then i don't give dinner to boy
A much easier idea would be "threathen NPC with object"
example: threathen man with gun
Homestar
>recognise"'s (which also discourage the untrained IF-newbie), that we
>restrict our thinking to common actions. As a result, "Threaten to
>drop jewel" sounds to me like a classic guess-the-verb annoyance,
>though logical in a movie or novel plot.
I think you could get around that problem, if you set the situation up
cleverly enough. You could have a simpler puzzle earlier on that
introduces the verb to the player (though I can't think of what that
puzzle might be off hand.) Otherwise, the game could suggest to the
player to simply threaten the NPC. If I had been advised that a certain
NPC was vulnerable to threats, on meeting him I might well try THREATEN
HIM. The parser could reply 'You must threaten to do something,' or
(more ambitiously) 'What do you want to threaten to do?'
> (See a former discussion of "Should there be toilets in
> IF?"*)
Five words for you--Planet of the Infinte Minds.
Home*
David Alex Lamb
>> the other
>> is when there simply IS no solution - you've managed to destroy the
>> only key to the door you have to go through, etc.
>
>I nominate "a deadlock."
In CS "deadlock" has the specific meaning of a situation where a possible
opereation is blocked waiting for some other to complete, while the second is
also blocked waiting for the first.
I'm having trouble thinking of a better word. "Dead" certainly fits; there is
literature on proving "liveness" in concurrent systems, meaning that progress
can still be made. One typically has to take a transitive closure over some
graph representing the operations that lead to a solution -- or at least a
shortest path check in a similar graph. Recently there is a lot of work on
"model checking" of enormous graphs in reasonable time.
An author might be able to construct such a graph to find if there are any
"dead" states, with tool support for editing and checking the graph. I
strongly doubt it could be deduced from the IF code.
--
"Yo' ideas need to be thinked befo' they are say'd" - Ian Lamb, age 3.5
http://www.cs.queensu.ca/~dalamb/ qucis->cs to reply (it's a long story...)
David Alex Lamb
Ian Haberkorn <haber...@yahoo.com> wrote:
>Fredrik Petersson <use...@pesononline.com> wrote in message news:<40806324541...@news.chello.se>...
>> I'll propose that "stuck" should mean the first version: there is a solution,
>> but the
>> player has a hard time finding it. I couldn't really come up with a concise
>> way of
>> saying that there is no solution. Well, except, "there is no solution".
>
>I guess the first term is "stuck":
>
>http://www.ifwiki.org/index.php/List_of_things_that_may_get_a_player_stuck
I don't think that's right -- the player is usually "stuck" because s/he
hasn't thought of some action s/he could take to advance the game, rather than
that no such actions exist.
>Maybe someone can add the term to the glossary - I couldn't find out how...
>
>The second seems to be "Unwinnable": http://www.ifwiki.org/index.php/Unwinnable
This sounds better to me.
David Alex Lamb
>whatever we wanted! The problem is, it's so much work. The farther an
>action is from advancing the score, the less we are likely to
>implement it. (See a former discussion of "Should there be toilets in
>IF?"*)
I can imagine wanting to do so. The player finds toilets in most of the
buildings, but none in the wizard's tower. The wizard is really an undead
lich, who needs no toilets and saw no reason to build any.
Michael Roy
> In the command THREATEN TO DROP THE JEWEL, the words THREATEN TO needs
> to be an operator that modifies the DROP action.
This looks like a clever way of handling it to me, but wouldn't it
require the modification of every single verb in the library to check
whether it's been called in threaten mode? Or is there a clever way out
with a global verb routine?
> Step 1b stays in because a threat isn't credible if the PC is
> restricted from performing the action.
But a PC could still conceivably make an incredible threat.
> Modifying my earlier example, the NPC Bob would need these methods to
> respond to HOLD JEWEL OVER CLIFF THEN THREATEN TO DROP IT:
>
> react_before [;
> Drop:
> if (noun.held_over == cliff) {
> if (noun == jewel) {
> self.mood = cooperative;
> "~OK~, Bob shouts, ~I'll tell you what you want to know!~";
> };
> "~Go ahead and drop it,~ Bob says, ~I don't care about that.~";
> };
> ],
What if someone else in scope does care? The fact that Bob doesn't
shouldn't stop the action. Also, wouldn't HOLD JEWEL OVER CLIFF AND
THREATEN TO DROP IT and HOLD JEWEL OVER CLIFF AND DROP IT have the same
response from that?
Michael
Rikard Peterson
> informant, if informant tell me about murder then I give informant
> dollar
> bob, if bob push button then bomb explodes
> fred, if fred kill me then lisa kill lisa
If you implement that, I absolutely think you should implement "you":
informant, if you tell me about (the) murder then I give you (a) dollar
bob, if you push (the) button then (the) bomb explodes
fred, if you kill me then lisa kill(s) herself
This feels natural enough that I think it could work. The big question
then is how to educate a player to work with it. I think a "normal" IF-
player could learn it if you give some clues (or maybe describing this
syntax in the ABOUT-text or similar would be the wise thing to do) but
I wonder what a newbie would think.
I think it's an interesting alternative or complement to ask/tell
conversations, and I'd like to see it tried in a game.
Rikard
peson
stuck - there is a solution but the player has a hard time finding it
deadlocked - a particular puzzle is unsolvable, typically because an
object or location has become unreachable.
unwinnable - the game as a whole has become deadlocked, because a puzzle
that has to be solved to get to the winning end has become deadlocked.
/ peson
Brandon J. Van Every
>
> An author might be able to construct such a graph to find if there
> are any "dead" states, with tool support for editing and checking the
> graph. I strongly doubt it could be deduced from the IF code.
One could simply say the player is "dead." Inability to proceed has always
been a good proxy for death in MUDs, when you don't actually have the
administrative priveledges to kill somebody. I suppose "Purgatory" is more
colorful, however. Doomed to wander forever!
Brandon J. Van Every
I like it!
Brandon J. Van Every
Unless your "certain, limited setting with a meta goal" is a lot more
specific and developed than you're letting on here...
...from a storyteller's standpoint, you are doomed to a futile shoving
around of things. You don't know what your story is, why anything is going
to happen, or how the audience's attention is to be maintained. In fact
you're leaving it up to your beta testers to write your story for you. What
you're doing is the classical Engineering approach to creative content. You
are simulating it, rather than facing the difficult task of what your story
is about, why anyone is supposed to care, and what techniques you're going
to use to get people to care.
Of course, feel free to discover these things as you flounder along. If I
am around here by the time you finish your game, I'll say I Told You So.
A middle road that would save you a lot of grief, would be to forget about
all that coding stuff at the outset. Sit down with pencil and paper and
storyboard some things. Forget about object interaction, beta testers, and
that sort of concern. That's programmer stuff.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
Brandon J. Van Every
>
> Of course, the average player will then want to try holding everything
> over everything else in the game, not to mention wanting to threaten
> every NPC that they encounter with every possible action.
Well, the latter could be hillarious. Good idea if you feel like completing
those branches. One dilemma is how you're going to get players to think of
using the abstract verb 'THREATEN'. If they never use it, all your hard
work is potentially for nothing. It could be 'Easter Egg' work, but it's
probably better to have people acutally access what you write, especially
since this is a recurring problem for all sorts of verbs.
In fact, as a conceptual piece, one might devise a work with an extremely
limited command set. The 1st scenes might explain / train the user that the
command set is terribly limited, but not actually reveal what all the
commands are. The game would be about every possible interpretation of the
same 20-odd commands.
Hmm, that dovetails rather nicely with my stupid title entry,
"A Day Spent Walkthroughing"
Brandon J. Van Every
> In article <38n2g8F...@individual.net>,
> Brandon J. Van Every <try_vanevery_a...@yahoo.com> wrote:
>
>> is full of devices. People in the IF world often come from a
>> programming / engineering / simulationist background; they assume
>> the primacy of statements like "You are you."
>
> And you wonder why people accuse you of being a troll.
Gee, and I didn't even use my preferred nasty word, 'Enginerd' ! I guess
qualifiers like 'often', as in, "this doesn't have to apply to anyone in
particular or you personally," are lost upon a certain percentage of people.
A knowable percentage, unfortunately; I might have anticipated the umbrance.
I will stand my ground, however, and amplify: the problem with such people
is they know how to program, not how to write. Anybody who can't tell that
from looking at archives of IF work... is one of the people who doesn't know
how to write.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
Brandon's Law (after Godwin's Law):
"As a Usenet discussion grows longer, the probability of
a person being called a troll approaches one RAPIDLY."
[but honestly this one is too short]
Brandon J. Van Every
> In article <fa8b3c27.05030...@posting.google.com>,
> Ian Haberkorn <haber...@yahoo.com> wrote:
>> As programmers, we are really pretty boundless - we could implement
>> whatever we wanted! The problem is, it's so much work. The farther an
>> action is from advancing the score, the less we are likely to
>> implement it. (See a former discussion of "Should there be toilets in
>> IF?"*)
>
> I can imagine wanting to do so. The player finds toilets in most of
> the buildings, but none in the wizard's tower. The wizard is really
> an undead lich, who needs no toilets and saw no reason to build any.
Assuming, of course, that this is some key plot point that makes the player
go "Aha!" Or that there's a gigantic slew of such consistent clues afoot,
and any one of them might tip the careful viewer off, but the casual viewer
might leave them all unnoticed. This is the "Fight Club" approach.
It would be poor form to have this great "Toiletless Lich" simulation if
that information was not clearly communicated to the player somehow. In IF,
it is not enough for things to happen. Things must happen in a way that the
player can perceive, so that causality is demonstrated. Otherwise it's
random, and randomness is frustrating. In film this is typically described
as "setting up scenes" and "paying them off."
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
samwyse
> Jan Thorsby wrote in news:42275454$1...@news.broadpark.no:
>
>>informant, if informant tell me about murder then I give informant
>>dollar
>>bob, if bob push button then bomb explodes
>>fred, if fred kill me then lisa kill lisa
>
> If you implement that, I absolutely think you should implement "you":
>
> informant, if you tell me about (the) murder then I give you (a) dollar
> bob, if you push (the) button then (the) bomb explodes
> fred, if you kill me then lisa kill(s) herself
>
> This feels natural enough that I think it could work. The big question
> then is how to educate a player to work with it. I think a "normal" IF-
> player could learn it if you give some clues (or maybe describing this
> syntax in the ABOUT-text or similar would be the wise thing to do) but
> I wonder what a newbie would think.
Actually, I suspect that this would be much more complicated than my
idea, simply because, again, people will try *everything*. Also, the
first effect can be accomlished using just dyadic actions. Each action
would either set flags inside the NPC object or, if all of the flags
were set, execute the combined action:
> ASK INFORMANT ABOUT THE MURDER
"Listen up," you say, "I don't have much time to waste. Tell me
everything you know about Ann's death."
"What's it worth to you?"
>GIVE HER 20 DOLLARS
You pass $20 to the woman, who swiftly hides it inside her blouse.
"You need to talk to Bob. He was visiting her every night while her
husband was at the club."
--- or ---
>GIVE INFORMANT 20 DOLLARS
You pass $20 to the woman, who swiftly hides it inside her blouse.
"So, what do you want to know?" she asks.
> ASK HER ABOUT THE MURDER
"Listen up," you say, "I don't have much time to waste. Tell me
everything you know about Ann's death."
"You need to talk to Bob. He was visiting her every night while her
husband was at the club."
samwyse
> samwyse wrote:
>
> > In the command THREATEN TO DROP THE JEWEL, the words THREATEN TO needs
> > to be an operator that modifies the DROP action.
>
> This looks like a clever way of handling it to me, but wouldn't it
> require the modification of every single verb in the library to check
> whether it's been called in threaten mode? Or is there a clever way out
> with a global verb routine?
My hope is that little modification would need to be made. I looked at
every instance of react_before in DM4, and my idea would allow them all
to continue to function in a credible manner without any changes. The
library has a routine that runs all applicable 'react_before' and
'before' routines, runs the action, and then runs all the 'after' and
'react_after' routines. For a threat, just the 'react_before' routines
would be run, and that would be it. Blofeld (page 137) would snatch the
beretta even if you only threatened to shoot him, while the psychiatrist
(exercise 26, page 448) would only comment on threats to take things,
not threats to put things down or look around.
>> Step 1b stays in because a threat isn't credible if the PC is
>> restricted from performing the action.
>
> But a PC could still conceivably make an incredible threat.
:-)
You could always check in the player's orders routine if a threat is
being issued.
>> Modifying my earlier example, the NPC Bob would need these methods to
>> respond to HOLD JEWEL OVER CLIFF THEN THREATEN TO DROP IT:
>>
>> react_before [;
[...]
>
> What if someone else in scope does care? The fact that Bob doesn't
> shouldn't stop the action. Also, wouldn't HOLD JEWEL OVER CLIFF AND
> THREATEN TO DROP IT and HOLD JEWEL OVER CLIFF AND DROP IT have the same
> response from that?
First, I just noticed a mistake in my code:
react_before [;
Drop:
if (noun.held_over == cliff) {
if (noun == jewel) {
self.mood = cooperative;
print "~OK~, Bob shouts, ~I'll tell you what you
want to know!~";
rfalse;
};
print "~Go ahead and drop it,~ Bob says, ~I don't
care about that.~";
rfalse;
};
],
react_after [;
if (noun == jewel && noun.held_over == cliff) {
self.mood = angry;
print "Bob stares at you. ~Oh, you shouldn't have
done that!~";
rfalse;
};
],
Given that change, then my intent is that THREATEN would do this:
> THREATEN TO DROP JEWEL
"OK", Bob shouts, "I'll tell you what you want to know!"
while actually dropping the jewel would do this:
> DROP JEWEL
"OK", Bob shouts, "I'll tell you what you want to know!"
The jewel disappears into the void.
Bob stares at you. "Oh, you shouldn't have done that!"
Note that Bob's mood changes once in the first example, but twice in the
second. Needless to say, Bob's responses to the player change according
to his mood, and we presumably want him to be cooperative.
David Fisher
> How far should IF authors go in creating a sense of "boundlessness"
> in their games ?
Whew .... thanks for all of the responses ! [ One hour later ... ]
This is a very thoughtful news group, which I appreciate very much ...
Some replies to individual posts coming soon.
David Fisher
David Fisher
>> How far should IF authors go in creating a sense of "boundlessness"
>> in their games?
Steve replied:
> Boundlessness of any flavor is probably not a goal in itself -- not in
> IF anyway: IF relies on simulation, but demands narrative. Interesting
> narrative is orthogonal to "boundlessness" (that is, the two concerns
> appear to be mutually independent).
>
> An interesting narrative will emerge from a perfect simulation with
> about the same frequency that an interesting narrative emerges from
> "real life." You could imagine a "gamemaster AI" or "drama manager"
> that can handle all the "unbounded" actions of the player, and tie
> everything back into the narrative, but at this point, we're talking
> about boundlessness as running *against* the narrative, and something
> to be recuperated -- which suggests boundlessness is a problem for IF
> rather than a goal.
>
> There's much more to say on the subject,
I'd love to hear more ... (I'm still not sure why you are saying simulation
is in conflict with narrative - I can imagine a few reasons, eg. the
difficulty of keeping the narrative on track when the player decides to go
and do something at variance with the intended plot, but I want to
understand what your thoughts are on this issue).
BTW. Simulating the universe to the point of having to explicitly tie your
shoe laces, etc. would obviously get boring, but that wouldn't really be the
idea - not getting bogged down in the details of mimicking reality, but more
being able to "do anything" that the player would expect to be able to do in
the world you have created. The "gamemaster AI" that you mentioned is close
to what I have been talking about & imagining ...
> but instead, I'll address in
> particular what I think are your two primary notions of boundlessness:
>
>> (1) Realistic conversations
>>
>> > Say "How would you like to earn a some gold, Fred?"
>
> You can make some progress towards this with currently available
> "natural language understanding" (NLU) technology, though nothing like
> this is yet available in any IF authoring system. I think NLU would be
> cool for conversation, but not for parsing (see below). -- Cool for
> conversation, but problematic, in that this may imply a need for a
> highly sophisticated "natural language generation" system.
>> (2) Accepting detailed commands
>
[snip]
>
> The upshot: this is a terrible idea in that it would produce
> guess-the-adjective puzzles. (Guess-the-verb is already bad enough.)
New thread on the range of available player commands coming soon to a
newsgroup near you ...
David Fisher
David Fisher
>> I was deliberately giving some "extreme" examples of where IF could
>> potentially go. Maybe I should tone it down a bit ...
>>
>> The second example may have been the most realistic:
>>
>>>Hold the jewel over the cliff and threaten to drop it
Samwyse replied (on March 3rd 2005, 11:08 PM):
> Of course, the average player will then want to try holding everything
> over everything else in the game, not to mention wanting to threaten every
> NPC that they encounter with every possible action. After all, if you can
> THREATEN TO DROP JEWEL, then you would expect that you
> can THREATEN TO ATTACK BOB, THREATEN TO KISS BOB,
> THREATEN TO UNLOCK GRATE, THREATEN TO LOOK IN
> MAILBOX, THREATEN TO RESTART GAME, etc. This quickly
> gives rise to a combinatorial explosion.
I like the idea of threatening the game itself ... how about:
THREATEN TO UNPLUG COMPUTER
or
PROMISE TO GET A NEW MOTHER BOARD
:-)
David Fisher
Ian Haberkorn
> Unless your "certain, limited setting with a meta goal" is a lot more
> specific and developed than you're letting on here...
It certainly is.
> A middle road that would save you a lot of grief, would be to forget about
> all that coding stuff at the outset. Sit down with pencil and paper and
> storyboard some things. Forget about object interaction, beta testers, and
> that sort of concern. That's programmer stuff.
Very respected posters on this forum (e.g. Emily Short, Andrew
Plotkin) have some way or another questioned and broken IF conventions
to advance the genre. They encouraged others to do the same, the
attitude being "even if you fail, we'll have learned something".
So I am trying to make a game that is different in some respects. It
is deliberately not the storyboard way, knowing it might fail (as I
said: "futile shoving around"). Being a beginner with limited spare
time will certainly not reduce this risk.
> Of course, feel free to discover these things as you flounder along. If I
> am around here by the time you finish your game, I'll say I Told You So.
Surely I was hoping for another form of encouragement, maybe along the
lines of "Good luck, maybe sth interesting will result".
Finally, the respected posters above mentioned that ideas and posts
should be supplemented by working examples. So I'll go back to my
Inform compiler now.
Ian
Jan Thorsby
"Jan Thorsby" <no_jthor...@broadpark.no> skrev i melding
news:42275454$1...@news.broadpark.no...
> If one is going to implement such complex conversation, some other ideas
> comes to mind.
One more idea, instead of threats maybe just a way of telling what has
happened or what is going to happen: [NPC one is talking to], [Object]
[Action] [Optional object]
policeman, fred killed lisa
policeman, fred will kill lisa
bob, lisa died
superman, bomb will explode
But off course "tell superman about bomb" would be much easier to code.
Brandon J. Van Every
> "Brandon J. Van Every" <try_vanevery_a...@yahoo.com>
> wrote in message news:<38pkdlF...@individual.net>...
>
>> Unless your "certain, limited setting with a meta goal" is a lot more
>> specific and developed than you're letting on here...
>
> It certainly is.
>
>> A middle road that would save you a lot of grief, would be to forget
>> about
>> all that coding stuff at the outset. Sit down with pencil and paper
>> and
>> storyboard some things. Forget about object interaction, beta
>> testers, and
>> that sort of concern. That's programmer stuff.
>
> Very respected posters on this forum (e.g. Emily Short, Andrew
> Plotkin) have some way or another questioned and broken IF conventions
> to advance the genre. They encouraged others to do the same, the
> attitude being "even if you fail, we'll have learned something".
>
> So I am trying to make a game that is different in some respects. It
> is deliberately not the storyboard way, knowing it might fail (as I
> said: "futile shoving around"). Being a beginner with limited spare
> time will certainly not reduce this risk.
You say you're a 'beginner'. I'm not sure if you're a beginner at IF or a
beginner at writing. I suspect both. Your original dilemma was about how
many appliances to include in your kitchen, which sounds like a beginning
writer's concern. A more experienced writer would be well past that: the
answer is always "the number that best supports your story." Because you
sound like you're a beginning writer, I'm taking the tone that I do. If you
are actually an intermediate or advanced writer, and merely muddled about
the newfangled IF concerns or what it means to be "avant garde," then I
apologize for patronizing you.
What's your honest assessment of your writing skills? The people you
mention are very good writers, lotsa experience. Being experienced in the
basics of craft and trying something avant garde, is rather different from
being a beginner and trying something avant garde. Without mastery of some
basics, the beginner is going to fail. There's nothing inherently wrong
with failure: we all need to make our first 5,000 mistakes. But it's much
faster to pick up a book on the basics of craft - plot, pace, character,
dialogue, setup, payoff, etc. - and learn something about the received
wisdom of the ages. Otherwise one ends up spending several years
reinventing the wheel. Assuming one is clever enough to do so; an
astounding number of people have no idea how bad their writing is.
>> Of course, feel free to discover these things as you flounder along.
>> If I
>> am around here by the time you finish your game, I'll say I Told You
>> So.
>
> Surely I was hoping for another form of encouragement, maybe along the
> lines of "Good luck, maybe sth interesting will result".
I'd rather save you some time and not pump sunshine up your skirt. If I've
guessed your level of experience correctly, please, go get a book on how to
write. My own library of such books is tiny so I'm not going to recommend
anything in particular. A few books, a lot of writing, a lot of critical
reading, and some talking to more experienced writers. Pretty much that's
the drill. Writing isn't rocket science, but it is a craft and a lot of
people don't know the basics.
> Finally, the respected posters above mentioned that ideas and posts
> should be supplemented by working examples. So I'll go back to my
> Inform compiler now.
Well, IF in the sense of Inform is a task and a goal in and of itself.
There are other forms. I prefer the ones that have close to zero technical
overhead and are almost pure writing.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
On Usenet, if you're not an open source hippie who
likes to download and play with programming toys
all day long, there's something wrong with you.
Brandon J. Van Every
>
> superman, bomb will explode
>
> But off course "tell superman about bomb" would be much easier to
> code.
Not really.
superman, bomb
Doesn't matter what comes afterwards.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"The pioneer is the one with the arrows in his back."
- anonymous entrepreneur
samwyse
> Very respected posters on this forum (e.g. Emily Short, Andrew
> Plotkin) have some way or another questioned and broken IF conventions
> to advance the genre. They encouraged others to do the same, the
> attitude being "even if you fail, we'll have learned something".
>
> So I am trying to make a game that is different in some respects. It
> is deliberately not the storyboard way, knowing it might fail (as I
> said: "futile shoving around"). Being a beginner with limited spare
> time will certainly not reduce this risk.
Brandon's reply covers a lot of good ground, so I'm just going to focus
on this statement. USE A STORYBOARD! Of course, it may not be called a
storyboard, you can also call it a transcript or plot diagram or
something else. Humans have been telling each other stories for a very
long time. We can quickly tell what works for us and what doesn't.
Storyboards and transcripts are ways for the author to tell if something
is going to work *before* they get six months into coding.
That said, I'm also going to urge you to continue down your current
path. Everyone learned to write by writing, and everyone learns to code
by coding. Everyone's early stories are meant to be written and
discarded. (Few people would be interested in reading Stephen King's
fifth grade essays. Maybe one or two, but certainly not all of them.)
I say this because I-F authors are generally adults who learned writing
as children and have forgotten that their early stuff was pretty
unreadable. As adults, they can write stuff that is readable, but they
have just started coding, so the same stuff is very likely to be unplayable.
In I-F, your first "essays" are likely to classified as collegiate,
slice-of-life, or travel (see http://www.wurb.com/if/genre for
definitions). These genres are well-suited for implementing lots of
objects and/or places with no idea of how they fit together to form a
story. OTOH, I'm not sure how many of these games really need to be
preserved in the archive. My first story tells about my trip to Russia
a while back. It's about 80% done and may never be finished, in part
because even I have a hard time playing parts of it. Even if it ever
gets finished, I'm not sure that I'll ever want to put it in the
archive. But writing it gave me the tools I needed to write and
complete my second story, which won the C32 comp.
M. Damian Dollahite
> I'll propose that "stuck" should mean the first version: there is a
> solution, but the
> player has a hard time finding it. I couldn't really come up with a
> concise way of
> saying that there is no solution. Well, except, "there is no solution".
>
The term I've typically seen used for the latter is "walking dead" --
meaning you can still wander around, but no progress can be made, and
therefore you have effectively lost the game -- ie "died" -- and just
don't know it. However that term isn't very professional sounding, so I
don't recommend using it as an official term.
David Alex Lamb
Brandon J. Van Every <try_vanevery_a...@yahoo.com> wrote:
>David Alex Lamb wrote:
>> In article <fa8b3c27.05030...@posting.google.com>,
>> Ian Haberkorn <haber...@yahoo.com> wrote:
>>
>> I can imagine wanting to do so. The player finds toilets in most of
>> the buildings, but none in the wizard's tower. The wizard is really
>> an undead lich, who needs no toilets and saw no reason to build any.
>
>Assuming, of course, that this is some key plot point that makes the player
>go "Aha!" Or that there's a gigantic slew of such consistent clues afoot,
>and any one of them might tip the careful viewer off, but the casual viewer
>might leave them all unnoticed. This is the "Fight Club" approach.
>
>It would be poor form to have this great "Toiletless Lich" simulation if
>that information was not clearly communicated to the player somehow. In IF,
>it is not enough for things to happen. Things must happen in a way that the
>player can perceive, so that causality is demonstrated. Otherwise it's
>random, and randomness is frustrating. In film this is typically described
>as "setting up scenes" and "paying them off."
It isn't usual for IF to have toilets AFAIK. If the game is set up with
several different buildings, all of which have toilets, and if it is possible
to search the wizard's tower without being blocked (at least requires lich to
be absent), it might leap out at some people (but not others, I admit).
Multiplel clues would be a good idea, but I am amused by the idea of the
missing toilets being the kicker.
Matthew Russotto
David Alex Lamb <dal...@qucis.queensu.ca> wrote:
>In article <38n91jF...@individual.net>,
>Brandon J. Van Every <try_vanevery_a...@yahoo.com> wrote:
>>Fredrik Petersson wrote:
>>> the other
>>> is when there simply IS no solution - you've managed to destroy the
>>> only key to the door you have to go through, etc.
>>
>>I nominate "a deadlock."
>
>In CS "deadlock" has the specific meaning of a situation where a possible
>opereation is blocked waiting for some other to complete, while the second is
>also blocked waiting for the first.
>
>I'm having trouble thinking of a better word. "Dead" certainly fits; there is
>literature on proving "liveness" in concurrent systems, meaning that progress
>can still be made.
"Dead" is technically correct (in that the game, modeled as a finite
state machine, has reached a "dead state"), but certainly confusing as
the player character isn't necessarily dead.
--
There's no such thing as a free lunch, but certain accounting practices can
result in a fully-depreciated one.
Matthew Russotto
Brandon J. Van Every <try_vanevery_a...@yahoo.com> wrote:
>Matthew Russotto wrote:
>> In article <38n2g8F...@individual.net>,
>> Brandon J. Van Every <try_vanevery_a...@yahoo.com> wrote:
>>
>>> is full of devices. People in the IF world often come from a
>>> programming / engineering / simulationist background; they assume
>>> the primacy of statements like "You are you."
>>
>> And you wonder why people accuse you of being a troll.
>
>Gee, and I didn't even use my preferred nasty word, 'Enginerd' ! I guess
>qualifiers like 'often', as in, "this doesn't have to apply to anyone in
>particular or you personally," are lost upon a certain percentage of people.
They're not lost. However, they often lack a certain sincerity when combined
with a pejorative generalization; they appear to be inserted solely to
provide the author an "out" when someone takes offense.
>I will stand my ground, however, and amplify: the problem with such people
>is they know how to program, not how to write. Anybody who can't tell that
>from looking at archives of IF work... is one of the people who doesn't know
>how to write.
A look at archives of IF work is much like a look at a publisher's
slush pile. You'll find a lot of work containing bad writing. In IF
work, you'll find bad programming too.
Brandon J. Van Every
>
> It isn't usual for IF to have toilets AFAIK. If the game is set up
> with several different buildings, all of which have toilets, and if
> it is possible to search the wizard's tower without being blocked (at
> least requires lich to be absent), it might leap out at some people
> (but not others, I admit).
>
> Multiplel clues would be a good idea, but I am amused by the idea of
> the missing toilets being the kicker.
If I cared about toilets as a story device, I'd be inclined towards
hyperbole. Toilets line the halls. Toilets on the ceilings. Toilets at
the dinner table. The Lich is the one and only being who doesn't approve of
widespread toilets.
'High concept' vs. 'low concept' is a difference in focus.
Brandon J. Van Every
> In article <38pld8F...@individual.net>,
> Brandon J. Van Every <try_vanevery_a...@yahoo.com> wrote:
>>
>> Gee, and I didn't even use my preferred nasty word, 'Enginerd' ! I
>> guess qualifiers like 'often', as in, "this doesn't have to apply to
>> anyone in particular or you personally," are lost upon a certain
>> percentage of people.
>
> They're not lost. However, they often lack a certain sincerity when
> combined with a pejorative generalization; they appear to be inserted
> solely to provide the author an "out" when someone takes offense.
I had no intention of apologizing to people whose writing sucks. I mark
people for a reason.
> A look at archives of IF work is much like a look at a publisher's
> slush pile. You'll find a lot of work containing bad writing. In IF
> work, you'll find bad programming too.
That would be the reason.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
crappy software with total shit for tools and process."
- Ed McKenzie
Brandon J. Van Every
>
> That said, I'm also going to urge you to continue down your current
> path. Everyone learned to write by writing, and everyone learns to
> code by coding. Everyone's early stories are meant to be written
> and discarded.
To be sure, learning to write, and learning to code, are distinct goals.
The overlap is tenuous, and the problem is hardly unique to IF. Any game
has the tension of whether to pursue the creative limit, or the technical
limit. Most games are written by programmers who pursue the latter, and
fail at the former.
My advice is, if you already know how to program, don't set "learning how to
program IF" as your goal. There is no rocket science in IF programming, it
is still programming. Instead, learn how to write. Learn what you're weak
at.
On the other hand, if you don't know how to program terribly well, and want
to improve at it, by all means use IF as your excuse.
Keep tucked in the back of your mind, however, that you really don't have to
do IF with command parsers, TADS, Inform, and the like. A hypertext is a
perfectly valid IF medium. Programming is not required; IF-by-parser is a
particular medium with particular creative possibilities and limits. The
limits of writing itself are more fundamental than any IF-by-parser limit
you will encounter.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
Taking risk where others will not.
Brandon J. Van Every
Chris Pickett
> OK, here are the definitions I'm voting for:
>
> stuck - there is a solution but the player has a hard time finding it
common usage, i think that's fine.
> deadlocked - a particular puzzle is unsolvable, typically because an
> object or location has become unreachable.
deadlock really only applies to concurrent systems, i don't think it's
appropriate for single-player IF -- especially since you might want to
introduce multiplayer IF in the future. you could get into a
deadlocked state with NPC's i suppose ... i guess in short i think
it's better to reserve that word for situations that really deserve
it.
i do like "unsolvable puzzle" and "unreachable solution" though.
> unwinnable - the game as a whole has become deadlocked, because a puzzle
> that has to be solved to get to the winning end has become deadlocked.
sure -- or in terms of reachability, the (desired) end of the game is
unreachable because one or more puzzles upon which the end depends
have become unsolvable.
i think it's also neat to think of a game as one big puzzle composed
of many smaller puzzles, which may each in turn be composed of smaller
puzzles. this kind of hierarchical structure should help with
verification -- of course it's not usually ever the case that all
puzzles are independent of each other so there's some subtlety in
there that needs to be worked out.
cheers,
chris
samwyse
that's a bit annoying. I coded up a simple NPC:
react_before [;
print "^Bob asks, ~Are you sure you want to do that?~^";
rfalse;
],
react_after [;
print "^Bob says, ~I guess so.~^";
rfalse;
],
Sometime, the result is good:
> LOOK
Bob asks, "Are you sure you want to do that?"
The Kitchen
This is just a kitchen.
Bob says, "I guess so."
With other verbs, though, you get this:
> TAKE KNIFE
Bob asks, "Are you sure you want to do that?"
Bob says, "I guess so."
Taken.
I'd hoped that the "Taken." message would also be printed between the
two messages from Bob. I think I see where the issue is in the code for
BeforeRoutines and AfterRoutines in the parser. I also think I see a
work-around, but it will likely mean a new property for NPCs that works
like react_after, but runs even later, maybe in GamePostRoutine.
Michael Roy
meddle_late_late() does this in Platypus. For all the complaints about
it having too many action properties, there's almost always one there
that does exactly what you need (if only the rest of it weren't so buggy).
I'd also worked around something similar to this a while back using
linked lists of messages to display at the end of the turn, but that's
probably more complication than is required for a purpose such as this.
Michael
David Fisher
> How far should IF authors go in creating a sense of "boundlessness" in
> their games ? Here are a few (extreme) possibilities:
I found a good quote in
http://grandtextauto.gatech.edu/2003/05/12/how-to-destroy-possibilities ...
"I believe it would be difficult to conceive of, let alone implement an
"unconstrained" interactive experience (or any other form of artistic
expression). While constructive games like SimCity are extremely open-ended
and generative in nature, there is a very specific and limited set of tools
at the interactor's disposal and it is the nature of these tools and the
interface in which these tools are used that defines the interactor's
experience. The same holds true for GTA3, Facade or any other video game,
IF, board game, etc. What makes these games seem "limitless" is that they
are "complete" - in other words, the typical interactor's expectations of
agency are satisfied by the set of choices available to them *within the
context of the experience*."
- (written by Athomas Goldberg)
What I'm trying to figure out is what "the typical interactor's
expectations" are ... they seem to be quite a bit higher than what is
available most of the time.
David Fisher
M. Damian Dollahite
> What I'm trying to figure out is what "the typical interactor's
> expectations" are ... they seem to be quite a bit higher than what is
> available most of the time.
>
> David Fisher
>
>
The problem is that when you give a person a naked prompt and tell them
to type anything they want in natural language, you set their
expectations so high that it's not humanly possible to live up to them.
Graphical adventure games typically have maybe 5 hotspots per room and
no more than 10 verb icons, meaning there are less than 50 possible
actions per room. SimCity has many more icons, but they do the same
thing no matter where you use them, so the possible actions remain
capped around 50.
Text games, on the other hand, tend to have 10-20 objects per room (to
make a *conservative* estimate) and fifty to a hundred or more actions.
And since the action list is hidden, players are likely to try all the
thousands of other phrasings allowed by human language. Then once they
get accustomed to IF-ese, they'll start trying ungrammatical phrasings
with unimportant words left out to save time (eg "LOOK DOOR" instead of
"LOOK AT DOOR"). Even if you implement all the phrasings your beta
testers come up with, players will come up with hundreds more that your
testers missed.
When you try to accept natural language commands and apply them to a
fully-detailed environment, the number of possible inputs explodes far
beyond anyone's ability to implement them all, so players will
inevitably find something that doesn't work as they expect.
Jon Ripley
> David Fisher wrote:
>
>> What I'm trying to figure out is what "the typical interactor's
>> expectations" are ... they seem to be quite a bit higher than what is
>> available most of the time.
> them to type anything they want in natural language, you set their
> expectations so high that it's not humanly possible to live up to
> them.
> When you try to accept natural language commands and apply them to a
> fully-detailed environment, the number of possible inputs explodes far
> beyond anyone's ability to implement them all, so players will
> inevitably find something that doesn't work as they expect.
A fair approximation is possible with a smart pre-parser input processor if
you don't want to go down the inevitable AI route. But you need to give a
lot of thought as to what anyone might try to do. It involves every base
command and object having as many synonyms as the author could think of,
good awareness of containers, the ability to discard irrelevant words and
some dirty disambiguation tricks, especially to decide what 'it' and 'that'
currently refer to.
I was able to enter the following at the prompt, in a long-lost game, many
years ago.
What now? unlock the middle desk draw with the key from under the mat, read
the code key from the paper in the middle desk drawer and input the code on
the door keypad, afterwards open the door and proceed north, then open the
fridge, take the bowl and pour cereal into it, add milk from the bottle in
the fridge and eat your breakfast.
All that was pre-processed and reordered before being passed to the main
parser as a sequence of more conventional commands similiar IIRC to the
following.
take key (under mat)
unlock middle_drawer (with key)
take code (from middle drawer)
read code
enter code (on keypad)
open door
north
open fridge
take bowl (in fridge?)
drop cereal (into bowl)
take bottle (from fridge)
drop milk (from bottle) (into bowl)
eat (from bowl)
I'm not sure what the value of such a parser is these days, as IF has
developed I still prefer the simple ways of entering commands. It seems that
such pre-parsing acrobatics may be more suited to games supporting voice
recognition.
Anyways,
Jon Ripley
--
http://jonripley.com/
Adam Thornton
samwyse <deja...@email.com> wrote:
>I say this because I-F authors are generally adults who learned writing
>as children and have forgotten that their early stuff was pretty
>unreadable. As adults, they can write stuff that is readable, but they
>have just started coding, so the same stuff is very likely to be unplayable.
Whoa.
I think you just put your finger on something very profound.
A lot of the luminaries are Nerds Of A Certain Age. Which is to say,
not only have they been writing a long time, but they have ALSO been
coding for a long time. Specifically, those of us raised during the
heyday of the 8-bit micro (and if you haven't seen it yet and you feel
like a good weep, go watch "Hey Hey 16K") were writing our first BASIC
adventure games about the same time we were writing our first crappy
short stories.
I hadn't stopped to realize that the younger generation of IF
enthusiasts grew up with the-computer-as-appliance rather than
the-computer-as-programming-vehicle, but I bet that a lot of the younger
set really DID learn to write decades before learning to code.
Hmmm.
Adam
samwyse
> In article <6lYVd.1046$WK2...@newssvr30.news.prodigy.com>,
> samwyse <deja...@email.com> wrote:
>
>>I say this because I-F authors are generally adults who learned writing
>>as children and have forgotten that their early stuff was pretty
>>unreadable. As adults, they can write stuff that is readable, but they
>>have just started coding, so the same stuff is very likely to be unplayable.
>
> Whoa.
>
> I think you just put your finger on something very profound.
>
> A lot of the luminaries are Nerds Of A Certain Age. Which is to say,
> not only have they been writing a long time, but they have ALSO been
> coding for a long time. Specifically, those of us raised during the
> heyday of the 8-bit micro (and if you haven't seen it yet and you feel
> like a good weep, go watch "Hey Hey 16K") were writing our first BASIC
> adventure games about the same time we were writing our first crappy
> short stories.
Well, I'm a Nerd *Over* A Certain Age, which means that I didn't start
coding until college, but dispite that have been doing it for most of my
life. (And I just watched "Hey Hey 16K" http://www2.b3ta.com/heyhey16k/
and, yes, it did bring a tear to my eye.) My 23-year-old son learned a
bit of BASIC on a PC/XT clone and wrote an adventure game. IIRC, he
used GOSUBs as if they were GOTOs, which if you played long enought
would eventually cause a stack overflow. So, he got to write crappy
short stories *and* crappy programs at the same time.
> I hadn't stopped to realize that the younger generation of IF
> enthusiasts grew up with the-computer-as-appliance rather than
> the-computer-as-programming-vehicle, but I bet that a lot of the younger
> set really DID learn to write decades before learning to code.
Yes, I dispair of how I'll ever teach programming to my 7 and 4 year-old
daughters.
David Alex Lamb
samwyse <deja...@email.com> wrote:
>Yes, I dispair of how I'll ever teach programming to my 7 and 4 year-old
>daughters.
My younger daughter taught herself simple programming from the notes about
Logo in her math book (around grade 5 or so, I think). Her older sister
copied, and went on to learn a couple of more complex languages -- about 1/4
of Java (enough to write a CYOA and a Movie Title Generator), plus a homebrew
invented by one of her friends in school (in which they're creating a MUCK).
So it's not so hopeless.