After talking with Scav about notation variants I thought it'd be super useful if there were some generic format for representing a form than could then be displayed in whatever manner suited the user's fancy. It turns out not to be terribly difficult1, the main challenge being the development of a grammar that is both concise and unambiguous at the same time.
When writing forms down for typesetting what I've done to this point is to put the symbols into a .csv file in the same way I want them to be displayed on the page and then run the file through a fairly simple formatting script to turn it into a table. That .csv file looks something like:
RP SK,,RP ,BACK DDE, SS,,
This format has the benefit of being extremely concise; every character sequence is short and absolutely necessary. However, if I need to do any complex typesetting for something like a grapple it suddenly becomes an effing disaster:
<div>(LOW)<br/>⇈<br/>BB</div>,, ,,BS HP IB,FORWARD, ,NS,
It's no longer concise; the use of HTML for typesetting introduces a lot of extraneous characters which interfere with human comprehension. Additionally, in doing so I've committed the cardinal sin of mixing meaning and representation, making the file basically useless except in one particular situation. And I still have to do a lot of manual touchup of the resulting HTML so that things align properly. Wouldn't it be peachy-keen if there were a way to write down the meaning ("forward bird break against the opponent's left, outer wrist" in this case) in a easily typeable, easily readable fashion?
Turns out that the system I've been using is almost comprehensible to a computer as is. There is, however, an unresolvable ambiguity that arises from the use of direction ("forward", "back", etc.) to denote both the motion of the body and the direction of a strike. Consider the sequence
FORWARD RP
That could mean one of two things:
- Move forward while executing a reverse punch.
- Execute a forward reverse punch.
If I'm a human I'm going to look at the greater context to figure out what's going on. For example, if it appears on the left or the right it's a targeting instruction, since all movement glyphs appear in the middle column of a line of notation. It would be simple to teach that rule to a computer. But consider the following technique:
,LEFT DDBF, SS,, TK,JUMP FORWARD, SS,,
Does "LEFT DDBF" mean "move left while executing a double downward backfist block" or does it mean "left double downward backfist block"? I know which interpretation makes sense, but making that distinction is beyond the capabilities of a computer. That being the case we need some simple way to let the computer know that the direction is a targeting modifier and not a movement. Here's what I've come up with so far:
start → line* line → blankline | actionline blankline → [ \t]* '\n' actionline → left ',' center ',' right '\n' left → atom* center → atom* right → atom* atom → direction | jump | turn | action direction → 'BACK'|'LEFT'|'RIGHT'|'FORWARD'|'FORWARDLEFT'|'FORWARDRIGHT'|'BACKLEFT'|'BACKRIGHT' jump → 'JUMP' turn → 'TURNLEFT'|'TURNRIGHT' turn_modification_clause{0,1} turn_modification_clause → '(' \d+ ')' action → symbol modification_clause{0,1} modification_clause → '(' modifiers+ ')' modifiers → direction | grapple | symbol symbol → [A-Za-z]+ grapple → 'GRAPPLE'
What this works out to in English is
- A notation block is composed of carriage-return-delimited lines.
- All lines are either blank, or have three fields (left, right, and center)
- Each field is composed of multiple atoms.
- An atom can be:
- A direction, indicating motion.
- A jump.
- A left or right turn with an optional modification clause. The modification clause can be used to provide a number of degrees; when omitted 90° is assumed.
- An arbitrary symbol indicating a strike/stance with an optional modification clause. The modification clause can consist of a direction, a symbol (indicating the target), and the keyword "GRAPPLE" indicating that the move is a grapple. The usual defaults are assumed if no clause is supplied.
This seems to be pretty compact; in most cases it won't be necessary to type anything more than short symbols and commas. I suspect that as I work with this I'll probably expand it a little bit to account for things like comments, but this is the gist of it. Thoughts?
1 Those interested in the technical details can look here.
No comments:
Post a Comment