I’ve gotten the basic combat loop operational; as yet the battle is an infinite loop but that’s easily fixed. Two problems have brought me to a screeching halt.
First is the problem of duplication of sentence instances. Currently the system insures only that the same Actor was not selected immediately previous to the candidate Actor. So now I have a case in which Percival is selected, then Tristram, then Percival again. That’s just wrong.
The obvious solution is to go through each of the Actors in sequence, so that Arthur gets to respond to each duke. But that is difficult to do with the current operator list, which deliberately avoids explicit loops. Besides, it would be better to present the Actors in a random sequence.
I would have to use PickBestActor, but the new script looks like this:
AcceptableActors
AllActorsWho
AND
TopLessThanBottom(BNumber)
Rank
CandidateActor
0.5
NOT
AreSameActor
CandidateActor
PastDirObject
LookUpCausalEvent
AND
AreSameVerb
PastVerb
CandidateEvent
selectFighter
AreSameActor
PastDirObject
CandidateEvent
CandidateActor
Along with a Random value in the Desirable script, this should do the job, but for one flaw: it Poisons when all the Actors have been used. Here is where an error catching operator (e.g. Try { } CatchPoison) would be great to have. But I don’t think that I am close enough to the code to pull off something like that now; I’m rusty and the Poison code is really tricky stuff.
Here’s another idea: what if I assign a new Actor Attribute called Visits. It’s a BNumber, but it is always used as a Number, like so:
SetVisits
ThisSubject
Number2BNumber
sum
BNumber2Number
Visits
ThisSubject
1.0
This would increment the number of visits that we have already given the Actor; we could then make the Desirable script for selecting that Actor inversely proportional to Visits. Or we could use a PickBestActor to select the Actor with the lowest number of Visits. That insures that we don’t get unnecessary repeats.
But what if the Actor’s Enthusiasm value has not changed since the last visit? Then we’ll get an exact repeat. Now what?
Two possible solutions: add even more sentences to the sentence display. That’s a ghastly solution because I would need at least 88 new sentences to do the job. Ugh! Or I could generalize all the sentences with Tinkertoy Text. The flaw in that reasoning is that this would rob the sentences of any personal details. No, that is unacceptable.
I see no solution to this problem as yet.
Second is the long-term nature of interactive storytelling. This is disheartening realization. Let’s start with the extreme case of the boy romancing the girl. He can give her flowers, which will probably increase her affection by a small amount. He could also give her candy, which might also increase her affection for him by a small amount. But the entire romancing process takes a long time; he’ll have to engage her in hundreds of interactions. But those interactions can’t just be repeats of the same thing over and over; more flowers and candy can only go so far. Which in turn means that we must have hundreds of different verbs.
I always knew that interactive storytelling would require a lot of verbs, but this really underlines the problem. It can’t work unless we have a HUGE number of verbs. I’ve been thinking in terms of a hundred or so verbs. This realization means that there must be hundreds of verbs. Interactive storytelling relies on a critical mass of verbs that is much larger than I had imagined. It’s simply too big.