IFWiki:ADRIFT project
This page is about the ADRIFT project on IFWiki. The aim of this project is to document the ADRIFT authoring system more fully.
Rough Notes
- All pages about ADRIFT should be categorized in Category:ADRIFT or one of its subcategories.
- Wherever referring to the ADRIFT authoring system or platform, the word "ADRIFT" should be typed all in capital letters.
- The article prefixes A4: and A5: will be reserved for the use of pages in the ADRIFT project. Pages outside the ADRIFT project shouldn't use them. A4 is for ADRIFT 4 authoring system features; likewise, A5 for ADRIFT 5.
- We will want articles about various dialogs, fields, and options in the ADRIFT Generator. It is not yet clear how such articles should be named, except that we'll want to use the A4: prefix to distinguish them from similar articles for other authoring systems.
- The ADRIFT project should co-operate with the Code Compare project. Pages in the ADRIFT project should intelligently link to similar pages in other authoring systems, probably via a topic template at the bottom of the page.
- There's no sense worrying about how to document ADRIFT 5 until it actually exists. It's possible that we might want to split the ADRIFT project into two—an ADRIFT 4 project and an ADRIFT 5 project—but it's impossible to tell if that's desirable until ADRIFT 5 has been released.
- Because ADRIFT 4 is not back-compatible with ADRIFT 3.9, nor ADRIFT 3.9 with ADRIFT 3.8, it is particularly important to indicate which version of ADRIFT a game was written in or for. We will also want separate categories for ADRIFT 4 games, ADRIFT 3.9 games, and ADRIFT 3.8 games in much the same way we separate TADS 2 and TADS 3 games from each other, or Inform 6 games from Inform 7 games.
Transcribing ADRIFT "Code"
ADRIFT is an authoring system, not a programming language, and games written in ADRIFT do not have "source code" in the usual sense. ADRIFT authors use the ADRIFT Generator and its dialogs where they enter text into pre-labelled fields and select pre-defined options, and the .taf story file is created from that. Since it would be cumbersome in the extreme to screen capture and display the dialogs as screen images, and because long data is sometimes visually truncated in those displays, it is preferable to adopt some form of ADRIFT notation for IFWiki instead.
A simple example of IFWiki's ADRIFT notation can be found at Smell restrictions (ADRIFT example).
IFWiki's ADRIFT notation format aims for simplicity, readability, flexibility, and accuracy.
Use sections to represent the main dialog boxes in the ADRIFT Generator. Most ADRIFT game transcriptions should use sections called Options, Introduction & Winning, Rooms, Objects, Tasks, Events, and Characters. This is the preferred order, but other orderings are acceptable. Subsections are used for each individual room, object, task, event, and character in the appropriate sections.
Ignore most tab names. For example, the Room dialog has Description and Directions tabs, but it's usually unnecessary to document what tab a field is from since each tab has different fields. (However, see Restrictions below.)
Use bulleted lists to define each section or subsection, listing any filled-in fields and selected options. Include the labels, so we know which field is which. Leave out unused fields. Leave out unselected options unless they are selected by default.
Useful templates:
- {{rx}} which displays as:
This is a selected radio button. - {{cx}} which displays as:
This is a checked checkbox. - {{fq|Sample text}} which displays as: Sample text
"fq" stands for "field quote". Use field quotes to markup text in fields, text in text-boxes, and text in combo-boxes. Preface a field quote with whatever label the ADRIFT Generator uses for that field, text-box, or combo-box.
Use italics for comments.
Some special notes:
- Aliases. This is a multi-line editable combo-box. Pretend it's a list of fields, e.g.:
- Object exists in. This is a boxlist where you can select more than one item. Pretend it's a list of checkboxes, e.g.:
- Restrictions. This tab in the Task dialog builds up a list of restrictions. Use a subbulleted list for these restrictions. For simplicity's sake, use plain text for the restriction's condition, and field quotes just for the "else display" part. For example:
Campbell: You can output ADRIFT games as XML by exporting them as a module. Would it make sense to create an XSLT to transform the output directly to a suitable format for this project, to automate the process somewhat? It is surely impractical to continue as above?