I7: Indistiguishable (sometimes) objects

Authoring Inform 7
1

I need to create the following effect, and am at a loss for how to approach it:

1. There will be a thing (we’ll call it a widget). There will be two widgets in the world, one of which starts out offstage.

2. A widget can be in one of two states, frobodlicated or unfrobodlicated. However, I don’t want this to be too obvious to the player until he figures out how to frobodlicate a widget; therefore, I want an unfrobodlicated widget to be described as (and referred to by the player in commands) simply as a widget.

3. When two widgets are in the same place and the same state, I need them to be indistinguishable. Thus, for example, if the player is carrying two widgets which are both frobodlicated, I want them to appear in his inventory as “2 frobodlicated widgets”; if he then types “drop frobodlicated widget” it will drop one without the necessity (or even the possibility) of specifying which one.

4. If the two widgets are in different locations, I need to be able to specify which one is referred to. In particular, when the trigger occurs to move the initially offstage widget onstage, I need to be able to specify that that is the one which gets moved, regardless of the state that the other one is in.

5. If the two widgets are in different states, I need to be able to distinguish them for all purposes. For example, if the player holds both and they are in different states, the inventory list would contain entries for “a frobodlicated widget” and “a widget”; if he then wants to drop (or do something else with) one of them, it would understand a reference to “widget” as the unfrobodlicated widget and a reference to “frobodlicated widget” as the frobodlicated widget.

I understand from the documentation that to create multiple indistiguishable widgets I would create widget as a kind, not a thing; each widget would then be implemented as an unnamed instance of the widget kind. However, I need to be able to distinguish them in certain situations (i.e., where they are in different places or different states). On top of this, I need to avoid the dreaded disambiguation loop problem where the printed (and understood) name of one item (the unfrobodlicated widget, which I want to appear as “widget”) is a subset of the name of another (the frobodlicated widget).

Frankly, I can’t figure out where to begin with this.

Any advice would be greatly appreciated.

Thanks.

Robert Rothman

2

The example “Hot Glass Looks Like Cold Glass” handles pretty much exactly this. You can make a certain property of an object determine whether it should be parsed differently and described differently to the player.

3

Thanks. I will study the example.

Robert Rothman

4

Having studied the example, I thought I understood the concepts, but I’m running into trouble right off the bat.

[code]“SizeTest” by Me

Size is a kind of value. The sizes are normal and shrunken. A thing has a size. The size of a thing is usually normal. Understand the size property as referring to a thing.
Before printing the name of a thing (called thisthing) when the size of thisthing is shrunken: say "shrunken ".
Before printing the plural name of a thing (called thisthing) when the size of thisthing is shrunken: say "shrunken ".

A card key is a kind of thing.

Someplace is a room. A normal card key is in Someplace.[/code]

Stripped to its barest essentials, this seems to be the first part of the principle illustrated by the Hot Glass example. When I try to compile it, I get an error message telling me that the statement “A normal card key is in Someplace” does not describe the object with sufficient specificity. In the Hot Glass example, the line “Three room temperature glass dishes are on the counter” describes the object by its kind and its heat property, just as my statement describes the object by its kind and its size property. What am I missing?

Thanks.

Robert Rothman

5

When it tried to compile it:

When I kill the line that defines a card key as a kind of thing, it compiles and runs fine. If I add a line telling inform to preface it with the word “normal”, that works too. If I then go on to say “The size of the card key is shrunken.” that produces the anticipated result. If I introduce a second card key using private names, it also produces the desired result. I get one normal card key and one shrunken card key.

So I guess the problem line is defining the card key as a kind of thing? Or maybe not. But taking it out does what I want it to do. :slight_smile: Not sure what other issues that would cause.

[EDIT]

To clarify:

"SizeTest" by Me

Size is a kind of value.  The sizes are normal and shrunken.  A thing has a size.  The size of a thing is usually normal.   Understand the size property as referring to a thing.
Before printing the name of a thing (called thisthing) when the size of thisthing is shrunken: say "shrunken ".
Before printing the plural name of a thing (called thisthing) when the size of thisthing is shrunken: say "shrunken ".
Before printing the name of a thing (called thisthing) when the size of thisthing is normal: say "normal ".

[A card key is a kind of thing.]

Someplace is a room.  A card_key01 is in Someplace. The printed name of card_key01 is "card key". The size of the card_key01 is shrunken. A card_key02 is in Someplace. The printed name of card_key02 is "card key". The size of the card_key02 is normal.

Gets me:

SizeTest
An Interactive Fiction by Me
Release 1 / Serial number 110531 / Inform 7 build 6G60 (I6/v6.32 lib 6/12N) SD

Someplace
You can see a shrunken card key and a normal card key here.

>

[Second edit because I’m stoopit.]

6

It looks like you have to say “One normal card key is in Someplace.” I suppose this is to distinguish sentences that place one generic object of a certain kind in a room, like that, from sentences that declare the properties of a kind, like “A card key has a door called target” (I didn’t actually check to see if that compiles).

EDIT: “You” = Robert; hadn’t seen I4L’s comment when I posted.

EDIT 2: “In Someplace is a normal card key” also works, as per the I7 error message.

7

Thanks. Matt’s solution worked. Who’d a thunk there’d be such a diffference between “a card key” and “one card key”?

14L, giving unique identifiers to different card keys does indeed avoid the problem I was having, but it doesn’t work for what I need it to do in other respects. Basically, there is a way that the player will be able to change the size of a card key (figuring out how and when to do that will be one of the puzzles). If the player is in possession of more than one of the same size, I need them to be indistinguishable. One the other hand, if the player has one of each size, I need him to be able to specify which he is referring to. And just to add to the fun, until the player figures it out, I don’t want to give away the fact that there is a size property which can be changed, so a normal-size card key (which is the only one available until he figures out how to shrink it) needs to be described as just a “card key.”

I’m sure I’ll run into a bunch of other problems before I get all this to work, but tis got me over the first hurdle.

Robert Rothman

8

I’m new at this. I just like to hear myself talk. :wink:

Plus you never know what can be learned when you “think out loud”.

Glad it’s worked out!

9

One of my favorite programming tools is a rubber duck. Well, not a literal one.

en.wikipedia.org/wiki/Rubber_duck_debugging

This might be a good time to say thanks to all the forum members who have performed so admirably (stoically?) as rubber ducks for me. Plus, I got tons of helpful feedback too!

10

I’ve got a rubber chicken (a real one). Would that work? If not, how about a whoopee cushion or a joy buzzer?

(Come to think of it, maybe I should use some of those objects in a game; perhaps the player is stuck in a novelty shop and has to figure out how to use the inventory to escape).

Robert Rothman