Newsgroups: rec.arts.int-fiction
Path: gmd.de!ira.uka.de!yale.edu!newsserver.jvnc.net!darwin.sura.net!bogus.sura.net!howland.reston.ans.net!sol.ctr.columbia.edu!The-Star.honeywell.com!umn.edu!milli!thornley
From: thornley@milli.cs.umn.edu (David H. Thornley)
Subject: Re: How do you write Romantic I-F ?
Message-ID: <C2I1pM.Lz4@news.cis.umn.edu>
Sender: news@news.cis.umn.edu (Usenet News Administration)
Nntp-Posting-Host: milli.cs.umn.edu
Organization: University of Minnesota, Minneapolis, CSci dept.
References: <1993Feb11.095808.11529@nuscc.nus.sg> <1993Feb12.214934.13353@freenet.carleton.ca> <10695692@MVB.SAIC.COM>
Date: Mon, 15 Feb 1993 16:55:57 GMT
Lines: 82

In article <10695692@MVB.SAIC.COM> Whitten@Fwva.Saic.Com (David Whitten) writes:
>In a previous article, Whitten@Fwva.Saic.Com (David Whitten) says:
>>Theory:
>> 
>>I think it is possible to do more than either of these attempts, perhaps with
>>invisible objects that represent plot goals, with the traditional 'keep you
>>from doing something' approach to various encounters - treating certain kinds
>>of encounters as rooms - but not actually being visible as rooms.
> 
>aa382@Freenet.carleton.ca (Marc Sira) writes:
>>I think you're basically talking about Zork, etc, with the objects, obstacles
>>and goals renamed. You can call "the key that unlocks the door to get the
>>gold", "the affection that unlocks the hearts to get the true love" - you're
>>still playing the same game.
>>
>>Plundered Hearts was this sort of thing - the treasure was the romance itself,
>>although the game was more story-oriented and less freewill-oriented (the
>>usual tradeoff). I don't see anything fundamentally different in what you
>>suggest (so far, but I'm interested enough to keep reading :).
>>
> 
>Well, what I'm trying to do is to be just as freewill oriented as as a
>'regular' adventure/ I-F novel.
>I agree the first approximation seems to say the goals and obstacles are
>just redefined.  And it is possible that that is all there is to romance
>anyway :) :).
> 
>But in thinking about it, this seems to be an application that will stretch
>the limit of the I-F technology, since no one to my knowledge provides
>definitions structures for non player characters.  There already is a well
>thought out system that involves objects, rooms, keys, and locks.
> 
The traditional stuff is, well, traditional, and has been used before and
in ways people expect.  If you want interesting NPCs, you need to implement
goals, beliefs, and perceptions, and the basic choice is to enumerate the
possible situations and resultant actions, create an AI, or fudge the problem
(the adventurer in Enchanter basically wandered around looking for treasure
except under some well-defined circumstances).

Frankly, I don't see what would be the NPC equivalent of rooms and objects.
The nature of most objects is to do certain things when manipulated properly
- that is, to be predictable and simple.  The nature of NPCs is to be
unpredictable and complex.

It seems to me that TADS (the only current adventure system I'm familiar
with) would be as good a starting point as any.  You could easily keep
state information with the NPCs, you have a general-purpose programming
language to use, and the manual provides at least some advice on implementing
NPCs as state machines.  Another possibility might be to swap NPC versions
in and out - say, have a Lisa class, with startLisa, scornedLisa, lovingLisa,
etc., as instantiations.  This would do the same thing as the state approach,
but might be easier to work with.  (Then again, I haven't tried it.)

>In a previous article, Whitten@Fwva.Saic.Com (David Whitten) says:
>>This means you have to view 'movement' as within a two dimensional space 
>>rather than a one dimensional space as is currently provided by programs...
>>
> 
>aa382@Freenet.carleton.ca (Marc Sira) writes:
>>Hmm?
>>I think you'll have to define your dimensions before this will make sense to
>>me.
>>
> 
>[This may be a bad choice of terms, but I was thinking of the physical
> layout as one dimension and the plot layout as another.  Therefore,
> in addition to moving in physical space, the player and NPCs would
> also be moving in plot space.]

Sounds like this might be a useful way of thinking.  In TADS, I would
implement it as states represented by variable values (either global
variables or variables in the "me" object).  It shouldn't be much harder
than implementing rooms from scratch, since the main difference is that
you wouldn't print descriptions but would have a lot of code in the NPC
objects.  Of course, what you want will require a whole lot of NPC code
anyway.

DHT




