Dragonspeak is a very simplistic scripting language whose basic purpose is to offer (reasonably flexible) scripting for the
graphical MUD Furcadia, specifically for user-created custom maps (termed
dreams); as a dream lacking DragonSpeak lacks any functionality whatsoever.
The syntax itself is designed to read as plain engish, and is designed "so a seven-year-old can learn it". One of the biggest irritations about the language itself is it's lacking of an OR function; only AND is supported. A sample DragonSpeak block looks like this:
(0:3) When somebody moves into object type 43,
(1:201) and variable %a is greater than 1,
(1:81) and the triggering furre is within the diamond (40,40) - (60,60),
(3:6) where the triggering furre moved into,
(5:5) change object type 43 to type 44.
(5:8) play sound 5 to whoever set off the trigger.
(5:350) set variable %position to the X,Y position the triggering furre (moved from/is standing at).
(5:200) emit message {You have moved into object type 43 at %position.x,%position.y.} to
whoever set off the trigger.
(5:50) set countdown timer 3 to go off in 5 seconds.
(0:50) When countdown timer 3 goes off,
(3:2) at position (%position) on the map,
(5:5) change object type 44 to type 43.
Dragonspeak blocks consist of causes (which begin with 0:), conditions (which begin with 1:), areas (which begin with 3:) which define what parts of the map the effects (which begin with 5:) take action on. There are also filters, beginning with 4:, which further effect the range of areas, by specifying rules such as the area should only effect spaces containing object type X, where X would be a number. The lack of any lines using 2: statements is a mystery, but it is possible it is either reserved for future functionality, or was used for pre-alpha since removed functionality.
As has been mentioned, no OR function is available (for both causes and conditions). The language itself is only updated when there is a general client update, which happens about once a year, at best.
Arrays are (barely) implemented, and their functionality is practically nil due to their crippled nature; there is no looping functionality, so you cannot loop through them, nor are
PHP-esque associative arrays supported. The entire support of arrays consists of 3 effects:
(5:311) use variable # as an array, and set element # of it to #.
(5:310) use variable # as an array, and copy element # of it into variable #.
(5:390) Starting with entry #, set # elements in array # to #.
Various server bugs exist (which may have now been fixed) which limit the length of arrays and cause bugs with player's avatars appearing where they are not, on the map.
Variables are prefixed with %. An extremely old symbol, @ is supported to identify variables by number, before named variables were supported. Variables can only hold integers; strings are not supported at all; there is some limited support for constant strings, such as emitting a message to the player. These constant strings can hold dynamic variables, so the value of a variable can be outputted to the player.
Variables can also hold coordnates, which are really two integers held together (x and y), which are as they are described used to signify a location. The above line, (5:350) set variable %position to the X,Y position the triggering furre (moved from/is standing at)., is an example of setting position variables. In this case, the individual elements of the variable can be accessed using the notation .x and .y; such as %variable.x and %variable.y. Since coordinates are ordinarily specified as (X,Y), position variables can replace both parameters and the server will assume it to be used as both of the coordinate parts.
Ordinary variables specified as %variable are really signified as %variable.x; .x is the default element, and variable names specified without a .x and a .y are assumed to reference the .x aspect. Even non-position variables have .x, and merely lack .y.