By combining zones into clearly defined interconnected polygons, spatial relationships between zones can be determined.

Tactical Waypoints/Zones RPG Mapping System >>

What are tactical waypoints?

Waypoints represent points, path corners/junctions and regions around the map of particular interest. Think of it as “rooms” in narrative-style text-based adventure RPGs or MUDs (roleplaying games or multi-user-dungeons). The difference however, is the ability to spot other characters across multiple waypoints, and pre-declare ranged attacks or other combat actions. So, they don’t act as mere self-contained rooms, but as actual locations/spots with various linked relationships. Such waypoints are linked by a graph system, so such waypoints are also called “location nodes” belonging to the graph, connected by arc lines.

Each tactical waypoint has a “Size” assosiated with them to indicate roughly the maximum amount of people that can occupy the waypoint before it becomes crowded and such. It contains other information like the “openess vs encloseness” of the waypoint, and other tactical-related information that can be used to handle procedurally unscripted combat/non-combat encounters that isn’t restricted to just a single location alone. Stuff like entrances, chokepoints, doors, open vs enclosed paths, etc. can be represented by the waypoint system and can be used by both AI, CRPGs, players and GMs to handle unscripted tactical encounters in a fairly spatially aware manner. (Don’t expect it to be fully precise down to the “millimeter”, though.). AI-generated Movement paths/funnelled coridoors can be determined in a roughly accruate manner over over such maps’ waypoints as well.

Tactical waypoints can be labeled with abbreviated visibility codes allowing you to quickly see at a glance (without needing a computer) what location waypoints areas are visible in relation to others and better understand the nature of that waypoint. All NPCs, potential encounters, etc. can be created/spawned in relation to these tactical waypoints.

The purpose of such waypoint design is to provide a “text-based adventure” narrative feel to both adventuring and combat sequences in an RPG (somewhat like a gamebook/pen-and-paper RPG combination), but without necessarily having movement restricted entirely to it and allowing more “open-world/emergent” sandboxed events to occur within such a gridless narrative map system. Both PCs and NPCs will be able to make informed decisions of where to locate themselves, either to observe, scout, hide, etc., and provide more avenues of actions to experiment and play around with the given system.

Example map:

An example wip preview map on notated waypoints. This is just an example to indicate how notated waypoints can be used to be able to determine clear-cut visiblity rules between locations.

https://s27.postimg.org/4c23y4ixf/tacticalwaypoint_preview.jpg

Map source: https://www.pinterest.com/pin/516225176023649276/

Is there a map editor/creator app for this?

Yes, there is an app for this. But some of the key specifications of this mapping system are still a pen&paper testing stage and have not been dived in to be fully coded-in yet.

Determining ranges.

Primarily using range band system.

If the map is a scale-map, range band template pieces can be easily used. Or compass.

If it isn’t entirely drawn to scale, rough estimates can be used at GM discretion, or if using a CRPG, some projection or/and per pixel/arc distance weight map can be used to infer approximate ranges between location waypoints. Or a precomputed truth table of ranges.

Visibility notation format >>

Determining LOS/Visibility Detection.

The LOS/Vis engine is key to this mapping system. What’s more? With the following abbreviation format, it’s fairly easy to glance over this on the illustrated map and plan out your visibility encounters accordingly.

Such notations within the linked graph act as a guide to show what locations can possibly be visible from where in a “generalised/coarse” manner. They therefore serve as a guide to perform “rough/good enough” visibility resolution, OR, if you need precision, may be used as a basis for more precise visiblity resolution with a to-scale map.

How to read visibility notation format from these tactical waypoints?

(1st Visibility part).(2nd Visibility part)

Unless otherwise stated in the docs, visibility is assumed to be always a 2-way (vice versa) affair.

Note that the Waypoint/Visibility Notation Spec is a work in progress and more stuff will be included later on to involve various possibilities when they are encountered.

1st Visibility Part

Core Visibility propagation rule number:

Diminised Core visibility flag -

After the Core Visibility Propagation Rule number, a - suffix can be added to indicate diminished state for the Core Visibility Propagation rule to further modify it and reduce it’s potential visibility in a more nuance manner.

For diminished cases 2 and 3, You may also use double diminished notation (ie. 2 consecutive minuses --) to assume stricter “lower number” effects of that diminished core visibility.

Double diminished cases:

Other visibility flags

The other visibility flags indicate secondary rules/alternate means to propagate visibility accordingly.

After the number in the 1st part, lower-case letters are used to represent other visibility related flags, each letter representing a specific flag. This letters may include a related number after it to indicate more information regarding it.

Path visibility flag p:

Entrances (openings) e:

Examples:
3e+
3e.+L

