intfiction.org

I downloaded I7 about a year ago with only a slight interest in creating adventure games/interactive fiction/etc. and because the interest was only slight, I hadn't really TRIED to learn it until now. However, lately I7 has been fascinating me and I'm really keen on creating an adventure game set in the world of Batman (go figure, eh?). However, even after reading the documentation/recipe book and what have you, I feel like I'm just not grasping what I assume are probably stupidly simple commands. So if you guys could please help a beginner in the way of this fantastic program, it would be much appreciated. I will try to be as detailed as possible about my issues, so please bear with the lengthy post

1) I'm having difficulty understanding the basic concept of walking into a building and being inside of a room. Should all/most places be described as rooms and then further rooms should be placed INSIDE of another to create the effect of a building? Or does one define something as a "building" and then create rooms inside of it? To apply it to my game, basically, you begin in the center of a city (outside) and can choose 1 of 4 cardinal directions. I would like the player to be able to go N (for example) and approach a building and then after that, decide whether or not they want to enter said building. If they decide to enter, then they obviously would be in a room contained in the larger building (which has been defined already obviously). What I7 doesn't seem to like is that I'm trying to say that the "lobby" (the room upon walking in) is inside of the larger building and therefore it thinks that I'm trying to describe the larger building twice. Is there some simple thing I'm missing here? Just to say "enter the building and now you're in x room"?

2) Being in a particular position and having to LOOK in a certain direction in order to notice a particular item. In my game, when standing in front of a certain building, I would like to somehow suggest to the player that they should look DOWN in order to discover a particular item on the ground. The closest I can get right now is just to flat-out say that there's an item at their feet and from there they will be able to examine it/pick-up--but obviously this requires no sense of looking whatsoever and I don't want the item to be immediately described upon reaching the location. Though this could probably be answered with the previous statement, I would also like for a player to be able to look UP and notice something at the very top of the building (but the something isn't an item, so a simple description would suffice).

3) Another incredibly simple one I imagine--starting the player with an item and (maybe not so simply) having the item interact with something, all before the banner text. As sort of the "opening scene" I would like the player to have an item referred to as "change" on them (I was going to initially have the player have x amount of change, but I have a feeling as a beginner that trying to factor in a loss and/or gain of money would be a tad over my head). Then immediately after introducing the starting location vaguely, an item would be mentioned that one must put the change into. After doing so, an explanation further detailing the broad location of where the player is should appear. Then after that explanation text, the banner text would appear and the game would "begin" (so to speak) with the player being in a specific place (the aforementioned center of the city).

Again, thank you very much for any and all help you can provide--I'm really looking forward to getting the ball rolling on this project.

I'm a bit of a newbie myself, but regarding your first question, I believe the room-within-a-room concept you're looking for is Regions:

http://inform7.com/learn/man/doc31.html

You'd define each building as a Region, then put all of the individual rooms for each building inside the corresponding Region.

1) Think of "rooms" not as rooms but as places. You'll probably be better off by creating one room called "At the Entrance of Gotham City Hall" to represent the area outside just outside the City Hall and then creating another room ("Gotham City Hall Lobby") to the north of it and so on. You don't *have to* model rooms inside a building as inside anything to make it look like rooms inside a building to your readers/players.

2) Inform games understand the commands "LOOK DOWN/UP/NORTH/SOUTH" etc. by default. But those commands trigger the examining action! So, to write rules for them, you have to write rules like "Instead of examining up in At the Entrance of Gotham City Hall: say this or that" or "Instead of examining down in Gotham City Hall Lobby: do this or that".

_________________
Man ska inte tro allt man tänker.

The example showing you how to suppress the banner text is at http://inform7.com/learn/man/ex35.html#e35.


(By tradition, and as a courtesy to all the people who have worked on Inform, authors ensure that the banner is printed some time near the beginning of each game played. So please only defer it, rather than suppress it altogether.)

I've always found that example a bit strange since it gives instructions for a very specific case instead of just telling how to do it in the general case. It also suppresses the banner when the player explicitly commands VERSION which is not good. A better method is:

_________________
Vorple UI library — Beta testing site — Blog

Hey guys, sorry I didn't get back to responding right away--I've been awfully busy with school. So I'm going to real quick respond to a few of you and get some more questions out of the way (I had this originally typed a few days ago and just haven't gotten around to sending it, I'm not even sure I had it completed, haha). Just want to say thank you, any help you guys offer is greatly appreciated and I can't imagine I would get anywhere without your input!



