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.
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:
"Test"
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."
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.)
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.
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!