When a waypoint position is marked with “e” for the 1st part, the waypoint position acts as an “entrance-like” tunnel opening which can be spotted/fired through that opening from any directly linked location further behind as well. This is by default done with a greater limited field of view region (ie. set up limited tunnel trap region for visibility check based on the size of the opening). However, if at the given entrance, it is assumed there is no field of view limitation from it by default, unless further notations are added.

When you are located at a given “entrance” node, your position of “which side of the entrance” you are located in (ie. which connected location to the entrance node you are “favoring”), must be noted.

If the location is further marked with an e+ (ie. additional + after e), visibility through that position is always limited to a tunneled limited field of view based on the size of the opening, even if the character is located directly at that location itself. This normally applies to very small openings like murder holes. The disadvantage of narrower openings though is that they give lesser time for a character to react when spotting someone running through the visible region of that narrower opening. Rules for handling such aspects are handled in your respective RPGs.

If the location is marked with an e-, that location acts as a full visibility gateway from any immediate linked position behind to allow you to look directly across the entrance to the next immediate connected location without needing a limited tunneled field of view at all (ie. you can see all of the next adjacient location).

Suffixing the e definition with a # character will always restrict the visiblity propagation of that entrance to the next immediate adjaciently connected location only, and will always stop the visiblity propagation beyond that point. (eg. e#, or e-# or e*#, each with their varying natures, will restrict visiblity scope to the next adjoining location(s) from that entrance, and visibility can never propagate further.

Doors d

In most cases, Doors work together with the Entrance flag but may not necessarily be the case at certain “odd” times where there is some “door” without an “entrance”. Not to be taken literally (eg. a furniture door) , “doors” conceptually allow you to determine whether that location state is “open” and “closed”, and thus block/limit both visibility and travel through it if the door is closed. You can also lock the door location node, so the door cannot be opened and you can’t get pass a door location.

Doors are deemed default closed by default, unless you add a number after the d to represent the modified state of that door.

The decimal number after the d flag indicates the bitmask binary state of the door, with the first 2 bits (1 and 2) ) representing the openness of the door and the last bit (4) representing the state of the lock of that door. For quick reference you can just check the truth table legend below for all the possibilities.

Typical legend:

Unusual door bitflag combinations:

Unusual door bitflag combinations from d5 onwards can be used to represent the state of a door being yanked opened, but the door lock turn is still turned to “locked” position, which may mechanically interfere with it’s closing due to a jutting lockpiece. Alternatively, it can be used to represent a door that is automatically locked the moment you close the door, (eg. 1 way doors, electronic hotel room doors, or a door with the lock button pressed in, etc.).

Transparent see-through doors may be marked as transparent in such cases by suffixing it with a - flag. (eg. To produce something like d4-, where the door is fully locked and fully closed, but also fully transparent and can be seen through). This may be combined with the e entrance flag for additional tunneled visibility information through that given entrance+door node combo.

Implied doors

In some cases, for brevity, doors might be “implied” by the GM and players based on “common-sense” and not explicitly shown as it’s own locatio waypoint on the map. For such implicit cases, it is assumed the door lies along the given connection line on some “breakpoint” between the 2 locations, usually where the line intersects the outlying region of the “entering-in” location, or at the weighted midway points between the 2 locations. Alternatively, this can be infered from the map illustrations themselves.

Usually, it’s best to explicitly mark doors with d locations to avoid such ambuigity (particular for CRPGs), but sometimes, it can be cumbersome to do so.

Blockades b:

Blockades do not allow you take up position directly “inside” the waypoint, but only around the radius of it. Once you are at a blockade, you must favor a specific side of the blockade in order to be able to take cover or hide from relavant enemies with this blockade. Whether you are able to hide fully or not is dependant on the height/size of the blockade itself (For this, use your common sense based on the 3D nature of the blockade.).

The number suffix after b indicates the visibility rules of this blockade in relation to it’s surroundings. Usually, the higher the number, the “better” it is in blocking yourself from the other surrounding locations.

Blockade rating legend:

If number is left out, it is assumed b3 is used.

Multiple connections to a blockade might be further marked with a connection group capital letter on the 2nd part which is preceded by a lowercase b (eg. bB, bC, etc.), as if being treated as 1 whole connection-group with regards to the blockade if they share the same capital letter.

Visibility propagation path being traced to a given blockade node will take the “shortest path” to that location, often based on heuristic means or by GM arbituation with whatever that “makes the most sense”.

Coverc:

Cover works exactly similar to Blockades, except that the location marked with c(cover) instead of b (blockade), allows you take visible cover within/inside the location itself (like a regular location node) unlike being forced “around” it like what blockades do. Thus, cover doesn’t necessarily block much movement. Examples may include brush, area around a tree, or obstacles that aren’t “blockishly” large enough to be significantly considered a blockade obstacle.

