Naming/handling multiple similar objects

Hi! I am very new to Inform 7 (used it for just a few days), and I have a question.

I feel like I am missing something obvious, but here goes:

If I have, say, “floor”-objects in multiple rooms, what is a good way to handle this?

Inform does not let me have multiple “floor”-named objects, even if they are marked as scenery and in different rooms.

And if I rename them to something like: “floor of statue room”, then when I try to “kick statue”, Inform asks me if I mean the floor or the actual statue that is also there… which I don’t find very practical.

How is this generally handled?

For multiple similar objects, create a kind of thing.
For a “floor” object in every room:

[code]“Cat Floor”

Lab is a room. Annex is west of Lab.

A floor is a kind of supporter. A floor is scenery. Understand “floor/ground” as a floor.

One floor is in every room.

A cat is in lab.

Exactly what I was looking for, thank you!

Another option is to use a backdrop. Under the hood, a backdrop is one single object that I7 drags from room to room. Then you intercept the Inserting it into action and move inserted objects into the room itself.

Hmm hmm. Then again – how can I give different descriptions for these floors in different rooms?

Out of the “One floor is in every room.”, I get the impression that these are indeed objects – in the sense of object-oriented programming… and that each floor owns their properties (like description).

I tried this, which compiles, but the description doesn’t get set at all:


A floor is a kind of supporter. A floor is scenery. Understand "floor/ground" as a floor.

One floor is in every room.

The First Room is a room. The description of floor in here is "The ground is grassy here."

And, if I type:

The description of floor is "The ground is grassy here."

…the description is changed in every room.

I’m still kind of confused.

That depends. Do you intend for the description of every floor to be hand-crafted, do you want a few types of floors, or do you want it to be vary by things in the environment? There are several methods to achieve each.

The declaration of “The floor in here” will not work as you expect. I7 has no way of inferring that one and only one floor will exist in a given room throughout the game, and consequently, assertions that attempt to identify an object of a kind in that manner will be misunderstood.

(Will provide code when I get the time to sit down at an actual computer.)

Instead of “one floor is in every room”, you can place them individually.

A linoleum floor is a floor in kitchen. The description is "It needs waxing."

Alternately, use “one floor is in every room” and wherever you want specifics, say:

Instead of examining a floor when the location is the kitchen: say "It needs waxing."

The word “usually” is helpful when creating kinds.

The description of a floor is usually "This particular floor isn't very interesting."

A related question: how large a role does the floor play in your game? How deeply should it be implemented? Because a deep implementation tends to steer the player towards itself: the floor becomes obviously significant.

You can also do this while still having the floors appear as “floor” by changing the printed name property:


A floor is a kind of supporter. A floor is scenery. Understand “floor/ground” as a floor.

One floor is in every room.

The printed name of a floor is usually “floor”.

The kitchen-floor is a floor in the kitchen. The description of the kitchen-floor is “A linoleum floor.”

The hall-floor is a floor in the hall. The description of the hall-floor is “A parquet floor.”[/code]

And you could also add individual synonyms to the floors:

Understand "parquet" as the hall-floor. Understand "linoleum" as the kitchen-floor.

I would second Eleas in saying that unless floors are really important in your game, you don’t want to fully implement them. It’s wasted effort, increases chance of bugs, and, most importantly, sends a confusing message to the player. However, if floors somehow are important, then by all means use them!

Do realise that Inform has no way of knowing that your floor is a floor; if you define it as a supporter (which is sensible), then Inform has no way of knowing that everything in the room is supposed to be on the floor. So you will have to (1) ensure that dropped objects are always put on the floor, and (2) ensure that every object in your game is always put on the floor, and (3) ensure that movement puts the player on the floor of the new room. Think of code like this (untested, since I’m not behind a compiler at the moment, so there might well be some syntax bugs!):

[code]Instead of dropping:
let item be a random floor in the location;
try putting the noun on item instead.

When play begins:
repeat with item running through things:
if item is in a room and item is not a floor:
let item2 be a random floor in the location of item;
now item is on item2.

Last after going:
let item be a random floor in the location:
now player is on item.[/code]

Well well, I like this idea of simply having some amount of pre-defined floor types. I really don’t plan floors to have a big part in my game, and keep it simple.

I’ll play around with the examples you’ve given. Thanks everyone!

It is easier to not make the floor object a supporter, and write

Check putting something on the floor-obj: instead try dropping the noun.

This covers what players will expect without upending Inform’s whole notion of “stuff in the room”.

(You could also catch SEARCH FLOOR and display a list of what’s in the room, but the benefit is marginal.)