It’s fair to say that the standard library is what makes it generally possible to play a game written in Dialog. I keep learning stuff glancing through it.
I was experimenting with an LLM fallback system, as I posted elsewhere, which relies heavily on the fact that I can do state injections into a compiled Dialog game during runtime.
The problem is that I cannot technically inject this state into objects without definition, so I can’t spill water on my pants and then set my pants to wet if I don’t technically have pants.
Of course, narratively, I’ll have pants, sure. But I don’t really have pants. Just like the foyer of the Opera House has a floor, and if I wring my cloak onto the floor, it should now be a wet floor.
But the foyer does not have a floor. Not really. So it cannot be wet.
How I get around this right now is to have a container property for narrative facts, but that doesn’t really affect the world the way I would want it to, which leads me to the following:
Imagine for a moment one would establish a sort of standard object library for stuff that just is or can be assumed, what would this ideally look like? I really do want to leave a wet puddle on the floor, please.
Inform (6-, not 7) used to do this, with default definitions of things like walls, floors, and ceilings, but this led to a lot of authors forgetting to override them—so you could push the wall of a grassy meadow, or examine the ceiling of falling through the sky at terminal velocity. Eventually it was decided that the author knows better than the library developer which things can be taken as default in their world. Most Dialog games probably have their protagonist wearing some kind of default clothes, but Wise-Woman’s Dog certainly doesn’t!
Huh, fascinating! I did run into that when just forming a hypothesis of how it would be done, because you’re right: Not every object is created equally, the foyer of the opera house is not a damp cavern.
In which case, would it be manageable to have a set of opt-in default definitions, such as (#foyer is a #building-room) (or whatever the syntax is, I’m still learning exactly how it works and I’m standing in the middle of the grocery store )
It’s possible, but generally the responses to EXAMINE FLOOR etc will be specific to a particular game, so Dialog leaves it up to individual authors. Is a “default” floor packed earth, hardwood, marble, linoleum, or carpet? It just varies too much for there to be a sensible default.
I’d suggest having Eidolon instead attach this information to the room object (for floors etc) or the player object (for clothes). Instead of “floor is wet”, say “foyer has a wet floor”; instead of “pants are wet”, say “player has wet pants”.
This is true, but it would have to insert some kind of property like floor which it then assigns a wet property to, even if it’s just paying lip service to it. I found the problem I now ran into is that I could alter the narrative state of quite a few things that weren’t defined, but the moment something did have a definition somewhere in the script, if at least implied or as a fallback, it would trigger the default description.
Even when the earlier narrative descriptions had me make the wall and floor quite smelly, it was somewhat disappointing to get the fallback response of “It smells as you would expect”, for example. What might be an elegant way to override that in a way that is compatible with the way Dialog currently allows injections?
I think the easiest way would be to change a lot of the default action implementations in the library—the ones that just say “nothing interesting happens”. If your goal is to provide more interesting alternatives to those, then make the default response be equivalent to a parser error, so Eidolon steps in to handle it instead.
As for how to do this: make the default (perform $Action) rule (the one that comes after all the action-specific ones) tell Eidolon that it’s going to give a default fallback answer, then remove a bunch of the action-specific perform rules that say “you smell nothing unexpected” and so on. Then they’ll all fall through to the general “this action isn’t implemented” handler.
That’s roughly how it’s currently handled. It’s basically inserted as a very unlikely alternative to all other actions, which was the way I could get it to function. Though I realised I needed to clean up the name a bit, so that when it does show up in a list of Did you mean ... actions, it shows something a little prettier than eidolon-fallback
)