123 lines
7.3 KiB
Markdown
123 lines
7.3 KiB
Markdown
# 5D Diplomacy With Multiversal Time Travel
|
|
|
|
_5D Diplomacy with Multiversal Time Travel_ is a _Diplomacy_ variant that adds multiversal time travel in the style of its namesake, _5D Chess with Multiversal Time Travel_.
|
|
|
|
## Acknowledgements
|
|
|
|
This project was inspired by [Oliver Lugg's proof-of-concept version](https://github.com/Oliveriver/5d-diplomacy-with-multiverse-time-travel). The implementation is based on the algorithms described by Lucas B. Kruijswijk in the chapter "The Process of Adjudication" found in the [Diplomacy Adjudicator Test Cases](http://web.inter.nl.net/users/L.B.Kruijswijk/#5) as well as ["The Math of Adjudication"](http://uk.diplom.org/pouch/Zine/S2009M/Kruijswijk/DipMath_Chp1.htm). Some of the data model is inspired by that of Martin Bruse's [godip](https://github.com/zond/godip).
|
|
|
|
## Variant rules
|
|
|
|
### Multiversal time travel and timeline forks
|
|
|
|
_Diplomacy_ is played on a single board, on which are placed armies and fleets. Sequential sets of orders modify the positions of these units, changing the board as time progresses. This may be described as something like an "inner" view of a single timeline. Consider instead the view from "above" the timeline, from which each successive state of the game board is comprehended in sequence. From "above", each turn from the beginning of the game to the present can be considered separately. In _5D Diplomacy with Multiversal Time Travel_, units moving to another province may also move to another turn, potentially changing the past.
|
|
|
|
If the outcome of a battle in the past of a timeline is changed by time travel, then the subsequent future will be different. Since the future of the original outcome is already determined, history forks, and the alternate future proceeds in an alternate timeline.
|
|
|
|
Just as units in _Diplomacy_ may only move to adjacent spaces, units in _5D Diplomacy with Multiversal Time Travel_ may only move to adjacent times. For the purposes of attacking, supporting, or convoying, turns within one season of each other adjacent. Branching timelines and the timelines they branched off of are adjacent, as well as timelines that branched off of the same turn in the same timeline. A unit cannot move to the province it is currently in, but it can move to the same province in another turn or another timeline.
|
|
|
|
When a unit changes the outcome of a battle in the past, only the timeline of the battle forks. If an army from one timeline dislodges an army in the past of a second timeline that was supporting a move in a third timeline, an alternate future is created where the army in the second timeline is dislodged. The third timeline does not fork, since the support was given in the original timeline. Similarly, if a unit moves into another timeline and causes a previously-successful move from a third timeline to become a bounce, the destination timeline forks because the outcome of the move changed, but the newly-bounced unit's origin timeline does not fork because the move succeeded in the original timeline.
|
|
|
|
### Sustaining timelines and time centers
|
|
|
|
Since there are many ways to create new timelines, the game would rapidly expand beyond all comprehension if this were not counterbalanced in some way. This happens during the _sustain phase_, which occurs after the fall movement and retreat phases and before the winter buid/disband phase.
|
|
|
|
WIP: the sustain phase has not been implemented yet
|
|
|
|
### Victory conditions
|
|
|
|
The Great Powers of Europe can only wage multiversal wars because they are lead by extradimensional beings masquerading as human politicians. When a country is eliminated in one timeline, its extradimensional leader is executed, killing them in all timelines.
|
|
|
|
### Unit designations
|
|
|
|
In _Diplomacy_, orders refer to provinces, such as "A Mun-Tyr". In _5D Diplomacy with Multiversal Time Travel_, this is insufficient to unambiguously identify a province, since the province exists in multiple timelines across multiple turns. The convention for identifying a multiversal location is `timeline:province:turn`, where `timeline` is the timeline's identifier and `turn` is the turn's identifier. Thus, an army in Munich in timeline "bravo" in Spring 1902 is referenced as "A b:Mun:S02".
|
|
|
|
(Why this order? Short representations for timelines and turns can be confused for each other, especially for timelines designated with `foxtrot` or `sierra` and turns in Fall or Spring. _5D Diplomacy with Multiversal Time Travel_ is already complicated enough, so the timeline and turn are put on either side of the province.)
|
|
|
|
WIP: parsing of turn designations has not been implemented yet
|
|
|
|
### Open convoys
|
|
|
|
The standard _Diplomacy_ rules require that a convoy order include the convoyed unit's origin and destination. This is hard to coordinate once there are multiple turns and timelines involved. _5D Diplomacy with Multiversal Time Travel_ thus introduces the concept of an _open convoy_, a nonspecific convoy order that can become part of a convoy later.
|
|
|
|
WIP: open convoys have not been implemented yet
|
|
|
|
## DATC compliance
|
|
|
|
WIP
|
|
|
|
## 5dp script
|
|
|
|
Order notation is case-insensitive.
|
|
|
|
### Order element grammar
|
|
|
|
A unit type is specified with a single letter.
|
|
```
|
|
<unit-spec> = "A" / "F"
|
|
```
|
|
|
|
A timeline is specified with a primary designation initial, plus a secondary designation if there are enough timelines.
|
|
```
|
|
<timeline-spec> = <tl-primary> <tl-secondary>
|
|
<tl-primary> = "a" / "b" / ...
|
|
<tl-secondary> = "" / "1" / "2" / ...
|
|
```
|
|
|
|
A province is specified with a known three-letter abbreviation. A named location in a province may optionally be specfied with its abbreviation. A named location is not necessary for the _form_ of a province to be valid, though an order may be invalid if the omission creates an ambiguity.
|
|
```
|
|
<province-spec> = <province> ["/" <location>]
|
|
<province> = "MUN" / "TYR" / ...
|
|
<location> = "nc" / "sc" / ...
|
|
```
|
|
|
|
A turn is specified with the season's initial and the short form of the year. Winter is numbered in the year of the previous Fall.
|
|
```
|
|
<turn-spec> = <season> <year>
|
|
<season> = "S" / "F" / "W"
|
|
<year> = "01" / "02" / ...
|
|
```
|
|
|
|
A multiversal location is a timeline, a province, and a turn separated by a colon.
|
|
```
|
|
<multiverse-spec> = <timeline-spec> ":" <province-spec> ":" <turn-spec>
|
|
```
|
|
|
|
Thus, `b1:IRI:F02` represents the Irish Sea, in Fall 1902, in timeline bravo-prime.
|
|
|
|
### Order formats
|
|
|
|
Note that DATC 4.C makes unit designations superfluous outside some build order cases. Thus, the `<unit-spec>` is considered optional in the orders below.
|
|
|
|
Hold orders require the unit and an indication of a hold order.
|
|
```
|
|
<hold-order> = [<unit-spec> " "] <multiverse-spec> " " <hold-token>
|
|
<hold-token> = "hold" / "holds"
|
|
```
|
|
|
|
Move orders require the unit, target, and an indication of movement instead of support.
|
|
```
|
|
<move-order> = [<unit-spec> " "] <multiverse-spec> <move-token> <multiverse-spec>
|
|
<move-token> = "-" / " to "
|
|
```
|
|
|
|
Support-hold orders require the unit, target, and an indication of support instead of movement.
|
|
```
|
|
<support-hold-order> = [<unit-spec> " "] <multiverse-spec> <support-token> <multiverse-spec>
|
|
<support-token> = " S " / " support " / " supports "
|
|
```
|
|
|
|
Support-move orders require the unit, target, and the support and move indicators.
|
|
```
|
|
<support-move-order> = [<unit-spec> " "] <multiverse-spec> <support-token> <move-order>
|
|
```
|
|
|
|
Convoy orders WIP.
|
|
|
|
Retreat orders WIP.
|
|
|
|
Build orders WIP.
|
|
|
|
Disband orders WIP.
|
|
|
|
Sustain orders WIP. |