Here's my idea for the syntax for checkpoints and "refined" tutorial messages (That is, tutorial messages using this syntax. Levels with names starting with "tutorial" can still use the old syntax). It's a modified version of the syntax I posted in jebby's Checkpoints topic.

Checkpoints and refined tutorial messages don't have to be declared in the level code like the old tutorial messages. Rather, they are declared on separate lines beginning with the "!" (exclamation point) character. The two recognized "!" commands: "!cp(id)" for checkpoint and "!msg(id, message)" for tutorial message. They both have an ID parameter, which is an integer used to identify this event. IDs do not have to be unique - you can have multiple checkpoints and/or messages with the same ID. Tutorial messages defined in the old syntax with have IDs 0-9, the same as the number used to place them in the level. The message parameter for "!msg()" is the message to be displayed to the user. Specifically, I will grab any characters between "," and ")", remove any spaces at the beginning and end, and then remove the first and last character if they are single or double quotes.

After the command defining the event, you define when the event should trigger with a space-separated list of requirements (and/or modifiers). Here are the ones I have planned so far:


Examples:

In this syntax, the first tutorial message on tutorial level one would be



Rather than having the "Oops! You fell into a hole!" message in tutorial one repeat every time you enter a different hole (at least twice if you collect the gem), it could be set to skip additional messages after the first one is triggered by setting "id(skip, 6)" or by replacing the separate events with one event with an "in()" region that covers all the holes.

And rather than displaying the "Hmm.. looks like you're stuck." message in tutorial 3 when you climb up the boulder cascade, it could be displayed as soon as the way through is blocked off and Hannah has not gone across by testing Hannah's position with an "in()" region and the boulders' state with "tile(24, 24, o)". The same goes for the "Phew! That was close." message, it can wait to be triggered until the boulders have fallen down and blocked the way back. Then those two messages can be made mutually exclusive by giving them the same ID and a "id(skip, value)" clause so that once one has triggered, the other is disabled.

There are a lot more applications, but I'll leave those up to the level designers to come up with.

Let me know what you think of this syntax. I think it's flexible enough to do pretty much anything, but also pretty easy to use and understand (as much as it can be). Actually, I just thought of another requirement I could add: "gem()" to trigger only if the gem has been collected.

How are the value and the ID of an event determined?

The ID of the event is declared at the beginning of the line. It's the first parameter of "cp()" and "msg()". Tutorial messages declared with the old syntax will have an ID equal to the number used to place them in the room (0-9).

"value" is the second parameter of the "id()" requirement. The usual case of "id(skip, value)" would be to set value to the ID of this event, so the event will not trigger if another event of the same or greater ID was triggered, but you could also set it to any other ID.