I7: List Problem

I’ve got a room in my game which the player can only enter once. What this means is that if he happens to drop a critical object (there’s no reason to do so but the player is not blocked from doing so) and fails to pick it up before leaving, he can get the game into an unwinnable state. I’m OK with allowing the possibility, but if it happens I want to warn the player as soon as he leaves the room that he may have screwed up. Thus, I need to flag situations where the player brought something into the room with him and does not have it when he leaves.

My thinking is to generate a list of items enclosed (to pick up indirectly held items) by the player when he enters, and a similar list when he leaves. Then, I would run through the list of things on the “entry” list and check each item to see if it is also on the “exit” list. If anything is missing, I would set a flag which I then use to generate the “You left something behind” message.

[code]“Forget Me Not” by Me

ThisRoom is a room. ThatRoom is north of Thisroom.

A gizmo is in Thisroom. A gadget is in Thisrroom. A whoozeewhatzit is in Thisroom.

Forgotten is a truth state that varies.

After going to Thatroom:
Now Inlist is the list of things enclosed by the player.

After going in Thatroom:
Now Outlist is the list of things enclosed by the player;
Now Forgotten is false;
Repeat with item running through Inlist:
If item is not listed in Outlist:
Now Forgotten is true;
If forgotten is true:
Say “As you leave, you get the nagging feeling that you might have left something behind.”.[/code]
doesn’t compile. The error messages suggest that the statements creating the two lists are not doing what I expect them to do. I don’t have much experience with lists. Any suggestions?

Thanks.

Robert Rothman

There were a couple of things wrong with your code. First, you need to create the lists as global objects. When they’re local to the rules, they won’t persist between turns. Second, the “after going in thatroom” rule runs when you enter the room (because it’s the going action, and you’re now in thatroom).

This seems to work:

[code]ThisRoom is a room. ThatRoom is north of Thisroom.

A peach is in Thisroom. A pear is in Thisroom. A banana is in Thisroom.

Forgotten is a truth state that varies. Forgotten is false.

Inlist is a list of things that varies. Outlist is a list of things that varies.

Instead of going to Thatroom:
Now Inlist is the list of things enclosed by the player;
continue the action.

After going south from Thatroom:
Now Outlist is the list of things enclosed by the player;
Now Forgotten is false;
Repeat with item running through Inlist:
If item is not listed in Outlist:
Now Forgotten is true;
If forgotten is true:
say “As you leave, you get the nagging feeling that you might have left something behind.”;
otherwise:
continue the action.

Test me with “take all / n / drop peach / s”.[/code]

Another thing to note is that lists are memory-hoggy – I think someone posted that if you include a single list, then I7 compiles in all the code for handling lists into your program.

It seems to me that you could do this without lists, by using a property. This isn’t tested even for compilation, but it might work

[code]A thing can be held-on-entering. A thing is usually not held-on-entering.

After going to ThisRoom:
repeat with item running through things enclosed by the player:
now item is held-on-entering.

After going [? not sure if this will capture any direction] from ThisRoom:
if any held-on-entering thing is not enclosed by the player:
say “You have the feeling that you might have forgotten something. Sure you want to leave?”;
if the player consents: [not positive this will work as intended]
now every held-on-entering thing is not held-on-entering; [? maybe you need a repeat loop here; actually if the player can only enter once, you don’t need to reset held-on-entering in this way as it’ll never be checked again]
continue the action;
otherwise:
say “OK, you’re still here.”[/code]

That was me: The cost seems to be about 48 kilobytes (file size)*, which can make a real difference if you’re compiling to the Z-machine, but is utterly inconsequential if you’re compiling to Glulx. If your game is Glulx and you find lists convenient for a given purpose, there’s no reason not to use them.

–Erik

*That is, including just one list variable in your game will increase the file size by about 48K thanks to the code needed to support list functionality.

Thanks.

So far, this game has fit into z8, but I have no problem going to Glulx if I exceed z8’s limits. I’ll try the list approach and see what happens.

Robert Rothman