Core Visibility Bypasses

In some cases, a particular location node might be a sunken ground region/crater, etc. region that is still directly crossable, but characters from surrounding regions may not be able to visibly look into that location due to it’s sunken slope, but yet may still be able to look beyond/across it. This notation allows you to specify concavely sloping regions on the map that is still crossable on foot.

For such a case, you can specify 2 Core visibility values, divided by a slash / character. The 1st value represents the visibility rule for looking “into” that location, while the 2nd latter value (aka. the bypass section) indicates the visibility rule for propagating visibility beyond that location. Thus, this allows to propagate visibility beyond that target location even though that target location itself may not be visible from where you are.

Examples:
0/2 - Perhaps a “shallow” crater. Can see openly beyond it (right 2) but you must be in a location at least adjacient to it to look into it (left 0).
1/2 - Perhaps a “deeper” crater. Can see openly beyond it (right 2) but you must at least reach into it’s border to look into it (left 1).
0/3p - Only visible across it along any given straight connected path set of locations (right 3p). But target location itself is only visible if you arrive at a any location adjaciently connected to this location itself (left 0).
1/3p - Only visible across it along any given straight connected path set of locations. But target location itself is only visible if you arrive to at least the border of that location itself.

Peak flag k

Any waypoint or connected set of waypoints marked with a k flag represents a PEAk location where being closer to the center of that waypoint location region, implies a “closer to peak/highest point” sort of state.