Hmmm, while I understand what you're saying, I feel like this approach would only seem to cause some issues (and it doesn't seem entirely practical). For instance, if I have building A north of building B, I can understand saying "okay, you're at the entrance of building A" but going north, in my mind, should bring you to building B, not bring you into a room inside of building A. Otherwise I don't get how you could get to building B at all without going through all the rooms contained in building A. Is there a way I can say, "go NORTH to go to the next BUILDING or ENTER/GO FORWARD into this one"? Then once entered, all cardinal directions would be relative to the inside of the building (until retreating to the first room and deciding to EXIT). The current set-up I have is pretty much a top-down view of all the buildings in the city as rooms, laid out exactly how I want it--it seems so counter-intuitive that if I want to add rooms to these buildings now, I'll have to go and change EVERY cardinal location of current rooms to accommodate.



I don't think I'm following you on this one. So if I'm reading this correctly, the action of looking in a direction automatically examines everything in that particular direction? So if I have multiple objects on the ground (for instance), the action of looking down will cause the descriptions of ALL the items to appear or will it just mention that all of the items are there? For example, in my story, the character should look down and be told that there is a business card there, then upon examining the card, be told what the card actually says. I don't want the character to look down and be told what the card says immediately.

Your suggestion on the "looking up" conundrum worked perfectly though! I thought maybe I could apply it to the "business card" scenario, but I can't quite grasp placing an object in a scene without it explicitly telling the player that it's there right away, so I'll have to put that one aside for right now.



That definitely seems like a good start to what I'm trying to do, much appreciated. No worries, I don't intend at all to completely cut-out the banner, just as I said, "delay" it until after a very brief opening scene. I tested the code out and it worked wonderfully, but when I attempted to apply it to my story, I realized there were a few complications that arose.

Firstly, is that I'm not entirely sure how to make one object interact with another (or give the objects properties that they could interact with something). I ideally want the player to be told that they have change in their pocket from the very first paragraph (and later on, if I can get the "looking down" thing figured out, maybe the change will begin on the ground--but I digress). They will then be told that there is an [object that accepts change] near them and they need to simply say something to the effect of "[place change in object]." From there, a paragraph of text will appear followed by the banner. Following the banner, the current location will be named and the game will continue as I have it planned. What I'm having trouble figuring out is if I should be considering the change/receiver as a lock and key type of interaction? Or if there's a simple [put two objects together and cause x to happen] command?

No, all directions are independent. You can make Before the B Building "north of" Before the A Building and make A Building Lobby "inside from" Before the A Building without needing to rearrange anything else, or conflicting with each other.

No, by default examining a direction does nothing. ("You see nothing unexpected in that direction.") Any behavior you want to happen, you'll have to code yourself.

The simplest way is to not actually place the card in the room until you want the player to notice it:



I think the inserting it into action is all you need in this case.

@Batman:
What I meant was you can do things like this:



Thus you can have room B being "inside" from room A, and room C being north of room B without creating a container or a region or anything to put both B and C into.

_________________
Man ska inte tro allt man tänker.

Boy, do I feel dumb!

It always seems that when I'm toying with something in I7 that the solution isn't so much my "approach" to solving the issue, but just a matter of what words/language I use.

For instance, with the "rooms inside buildings" issue I was having, I had tried to say "x is a room inside of y" and when that didn't work, I assumed that I7 required something a tad more complex to create a room. The issue (thanks to Felix) was simply that I needed to phrase it as "x is a room inside FROM y." It may not sound right grammatically, but I'm relieved to know that was all it needed

@ChrisC

Your solution to both the "coin slot" and "business card" issues worked perfectly. Now, the business card won't even be mentioned until the player looks down and I can make the coins interact with the device. The ONLY thing that goes over my head is the movement of the banner. I haven't tested the code in it's entirety simply because I don't get what is happening in these lines:



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.

This all brings me to the next set of troubles (I hope I'm not being a burden with my onslaught of questions)...elevators. I've checked every resource I could find on this, but all I could seem to manage was the "Dubai" example (http://inform7.com/learn/man/Rex118.html#e118). While it may be (possibly) what I need, the way it's presented does nothing short of confusing me. In short, I want the player to be inside the elevator (obviously) and be prompted with a simple "what floor?" (or have them enter "go to x floor" without a prompt). Because of the particular way I have the building structured in the story, it would be completely unreasonable to allow the player to have access to every floor (out of the 30 floors of the building, the player should only be allowed access to less than 10). While the theory behind the Dubai example seems to be exactly what I'm trying to do, much like my comment above, 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.



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.

The rest of the code...augh...I don't even know where to begin. Can someone break it down into layman's terms for me (can't believe I'm asking a natural-language syntax to be simplified)? Really, what the situation breaks down to is this:

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.

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.

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 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.

[/quote]
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.