Processing all the wonderful feedback I received for my IFComp entry, and looking where I might need to tweak things I come across the following:
On the throne, a gleaming sword rests, confirming
your authority as the rightful ruler of the realm.
:
Allowed actions: {seizing your sword}.
Good vs Evil.7 >seize my sword
With the broken axe handle in hand, you decide to seize your sword,
hoping it will serve as a suitable replacement for your shattered axe.
Good vs Evil.8 >i
Your muscles ripple beneath your sun-tanned skin.
You are definitely as good-looking as ever.
You are carrying your sword (wielded), an axe handle,
a bottle of wine (closed), and your loincloth (being worn).
Allowed actions: {marching west}.
Good vs Evil.8 >undo
You carefully place your sword back on the throne.
The game shows the sword as your sword in the room description, the action is known to the game as seizing your sword, and in the inventory it also shows up as your sword. But the command the player needs to use is seize my sword. Is this indeed the correct way owned things are handled? To me it is a bit confusing sometimes. When the player wants to examine himself/herself/itself, they are supposed to use x me instead of x you. But i (which I interpret as take MY inventory) shows the things owned by ME as YOUR âŚ
Yeah this is a bit awkward. Inform basically considers the player character (in game) and the player (sitting at the keyboard) as the same person by default. So the game tells you: âYou are holding your swordâ, and you might tell the game âI would like to put my sword downâ, or whatever.
In my game, I manually ensured that the player could use both âyourâ and âmyâ to refer to things conceptionally owned by the PC, e.g.:
The armor is wearable and proper-named. The printed name is "your armor".
Understand "your/my/-- battle/combat/-- armor/armour/rattle" or "your/my/-- suit/set of/-- battle/combat/-- armor/armour" or "suit" as the armor.
(Thereâs probably a more general way to accomplish this that I never bothered to research, but this works well enough.)
You donât need to specify âmyâ as a synonym. The parser lets you apply âmyâ to every object by default. It gives a disambiguation bias towards things in your inventory, but to the (classical) adventurer, everything you see is âmineâ. :)
Itâs more nuanced than that. When an object name is preceded by what the parser labels the âdescriptorâ my, if (and only if) disambiguation is required the parser completely excludes any object not directly worn or carried by the actor(not the player).
So after
Lab is a room.
Bob is a man in the Lab.
Persuasion: rule succeeds.
A sword is a kind of thing. Understand "sword" as a sword.
The longsword is a sword. Bob carries the longsword. The scabbard is an open container. The scabbard is carried by Bob. The dagger is a sword. The dagger is in the scabbard.
The bastard sword is a sword. The player carries the bastard sword.
you can get the following output:
Lab
You can see Bob here.
>bob, x sword
(the longsword)
Bob looks closely at the longsword.
[disambiguates to highest-scoring sword == longsword because it is directly held by the actor (Bob)]
>bob, x my sword
Bob looks closely at the longsword.
[disambiguates to only sword directly carried/worn by the actor (Bob) == longsword]
>bob, drop sword
Bob puts down the longsword.
[MULTIHELD token disambiguates to only sword directly carried by the actor (Bob) == longsword]
>bob, x sword
(the longsword)
Bob looks closely at the longsword.
[disambiguates to highest-scoring object == longsword because it is directly in the location]
>bob, x my sword
There is no reply.
[disambiguation excludes all swords as none is directly held/carried by the actor (Bob)]
Itâs one of the many little features in the I6 parser that now get in the way more often than not. I think it would be better to remove these special features and instead say, for example, Understand "my" as a thing when the player encloses the item described or the player incorporates the item described.
Agreed. Further, I would submit that applying the descriptor âmyâ to the actor rather than to the player is actually a bug. Also, more arguably, allowing âmyâ to apply to any object so long as disambiguation isnât required seems odd- but perhaps this fits into the parserâs paradigm of allowing unambiguous if ungrammatical input.
Yeah, the nuance Peter describes (which I had forgotten about, thank you) is an unintuitive complication at best. It doesnât fit into any good scheme that âget my fooâ will return a parser error rather than disambiguating when there are two (poor) candidates. (But work fine if thereâs only one.)
Also it interferes with games where some objects are unambiguously owned. (âMy wandâ, âHermioneâs wandâ, âRonâs wandâ shouldnât change descriptors just because they get dropped or picked up.)
I doubt it causes many problems, but Iâve always been surprised that the terms âlitâ and âunlitâ exist as hard-coded optional parser descriptors- perhaps for the rare situation where there are ten candles on the table only one of which is litâŚ?- so, analagously to âmyâ, one can type âdrop lit swordâ and thereby drop your unlit bastard sword- as long as youâre carrying only one sword- whereas âdrop lit swordâ will fail if you are carrying more than one unlit sword, with âYou canât see any such thingâ.
Now that you mention this, that surprised me when I was creating my IFComp entry. I had a âdimly lit pathâ but forgot to put in an understand statement for the path. The game recognized x path and x lit path but not x dimly lit path and I could not figure out where the lit path part was coming from⌠Thanks for pointing this out!
Order vs Chaos.47 >x lit alcaz
Alcaz, your court mage, strikes an imposing figure,
wearing a mage's robe and carrying his staff of arcane magic.
He is studying the runic script on the marker.
I guess everything and everyone becomes enlightened lol
Of course, as Iâm sure you know, I7 Understand... as .... phrases (as far as parsing objects is concerned) are compiled to I6 parse_name routines- theyâre just a lot easier than writing a parse_name routine directly!
Of course, itâs syntactic sugar, but itâs very useful syntactic sugar! Previously, if you wanted every object in the game to recognize âmyâ when carried, youâd need to either give everything a parse_nameâŚor put it into the parser itself. So thatâs what they did.
Now, a single Understand line can add conditional grammar to every object in one fell swoop, which is far, far easier!
Well, not quite- you could just add code to a thingclassparse_name routine inherited by every thing in the game⌠which is exactly what an I7 Understand "lit [thing]" as a thing when the item described is lit phrase does. I wonder therefore if the hard-coded descriptors in the parser are a relic from a time before parse_name routines were introduced.
EDIT although actually itâs awkward that you also have to add the code to any thing or class providing its own parse_name routine, since this isnât an additive property and providing a parse_name routine therefore supersedes any inherited one. The I7 compiler automatically adds the code to create such âpseudo-inheritedâ parse_name routines for you. Out of the box, the only thing compiled with a parse_name routine is the player object, selfobj.
EDIT2 the pain of this when programming directly in I6 could be reduced by using the superclass operator