I have been struggling with the problem of deal-making for some days now. In the original game, there was just one kind of deal: an aura-count for an aura-count. But now there are six different things that can be traded: Props (relics); promises to not betray; promises to not attack; news of who has betrayed whom; history of who used what aura in dream-combat; and aura-count estimates. There are thirty-six combinations of these elements, and they all have different WordSockets. I considered creating 36 versions of the Verb ‘offer deal’, but this was particularly messy, because one Actor doesn’t really know what the other Actor has to offer.
This left me with ‘half-deals’: the first Actor either offers something or requests something. In the first case, the second Actor responds by either rejecting the offer flat out (because it has no value to him), or by presenting what he’ll give in return. The first Actor then decides to accept or reject the deal.
In the second case, the first Actor requests something, usually information. The second Actor has two possible responses: rejecting the offer because he doesn’t have the requested information, or demanding what he wants in return.
Deal Anticipation
Setting up a deal could be tedious if two Actors have to go through a long list of possibilities because they have no idea what the other Actor wants or has. In the original game, this was obviated by the Actors automatically knowing what information the others had. I’ll need something like this, except that it will have to be more complicated, pre-calculating everything that is possible under the circumstances.
There’s a catch in this: if you know what aura-counts every other Actor knows, you can get an idea of who they might be attacking. The solution to this problem, I think, is to be able to know in advance only the Actors about whom they know something, not which aura-counts in particular they know.
There’s an additional problem here in that historical information loses value with time. If I attack Camiggdo with shial and he defends with tanaga, I win and I know that he has only one tanaga left. However, two turns later, I don’t know if he still has that tanaga. Thus, my information loses value with time. Thus, each aura-count has a variable confidence level. The sentence structure for revealing aura-counts would have to be something like this: Subject tells DirObject that 4Actor aura-count katsin is 2 as of 3 days ago.
Yuck! This makes everything entirely too complicated. The player must go through all manner of complicated calculations to figure out the meaning of all this. I need a better system.
Relic necklaces
There’s a better way to handle the Prop economy. The idea is to make every Prop a bead that was fabricated from something important. Acolytes wear small necklaces with these beads on them. The beads should have some small benefit, so that acquiring beads is a worthwhile activity. But what is that benefit?
It is tempting to have the beads provide greater insight into another person’s aura counts.
Bingo!
That’s it! We use “magic” as part of the whole aura-schmeer. Each Actor knows others’ aura-counts basic on intuition, and that intuition is in turn based on dream-combat, physical encounters with that person, interstitial stories, and the power of his relic-necklace. That intuition is constantly shifting with time.
This suggests a really nice display presenting what you know about each Actor. I present here a number of possibilities:
Each of these cases presents the same basic situation: the Actor has 3 red auras, 2 green ones, and one blue one. In each case, the magnitude of the indicator could be varied randomly by a small amount to indicate the degree of confidence that the Actor has in that aura count. The second image may seem strange, but it is a combination of red, green, and blue in the ratios 3:2:1.
My current preference is ‘dots’. However, I am tempted to do some sort of blended version of ‘circles’ in which the colors blend into each other.
It would be really great if this display could be animated, with the graphic elements in motion, but that would require client-side software of some complexity. For now, I shall put it off in anticipation of funding.