The reasons given were:
o Don't discount atmosphere, it's important.
o Time provides rich, realistic mechanics while being simple
to understand because the concept is familiar to everyone.
o Modelling time gives us the ideal game mechanic -- something
which is simple and straightforward for the novice to use,
but which can be optimized to death by power players trying
to eek out a little extra advantage.
Can we take the reasons why modelling time is good and apply them to
other parts of a PBEM, such as the map?
I think of Olympia's map as being nodal. It takes a long time to move
from province to province, but within each province/cluster, movement
is fast. Locations are subjectively large, so everyone in a city is in
the same place. It doesn't take any time to leave a castle in the city
and get on a ship at the dock.
I chose this model to make the game easier to play, believing that
a straight grid or hex map with line-of-sight rules would be too
fine-grained to work with in a PBEM format with a week turnaround.
Or do the arguments in favor of realistic time suggest having a
realistic map as well? (Better atmosphere, more complex yet easier
to reason about.)
Some of you figured that I must have been beaten down by hordes of
naive newbies whining about cascading order failures, and was ready
to chuck Olympia time. It's true that I am always trying to think
of ways to minimize player errors, but I wasn't considering removing
time from Olympia. Thanks for your concern and nice comments, however.
I originally approached Olympia as a simulation, knowing nothing about
game design. I wasn't excited by abstract point systems, I wanted
thousands of units moving about and interacting in a virtual world.
Some players really fall in love with the simulation side of Olympia
(as I was awe-struck upon seeing a T'Nyc turn report). Others are
indifferent to it. This latter group, I assume, would have no trouble
with phases-and-points. But since apparently there aren't any
representatives from the latter group on the design list... :-)
(Which is not surprising, I suppose, as they probably aren't even
-- Rich Skrenta <email@example.com>