Update README with order parsing grammar
This commit is contained in:
parent
fa04aab6c6
commit
158c952b6b
99
README.md
99
README.md
|
@ -22,8 +22,105 @@ When a unit changes the outcome of a battle in the past, only the timeline of th
|
||||||
|
|
||||||
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.
|
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.
|
||||||
|
|
||||||
(TODO)
|
WIP: the sustain phase has not been implemented yet
|
||||||
|
|
||||||
### Victory conditions
|
### 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.
|
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 by name or abbreviation, such as an order given to "Army Munich" or a build order for "London". 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 might be referenced as "Army bravo:Munich:Spring 1902" or "A b:Mun:S02" for short.
|
||||||
|
|
||||||
|
(Why this order? If timeline and turn identifiers were next to each other, it could be difficult to immediately see which one is the timeline and which one is the turn if both are in a short representation, especially for timelines designated `foxtrot` or `sierra` compared to turns designated as being 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
|
||||||
|
|
||||||
|
## 5dp script
|
||||||
|
|
||||||
|
Order notation is case-insensitive.
|
||||||
|
|
||||||
|
### Order element grammar
|
||||||
|
|
||||||
|
Where a unit type is expected, either the full unit type name or a single letter is valid.
|
||||||
|
```
|
||||||
|
<unit-spec> = <unit-long> / <unit-short>
|
||||||
|
<unit-long> = "Army" / "Fleet"
|
||||||
|
<unit-short> = "A" / "F"
|
||||||
|
```
|
||||||
|
|
||||||
|
Where a timeline is expected, either the full timeline designation or an initial is valid. An omitted secondary designation is equivalent to a secondary designation of 0.
|
||||||
|
```
|
||||||
|
<timeline-spec> = <tl-long> / <tl-short>
|
||||||
|
<tl-long> = <tl-long-primary> <tl-long-secondary>
|
||||||
|
<tl-long-primary> = "alfa" / "bravo" / ...
|
||||||
|
<tl-long-secondary> = "" / "prime" / "second" / ...
|
||||||
|
<tl-short> = <tl-short-primary> <tl-short-secondary>
|
||||||
|
<tl-short-primary> = "a" / "b" / ...
|
||||||
|
<tl-short-secondary> = "" / "1" / "2" / ...
|
||||||
|
```
|
||||||
|
|
||||||
|
Where a province is expected, either the province's full name or a known abbreviation is valid. A named location in a province may optionally be specified with either its full name or a known 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-long> / <province-short>) ["/" (<location-long> / <location-short>)]
|
||||||
|
<province-long> = "Munich" / "Tyrolia" / ...
|
||||||
|
<province-short> = "MUN" / "TYR" / ...
|
||||||
|
<location-long> = "north coast" / "south coast" / ...
|
||||||
|
<location-short> = "nc" / "sc" / ...
|
||||||
|
```
|
||||||
|
|
||||||
|
Where a turn is expected, either the full seasonal designation or an abbreviated form is valid.
|
||||||
|
```
|
||||||
|
<turn-spec> = (<season-long> / <season-short>) [" "] (<year-long> / <year-short>)
|
||||||
|
<season-long> = "Spring" / "Fall" / "Winter"
|
||||||
|
<season-short> = "S" / "F" / "W"
|
||||||
|
<year-long> = "1901" / "1902" / ...
|
||||||
|
<year-short> = "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, the following multiversal locations are equivalent:
|
||||||
|
* `bravoprime:Irish Sea:Fall 1902`
|
||||||
|
* `b1:IRI:F02`
|
||||||
|
* `bravoprime:IRS:Fall02`
|
||||||
|
|
||||||
|
### 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.
|
Loading…
Reference in New Issue