>Appendix A: Notes on Realism
>-----------------------------
>
>Game design often requires tradeoffs of realism against playability.
>Here the author attempt to justify, or at least apologize for, some
>of Olympia's.
> o From time to time a player will suggest that Olympia should use
> a hex grid instead of a nodal map. While many games do make use
> of grid maps, the PBM format makes it difficult to work with that
> fine a level of granularity.
Nodal map? It looks very much like a square grid to me. It could easily be
made to look like a hex grid too, without significant change to the way the data
is stored (I suspect). The mapping from a hex grid to a square grid is fairly
trivial (either a brick pattern, or a diamond pattern would do, though the
former is probably nicer). Is it worth it? Probably not if the code is already
in place, but if ever that area needs heavy rewriting... consider it at least.
> Olympia's geography is based on subjectively large provinces
> whose contents are all considered to be in more or less the
> same place. The rule is:
>
> Units in the same region can interact with each other;
> Units in different regions cannot.
>
> It is hoped that Olympia's abstract nodal map models the
> important aspects of game geography, while omitting less
> significant details, to enhance playability in the PBM format.
>
>
> o Units in Olympia move by first waiting the duration of the journey
> in the starting location, then instantly jumping to the destination.
> This offends realism in several ways: One can see units long after
> they have departed; an interrupted movement order instantly brings
> units back to their starting location; and interaction (such as
> combat) is possible with units after they have left.
>
> Note that some interaction with units, such as giving items and
> stacking, is explicitly prevented after they have begun movement.
> Combat is allowed up until the point a unit has actually moved out
> of a location, however.
>
> Why not do it another way?
>
> 1) Make the route a pseudo-location, and allow units to
> stop part-way across, meet each other on routes, etc.
>
> 2) Have units go into "hyperspace" for the duration of
> their journey.
>
> 3) Have units spend half the time in the original location,
> and half in the destination.
>
> Option (1), depending on how it is implemented, either introduces a
> second level of a locality, or a second kind of location.
>
> If a second level of locality is chosen, then the definition of "in
> the same location" must be expanded to include how far along a
> particular route one is.
>
> If each sub-route along a journey is a full-fledged location, then
> we have constructed the route from little hexes, but the map has
> a very strange shape. If we are to choose hexes, then we should
> throw out the nodal route system altogether, and not try to combine
> the two.
>
> In either case, the rules become too complex and unwieldy.
>
> Option (2) extends the locality model by saying that a unit may
> be "nowhere"/in transit. This tends to foul up code that may want
> to know where a unit is.
>
> If a unit dies in nowhere, where does its dropped items go?
> What is the weather like in nowhere?
> Are two units in nowhere in the same place?
> What does a cast of "Locate character" show for a unit in
> transit?
>
> Although there may be answers for these questions, they all require
> special case handling in the code. Often asking unforseen questions
> about a unit in hyperspace results in a program crash.
>
> Furthermore, hyperspace allows units to easily hide from would-be
> attackers. To avoid combat, a unit need only stay on the move
> constantly, and no attacker will be able to pin it down.
>
> The objection to option (3) is that an interrupted movement
> would leave the unit at the destination without having traveled
> the required amount of time. I also felt that it was slightly
> cleaner to have the special no-interaction rules only for
> one case (departure) instead of for both departure and arrival.
>
> In a game with hex grids, one doesn't think twice about jump
> movement after a time=4 delay. Olympia's province routes simply
> take longer to traverse.
>
> The Olympian movement model is ultimately a tradeoff of simplicity
> vs. realism. Given the requirements:
>
> o One can't cheat by interrupting movement
> o One can't hide from combat by moving
>
> additional modeling or complexity in the movement model would add
> little enjoyability to the game. Thus, it seems best to choose a
> simple movement model.
I think that option 3 could be made to work and not violate the requirements
stated.
The first requirement can be maintained by treating a 'stop' during movement
specially.
If you are in the first location, and have travelled for 3 days, then it takes 3
days to get back to where you were, at which point you carry on as normal. If
you are in the second location, effectively you cannot stop during movement, and
will continue till you reach your destionation.
OR
You cannot 'stop' during movement. Period.
I do, however, question the ability to attack someone who has (essentially) 7
days head start on you. Dividing the journey into parts where the stack is in
each region reduces this problem in scale, but does not remove it. It also
keeps the ideal that wherever you are you _can_ be attacked. I think this would
be a reasonable compromise.
Of course the limiting factor here is how complex it would be to code and
describe the method described above. I don't see anything desparately tricky,
but I don't know what the code looks like.
John