OLYMPIA: New Commands?

Scott (srt@aero.org)
12 Jun 92 23:25:12 GMT

One of the problems with Olympia is that units can't react to
happenings in their environment, except through WAIT.

Part of the problem is that WAIT limits you to only a few conditions.
I'd like to see the conditions extended in two ways.

First, add a way to WAIT for someone to do a particular command, i.e.,

WAIT DOES 1041 "work"

would wait until unit 1041 issues a "work" command, exiting
immediately if 1041's last command was a work command. Of course, this
would be dependent upon you observing the action, so that if you
issued:

WAIT DOES 1041 "MOVE 1042"

The wait would only terminate if you could actually detect that move
happening, ie., by being in 1042 or in the province he moves from.

For simplicity, you might simply rule that a command is detected if
you are in the same province, you have sufficient OBSERVATION, and the
command is "observable", i.e., you can't see someone set their idle
command.

Second, extend the unit specification in WAIT to include two kinds of
wildcards: any unit, and any unit of a faction, i.e.,

WAIT DOES * "USE 110 2"

would wait for anyone to "USE 110 2", and

WAIT DOES $572 "STACK 3307"

would wait for anyone in faction 572 to stack with 3307. It would be
most impressive and useful if the unit that matched the wildcard would
be available for a later command through a variable, i.e.,

ATTACK $LAST

to attack the unit that matched the last wildcard. This would permit
you to implement "Don't use ENTERTAINMENT in this province, on pain of
attack from my guard unit" and many other things. (But would you attack
yourself if you entertained, hmmm?)

Of course, this can get endlessly complicated, so that you could
represent, "No one is allowed to use ENTERTAINMENT except factions 811
and unit 1076". But I don't think anyone really wants that (Rich
least of all :-). I suspect that "anyone" and "any faction member"
will cover most of the possible uses.

----

The second part of the problem is that WAIT would be more useful if it
was an asynchronous interrupt, i.e., WHEN:

WHEN DOES $572 "MOVE 1034"
cancel pr
move 1057
stack 534
set 0 idle "work"
DONE

When someone from faction $572 moved into 1034, this unit would cancel
what it was doing, move to a neighboring province, stack with a
protective stack, and start working to fill its time.

This would be very useful, especially if multiple WHENs were allowed.
Here's another example:

WHEN DOES $545 "MOVE 1034"
cancel w
give $LAST 4 5
DONE

In this example, you pay off a business deal as soon as the
representative from the other faction arrives. Note the "cancel w",
which cancels out the WHEN. If this isn't used, the WHEN will get
queued again after you exit.

----

Unfortunately, you can't capture all the conditions you'd like to test
for with the <unit> <command> syntax. You still need the kinds of
things that are currently implemented in WAIT:

ITEM SKILL UNTIL
LOC STACK
MEN TIME
SIGNAL UNIT

It would be nice to also have HEALTH, FATIGUE, and WEIGHT.

----

I also find myself wanting to do the opposite of the current tests,
i.e., I don't care so much about WAITing till I have more than X gold,
I'm more interested in WAITing until I have less than X gold. (This
permits studying until you only have your maintenance cost left, for
instance.) I don't have any good ideas on how to implement that.

Maybe we need >, <, =, != for the numeric values?

Hmm. If you did implement $LAST above, you could also implement
psuedo-vars for gold, loc, men, health, fatigue, weight, and time.
Items in the inventory and some of the others are more difficult.

WHEN < $GOLD 100
cancel r
set 0 idle "work"
DONE

I like this, but ITEM really screws it up. Of course you could have
ITEM(#), but that seems pretty complex. I dunno.

----

We now return you to the regularly-schedule stacking discussion.

-- Scott T.