Library messages and the passage of time

Authoring Dialog
1

Hi there!

I’ve really enjoyed IFcomp this year, but even so, I’ve found the need to resist posting questions about Dialog during this period a real strain on my garrulous nature. So I put such questions and comments as I had aside into a text file, which is why this question is rather long. I hope it doesn’t come over as a wall of whine. :slight_smile:

Anyway…

Would you consider renaming (story noun) to (story subtitle) ? I think this would describe its purpose more clearly.

Looking through stdlib, I noticed that the “wait/z” command only prints a message, and doesn’t advance the game clock. Have I understood that correctly? If so, I’d like to suggest that it should, as that’s pretty much what the player’s asking the game to do, and (e.g.) waiting in one place to observe the patterns of patrolling NPCs is a reasonable problem-solving strategy that players would expect to be able to try.

If, on the other hand, you’d rather that waiting didn’t advance the clock/turn counter, then it seems only fair to change the message to make clear that time in the game world is not advancing, especially as the turn counter is not displayed by default.

I don’t know much about the z-machine, only that its resources are limited, so perhaps what I’m suggesting is too expensive, but would you consider making all actions call out to a (narrate #action) message?

This would offer a consistent way of changing the default library responses, a powerful means of changing the feel of a game without needing to tamper with the actual engine. I always liked the way Inform’s library_messages object facilitated this, and Dialog authors could essentially replicate the library_messages system by having a section at the end of their source code, e.g:

%% Default Responses
(narrate #save) Your achievements have been noted, ensign.
(narrate #drop) You carefully place (the $obj) on the clingpad. %% (because objects floating around in microgravity environments are a hazard.)

etc.

I also noticed that for those actions which only print a message, Dialog doesn’t distinguish between refusal and performance. Again, subject to the conservation of resources, should it?

A refusal, e.g. “You consider attacking (the $obj) but decide against it.” arguably represents a momentary impulse on the part of the PC, and can therefore be represented as taking no noticeable amount of time. Yet despite e.g. “You jump around for a while.” specificially saying that time has passed, it doesn’t do so.

If, despite being futile (at least, in terms of progressing towards a solution) perform jump did call (tick), then, say The Mother Superior, animated using (on every tick) would naturally respond to one of her novices jumping around – even if only with a default response – rather than remaining (buggily?) indifferent.

So Jump would become

(narrate [jump]) You jump around for a while.

(perform [jump])
	(narrate jump)
	(tick)
	(stop)

So (tick) would consistently be in the (perform [whatever]) part of an action.

I’m looking forward to seeing the source code for your comp entry with great interest.

Best wishes

DD

2 Likes
2

Regarding (story noun), I’m somewhat ambivalent but I guess it could be confusing. (story headline), like what Inform uses, could be another option.

Regarding wait and jump, time is advanced since they’re not commands. From “Actions — Stopping and Ticking”:

After an action has been tried, the standard library will generally advance time in the game world, by querying a predicate called (tick)…Time is not advanced after commands, i.e. actions such as [save] and [transcript off] that take place outside the game world.

You can see this by defining a rule like (on every tick) Time is ticking! and then waiting or jumping. The specific code is in (try-decorated $Verb $ObjList), if you’re curious.

As for narrating actions, you can narrate dropping an object with (narrate dropping $Obj). All core actions have a corresponding narration predicate. Since save is a command, though, it doesn’t have one. I’m not sure if this will ever be added, but if not, it’s not too hard to do it yourself. It’s a reasonable change that doesn’t clash with the existing structure (and the standard library is designed to be edited by authors anyway).

2 Likes
3

Thanks for these questions and suggestions!

As @Pluie writes, time does advance after “wait” and “jump”.

This is a good point, and I can see how it would make more sense as a “prevent” rule. The rationale is that the story author may wish to override the default “perform” rule for a particular object, and e.g. have (perform [attack #bear]) do something successfully. If the default refusal were part of the prevent rule, the author would have to override that instead, and thus write a successful action inside a prevent rule. That’s equally illogical, but also has the side effect of stopping any queued-up actions.

Turning to the matter of a generic narrate predicate: When should it be queried? Most of the core actions query the narration predicate before applying changes to the world model. So (narrate taking #jewel) is invoked before the jewel is removed from its parent object, allowing you to state that “you briefly look around, then snatch the jewel off the pedestal” if and only if the jewel is on the pedestal. But e.g. (narrate entering $Room) is invoked after the player object is moved to the new room, and visibility has been recomputed. So it’s not obvious when a generic narrate predicate should be queried.

1 Like
4

Thanks for your replies!

I’m used to thinking of anything the player types in at the prompt as “a command”, and either missed or forgot that the Dialog documentation uses “command” only to mean actions like “save” which occur out-of-world. Sorry about that.

@Pluie I can see that I’ve not fully understood the order in which Dialog goes about processing a cycle of interaction (i.e. getting from the player typing something all the way back around to the prompt again.) I’ll go re-read the docs.

About (story noun)

Reading Dialog code, I’m struck by how good it is at being self-documenting. Unfortunately because “noun” has such a wide meaning, its inclusion conveys no additional information to a human reader. So an author of Dialog must learn the specific meaning for the usage intended here.

While (story headline) would be familiar to Inform users, I suggested (story subtitle) because that’s the standard bibliographic term, and perhaps more likely to be familiar to newcomers regardless of their background. Mirriam Webster defines subtitle as “a secondary or explanatory title”.

e.g.

All fall down: an interactive journal of a plague year, by Damien Defoe.

The title is “All fall down”, the subtitle is “an interactive journal of a plague year” and the author is “Damien Defoe”.