You can move from one connected zone to another adjaciently connected zone. However, how long it’ll actually take (ie. how many phases), depends largely on your game’s battle system. The movement precision unit within each zone itself should be based off the typical movement allowance of the average unit in the game per phase. How to account for slight movement speed differences per character, is to be discussed elsewhere. But obviously, it’s impossible for FATE-style zones to fully accomodate a single move in all situations (short of subdividiving the map too much to eventually become overly gridded), thus, a certain amount of tactical positionings must still be tracked from WITHIN the zone itself.
Tactical positioning within each zone is based off aspects , and is represented by whether you are at the located at the “center” of the zone, or “favoring a particular facing edge aspect within it from the center”, “or directly over a particular facing edge itself). Thus, “how deep you are” within the zone, in relation to a particular edge, is important and can mean the different between an enemy being able to spot you or not, or whether it takes longer to approach a particular destination because your position favored some other direction instead.
Moving towards a certain direction to favor a certain aspect would allow you to “get closer” to a destination along that aspect, but comparatively “further away” in relation to the oppsoite-facing aspects (or any other facing aspects). I’m trying to come up with a consistent way of calculating such “aspect” distances in this document.
This style of movement and tracking of relative position/distances within each given Zone (and across multiple Zones), is known as “Aspect-oriented” movement.
Normally, if favoring an aspect, place a counter within the respective facing aspect “sector” slice of that zone. If at the center (ie. no favoring), place at the center. If at the edge (ie. arrived, but do not wish to push out of that zone but stay within the fringe), place within the zone sector but with the counter’s base touching the edge of it.
I reccomend stackable counters that can easily see all the units in the stack. (Some pole for stackable flags, eg?)
To represent “movement-in-transit” situations from one location aspect/edge/center to another, or how much “favoring” occurs, have some sticky directional arrow counters to stick on the main unit counter to represent “how many moves/offsets” he has made so far along that particular direction towards the intended/favored destination. This can also be used to track his exact position reference within the zone itself at any given moment within each zone aspect.
Demarcation guide
The territorial polygon subdivision for each zone should be pretty close to a circular/squarish 1:1 aspect ratio. Eg. For longish zones (eg. a football field), you’d need to furhter subdivde it into zone polygons that are sized more towards a 1:1 aspect ratio. (So, it might be 2 halfs of a foogtball field, for example..). FOr a long road, the long road would be further subidivded into regular intervals to represent a fairly squarish zone segments along the road.
Typical “movement size unit” for each zone is represented by a rough “Move” unit to represent it’s radius from the “center” of that zone. Eg. A “Size-3 Zone” requires a total of 6 moves to cut across from one side to another opposite side, 3 moves to move towarsd the center of it from the edge of it. This can then be translated narratively to the descriptive “size” of the zone across all directions. The “Size” of the zone is explicitly designated per zone.
Every movement intention from one zone to another implies “Favored direction towards another zone”. The movement distance required is based off the size (aka. radius) of the zone, from the center, or if moving completely through it, double that radius (ie. the “diameter”).
Steering
Every side of a polygon zone may have a designated a steering aspect in relation to another side. For a roughly “Perpendicular” side aspects interseecting around 90 degrees, it’s an “Aspect-2” steerign ratio. For something intersecting lesser than that (ie. pretty much can be towards a roughly “Common” direction), it’s an “Aspect-1.5” steering ratio. For an “Opposite” facing side around (infinite/near-infinite) angular intersection at around 180 degrees, there is no steering aspect to it . This aspect is used to determine the “minimal” additional movement distance required to steer position from 1 aspect facing of the zone to another if you need to change direction halfway to another edge in order to switch destinations, before resuimg movement along that new facing aspect., If there’s no aspect to your movement in relation to another side, you would often prefer to backtrack completely the distance you have traveled so far back to the center of zone, before being able to move the full radial distance of the other side of the zone (ie. steering across multiple aspects would likely cost more movement..). The additional steering movemetn distance required is: RoundUp({Movement distance so far from center}*{Aspect Ratio} - {Movement distance so far from center})
when transitinoing (aka. “wheeling”) from 1 aspect facing to another. Once you’ve completeled this steering movement distance required, you are considered to have successfully switched to favor another edge aspect of that zone.
To identify “Aspect-2” sides, (instead of “Aspect-1.5” sides), 90-degree markers at corners of the polygon zone visualsation can be used to divide edges and deem them to be considered Aspect-2 sides relatively when divided in between by a 90-degree marker.. When comparing a side to another side that is divided by another in-between “Aspect-2” side (eg. that side is deemed “Opposite”).
Besides wheeling to any adjacient side along the given designated aspect ratio between the adjacient sides, you may attempt “wheeling” from any contiguous set of “Aspect-1.5” sides to another “Aspect-2” side connected to the above set, as if the set of “Aspect-1.5” sides are treated as a “single side” in itself.
Side travel favoring
“Don’t walk along the center of the road, if you want to grow old…”
When moving through a polygon zone, you may not necessarily move directly through the center of the zone. but instead move parallel in the direction across the center dividing line of the zone but offseted from the center, in opposition to the other “opposite side” of the zone. You can only move along a common set of Aspect-1.5 edges “as if it’s a straight line across the zone”.
When attempting this “sidewalking” strike-thorugh movement favoring a particular side of the zone, you must decide how far away from the actual center of the zone you wish to favour (ie. common set of Aspect-1.5 edges). By default, this incurs no additional mvoement cost through the zone since you are basically cutting through a “supposedly squarish” zone, just not through the direct center of that square but favoring a particular “side” offset from the center of it. The offset can be as large as the size of the zone itself, thus straddling close along the edge within the zone.
If this “side” you are travelling along the zone consist of multiple “Aspect-1.5” edges, how to track which edge facing aspect you are currently located in (and thus your “exact” position) while moving along this “straight” movement path through the zone? What facing aspect you currently exist in is simply divided equally (by default) across the total square diameter distance through the zone. So, if this “side” of the zone has 2 Aspect-1.5 edges, then if you haven’t crossed over the “center-line” , your position still belongs to the 1st Aspect-1.5 edge facing aspect of that zone. For 3 Aspect-1.5 edges, simply divide the total diameter distance by 3 to determine how much movement is required along this path per Aspect-1.5 edge switch. For For 4 Aspect-1.5 edges, do the same likweise by dividing by 4, and so on. Normally, you only need to do this if somewhere along your movement direction, you wish if you wish to change your movement direction to (eg. move towards another connected zone elewhere or towarsd the center of the current polygon zone you are in), thus you need to know what zone aspect you are located in at that moment, in order to calculate the new movement distance towards your new destination. Also, if someone wishes to aim at you, you’d obviously need a properly trakced position reference of where you are currently at within the zone during your travel transition to accurately determine base reachability/range to contact.