I'm against it. First, it is an affront to reality. Secondly, it
greatly limits the uncertainty and tactics of dealing with the
world. Of all the changes mentioned on this list, this is the one
I think would most likely improve the game.
In fact, I'm against perfect knowledge even in a province. How can
you know perfectly who is in a province, when a province is 16 days
journey across? As I argued in the original Olympia, I think it
would be better to have randomly imperfect information about who was
in a location. I think it would greatly improve the flavor of the
game.
If the only objection is that it makes the turn reports unwieldy,
then perhaps some new, better way of presenting turn information can
be invented.
(2) GIVE/GET/BUY/SELL across sublocations.
I suggested this originally because I felt that it was inconvenient
and led to unnecessary player errors. In my opinion, it had little
effect on game play.
Several people have pointed out that it actually does affect game
play to a certain extent, such as losing your top spot in a location
when you leave to do a BUY. However, I think David argued it well:
it is fairly ludicrous that a noble can command an army of a 1000
highly-trained men but doesn't have a servant he can send to buy a
unit of pitch.
So I'm in favor of this change, although I wouldn't cry if it didn't
happen. (I am getting tired of taking twice as long to finish my
boats and inns because I can't get into them to give the builders
more materials, though.)
(3) Conditional orders.
My feeling with conditionals is that (1) generally people want them
and (2) generally people think they might be abused and/or make the
game a programming contest (which few people seem to want). Since I
agree with both these points, I'd like to look for a way to
incorporate conditionals into Olympia without ruining the flavor of
Olympia.
One suggestion has been to limit conditionals by making the test
part of the condition take 1 day. I don't like this for two
reasons. First, taking a day to complete the condition strains the
usefulness of the conditional. Second, it doesn't prevent people
from stacking and overlapping conditionals in very complicated ways,
which returns us to the "programming problem".
The suggestion I like best at this point is to simply limit each
unit to 4 (or some other small number) of conditionals per month.
While this limit is totally arbitrary, it will add conditionals to
the game without creating huge problems. (Or so I feel anyway.)
I'd like to hear other people's suggestions on how to limit
conditionals.
-- Scott T.