In certain cases, if you take up position at directly close enough to a peak location’s center or projected peak crest line along consecutively connected k path of nodes, your character’s figure would be silouetted against the sky, leaving you easily spotted. Characters found in/around peak locations may want to avoid positioning too close to these lines/points to avoid being detected (ie. staying within the military crest https://en.wikipedia.org/wiki/Military_crest ), to avoid sillouetting themselves against the sky. In some cases, if they have to move, they may have to cross k and expose themself along the horizon. Alternatively, if stealth is essential, they may have to make a detour around k.

Of course, if you want to get noticed, staying at the peaked areas will make you much easier to spot.

2nd Visibility Part

Visibility-only Lookout position +L to target waypoint location node reference. .+L

A lookout position represents any position that has a connection link to another target reference waypoint that isn’t directly reachable on foot (eg. from elevated platform, etc.), but still has visibility towards that particular location. Such a lookout position is marked with any capital letter on 2nd part with a preceding +, and this represents a unique Letter reference to a particular matching target waypoint location node (whose notation’s 2nd part also contains that matching capital Letter ).

Lookout positions linking to it’s target waypoint location node reference, visually uses a dotted line link (instead of a solid line) to represent a “visibility-only” state of that link. You can’t travel directly from one location to another connected by a dotted line link.

The target waypoint location node is by default visible from that lookout position. However, depending on the lookout position notation of that target waypoint, it can provide further additional visibility propagation as shown in the list below.

Notation legend for lookout position’s target waypoint location node:

Examples:
3.+L

Teleport .*T

A teleport position (marked with any capital Letter on 2nd part with a preceding *), represents a position containing a teleportation link from one location waypoint to another. In various cases, this can represent an actual visual portal .

The size of the location node may represent the size of the “portal”.

If not combined with a plus sign (eg. *+T), it is assumed that the portal is “opaque”, and you can’t use the portal as a lookout point to that other connected location.

Non-opaque “lookout” portals with the + are deemed 1-way by default, unless you link the visibility-only lookout connections from both nodes. A two-way lookout portal can be represented with two consecutive pluses (eg. *++T).

For the 1st part, this may be combined with the entrance e flag to further indicate an actual “portal” window tunnel region which you can look through into the other location, but with a limited windowed field of view, and a door d flag to indicate whether the portal is closed/opened or/and locked accordingly.

Whether you can shoot or throw something through a portal is not, is left up to the description notes of that given waypoint. When an e entrance flag is included in, this is assumed to be the case by default.

For the 2nd part, any number after the capital Letter follows the Lookout position format (refer to the L-L3 table) visibility propagation details.

Examples:
3.*T

Along path visibility flag .p:

When the 2nd part of this location includes a lower case “p” letter, it indicates a “along path” visibility state, as if the location exists along the path itself. As long as there is path visiblity along the path connected to this location, this location itself is considered visible as well.

Take note, however, that this flag (being in the 2nd part) doesn’t mean visibility would necessarily propagate further from this location, only that this sole location itself is visible along the given path.

Examples:
3.p - Along path visibility.
2.p - Along path visibility, but doesn’t necessarily mean will propagate visiblity further (unless 1st part rule succeeds as well).

Implied concealment/obscurity

If propagated visibility through the Visiblity Notation graph happens to cross into/over a location node that has certain aspects of concealment/partial cover (eg. vegetation, trees, ruins, etc.), concealment penalties apply and may still make it hard/unable to spot/target enemies across those areas. At times, it may only allow you to “roughly” spot some “movement/rough shapes”, but will be unsure of the exact nature of such targets. Visibility notations typically only consider whether a character may spot another across the map in a general fashion, without factoring other conditions typical in actual battlefield conditions.

How such “camouflage/concealment” penalties/challenges are to be applied, lies outside the scope of this document, and is handled respectively by your own RPG rules. In most cases, the camouflage/concealment penalties will typically stack if the visibility propagation along the graph crosses over multiple layers of such areas.

Methods to determining waypoint assosiations and (optional LOS)

(Mix and match when approproiate)

In summary, in conjunction with the waypoints’ Visibility Notations, there are 3 similar variations to determiming actual map visibility towards specific target character positions or “where” a character should be located in:

  1. Pure narrative “character is somewhere inside” waypoint location
  2. From spatial 2D character position, select exclusively to be assosiated to 1 location that is exclusively within it, or within closest proximity/point to. (or variations of this thereof..) . A Weighted Voronoi grid overlay can be used to help determine this.

1. Pure narrative method:

Do not have exact spatial positions on the map (or at least, don’t reveal them to players), but simply assosiate characters directly to the waypoint nodes thsemselves narratively. When you do this, there is no “in-between” positions anymore. They are basically “inside” that waypoint, but exactly where within it is purely an optional descriptive affair by GM. Though player favoring of certain sides of that waypoint would be factored in by the GM.

When it comes to visiblity along a path lined up with walls/blocking sides, sometimes, favoring a particular side of the path when traveling along it might allow you to detect enemies “earlier”/“later” along the road when turns are encountered, or make you easier to spot on the opposite “open” side of the path vs the other side. This is often done on a “just-so” case by the GM, and may matter/not matter in various circumstances.

When travelling from one waypoint to another where there is distance to cover, this is again a “1d meter/text-based” affair. Simply strike off the distance until waypoint is reached, and GM prompts players on their intentions of general movement direction intents like “further in”, or “moving around border”, etc.. Though favoring of a certain side/flank when traveling along a certain path may involve a 2D/3D aspect, this may not be reflected on the map, or even if done so, no LOS tests are done because such positions are merely “conceptual” positions and never exact positions.

2. Narrative coarse position method with position abjucation

We still keep 2D spatial character positions on the map to deal with proximity assosiation to the given waypoints.

When a position lies solely within the radius of that given waypoint and doesn’t lie within any other waypoint, character “assumes” position at that waypoint.

He is either considered “bordering” the waypoint, or “inside it” if he is “deep enough” within it by a certain threshold thickness.

Expect positions within a generic waypoint radius to yield visual false positives/negatives when tracing actual 2d spatial LOS on the background image. As always, the background map image isn’t really used in determining LOS, and positions placed on it are more conceptual than spatial by using the waypoint radii. Players must be willing to accept such “jarring” cases where it appears as if there’s LOS visually on the map’s background image when there isn’t, or when visually it appears that there is LOS, but in narrative/conceptual rules, there is no LOS until he “crosses over” to the new designated waypoint location.

Alternatively, play the map without any overlaying background map image, just waypoint radii diagrams for a more abstract representation.

Abjucation of straddling/lying between mulitple wyapoint locations:

But what happens if a character doesn’t lie exclusively within a location radius?

Below are various methods you can mix and match as you see fit.

Include a voronoi grid itself? (as shown above)

This requires additional pre-processing to convert a set of sized waypoints on the same level into a voronoi grid itself. So, each convex polygon space clearly represents the location node assosiation a character is tied to. Again, this system isn’t entirely precise, it justs provides a clear-cut means of tieing a character’s 2D position to a particular location node for gaming purposes. Primarily, a voronoi grid provides a diagrammitic-2d-spatial representation of these narrative-based locations for rough estimates of distances.

https://www.youtube.com/watch?v=JqXwf_xj5Sk

Effectively, it’s pretty much the same as eyeballing the “midpoints” between 2 or more sized waypoints on the spot from where a character is, to determine which location waypoint he should be tied to.

However, by including a grid, this is clearly marked out for easy visual referencing.

Coding/algorithm references to generate voronoi grid from weighted sites:

https://github.com/Kcnarf/d3-weighted-voronoi
https://github.com/zbryikt/voronoijs
https://github.com/ArlindNocaj/power-voronoi-diagram

https://www.uni-konstanz.de/mmsp/pubsys/publishedFiles/NoBr12a.pdf