I have made a decision that in retrospect seems a no-brainer: I will allow only two people on a stage at any given time. This insures that we never have awkward three-party situations. It also means that I don’t need to display who is present one the screen; at any given time, the only other person present is the one you’re talking to.
The idea does have a catch: there will be problems finding a place to go. When two actors finish a conversation, they both depart the stage. They must go to different stages, but those other stages might well be closed due to a pair of actors being there. I’ll need to come up with a special algorithm, but I think that I’ll rig the ‘goodbye’ verb to have its DirObject wait for a period before leaving the stage.
The return of ‘you first’
Furthermore, I realized that I had to re-create the verb “You first”, which is used in response to the verb “How do you feel about?”. The new verb is necessary in order to permit the conversation to flow in both directions.
When to specify the ActorTrait?
Another small change: the verb “How do you feel about?” now takes a 5ActorTrait, so the form of the sentence is “Subject how do you feel about DirObject 4Actor 5ActorTrait”; thus an example would be “Zubi asks Camiggdo, how do you feel about Skordokott’s Good_bad?”. Or, even more detailed, “Zubi asks Camiggdo, how much good_bad do you believe Skordokott to be?” The previous version allowed the DirObject to respond with the ActorTrait about which he has the strongest feelings, but the Subject is the one asking the question, and the Subject should be able to choose the ActorTrait.
But this would impose a new requirement: that the Subject figure out which aura is most important to him. That’s trickier than asking the DirObject to describe the aura for which he has the strongest feelings. Which is better?
No, the original scheme works better.
Make it a game first
I’ve been tempted to get to work on the massive changes in the Storyteller program necessary to convert from the old text-based system to the new Sympoltalk system. It’s an itch that I very much want to scratch, but I have to exercise discipline here. The real reason why I want to switch to the graphics problems is my difficulty facing up to the demands of getting the game working. It has now reached the point of complexity that it’s difficult for me to keep track of how things are working; I’m starting to thrash. I realize now that I need some improvements in the SWAT program. In particular, I need some way to compare similar scripts across different verbs. It’s too clumsy to look at one script, then navigate to another script, then back, to compare them. And where there are multiple variations on a single basic script (such as the Desirability script for an option), the process of cross-comparing requires too many intermediate steps.
For now, I think I’ll just have to compare screenshots. But for the future, I need a way to quickly see all variations on a script.
Getting around
The actors aren’t moving properly. When one says goodbye to another, they must break up and go elsewhere. Remember, I don’t allow actors to decide where to go; their movements are controlled by the engine, although they can declare a Target Stage that will be given high priority. My original algorithm had one actor depart and the other actor remain in place in the expectation that somebody else would show up soon enough. This didn’t seem to be happening, so I tried another algorithm in which both actors departed, with each one required to find a new stage that had, at that time, only a single occupant. This in turn raised problems with two actors simultaneously converging on a stage on which a third actor waited. I went through several frustrating attempts to resolve this problem, to no avail.
So now I’m trying to come up with a new scheme. This time I’ll check a planned Target Stage against all other planned Target Stages to insure that there aren’t any overlaps. And I think that I’ll leave one actor behind on the old stage and wait for another actor to show up. The delays will be useful and I think I can count on an adequate amount of activity this way. We’ll see.
Later…
Still stuck. I’m having problems with poisonings preventing desirable Stages. So let’s do this from the ground up. There are seven stages and seven actors. At any given moment, six of the actors should be engaged in conversation on three different stages; one actor should be alone. When one of the pairs breaks up, the departing actor must find a new place to go. In the ideal, he would go to the lone actor. But he must also make certain that no other actor has already set that lone actor’s stage as a Target Stage. If so, then he should go to one of the empty stages. Here’s where I run into a killer problem. He should go to a stage that he has not been to recently. That requires a search of the HistoryBook to see when was the last time he was at that stage. If no such event is found, then the stage is poisoned. I need a way of determining how long ago he visited a stage even if it has never been visited. Strictly speaking, “how long ago” is undefined if the actor has never been to that stage, which is why the stage is poisoned. I need a way of carrying out a sequential AND test: if there is such an event, then use the difference in times; else use a very large value. My problem is that the PickUpperIf operator calculates the upper value even when the selector boolean is false. Perhaps I should change that operator… No, I looked at the code for that operator and it is not capable of being changed to skip a calculation.
Perhaps I should create an ActorTrait that stores the time of the last visit to a stage. This would, however, require a two-dimensional array, which the ActorTrait system is not set up to handle. I could add a new operator that would handle this directly, but I am averse to so clumsy a solution.
The particular problem I’m trying to solve is an oscillation. Cammigdo says goodbye to Nybun, goes elsewhere, and, upon leaving that actor, goes right back to Nybun because Nybun is the only free actor.
The only way to find out if an event took place without generating poison is the EventHappened operator. I need to use that as the means of preventing looking for bad events.
Later…
I just realized that there is another constraint to be placed on departing: an actor should not depart if another actor has just arrived. This seems to happen with disturbing frequency. Sheesh. So here are the collected constraints that apply to departing from a stage:
1. You must not leave if anybody else has your stage as a Target Stage.
2. You must not leave if anybody has just arrived at your stage.
3. The stage that you select must not be occupied by two actors.
4. The stage that you select must not be the one you just left.
Perhaps I should break the process down into two parts: 1) depart and go to the “nowhere” stage; 2) select a destination and go there. In step 1, the actor need only concern himself with insuring that he doesn’t leave if somebody else is about to arrive. In step 2, the actor need only consider the right conditions for entering a stage.
A new idea
What if actor motions must take place in some sort of clock synchrony? That is, we break time down into 8-minute steps and actors cannot move until their proper time. Of course, this would require that the changes be made in the code, not the scripts. Still, I have been unnecessarily avoiding making changes in the code. Screw that! This is my last chance to get interactive storytelling working, so I have to throw overboard any excess baggage.
So, what would be the best way to implement this at the code level? I think it would be with the built-in verbs for movement. I could make it instantaneous, so that there’s no possibility of time-based screwups.