Yes, that's right. It could also be a great advantage in situations where you have several moving pieces and need to be able to reference back to things that have already happened. For example, let's say I wanted to do a battle chess game within a design. Here are the moves:
White King's Pawn moves North 2 squares
Black King's Pawn moves South 2 squares
White King's Bishop moves NW 3 squares
Black King's Bishop moves SW 3 squares
White Queen moves NE 2 squares
Black Queen's Knight moves SW in L-shape
White Queen takes Black King's Bishop's Pawn - Scholar's Mate
The PCs are watching this battle take place, and can walk all around the battle chess field and interact with the characters. So in both OAUA and FRUA, when each of these moves takes place, Quest 1 advances by 1 stage. Since the party is able to freely move about the chess field, they could be at any place during any of these steps, and could encounter any of these characters at any point during the match. As the designer, I know that these steps are going to happen this way, but in order to make the player feel immersed in the event, I have to be able to determine what moves have taken place when they arrive at certain squares.
Let's say that the PCs wander around and end up on the same square that the White Queen moves to in Step 5. When the PCs arrive, is it an empty square? And if it's empty, is that because she's not arrived yet or has she already left? Or is she standing in that space right now?
When the Queen moves to this square, a Utilities event sets Quest 1 to a Value of 5. In both FRUA and OAUA, you'd need to use a Quest Stage - Step Six event on that square (followed by a Utilities event to re-set the stage back to 5) in order to determine if she was currently standing in that square. By the way, I misspoke in an earlier post -- I was thinking about the pass / fail chains following the quest stage event; there's not a built-in option to prevent the quest from automatically increasing the value by 1, no matter what my sleep-deprived brain was thinking. Anyway, here's where the differences lie:
In OAUA, I can preceed that event by a single Quest Stage - Step Seven event (followed by a Utilities event to keep the Stage value the same). If this event fired, I would know that the Queen had already come and gone and the game had continued on. This event would fire at any point in the match after the Queen had left. If this event doesn't happen, it chains to the Quest Stage - Step Six event in the previous paragraph. And if that event doesn't happen, then I know that the Queen has not yet arrived.
In FRUA, I have to use at least one Quest Stage - Step event for every possible value either above or below the Quest Stage - Step Six event mentioned earlier in order to know whether she has come or gone. In this case, there are only two more moves after she leaves that square, so I'll be efficient and use a Quest Stage - Step Seven event and a Quest Stage - Step Eight event (each followed by Utilities to keep the values constant). If either of these events trigger, then I'll know she has already left that square. If neither fires, then we proceed to the Quest Stage - Step Six event to see if she's there, and if that doesn't fire, then I would know she hasn't been there yet. Thank goodness this was a quick match, or I'd have to string a whole bunch of Quest Stages together to figure this out.
You could of course assign a different Quest to flag that square as having been visited by the Queen. I think this is how the majority of designers handle something like this, rather than working with Quest Stages. But then again, there are 64 squares on a chess board and not that many available quests...
I've asked Brian to see if he can find where he hacked the change in behavior in OA's CKIT. As we've talked about this, I'm wondering if it would be possible to include a toggle in the Quest Stage event to choose which way the designer would like the event to operate (i.e., == or >=), and/or perhaps what would be tremendously valuable would be adding my imaginary option to not advance the Quest Stage. This would save us from wasting Utility events after so many of these.