I can no longer put off the matter of general strategy for the actors. How do they pursue victory?
I see two basic strategies. At the outset, a player’s strategy should be opportunistic, attempting to find somebody to attack. If you can nail down just one opponent’s aura counts, you can make a pretty good guess as to what he’ll play. Later in the game, however, as opponents are knocked out of contention, you are forced to deal with the survivors, and your strategy must shift to learning about those.
Whoa! I just got an idea! What if actors who are knocked out of contention are still able to influence the outcome, perhaps by revealing information. Thus, if you knock somebody out by means of a dirty trick, they might help survivors defeat you in subsequent rounds. This means that you can’t just rely on dirty tricks to win.
Thus, although the number of combatants in Dream Space diminishes with time, they’re all accessible for conversation during the day.
Back to the business at hand
So, how does an actor figure out a decent course of action? That will depend mightily on the information in his possession. Should the strategy be pinpoint or wide-area? The pinpoint strategy makes it easier to select somebody to attack, but the wide-area strategy makes for better defense.
I presume that actors will prefer to attack those they don’t like. This will be reciprocal, so they are just as likely to be attacked by the people they themselves would want to attack. That establishes a clear priority: the more you like a person, the less likely you are to want information about them. This suggests that the desirability of getting information about an actor is concomitant with both pGood and sum(uAuraCounts). You still want to know a little about your friends’ aura counts, just in case.
This opens up a new set of verbs describing the outcome of Dream Combat. You know that everybody’s total aura count is diminishing by, on average, 4/3 of an aura each night.
Should I retain the combat result that two matching auras destroy each other? That limits the game to four or five turns — possibly not long enough. I can double the length of the game by making ties non-destructive. Here’s a compelling arguement in favor of non-destructive ties: the faster aura-counts change, the harder it is to know what the aura-counts are. OK, non-destructive ties.
So I have to revise the spaghetti diagrams again. I must add a new verb describing the results of dream combat. Now, this has to be limited. After all, nobody wants to reveal their own aura counts by revealing whether they won or lost in dream combat. Indeed, merely revealing that another actor won dream combat implies that the speaker lost. Of course, revealing that a third actor lost dream combat implies that the speaker won, but that’s not so informative — besides, people will certainly talk about events that took place in the preceeding nights.
Or should they? Really, how useful is it to learn that somebody won or lost dream combat two nights ago? If you obtained an aura-estimate from a time subsequent to that, shouldn’t you place greater weight on the more recent number?
I could handle this by increasing the uValue for such information based on its age. But wouldn’t this require use of the pValue at the time of the event? You really can’t assess the value of that information today unless you knew the context at the time of the dream combat.
So perhaps the only dream combat you can talk about is the immediately preceding night’s battles, either those you experienced directly or those you heard about from others.
How to access all this information
The player will have difficulty assessing what it all means. I’ll have a special display showing pValues and uValues of all aura counts of all actors. I’ll try my hand at a mock-up.
Egad! I’ve run into another problem! How do I express the uValues in SympolTalk? The uValue modifies a numeral. Thus, to show a pValue of +2 with a negative uValue, I’d have something like this:
Does that make sense to you? I think it’s confusing. If the black arrow were replaced by a ± symbol, it might make more sense, but it’s still just weird. So how do I express the uValues? Here’s a possible solution:
which in turn would make the above display look like this:
So here is the resulting screen mockup:
I’ll need to add six more rows underneath this one; the resulting display will be 900 px high, which exceeds my specification for window size, but I’m willing to dump that specification.
That’s enough for one day.