The Batman wrote:
I haven't tested the code in it's entirety simply because I don't get what is happening in these lines:
Can print the banner text is a truth state that varies.
Rule for printing the banner text when can print the banner text is false:
now can print the banner text is true.
I assume it has to do something with preventing the banner from showing up at the start--otherwise, wouldn't using [banner text] at the end just make the banner appear again? But trying to break it down logically, I just don't see what this is accomplishing. I'm trying my best to avoid simply copy-pasting code and actually understand what it is the particular codes are saying/doing, so if you (or anyone else) could offer some input there, that would be wonderful.
Yes. When play begins, all variables -- like that one -- which are given no initial values are assigned the default value for their kind. You can see these defaults on the Kinds page of the Index. For truth states, the default value is "false".
So, play begins, and "can print the banner text" is false. Among other things, a number of activities are launched when play begins. One of these activities is the "Printing the banner text" activity. Ordinarily, this prints the banner text. However, the phrase I wrote causes that activity to do nothing
when "can print the banner text" is false, except
to set "can print the banner text" to true.
So, in effect, that truth state variable and that rule combine to make the activity not display the banner text the first time it would be displayed -- at the beginning of the game -- and to behave normally (IE, to print the banner text) every other time, such as when "[banner text]" is said, or when the player types >VERSION.
I have no idea what the code is doing for the scenario.
I understand the initial declaration of the rooms/floors (in which every time a room is declared without a cardinal relation, it's like declaring a floor--when the author says x room is some direction from another, then it's adding another room to the floor). The "table of floors" is pretty straightforward and I think I get what the "The elevator exterior is a backdrop. It is not scenery." is getting at (if I'm correct, it's just saying "create something called elevator exterior that can be referenced, but don't treat it as an object or scenery, just as something that's constantly there). The "initial appearance" just refers to the description of the undisturbed elevator exterior.
Well, sort of. I think you should read WI chapters 3.8 and 3.9, Scenery and Backdrops, to familiarize yourself with the differences between them. A backdrop is a thing that is found in multiple rooms simultaneously; scenery is basically a not-mentioned thing, meaning it doesn't display an initial appearance like "You can also see an elevator here." at the end of any room description -- the assumption being that it will be described in the room description, or as part of the description of some other object, instead. Backdrops and scenery are two independent properties of things; any thing can be either, both, or neither. The Standard Rules define "A backdrop is usually scenery.", but that can be overridden, as the code above does.
Before entering the elevator exterior, try going inside instead.
Don't think I understand this one (even though it seems simply-worded). Is this some alternate way be able to call "going inside" "entering"? Or is it the properties of the "backdrop" that prevents something from "entering" it, but allows something to "go inside" it and the code is just preventing player confusion? If the latter, than what are the differences between the two? I'm guessing this isn't the most important code, so I'm not going to bother myself too much with it.
Before rules are defined in WI 7.3.
This line just redirects one attempted action (entering the elevator exterior -- which is a backdrop, not a door or an enterable container or an enterable supporter, and hence has no "entering" code defined for it) into another (going, with a noun of "inside" -- a direction). The usual purpose for this is to prevent code duplication -- instead of defining the same result for multiple actions, they're all redirected to one action. Minimizing code duplication is always a good idea, to prevent bugs from creeping in, so that if you ever need to change one of these code blocks there won't be another block or 3 to forget to update as well.
a) I don't need the player to have access to all 30 floors. If a player tries to go to an floor that I haven't designed, a simple "you have no reason to go to that floor" will suffice.
b) What I have currently is a room named "Elevator" that someone can just go "north" towards and be inside. I'm not fully grasping what makes a room "enterable" as opposed to being able to be accessed from a direction. Ideally, yes, I want someone to be in a room and then "enter" the elevator, but for now I'm settling for just going "north" into it.
c) I've created the "table of floors," but really don't know how to utilize/reference it. I'd like to be able to have a sign in the elevator that lists off the accessible floors and their respective names (a la, display the table). I don't think I7 likes the table being coded without it being used
Well, I'm getting tired, so I will leave that at that. I hope I've been clear enough on what I want, what I don't want, and what I understand and don't understand. As always, thanks for all the help--I definitely feel like my I7 production has increased ten-fold.
a) The code in the example dealing with "corresponding floors" is what you want here. Just say an error message rather than moving the player to a generic floor.
b) Rooms can't be entered, only things can. If you want the player to be able to enter the elevator, code like the above "Before entering the elevator doors, try going inside instead." will make those doors effectively transport the player to whatever room is inside from whatever room the doors are in -- as good as making them enterable, from the player's point of view.
c) I think you want to read through chapter 15 of WI, which describes tables in detail, including how to list through them and display their contents to the player.