Relative directions rotate along with their pattern
PuzzleScript[ > Player | Crate ] -> [ > Player | > Crate ]gets compiled to the following set of rules:
UP [ UP player | crate ] -> [ UP player | UP crate ]
DOWN [ DOWN player | crate ] -> [ DOWN player | DOWN crate ]
LEFT [ LEFT player | crate ] -> [ LEFT player | LEFT crate ]
RIGHT [ RIGHT player | crate ] -> [ RIGHT player | RIGHT crate ]You can restrict patterns so that they're only matched in a particular direction (by default, when the interpreter tries to find places to apply to rule, it tries all four rotations of it). To implement gravity, we could do
DOWN [ stationary Object ] -> [ > Object ]Which compiles to
DOWN [ stationary Object ] -> [ DOWN Object ]It would probably have been simpler to write the rule as
[ stationary Object ] -> [ DOWN Object ]which is the same thing.
Another good illustration of why rule direction might be important would be if you're making a word game.
[ C | A | T ] -> WINwould look for words in all four directions, so TAC would also match this rule. To fix it, you would restrict the rule to read left-to-right as follows:
Editright [ C | A | T ] -> WIN
Huzzah!
There are horizontal directons as well - if you want something that moves horizontally when you move horizontally, but ignores you otherwise, you do this
[ Horizontal Player ] [ Crate ] -> [ Horizontal Player ] [ Horizontal Crate ]
(Vertical is also a keyword that you can use).
Vertical and horizontal are both keywords, but is there a way of reducing the following to a single instruction?
[ ^ Player | Crate ] -> [ ^ Player | ^ Crate ]
[ v Player | Crate ] -> [ v Player | v Crate ]There is, and it's this:
[ Perpendicular Player | Crate ] -> [ Perpendicular Player | Perpendicular Crate ]Parallel is also a keyword, and means what you think it might :)
Tip: if you don't know what something does in the examples (or in your own code :S ), it can be helpful to add the DEBUG flag to the prelude to see how the compiler interprets it.