WANTED: Adventure-Writing Program -- For The COMMODORE 64 or 128!
Glenn P.,
but all I have to work with is an ophaned 8-bit computer called a "Commodore
128". (Believe it or not, despite being about 15 years old these babies still
have a fairly large, and quite fanatical, following -- as anyone who has ever
visited "comp.sys.cbm" could tell you.)
Does anyone know where I might obtain a good text-adventure writing program
for this computer system? (NOTE: The C-128 will also accept programs for
the Commodore-64.) I've heard-tell of something called "Quill" or
"AdventureWriter" but I don't seem to be able to find it anywhere.
Anyone able to steer me in the right direction -- or better still, E-Mail
me a copy of the program (MIME or UUencoded) -- wil have my deepest thanks.
--_____
{~._.~} "There are a hundred ways in which a boy can injure -- if not
_( Y )_ not indeed kill -- himself. The more advennturous he is and the
(:_~*~_:) greater his initiative, the more ways he will find. If you protect
(_)-(_) him from each of the hundred, he is sure to find the hundred-and-
========= first. Though most men can look back on their boyhood and tremble
========= at the narrowness of some of their escapes, most boys do in fact
W.T.P. survive, more or less intact, and the wise father is the trusting
========= father."
=====================================
:: --= Glenn P. =-- :: --"The Enchanted Places", Chapter 21,
:: c128...@GTI.Net :: By: Christopher Robin Milne.
da...@ddavies.demon.co.uk
"Glenn P.," <c128...@GTI.Net> wrote:
>
>Does anyone know where I might obtain a good text-adventure writing program
>for this computer system? (NOTE: The C-128 will also accept programs for
>the Commodore-64.) I've heard-tell of something called "Quill" or
>"AdventureWriter" but I don't seem to be able to find it anywhere.
>
>Anyone able to steer me in the right direction -- or better still, E-Mail
>me a copy of the program (MIME or UUencoded) -- wil have my deepest thanks.
>
Ah - the Quill - a very friendly adventure writing programme that
doesn't need programming skills. The only disadvantage is the
verb-noun limitation - but it was fun to use, and I'd jump at
something like it for the PC. (am I the only one who finds that
fiddling around with complex programming language destroys my
creativity?)
I have it in the loft somewhere (plus the manual) and you're welcome
to it - although I have no way of getting off its 5.25" floppy and
into my PC. I think I also have Adventure-writer, which I thought
inferior.
However, which country are you from? (I'm in UK)
David.
Nulldogma
> (am I the only one who finds that
> fiddling around with complex programming language
> destroys my creativity?)
Not me. I find that spending heavy time programming sucks up all my
incompetence and spits it back as syntax errors, leaving me able to write
relatively clearly.
To put it another way, I like having to program because it makes writing
seem easy by comparison.
Neil
---------------------------------------------------------
Neil deMause ne...@echonyc.com
http://www.echonyc.com/~wham/neild.html
---------------------------------------------------------
Andrew C. Plotkin
null...@aol.com (Nulldogma) writes:
> > (am I the only one who finds that
> > fiddling around with complex programming language
> > destroys my creativity?)
>
> Not me. I find that spending heavy time programming sucks up all my
> incompetence and spits it back as syntax errors, leaving me able to write
> relatively clearly.
>
> To put it another way, I like having to program because it makes writing
> seem easy by comparison.
Whereas I find that I can switch modes very easily; I can write a
paragraph of prose, bop out some code, and so on.
This is probably because programming is very easy (for me), and
so it doesn't distract me from the writing, which is hard as hell.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
John Wood
Andrew C. Plotkin <erky...@CMU.EDU> writes:
>
> null...@aol.com (Nulldogma) writes:
> > To put it another way, I like having to program because it makes writing
> > seem easy by comparison.
>
> Whereas I find that I can switch modes very easily; I can write a
> paragraph of prose, bop out some code, and so on.
>
> This is probably because programming is very easy (for me), and
> so it doesn't distract me from the writing, which is hard as hell.
Same here. Except that most of my time is spent trying to decide *what*
to write (or program) in the first place...
John
Roger Carbol
In a previous article, erky...@CMU.EDU ("Andrew C. Plotkin") says:
>Whereas I find that I can switch modes very easily; I can write a
>paragraph of prose, bop out some code, and so on.
I think partially this may be to what we call "writing" and
"programming" especially in this context.
"Writing" is easy when you're just popping out some words to
describe the pretty zorkmid. It's a bit harder when you're trying
to convey the inner struggle as the troll tries to fight his bestial
nature.
I think "writing" proper, in the sense of creating plot and story,
happen primarily outside of the coding process...I'm sure some
people can sit down, code up some locations and objects, and then
decide what the plot should be, but I know that I'm not one of them.
Similarly, "coding" is easy when you're trying to create a bottle
which can only be openned in the Hot Steam Room and no where else.
It becomes a little more difficult when you want to recursively
code a Zeno's Arrow situation while avoiding zero-divide underflows
etc etc.
Anyways that's my two bits...I wouldn't consider this message
as either "writing" or "coding"...=)
Roger Carbol .. uq...@freenet.Victoria.BC.CA .. if then else die
Andrew C. Plotkin
uq...@freenet.Victoria.BC.CA (Roger Carbol) writes:
> In a previous article, erky...@CMU.EDU ("Andrew C. Plotkin") says:
>
> >Whereas I find that I can switch modes very easily; I can write a
> >paragraph of prose, bop out some code, and so on.
>
> I think partially this may be to what we call "writing" and
> "programming" especially in this context.
>
> "Writing" is easy when you're just popping out some words to
> describe the pretty zorkmid. It's a bit harder when you're trying
> to convey the inner struggle as the troll tries to fight his bestial
> nature.
I don't find much difference. Of course, you've all probably gotten
the idea that I'm unwilling to just say "It's a sparkly gold zorkmid."
and leave it at that.
> I think "writing" proper, in the sense of creating plot and story,
> happen primarily outside of the coding process...I'm sure some
> people can sit down, code up some locations and objects, and then
> decide what the plot should be, but I know that I'm not one of them.
Mmm, sort of. (Again, I'm talking about me.) I have the design phase
and the writing/coding phase. In the design phase, I pace around and
invent plot and story, but I'm thinking about neither prose nor code.
I'm not writing anything that the player will see -- except maybe
introductory text, which there isn't much of. Emotions and attitudes,
yes. Dialogue and descriptions, no.
And it's all very vague at this point. My map of _So Far_ has one
bubble per area, not one bubble per room. I really only had a couple
of sentences of summary information for each area.
Then I get into writing and coding, which are entirely entwined, and
(like I said) writing is hard and coding is easy. Details of character
and attitude and feeling get chipped out with every sentence. When I
finish coding an area, I know far more about it than when I started.
> Similarly, "coding" is easy when you're trying to create a bottle
> which can only be openned in the Hot Steam Room and no where else.
> It becomes a little more difficult when you want to recursively
> code a Zeno's Arrow situation while avoiding zero-divide underflows
> etc etc.
But 99% of the coding is the former. There is only about one place in
_So Far_ where I had to sit down and work hard on coding. (The
movement of the blues and yellows, if I may point it out without
spoilers.) There are a few places where I had to think about it a
little (grid maps and complicated react_befores, mostly.) I spend most
of my time in the state of "Check variable, set flag, uh, now I have
to write the description of what happens. Bleah."
Greg Ewing
Andrew C. Plotkin wrote:
>
> writing is hard and coding is easy.
Well, I usually find that once I get an idea (which
I can't even classify along the easy/hard axis, because
it isn't something I *do*, rather it's something which
happens *to* me) the writing flows fairly readily,
but the programming, if any is required, takes
a lot of thought and effort.
Often this is not so much because the idea is inherently
hard to code, but because it is hard to find out enough
about how the library works to be able to twist it to
my usually perverted purposes.
The ideal library would do everything that anyone
has tried to do before automatically, and be flexible
enough to extend in any possible direction, and be
well documented enough to do so without having to
read more than one paragraph of the manual or to
read any of the library source at all.
So far I haven't seen such a library :-)
Greg
Neil K. Guy
Roger Carbol (uq...@freenet.Victoria.BC.CA) wrote:
: I think "writing" proper, in the sense of creating plot and story,
: happen primarily outside of the coding process...I'm sure some
: people can sit down, code up some locations and objects, and then
: decide what the plot should be, but I know that I'm not one of them.
I was thinking about this the other day, actually, when I was looking at
So Far. I think that it takes a particular kind of genius to have equal
facility with both English prose and with the formalized structures of a
programming language. Which is why there are so few truly good text
adventures out there. Lots of people can program and a small number of
people can write well, but very very few people can do both.
Several Infocom implementors were flawlessly bilingual in this fashion.
In the post-Infocom era I think we're lucky enough to have three such
people hanging around this newsgroup - Graham Nelson, Andrew Plotkin and
Dave Baggett.
- Neil K.
--
Neil K. Guy * n...@vcn.bc.ca * n...@tela.bc.ca
49N 16' 123W 7' * Vancouver, BC, Canada
Dan Shiovitz
In article <4rv0oa$4...@milo.vcn.bc.ca>, Neil K. Guy <n...@vcn.bc.ca> wrote:
>Roger Carbol (uq...@freenet.Victoria.BC.CA) wrote:
[..]
> I was thinking about this the other day, actually, when I was looking at
>So Far. I think that it takes a particular kind of genius to have equal
>facility with both English prose and with the formalized structures of a
>programming language. Which is why there are so few truly good text
>adventures out there. Lots of people can program and a small number of
>people can write well, but very very few people can do both.
Hmm. It's not really so obvious when someone does good code, because
it's often the apparently simple things that take the most work.
Bad writing, though, is immediately apparent. Vaguely speaking of which,
is there any interest in a thread on "tough things to code"?
I know trying to simulate the Part class in worldclass when I wasn't
*using* worldclass was a serious pain, as was another partially-finished
game where the player could slide the rooms around in a giant grid.
> Neil K. Guy * n...@vcn.bc.ca * n...@tela.bc.ca
--
dan shiovitz scy...@u.washington.edu sh...@cs.washington.edu
slightly lost author/programmer in a world of more creative or more sensible
people ... remember to speak up for freedom because no one else will do it
for you: use it or lose it ... carpe diem -- be proactive.
my web site: http://weber.u.washington.edu/~scythe/home.html some ok stuff.
Neil K. Guy
Dan Shiovitz (scy...@u.washington.edu) wrote:
: Hmm. It's not really so obvious when someone does good code, because
: it's often the apparently simple things that take the most work.
: Bad writing, though, is immediately apparent. [...]
Mmm... I'm not sure I'd agree with you there. I think lousy coding comes
through very easily most of the time. True, someone could do a bang-up
job of writing something that feels natural to the end user but is in
fact the most appalling spaghetti-coded mess of special cases imaginable,
but I think the likelihood of that happening is low. Use a well-written
program. Use a poorly-written program. You can tell the difference - the
quality (or lack thereof) inside usually shows through.
Again, I refer you to the works of the three people I mentioned in my
previous post. Look at Inform, WorldClass or MaxZip. There isn't much
writing in them, but it's pretty clear that they're quality programs.
: [...] Vaguely speaking of which,
: is there any interest in a thread on "tough things to code"?
Tough things? In my opinion anything infinitely divisible, like water,
or subdividing discrete objects like rooms. Since text adventures treat
objects (thus rooms) in an atomic fashion, it's hard to implement
locations within rooms, large rooms (unless you code up a bunch of rooms)
versus small rooms, etc. I dunno. Those two examples strike me as being
two things that are very problematic, as they fly in the face of the
basic paradigms of Infocom-style IF.
What else. Truly intelligent NPCs maybe? Undercooked scrapple? :)
More seriously, I found some of the hardest things to code in my game
were hacking TADS adv.t to provide a slightly more realistic model of
light and dark, a daemon that controls weather conditions, an endless
desert which is really just a single room, a train the user can ride and a
non-intelligent NPC. (which is of course a writhing mass of special-case
code...)
- Neil K. Guy
--
Neil K. Guy * n...@vcn.bc.ca * n...@tela.bc.ca
Andrew C. Plotkin
n...@vcn.bc.ca (Neil K. Guy) writes:
> : [...] Vaguely speaking of which,
> : is there any interest in a thread on "tough things to code"?
>
> Tough things? In my opinion anything infinitely divisible, like water,
> or subdividing discrete objects like rooms. Since text adventures treat
> objects (thus rooms) in an atomic fashion, it's hard to implement
> locations within rooms, large rooms (unless you code up a bunch of rooms)
> versus small rooms, etc. I dunno. Those two examples strike me as being
> two things that are very problematic, as they fly in the face of the
> basic paradigms of Infocom-style IF.
Definitely. I once did a tiny Inform game which took place in a grid
of rooms, where you could see anything in your room *or any adjacent
room*. And the game had to be able to parse nouns like "the rock to
the north". And you could hear objects that were more than one room
away, too, and the sound messages had to look like "You hear rumbling
to the south."
It was a monstrous pain. I actually threw out the entire room and
scoping system, and had a *single* room, and a daemon that made
objects appear and disappear and change names. And so on. This only
worked because it was on a grid; the method isn't applicable to a
normal layout of distinct rooms.
I'll see if I can get permision to upload the game and source code.
(It was a freebie we threw in on the Icebreaker CD -- Icebreaker being
an arcade game my company released last year. Yes, there *has* been an
Inform game published in a commercial product. :-) Nobody noticed, of
course.)
> What else. Truly intelligent NPCs maybe? Undercooked scrapple? :)
>
> More seriously, I found some of the hardest things to code in my game
> were hacking TADS adv.t to provide a slightly more realistic model of
> light and dark, a daemon that controls weather conditions, an endless
> desert which is really just a single room, a train the user can ride and a
> non-intelligent NPC. (which is of course a writhing mass of special-case
> code...)
Mmm, I can't think of anything else really hellish I've done. The
weather in "Weather" was just a counter which printed out stuff every
once in a while. The flowing water was sort of ugly, but really just a
set of chained counters; the code was largely repeated from room to
room.
Andrew C. Plotkin
> people can write well, but very very few people can do both.
>
> In the post-Infocom era I think we're lucky enough to have three such
> people hanging around this newsgroup - Graham Nelson, Andrew Plotkin and
> Dave Baggett.
I should point out that I also have a nice singing voice (although I
haven't sung much since high school), I can give back rubs, I can
recommend many neat books, I have long hair, and I'm single.
Neil K. Guy
Andrew C. Plotkin (erky...@CMU.EDU) wrote:
: It was a monstrous pain. I actually threw out the entire room and
: scoping system, and had a *single* room, and a daemon that made
: objects appear and disappear and change names. And so on. This only
: worked because it was on a grid; the method isn't applicable to a
: normal layout of distinct rooms.
Yes... that's how my desert works. It's a single room that moves objects
around and stuff, thereby simulating an infinitely large space. Real pain
to implement. I assume that Michael Berlyn did something similar in
Infidel's endless deserts. I also tried to code in the ability to 'look
north' and see stuff in the next chunk of desert, but gave up as it was
too much work.
: Mmm, I can't think of anything else really hellish I've done. The
: weather in "Weather" was just a counter which printed out stuff every
: once in a while. [...]
The two basic models, it seemed to me, for stuff like weather are 1)
totally random comments made from time to time and 2) a fixed set of
standard weather messages issued at appropriate times. The first implies
a totally random model of the weather conditions and the set implies an
immutable and fixed linear sequence of weather. I wasn't happy with
either approach, and hacked together a rather ugly lump of TADS code that
sort of combines the two. In my game weather conditions are randomly
determined, but follow trends. That way the weather is unpredictable, but
doesn't jump around totally randomly - it feels more realistic to me that
way.
Neil K. Guy
Andrew C. Plotkin (erky...@CMU.EDU) wrote:
: I should point out that I also have a nice singing voice (although I
: haven't sung much since high school), I can give back rubs, I can
: recommend many neat books, I have long hair, and I'm single.
This last leads me to suspect that there are certain other Plotkinesque
attributes of which we are not being informed...
Dan Shiovitz
In article <glsy5sK00WB2QA=T...@andrew.cmu.edu>,
Andrew C. Plotkin <erky...@CMU.EDU> wrote:
>n...@vcn.bc.ca (Neil K. Guy) writes:
>> Lots of people can program and a small number of
>> people can write well, but very very few people can do both.
>>
>> Several Infocom implementors were flawlessly bilingual in this fashion.
>> In the post-Infocom era I think we're lucky enough to have three such
>> people hanging around this newsgroup - Graham Nelson, Andrew Plotkin and
>> Dave Baggett.
>
>haven't sung much since high school), I can give back rubs, I can
>recommend many neat books, I have long hair, and I'm single.
rec.arts.int-fiction.personals, anyone?
SWM, college student, TADS Programmer. No AGT, No ALAN. Must enjoy
long walks on the beach and long coding sessions in the house.
Turn-ons: methods, daemons.
Turn-offs: debugging, writing the damn things.
Naah.
>--Z
Kathleen Fischer
n...@vcn.bc.ca (Neil K. Guy) wrote:
> The two basic models, it seemed to me, for stuff like weather are 1)
>totally random comments made from time to time and 2) a fixed set of
>standard weather messages issued at appropriate times. The first implies
>a totally random model of the weather conditions and the set implies an
>immutable and fixed linear sequence of weather. I wasn't happy with
>either approach, and hacked together a rather ugly lump of TADS code that
>sort of combines the two. In my game weather conditions are randomly
>determined, but follow trends. That way the weather is unpredictable, but
>doesn't jump around totally randomly - it feels more realistic to me that
>way.
Weather is on my list of things to add to my simpler "sampler" game. I was
planning on using the last (3rd?) approach (somewhat random with trends). Any
pointers or pitfalls to avoid? :) :) :)
As for hardest thing to code? Well, I'm a newbie so "just about everything"
could be one valid answer. More specifically, I'd have to say its getting my
non-verbal NPC (ie, no dialog to worry about) to behave in a believable
fashion. Her definition is 12 pages long and growing by the hour. The wierd
thing is that the code is NOT full of special cases (like what to do in this
room or with that object... I handed that a different ... hopefully more
"clever"... certainly easier to code... way), rather full of code to handle
attributes, objects and rooms in general, so I can add new things to the world
and she will behave properly without haveing to muck with her code. There is
also a substantial portion devoted to deciding where she wants to go next based
on her mood, what objects are around, where she is (ie, if she is tired and
there is something to sit on then she will probably choose that over going to
another room unless she is angry or frightened. Of course, if she is locked
inside something then that's another problem altogether... trust me, it makes
sence in the context of the game!).
What I haven't been able to figure out is how to get her to "find" the player.
If the player is in a room which has several exits, leading to several rooms
which all have several exits to several other rooms... one of which contains
the NPC... how can the NPC know which direction to go to find the player? I
can make her instantly "jump" to player's location, but I don't want to do
that... I just want her to move one room closer.
Anyway, just my $.02 (US)
Kathleen
--
// Kathleen Fischer
// kfis...@greenhouse.llnl.gov
// *** "Don't stop to stomp ants while the elephants are stampeding" ***
Neil K. Guy
Kathleen Fischer (kfis...@greenhouse.llnl.gov) wrote:
: [...] There is
: also a substantial portion devoted to deciding where she wants to go next based
: on her mood, what objects are around, where she is (ie, if she is tired and
: there is something to sit on then she will probably choose that over going to
: another room unless she is angry or frightened. [...]
Yes, I feel that internal state stuff is pretty important to simulating
a reasonably animate entity. My sole real NPC has a set of internal
attributes that determine whether it is angry, afraid, pleased, etc.
Therefore it doesn't behave in an entirely random fashion - its reactions
are essentially based on these internal values, over which the player has
some limited control. From a philosophical standpoint I'm a bit
uncomfortable with this whole business of trying to assign reductionist
numerical values to something as complex as behaviour, but hell - it's
just a game. :)
: What I haven't been able to figure out is how to get her to "find" the player.
: If the player is in a room which has several exits, leading to several rooms
: which all have several exits to several other rooms... one of which contains
: the NPC... how can the NPC know which direction to go to find the player? I
: can make her instantly "jump" to player's location, but I don't want to do
: that... I just want her to move one room closer.
That sort of stuff requires an algorithm to determine a path to the
player. You don't say what language you're coding in. If you're using
TADS check out Lars Joedal's go to command - you could modify that to
have your NPC determine the shortest route to the player and, if there is
a route, move the player one step closer.
Nulldogma
Anything with complex daemons drives me up the wall -- the el train in
Lost New York, with all its stopping and starting and changing directions
and multiple stations where you can get on and off, was an absolute
nightmare to code, though it may not look it from the end result.
Having an item that's attached to two other items is similarly awful.
There are times when you need relations between objects that are more
complicated than parent/child.
Oh, and NPCs, of course. My next game (unless it becomes my next game
after that) is going to be heavily NPC-dependent, and the prospect of
having to code it is scaring the bejeezus out of me...
Allison Weaver
On Wed, 10 Jul 1996, Greg Ewing wrote:
> The ideal library would do everything that anyone
> has tried to do before automatically, and be flexible
> enough to extend in any possible direction, and be
> well documented enough to do so without having to
> read more than one paragraph of the manual or to
> read any of the library source at all.
Yes, add this to my list of ideal manual wishes -- fully documented
libraries so that I can easily tell where I need to tweak to get my
particular idea to work. And so that I don't write code for something
that's already covered.
Allison
Neil K. Guy
Nulldogma (null...@aol.com) wrote:
: Anything with complex daemons drives me up the wall -- the el train in
: Lost New York, with all its stopping and starting and changing directions
: and multiple stations where you can get on and off, was an absolute
: nightmare to code, though it may not look it from the end result.
Oooh, yes. Ridable trains that stop at multiple stations and reverse...
My game also has two of the damned things. (yes there's a reason it's been
nearly 4 years in the making...) I went through many iterations trying to
get a model that worked well. I remember at one point noticing that after
a few turns the insides of the train were in one place and the outsides in
quite another. An interesting concept, if nothing else. Thankfully for my
fragile ego Michael Kinyon wasn't too brutal in pointing out some of these
embarrassing inconsistencies...
Nulldogma
> Oooh, yes. Ridable trains that stop at multiple stations and reverse...
> My game also has two of the damned things. (yes there's a reason it's
been
> nearly 4 years in the making...) I went through many iterations trying
to
> get a model that worked well. I remember at one point noticing that
after
> a few turns the insides of the train were in one place and the outsides
in
> quite another.
Yeah, those insides and outsides of trains simply refuse to stay together.
(The actual New York subway system sometimes has the same problem, but
thankfully fatalities are generally low.) Then there is the train cascade
effect, where each turn you get more and more trains arriving, until
they're so busy pulling up to the platform eight times per turn that they
never actually leave. (Chris Forman can tell you about all these, and
more.)
I'd offer to send you my train code if I thought it would help, but at
this point it's a cobbled-together mess that even I, quite literally,
don't understand. If my testers had found one more bug, I was ready to
scrap the entire thing and make the damn player walk to the Bronx...
Matthew Amster-Burton
scy...@u.washington.edu (Dan Shiovitz) wrote:
>rec.arts.int-fiction.personals, anyone?
SWM seeks NPC to talk TADS, ZIL, and AGT. No grues.
Matthew
Damien Neil
On 10 Jul 1996 20:30:33 GMT, Kathleen Fischer <kfis...@greenhouse.llnl.gov> wrote:
>Weather is on my list of things to add to my simpler "sampler" game. I was
>planning on using the last (3rd?) approach (somewhat random with trends). Any
>pointers or pitfalls to avoid? :) :) :)
Weather is nifty.
>As for hardest thing to code? Well, I'm a newbie so "just about everything"
>could be one valid answer. More specifically, I'd have to say its getting my
>non-verbal NPC (ie, no dialog to worry about) to behave in a believable
>fashion. Her definition is 12 pages long and growing by the hour.
From your description, this sounds like a rather interesting NPC indeed.
It sounds to me as though you've taken on a task that most authors
dodge as being far too daunting. Not that I want to discourage you --
quite the opposite! I've wondered for some time to what degree the
lack of depth to NPC coding is the difficulty of writing a good one,
and to what degree it is authors being too overwhelmed by the task to
attempt it.
>What I haven't been able to figure out is how to get her to "find" the player.
The (rather grotty) pseudocode below should describe a working algorithm.
There are probably more efficient ways of performing the desired path-
finding, but this ought to be fast enough for any reasonably-sized
game.
The pseudocode requires that each location have properties `seen',
`distance', and `comefrom', all of which it uses internally. It
also requires that there be some way of determining a list of
rooms that may be reached from any given room. It returns a ordered
list of rooms which the NPC must travel between to reach the player.
The general idea is to recursively traverse the entire list of rooms,
starting with the NPS's location. Each room is assigned a distance
(the number of rooms which the NPC must pass through to reach it),
and a `comefrom': the room from which the NPC will arrive when
walking the shortest path to the room. This allows you to find the
shortest path between the NPC and any room.
Translating this into Inform may be non-trivial. (Although certainly
possible.) It would help immensely if Inform had LISPish lists, as
TADS does.
init_search()
build_map(npc.location, 0, nowhere)
path := find_path()
function init_search
foreach room in list_of_all_rooms
room.seen := false
return
function build_map(room, distance, last_room)
room.seen := true
room.distance := distance
room.comefrom := last_room
foreach next_room in location.exits
if next_room.seen = false
build_map(next_room, distance + 1, room)
elseif (next_room != room) and (next_room.distance < distance + 1)
build_map(next_room, distance + 1, room)
return
function find_path
if player.location.seen = false
return []
room = player.location
roomlist = []
while room != npc.location
insert room at front of roomlist
room = room.comefrom
return roomlist
Hope this helps!
- Damien
--
The earth is flat.
All opinions expressed in the above are mine, not necessarily JPL's.
Kathleen Fischer
I was wondering if there is a list of game names matched with their authors
anywhere?
I would love to be able to read a posting by 'X' and know that they wrote game
'Y'.
Anyone?
Kathleen Fischer
ne...@godzilla.jpl.nasa.gov (Damien Neil) wrote:
>On 10 Jul 1996 20:30:33 GMT, Kathleen Fischer <kfis...@greenhouse.llnl.gov> wrote:
>>Weather is on my list of things to add to my simpler "sampler" game. I was
>>planning on using the last (3rd?) approach (somewhat random with trends). Any
>>pointers or pitfalls to avoid? :) :) :)
>
>Weather is nifty.
Yes, until you try to make it rain. I spent most of last night trying to
figure out if I really want to deal with everything getting wet and puddles on
the ground. I think not... unless its the quick evaporating kind of rain and
all my objects are covered in rustolium.
Neil K. Guy
Kathleen Fischer (kfis...@greenhouse.llnl.gov) wrote:
: Yes, until you try to make it rain. I spent most of last night trying to
: figure out if I really want to deal with everything getting wet and puddles on
: the ground. I think not... unless its the quick evaporating kind of rain and
: all my objects are covered in rustolium.
Ergh - yes, you have to be careful with this stuff. In my game it rains.
There are several different rain states, in fact, from drizzle to thunder.
But then you have to implement things getting wet. And its gets damned
complicated. Some things survive rain; some don't. Some things are ruined
by any exposure to water; others are only damaged to submersion. Clothing
gets heavier when it gets wet. Some things make noise when rained on;
others don't. Things dry off gradually, but won't dry off at all if it's
still raining. Etc. I've implemented all of those and more, but I'm still
not sure if it was all worth the effort.
Dan Shiovitz
In article <4s3g2g$t...@lll-winken.llnl.gov>,
Kathleen Fischer <kfis...@greenhouse.llnl.gov> wrote:
>ne...@godzilla.jpl.nasa.gov (Damien Neil) wrote:
>>On 10 Jul 1996 20:30:33 GMT, Kathleen Fischer <kfis...@greenhouse.llnl.gov> wrote:
>>>Weather is on my list of things to add to my simpler "sampler" game. I was
>>>planning on using the last (3rd?) approach (somewhat random with trends). Any
>>>pointers or pitfalls to avoid? :) :) :)
>>
>>Weather is nifty.
>
>figure out if I really want to deal with everything getting wet and puddles on
>the ground. I think not... unless its the quick evaporating kind of rain and
>all my objects are covered in rustolium.
Heh. This might be fun to do. I know for Lethe I coded up a GetWet
function in TADS that hopefully handled everything right .. I don't know
how difficult it would be to do the same in Inform. It's certainly
*doable*, anyway, just a question of whether you want to spend the time
(but if it's only a small game ...) Puddles would be kinda fun too, but
then you'd definitinely have to implement a fancy liquid handler into the
game.
>// Kathleen Fischer
>// kfis...@greenhouse.llnl.gov
Kathleen Fischer
>
>: Yes, until you try to make it rain. I spent most of last night trying to
>: figure out if I really want to deal with everything getting wet and puddles on
>: the ground. I think not... unless its the quick evaporating kind of rain and
>: all my objects are covered in rustolium.
>
>There are several different rain states, in fact, from drizzle to thunder.
>But then you have to implement things getting wet. And its gets damned
>complicated. Some things survive rain; some don't. Some things are ruined
>by any exposure to water; others are only damaged to submersion. Clothing
>gets heavier when it gets wet. Some things make noise when rained on;
>others don't. Things dry off gradually, but won't dry off at all if it's
>still raining. Etc. I've implemented all of those and more, but I'm still
>not sure if it was all worth the effort.
I'm not worthy... I'm not worthy... I'm not worthy.... oh great guru of
atmospheric phenomina
:)
Kathleen
ps. So, do you make puddles? Well, not you *personally*... I mean does your
game make puddles? :)
pps. Is this for a game that is "out there".... if so, I would love to play it!
--
// Kathleen Fischer
// kfis...@greenhouse.llnl.gov
Kathleen Fischer
>: game make puddles? :)
>
> Well, that *is* a personal question! Good heavens. :) My game doesn't
>actually support puddles, as I didn't think it would be worth it.
Hmmmmm...
-----
> l
It's pouring down rain, obscuring the landscape beyond recognition.
> l
Look? Look? The sky is falling. The rivers are overflowing their banks. It's
basically a bad day to be outside. Not to mention the fact that you just saw an
old guy with a long beard boarding a huge wooden boat. You can't see the nose
on the front of your face and you want me to admire the... hey... wait... the
rain seems to be subsiding.
> l
Through the last of the drizzle you can now make out a stunning cloth covered
concrete park bench.
Resting on the cloth is a picnic basket (which is open), a can of tuna, and a
mint condition IF Compiler Manual.
The cloud gives one last sputter (as if you weren't wet enough already) then
moves on, leaving you standing in the sunshine once more.
> x cloth
It's sopping wet, much the same way that you are.
> x basket
Too bad it was left open, for now it is full of water and the food is most
decidedly ruined.
> x ground
The ground is perfectly dry.
A kunkel walks by. "Dry? DRY?" he scoffs, grabbing a handful of the dusty
earth and pouring it all over your shoes for effect. "The author made you sit
though several tedious carriage returns of description of a torrential flood
and then she couldn't even go to the effort to make a little old puddle. Now if
this game had decent graphics..."
> pour water on kunkel
You heft the basket of water and dump it over the kunkels head.
"I'm melting... I'm melting..." he wails as he slowly disintegrates.
> l
There is stunning cloth covered concrete park bench here.
Resting on the cloth is a can of tuna and a mint condition IF Compiler Manual.
On the ground is a small puddle.
-----
>I could
>add puddles quite easily, however, as I have a set of routines already to
>handle water using TADS' create object feature. That's how I handle
>filling objects with water. For example, if you take a swim while
>holding an empty glass bottle you'll find the bottle fills up with
>water. That water object was created dynamically. Since Inform cannot
>create and destroy objects on the fly you'd have to do some pretty fancy
>messing around to implement something similar.
I have already created a water class and a pile of "stock" waters that I can
draw from. You can subdivide water easily (I have implemented a sink with
running water and a drain and such that seems to work fine... fills as many
containers as you can put into it. You even get a cool message complementing
you on your code breaking skills if you manage to ask for more water than I
have water to give.)
If I switched to Inform 6 it would be even neater, I know, but I am a
procrastinator as well. I'm waiting for the pretty Mac GUI to come out that
supports 6.0. Hello? Is anyone listening? :)
>: pps. Is this for a game that is "out there".... if so, I would love to play it!
>
> Nope. Not yet. I've been working on it since early 1992 off and on. At
>this rate it might be released shortly after Avalon.
OK... I'll bite... what's Avalon? I take it it is vaporware?
Kathleen
Neil K. Guy
Kathleen Fischer (kfis...@greenhouse.llnl.gov) wrote:
: I'm not worthy... I'm not worthy... I'm not worthy.... oh great guru of
: atmospheric phenomina
Nah - just someone who procrastinated on his thesis for far too long.
: ps. So, do you make puddles? Well, not you *personally*... I mean does your
: game make puddles? :)
Well, that *is* a personal question! Good heavens. :) My game doesn't
actually support puddles, as I didn't think it would be worth it. I could
add puddles quite easily, however, as I have a set of routines already to
handle water using TADS' create object feature. That's how I handle
filling objects with water. For example, if you take a swim while
holding an empty glass bottle you'll find the bottle fills up with
water. That water object was created dynamically. Since Inform cannot
create and destroy objects on the fly you'd have to do some pretty fancy
messing around to implement something similar.
: pps. Is this for a game that is "out there".... if so, I would love to play it!
Nope. Not yet. I've been working on it since early 1992 off and on. At
this rate it might be released shortly after Avalon.
- Neil K. Guy
Eileen Mullin
LOL! Sounds perfect for a new classifieds section in XYZZYnews. Send 'em
in, folks!
Eileen
In article <4s35qs$p...@nntp4.u.washington.edu>, mam...@u.washington.edu
John Baker
In <4s42h7$9...@lll-winken.llnl.gov> Kathleen Fischer
<kfis...@greenhouse.llnl.gov> writes:
>> pour water on kunkel
>You heft the basket of water and dump it over the kunkels head.
>
>"I'm melting... I'm melting..." he wails as he slowly disintegrates.
**** Your score has gone up ****
--
John Baker - http://www.netcom.com/~baker-j
**I boycott all businesses that send me unsolicited email advertisments**
"Honey, I never drive faster than I can see, and besides,
it's all in the reflexes." - Jack Burton
Julian Arnold
In article <4s3lr6$t...@lll-winken.llnl.gov>, Kathleen Fischer
<mailto:kfis...@greenhouse.llnl.gov> wrote:
>
> I was wondering if there is a list of game names matched with their authors
> anywhere?
>
> I would love to be able to read a posting by 'X' and know that they wrote game
> 'Y'.
It's the sort of thing you remember after a while here. There are 2
game lists (Inform and TADS) which get posted occasionally.
Off the top of my head:
Andrew Plotkin: Inhumane, A Change in the Weather, So Far
Graham Nelson: Curses, Jigsaw, Balances (+ numerous examples and demos
which don't count)
Dave Baggett: UU2, The Legend Lives!, +=3
Gareth Rees: Christminster, The Magic Toyshop
Magnus Olsson: Unc Zebulon's Will, Dungeons of Dunjin
CE Forman: Path to Fortune (with Jeff Cassidy), MST3K1 (Detective)
Whizzard: Avalon
Matt Barringer: Detective
Colm McCarthy: Shelby's Addendum
Neil DeMause: Lost New York, MacWesleyan
JasonDyer: The Mind Electric
Jacob Weinstein: Save Princeton, Toonesia
John Baker: John's Firewitch
Julian Arnold: Still nothing...
Jools
Russell L. Bryan
Neil K. Guy wrote:
> Since Inform cannot
> create and destroy objects on the fly you'd have to do some pretty
> fancy messing around to implement something similar.
Just to clear up that point, Inform 6 does provide tools for creating
and destroying objects on the fly. Since a lot of people are searching
for a programming language at the moment, I thought it would only be
fair to mention that.
-- Russ
Francis Irving
On Fri, 12 Jul 1996 11:48:56 +0100 (BST), Julian Arnold
<jo...@arnod.demon.co.uk> wrote:
>
>Andrew Plotkin: Inhumane, A Change in the Weather, So Far
>Graham Nelson: Curses, Jigsaw, Balances (+ numerous examples and demos
> which don't count)
>Dave Baggett: UU2, The Legend Lives!, +=3
>Gareth Rees: Christminster, The Magic Toyshop
>Magnus Olsson: Unc Zebulon's Will, Dungeons of Dunjin
>CE Forman: Path to Fortune (with Jeff Cassidy), MST3K1 (Detective)
>Whizzard: Avalon
>Matt Barringer: Detective
>Colm McCarthy: Shelby's Addendum
>Neil DeMause: Lost New York, MacWesleyan
>JasonDyer: The Mind Electric
>Jacob Weinstein: Save Princeton, Toonesia
>John Baker: John's Firewitch
>Julian Arnold: Still nothing...
>
But, at risk of starting controversy, which are any good?
I've just finished Curses - the best IF game I have ever played and
the first for ages. What possible follow up is as good?
Francis
P.S. How do you get the 550th point on Curses? My final score is
549/550. Of course, you can get 554/550, but that seems like cheating
to me. Looking at the Z-code, I found the "eating between meals"
score - 0 for eating the biscuit, but I'd done all the others.
Kevin Soucy
On Jul 12, 1996 17:19:06 in article <Re: List of game names and their
authors>, 'francis...@vegauk.co.uk (Francis Irving)' wrote:
>I've just finished Curses - the best IF game I have ever played and
>the first for ages. What possible follow up is as good?
atmospehere. The area near the end of the game could have been better
IMHO, but with that aside, you're in for a treat.
Hmmmm....maybe it's time to dig up Curses again. (Never quite got into it.
That and the fact that I really don't like games that don't list obvious
exits in the room description, or by command. That function makes mapping
so much easier!)
"AGT Master"
Stee...@Usa.Pipeline.Com
Julian Arnold
In article <31e6820d...@news.demon.co.uk>, Francis Irving
<mailto:francis...@vegauk.co.uk> wrote:
>
> On Fri, 12 Jul 1996 11:48:56 +0100 (BST), Julian Arnold
> <jo...@arnod.demon.co.uk> wrote:
> >
> >Andrew Plotkin: Inhumane, A Change in the Weather, So Far
> >Graham Nelson: Curses, Jigsaw, Balances (+ numerous examples and demos
> > which don't count)
> >Dave Baggett: UU2, The Legend Lives!, +=3
> >Gareth Rees: Christminster, The Magic Toyshop
> >Magnus Olsson: Unc Zebulon's Will, Dungeons of Dunjin
> >CE Forman: Path to Fortune (with Jeff Cassidy), MST3K1 (Detective)
> >Whizzard: Avalon
> >Matt Barringer: Detective
> >Colm McCarthy: Shelby's Addendum
> >Neil DeMause: Lost New York, MacWesleyan
> >JasonDyer: The Mind Electric
> >Jacob Weinstein: Save Princeton, Toonesia
> >John Baker: John's Firewitch
> >Julian Arnold: Still nothing...
>
> But, at risk of starting controversy, which are any good?
>
> the first for ages. What possible follow up is as good?
OK, to cover my ass, as it were, all the above are worth downloading and
playing. However, if you only have time to play, say, 5, these are the
one's I'd recommend (in no particular order):
So Far, The Legend Lives!, Jigsaw, John's Firewitch, MST3K1
That's IMO of course. Really, it all depends on what you want, in terms
of genre, length, difficulty, puzzle:plot ratio, etc., etc. None are
perfect.
> P.S. How do you get the 550th point on Curses? My final score is
> 549/550. Of course, you can get 554/550, but that seems like cheating
> to me. Looking at the Z-code, I found the "eating between meals"
> score - 0 for eating the biscuit, but I'd done all the others.
Can't remember. I think it's possible to score >550 points.
Anyway, I can't easily set Followup-To:, but further enquiries ought to
go to rec.games.int-fiction, not here.
Jools
Greg Ewing
Neil K. Guy wrote:
>
> The two basic models, it seemed to me, for stuff like weather are 1)
> totally random comments made from time to time and 2) a fixed set of
> standard weather messages issued at appropriate times.
A Markov chain might model this sort of thing reasonably
well.
If you haven't heard the term, a Markov chain is a system
which has a set of possible states and, for each state,
a set of transition probabilities to other states.
So, for example, if the weather one turn is sunny,
there might be a 90% chance of it staying sunny
next turn and 10% of it turning cloudy. If it's
cloudy, there would be some chance of it turning
sunny again or starting to rain, etc.
Greg
Mark J Musante
Kathleen Fischer (kfis...@greenhouse.llnl.gov) wrote:
> n...@vcn.bc.ca (Neil K. Guy) wrote:
> >Kathleen Fischer (kfis...@greenhouse.llnl.gov) wrote:
> >: game make puddles? :)
> >
> > Well, that *is* a personal question! Good heavens. :) My game doesn't
> >actually support puddles, as I didn't think it would be worth it.
[ long water-related, kunkel-cameoing script deleted ]
Must... resist... tempatation! Willpower... failing! Need... to... join...
Text Adventure Programmers Anonymous...
- Mark
PS: Not to be confused with Tappa Kegga Brew :-)
Christopher E. Forman
Julian Arnold <jo...@arnod.demon.co.uk> wrote:
: So Far, The Legend Lives!, Jigsaw, John's Firewitch, MST3K1
YES!!! I made the top 5!!!
(Don't download MST3K1 yet, though. Wait until the new release in August!)
--
C.E. Forman cef...@rs6000.cmp.ilstu.edu
Read XYZZYnews at http://www.interport.net/~eileen/design/xyzzynews.html
Vote I-F in 1996! Visit http://www.xs4all.nl/~jojo/pcgames.html for info!
Ask me about my list of Infocom products for sale or trade!
Volker Blasius
Kathleen Fischer wrote:
>
> I was wondering if there is a list of game names matched with their authors
> anywhere?
>
> I would love to be able to read a posting by 'X' and know that they wrote game
> 'Y'.
I don't know any, but a good place to start is
ftp://ftp.gmd.de/if-archive/Master-Index
which has the advantage that it is automatically kept up-to-date.
Volker