| summaryrefslogtreecommitdiff |
diff options
Diffstat (limited to 'content/wyrd_v1/_index.md')
| -rw-r--r-- | content/wyrd_v1/_index.md | 92 |
1 files changed, 42 insertions, 50 deletions
diff --git a/content/wyrd_v1/_index.md b/content/wyrd_v1/_index.md index c6e6e97..ac49ebe 100644 --- a/content/wyrd_v1/_index.md +++ b/content/wyrd_v1/_index.md @@ -1,57 +1,49 @@ --- -menuTitle: Wyrd -title: Wyrd (Version 1) +menuTitle: Wyrd Interpreter +title: Coding a Wyrd (Version 1) Interpreter weight: 4 --- Wyrd is the language in which the narrative is given to the game engine. It is purposefully kept small and simple to facilitate porting Tonkadur to a new engine. -The memory is seen as a table mapping strings to values. These values may also -be tables. Thus a reference is a list of strings corresponding to a move from -one table to the next. - -The program is a list of instructions. These instructions may use computations -as parameters. They sometimes use hard-coded strings parameters as well. -Instructions cannot take instructions as parameters. Instructions are not -associated to any value. - -An integer, called _Program Counter_ is used to indicate the current -instruction. In most cases, this integer is incremented by one after every -instruction. There is an instruction to modify the value of the Program Counter, -which allows conditional jumps and loops to be described. - -Computations are values and operations returning values. These are solely used -as parameters of instructions. They do not alter memory (with one exception) -and do not interact with the Program Counter in any way. An execution cannot be -stopped during the evaluation of a computation: it is part of its parent -instruction and is thus completed exactly when that instruction is performed. -Computations may _read_ from the memory, as they may need to fetch the value -associated with an address or traverse tables. All computations have a return -type. - -Wyrd does not have the notion of sequence or that lambda functions. It does not -even associate player choices with lists of actions. It's all done by carefully -managing the Program Counter. - -Lambda functions are stored as an `INT` corresponding to a line in the program. - -## Types -* `ADDRESS` (or `POINTER`, or `REFERENCE`), a list of `STRING` (note: not a - `STRING COLLECTION`). -* `BOOL`. This should be changed to `BOOL` soon, for consistency's sake. -* `[SOMETHING] COLLECTION`, table mapping `STRING` to `[SOMETHING]`. -* `FLOAT`. -* `INT`. -* `TEXT`, a list of `STRINGS` with attributes attached. -* `STRING`. -* `STRUCTURE` (or `DICTIONARY`), table mapping `STRING` to values of any type. -* `{String}`, a hard-coded string. - -#### Aliases sometimes used to refer to types -* `? ADDRESS`: an `ADDRESS` pointing to a particular type. -* `BASE TYPE`: `INT`, `FLOAT`, `BOOL`, `STRING`. -* `COMPARABLE`: `INT`, `FLOAT`, `BOOL`, `STRING`, `TEXT`, `ADDRESS`. -* `COLLECTION`: any `? COLLECTION`. -* `COMPUTATION`: any type. -* `NUMBER`: `INT` or `FLOAT`. +This part of the website guides you through the implementation of a Wyrd +interpreter. + +Wyrd files are meant to use easily parsable formats. Tonkadur provides Wyrd +files as JSON, since JSON parsers are commonly available in pretty much any +general programming language. However, the code generating this output is +cleanly separated from the rest of the compiler, so changing the compiler to +output in a different format should be approachable. + +As with Fate, Wyrd is split into computations and instructions. As a +reminder, computations do not modify the memory, whereas instructions may. +Furthermore, a computation in Fate may actually result in instructions in +Wyrd (a notable example being the `random` Fate computation, which is actually +implemented using the `set_random` Wyrd instruction). + +Here is an overview of the Wyrd interpreter: +{{< svg "static/images/wyrd_interpreter_overview.svg" "1000px" >}} + +The state a Wyrd story is described by `<State>`, a structure defined on [this +page](/wyrd_v1/state). + +* `execute(<State>)` executes the next `<Instruction>` and returns the updated + `<State>`. The semantics of each `<Instruction>` is explained on [this + page](/wyrd_v1/instruction). Their effect on the `{User Interface}` is + communicated by a `<InstructionResult>` member of `<State>`, but this it can + alternatively be returned alongside the updated `<State>` if the + implementation language permits it. All possible such effects are described + on [this page](/wyrd_v1/instruction_result). +* Calls to `compute(<State>, <Computation>)` come from two sources: resolving + the parameters of an `<Instruction>` and resolving the parameters of + `<Computation>` (recursive call). The semantics of each `<Computation>` is + defined on [this page](/wyrd_v1/computation) and is computed according to + current `<State>` (they do not, however, modify it). The result is given as a + `<Value>`, the semantics of which can be found on [this page](/wyrd_v1/value). +* The user may be called to provide an `<Input>`. This is presented by + `handle_input(<Input>, <State>)` on the figure above. The different + `<Input>`s and how to handle them are described on [this + page](/wyrd_v1/input). +* The parsing process (`parse(<File>)`) is described on [this + page](/wyrd_v1/file). |