Execution Order

Let's start with the vaguest picture, and zoom in a bit each section (the final level of depth will be dealt with in another article).

Zoom level 1

According to Rules 101, a turn is like this:

  1. The player is marked as being someone who wants to move
  2. Each of your rules is applied as often as it can be, before moving to the next.
  3. Movement happens.
  4. An optional extra stage for rules you want to apply at the very end.

Zoom Level 2

Let's look at section 2. What does it mean?

Say we have the following:

[ > Crate | Crate ] -> [ > Crate | > Crate ]
[ > Player | Crate ] -> [ > Player | > Crate ]

The player won't be able to push several crates in a row with this, because the first rule gets applied first, and then the second rule. So order does matter - these aren't abstract replacement rules floating around in a vacuum.

Zoom Level 3

Each rule gets applied in turn as often as it can be before the interpreter moves on to the next one. It sounds quite simple, doesn't it, but there's one point of ambiguity. The compiler compiles each rule you write down into several smaller rules (You can see the output by using the debug switch in the Prelude).

For instance

[ > Player | Crate ] -> [ > Player | > Crate ]

is compiled into these four instructions:

Rule Assembly : (4 rules )
===========
(52) UP [ up player | crate ] -> [ up player | up crate ] 
(52) DOWN [ down player | crate ] -> [ down player | down crate ] 
(52) LEFT [ left player | crate ] -> [ left player | left crate ] 
(52) RIGHT [ right player | crate ] -> [ right player | right crate ] 
===========

So the question is: When I say that each rule is executed in turn to exhaustion, do I mean the few rules you write, or the many rules the interpreter ends up with?

The answer is "the former". The compiler generates lots of rules, but packs them together into rule groups. The interpreter then, instead of applying one rule as much as it can before moving to the next, loops through each rule group as often as it can, before moving to the next.

You might wonder if you can construct rule groups yourself. The answer is yes, with use of the modest + symbol..

[ > Player | Crate ] -> [ > Player | > Crate ]
+[< Player | Crate ] -> [ < Player | < Crate ] 

That assigns both rules (or rather, the rules that are generated from them) to the same rule group.

That isn't a meaningful use-case, though. I haven't found out one yet. If you find one, let me know! It's used in the rigid bodies section, though that's a bit of an arcane subject.