Absolute Beginner Questions

Authoring Inform 7
1

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 :slight_smile:

  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.

2

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:

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.

3

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

4

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

"Bikini Atoll" by Edward Teller The Hut and the Tropical Beach are rooms. The conch shell is in the Hut. After taking the shell for the first time: say "As you gather the oddly-warm conch shell into your arms, you experience a sudden flash of deja-vu...[banner text]"; move the player to the Tropical Beach. Rule for printing the banner text when the player is not carrying the shell: do nothing. Test me with "look / examine shell / get shell / look".
(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.)

5

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:

[code]The display banner rule is not listed in the startup rulebook.

Before going to the lobby for the first time:
consider the display banner rule.[/code]

6

Hey guys, sorry I didn’t get back to responding right away–I’ve been awfully busy with school. :cry: 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?

7

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:

[code]Circus is a room. A ring is a kind of supporter. A ring is always enterable. Three rings are in the Circus.

The business card is a thing.

Definition: a thing is other if it is not yourself.

Instead of examining down when the location is Circus:
move the card to the location;
say “You see [a list of other things in the location].”[/code]

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

[code]Lobby is a room.

The player carries some loose change. Understand “coins” as the change.

A vending machine is in the lobby. Understand “slot” and “coin slot” as the vending machine.

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.

Instead of inserting the change into the vending machine:
remove the change from play;
say “The coins disappear into the slot on the front of the machine, which makes a hopeful-sounding clunk.[paragraph break][banner text]”[/code]

8

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

[code]At Gotham City Hall is a room.
Entrance to Gotham City Hospital ED is a room.
Entrance to Gotham City Hospital is north of At Gotham City Hall.

The City Hall Lobby is a room. It is inside from At Gotham City Hall.
The Reception Desk is north of the City Hall Lobby.
The Stairs are west of the City Hall Lobby. The Stairs are west of the Reception Desk. East of the Stairs is the City Hall Lobby.
The Second Floor is up from the Stairs.

The Emergency Department is a room. It is inside from Entrance to Gotham City Hospital ED.
The Resuscitation Area is south of the Emergency Department.

test me with “n / in / s / n / out / s / in / n / w / e / w / up / down / e / exit”[/code]

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.

9

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 :slight_smile:

@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:

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

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.

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.

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 :laughing:

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.

10

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.

11

While I feel like I’m grasping the code behind the elevator more and more each time I read it, I think I’m going to have to put it off for now. I tried my best to make the code work with what I wanted, but ultimately I couldn’t get it to NOT take the person to a certain floor, and then when the player tries to exit from the floor that I tried to forbid, it just brought them back to the lobby. So I thank everyone who tried to help me, but I think with my limited I7 knowledge, maybe that one’s just a little over my head and it’s more of a hassle than it’s worth. I’m hoping as I try more and more with my project that the “elevator conundrum” will seem more second nature.

So I’m just going to jump into my next bits of confusion:

Stairs and Hallways. They sound simple, they should be simple, the documentation makes them seem simple, but I’m just missing something here. Just want it so a player enters into a building that I’ve created and is in a “lobby” of sorts. If they continue north, they’ll be in a hallway with rooms on either side. If they continue north, the same thing and if they continue north further, the same thing (so never actually leaving the hallway, but having the option to each step). However, in addition to the rooms on either side, at the very end of the hallway should be an option to take stairs up or down (to reach the second floor and the basement respectively).

Should I not be thinking of this in terms of one continuous hallway, but rather as similar rooms that are identified as a hallway and connected by nothing but a direction? But then how can I have three different rooms named the same thing? Then with the stairs, how do I have two separate staircases occupying the same space? I understand at minimum that staircases should be considered doors, but I’m lost beyond that and all of the documentation I’ve read doesn’t seem to clarify much for me unless I want a really specific type of stair/hallway. I’m hoping this is significantly simpler than creating an elevator

12

I think the best way is to think of the hallway as having “sections”. Let’s make it 3 sections. Say the hallway runs east from the lobby.

Each section of hallway can have 3 doors (or simply rooms) on its north & south faces, so a 3-segment hallway would have up to 18 doors. Thus you can go in the room to the northeast, north or northwest of each segment of hall – if you need more rooms off the corridor, add more sections of hall (see below example).

The Lobby is a room.  "You're in the lobby.  From here you can see a corridor to the east."  

The West Hallway is east of the Lobby.  "Wow, this is a long hallway.  You see doors on the north & south walls, and the hallway continues to the east."

The Central Hallway is east of The West Hallway.  "You're in the middle of this long hallway.  You've never seen so many doors!"

The East Hallway is east of The Central Hallway.  "Wow, finally, you're at the end of the hallway.  You see more doors to the north and south.  And from here you can actually take the stairs up to the 2nd floor or down to the basement."

The East Upstairs Hallway is up from The East Hallway.  "This is the second floor hall.  It extends to the west, with many doors on the North and South sides."

The Downstairs Hallway is down from The East Hallway.  "It's a dim, dingy basement."

And from there you’d define up to 18 doors->rooms off the hallway (doors optional).

“Room” is only “a segment of usable space” in the game. It does not have to be a “room” per se. It could be a grove in the woods, it can be a section of parkland, it can be the end of a parking lot, it can even be a car in a train, a bus with 20 people on their way somewhere, etc.

So if you need a lot of doors, you have a lot of “segments of usable space”. If you need more rooms than 18 in your hallway, get more creative with the segmenting, or use numbers. I believe this works: “Hall Section 1” “Hall Section 2”. The idea is that your player gets a sense of the enormity by how many “turns” it takes to move down the hallway, and by how you describe it in the description text. Your text draws the picture of what they see in their minds eye. The “room” is only a container in which you can place people and objects so that they can interact – a segment of a fictional world.

Rooms don’t describe themselves. It’s up to you whether they have walls, floors, ceilings, or if the person is floating/flying in fairyland. “Room” best translates to “a useful place”. A container is usually “something smaller than a room, that you can put things into.” however you can have containers that can hold people – say a walk-in closet inside a room could be a large container. Try not to get stuck on the words for the base objects. A “door” could be a staircase, an escalator, a slide (think Chutes & Ladders)… it’s something that connects one “useful place” with another.

I hope that helps.

13

UPDATE before posting: Crisses’ idea is not bad either. You may want to give the rooms separate names anyway.

You can do this with the “printed name” property; the rooms will be named different things in the code but will show up the same way. Like this:

Hallway 1 is a room. The printed name of Hallway 1 is "Hallway". Mr Jones's Office is west of Hallway 1. Mr Brown's Office is east of Hallway 1. Hallway 2 is north of Hallway 1. The printed name of Hallway 2 is "Hallway". Utility Closet is west of Hallway 2. Ms Smith's Office is east of Hallway 2. Hallway 3 is north of Hallway 2. The printed name of Hallway 3 is "Hallway". Ms Robinson's Office is west of Hallway 3. Ms Murray's Office is east of Hallway 3.

I’m not sure why this is a problem? If you want the staircases to be doors, just have one of the staircases go up from the end of the hallway and the other go down:

The Second Floor Lobby is a room. The Basement is a room. The Second Floor Stairs are an open unopenable door. The Second Floor Stairs are up from Hallway 3 and down from The Second Floor Lobby. The indefinite article of the Second Floor Stairs is "the". The Basement Stairs are an open unopenable door. The Basement Stairs are down from Hallway 3 and up from the Basement. The indefinite article of the Basement Stairs is "the".

Just a note about niceties: The business with the indefinite article means that it says “You can also see the Basement Stairs here” rather than “You can also see a Basement Stairs here.” But it’s probably better to include the stairs in the room description and make them scenery, so that doesn’t appear at all. (In fact, as I’ve written the code, you’ll get a bunch of blank room descriptions; you should either write real room descriptions or at the minimum include one of the extensions that puts the exits at the end.) And if you make the stairs doors, you want them to be open and unopenable, so you don’t wind up having the player open the stairs.

Here’s another nicety: You don’t want to call the Basement Stairs the Basement Stairs when you’re in the basement, so you can do this:

Rule for printing the name of the Basement Stairs when the location is the Basement: say "stairs up". Rule for printing the name of the Second Floor Stairs when the location is the Second Floor Lobby: say "stairs down".

Another approach would be to make the stairs another room that you can go up and down from. You don’t have to make them doors if you don’t want.

If you’re wondering how you can have both sets of stairs be north of the end of the hallway, don’t try to do that. Even if you succeed in doing that, what would happen when the player tried to go north from the end of the hallway? You could try to catch that by asking for disambiguation (there’s a thread around here somewhere about that), but that’d be complicated for you and the player and not worth doing, probably.

14

Like many programming languages, there’s different ways to do the same thing. Eventually you come to know “when” you should do it one way or another – and that’s the toughest part of the learning curve, and not something answered in the main documentation (the recipes are better at this).

I think whether you need a “door” for the stairs, or simply to have the stairs be invisible and transportation up/down instantaneous is up to you.

However, here’s a dip into some of the game-building philosophy:

Think about how the player should experience it: If the player ought to “pause on the staircase” or be able to tie their shoelaces while on the stairs – then create the door=stairs. However, many times “in real life” taking the stairs is a complete non-experience… something we don’t stop to consider. We go up, and we’re in a new “experienceable place” – the stairs are a “non-experience” for us (it’s not memorable…). If you need the player to experience the staircase, by all means put it in as a door. If the staircase is a complete non-issue to the player’s experience of the environment, make the transportation seamless and get on with your story. Another thing: You can always add the door in if you change your mind – if during a scene, the player will bump into an important person or find a key object “while in the stairway” then you might need a room that is “the staircase”. Now it is an experience, something memorable, so it must occur somewhere.

The same thing goes for doors in the corridor. You can have a hundred “doors” in one “room”. If in your fiction they’re all going to be locked and never enterable (i.e. “just scenery”) then there doesn’t have to be a door defined in the code at all, just tell the player there are doors there and they will experience the doors as being there. Don’t define the doors, and change the error message from that room to tell the player how frustrating it is that all these doors in the hallway are locked. They will experience frustration, and hopefully get on with the story. You have to make sure they have an idea of how to do that.

So to me, it sounds like you’re getting tangled in the code. Just because you CAN make a door or room doesn’t mean you have to.

Think in terms of “is this part of the story?”

Here’s a radical idea: You can have 1 floor of the miscellaneous sections of the building defined. You can have the player enter the elevator and press a button which changes the scene and hence changes all the descriptions of the scenery “doors” on the floor when they exit the elevator (say, the scene changes the room numbers that are described…). Every floor in the building is identical, but there’s a message when the scene changes “The elevator door opens and the sign outside the door shows that you’re now on the 30th floor.” – they exit the elevator, wander around the floor, all the doors including the stairway doors are locked (except the restrooms! :slight_smile: and they’re identical on every floor, of course). Eventually they get back in the elevator. They can do this for floors 3-30. Just the 2nd and 1st floor are unique and have anything worth exploring (and whatever other floors you decide).

To prevent player frustration, though, make absolutely certain that they have hints and clues to which floors have the “interesting stuff” – whether the receptionist tells them to go to a particular place, whether they know they have an appointment on the 13th floor, or whether the dropped business card in the lobby has a particular room number they need to go to. Perhaps, the first time they visit a miscellaneous floor, they get a cell phone message (must have missed a call on the stairs or in the elevator!) reminding them that they’re late for their appointment in room 202.

The point is to make the world revolve around the story, not the story revolve around the world’s mechanics. There’s always more than one way to tell the story. :slight_smile: Find a way to keep it simple for you as the programmer while not frustrating the player to the point that they abandon the game.

15

Huh? This seems to be making an argument for implementing the stairs as a room, not a door. A door in I7 is just a thing that appears in both rooms and can be "enter"ed to transport the player to the other side of it; something like a souped up direction that can be examined like any other thing in a room.

16

Essentially, yes: what I’m saying is that you do not have to use a door, just because “door” is an available item type. I’m trying to explain that you can accomplish the appearance of a staircase without invoking a door object. And that if you do need to have an interaction that takes place in the staircase, you could choose a “room” instead of a “door” to be the “place the event takes place in” (while still appearing to be a staircase to the player).

  1. a door can be closed or locked - if part of the game purpose is to make the person seek out a key, or to attain something to get through the door (i.e. an appointment, or to restrict an area until a goal is achieved) then the door is part of the story. The “door” object is a convenience to the programmer when they need to separate an area in the storyline in some way. If you do not need to separate areas, you can choose to simply connect rooms over using doors between rooms. You can have a “faked door” between rooms without bothering to program one in – just describe it (see #2). However, for example, let’s say that you decide to program in “day and night” – the government offices’ front door should be locked at night, right? so then it’s part of the story that you can’t go to the government center at night. You lock the door between “inside and outside” the government center during the “Nighttime” recurring scene. It’s part of the story because it fits the players’ expectations for the behavior of the world they’re imagining. That’s when you should use a “door object”. (i.e. You can choose to use a door either way, but when you need to exclude people from an area, then you should use one.) This means when we don’t need to exclude people from an area, we can choose other ways to arrange our “rooms” that don’t need doors.

  2. when a door does not contribute something to the story, you can simply remove it. I recommend that you don’t waste time with a door in any case where it inconveniences you or the player to do so. If you describe a door as scenery (in the room description), and think someone might examine the door that’s not there as an object, then you can put in an error message to supply a description without adding an object to the game. (Understand “examine door” as a mistake…) But unless mentioning the door is somehow important, don’t mention it…

  3. (Postulate dependent on the ideas in #1 and #2) If you have an important interaction to take place on the stairs, and since stairs are (presumably) never closed or locked – there’s no need for “stairs” to be a door. You produce an ILLUSION of being in the stairwell by making a room you describe as the stairwell, in which you say ‘up’ to go one place, and ‘down’ to go another. However, if there’s a firedoor to reach the stairway and you need to lock the stairway door at some point (say, if the player is accidentally in the building and it becomes night, thus they get locked into the building…and only do this if it’s part of your story! Many IFs can become frustrating if there’s too much to sidetrack the players…), that’s different.

[code]Stairwell is a room. “You are standing in the stairwell. The stairs go in both directions so from here you may go up to the 2nd floor or down to the basement.”

Bozo is a person. Bozo is in the Stairwell. “There’s a clown here. He apparently has been camping out in the stairwell for months waiting for this moment. He reaches into his shirt pocket and pulls out a giant bouquet of flowers. He smiles mutely at you. Hanging off the bouquet is a business card that reads ‘Don’t forget your appointment in Room 202.’ The card flips over as he brandishes the bouquet revealing the other side, which reads ‘Have a nice day!’”

Basement Stairwell is down from Stairwell. “You are standing in the stairwell, and the only way to go from here is up the stairs or back west into the basement.”

Upstairs Stairwell is up from Stairwell. “You are standing on the 2nd floor landing. You can go west from here into the hall, down to the first floor, or continue up the stairs.”[/code]

Honestly, if you didn’t need Bozo there, I wouldn’t make these as rooms at all. But you CAN. The engine is flexible to fit your story. I say lay the world out simply and straightforwardly, because you can always add in more rooms/doors/features as they’re needed to embellish the story. You might even build backwards from the goal/end through to the beginning…that’s up to you, and that’s how some folk write novels, weaving in details and red herrings/dead ends as they move backwards through the plotline.

Don’t get stuck on “Rooms need doors because doors are available for transportation between rooms.” The key word is “available” – they’re not “needed” at all. That’s what I’m trying to explain. Think of everything as a plot device – literally and figuratively. If you a plot segment requires some type of device (room, container, prop, key, door, etc.), then you create it as an actual discrete object in Inform. However, you can seamlessly pass from one room to another without pausing in a doorway unless you really need that “doorway effect”.

17

This strikes me as a very bad idea. For one thing, it won’t catch “x door,” “look at door,” “l at door,” etc. For another, even if it gives the correct response when the player examines the door, it’ll produce a disastrous response when the player tries to (say) close it.

If you’re going to mention the door, implement it as an object (even if it doesn’t have to be the kind door), and code polite refusals for the obvious things to do with it (“No need to close the door”). If you don’t want to do that, don’t mention it.

18

I’m just thinking of the case of an Alice-in-Wonderland experience of a corridor that seemingly goes on forever, has innumerable doorways to either side, but one can’t (truly) interact with the doors. i.e. they will never open, lock, close, etc. and they all look the same. On the programmer’s end it’s easier, I would think, to code from the “refusal to allow the player to interact with the doors” than to place many-many doors in the corridor that are locked, unopenable, and nondescript.

The idea is: this is possible without making doors at all. I don’t know whether the player can actually poke their head inside these rooms – nor if the door poses a barrier in any way. The doors may purely be “scenery” objects or even for this area “backdrop” rather than “doors” per se.

There is no obligation to use doors, and you can work around them, even though a “door” object is available to be used. Understanding this, one gains the freedom to decide when a door is needed, when it is not necessary but still desirable, and when it should not be used.

I agree that it should not be mentioned if it could not be used. But how else to explain that just because one can use a “door” object as a staircase, a door-object staircase is not the only solution to advancing the plotline…the question is “do you really need to even mention this staircase?” and “is a staircase itself important here?” i.e. can the person go up or down without thinking about the stairs?

19

But don’t do it using “Understand as a mistake”! If you want to block any action involving the door, write something like this:

Instead of doing something when the current action involves the door: say "[refusal to interact with the door]"

Trying to bypass the parser in a case like this is a bad idea. And if you’re worried about the proliferation of doors, you can make the door object a backdrop, so there’s one object that’s effectively present in the whole corridor.

I agree that if the player can go up or down without thinking about the stairs, they should; but if you need to mention the stairs, you need to code them, and then maybe coding them as a door is a good idea, so long as you don’t make it a door you can open or shut…

20

I sit corrected. Thanks! :slight_smile:

Yes, that’s basically what I’m saying.

I just remember the frustrations of early IF – and even one or two instances conducted in Inform7 more recently – where the player (namely me) becomes frustrated trying to solve the puzzle because 1) there aren’t sufficient hints to help direct the player in what is relevant and 2) there are too many “things that could be relevant” in the game and given #1, you had to try everything possible with every object mentioned in case it did turn out to be important. You’d fill your pockets with tons of incidental items and try each one on everything you encountered in case it somehow by some miracle ended up being the one thing the monster was allergic to or something like that…

If you mention stairs, someone will spend a half hour playing around with the stairs, they’ll decide that MAYBE they’re “just stairs” and finally go on to explore another area. If there’s a corridor full of doors, they will try every means of opening them, and decide maybe there’s a certain order in which to open them…made worse yet if they all actually open into rooms that have nothing to do with the plot – at least if they’ve played through some of the games I’ve tried playing. :wink:

So most of what I’m saying is “Keep it Simply Story”. There should be plot-twists, devices, etc. but not devices because they exist in the game engine – devices because they’re adding something to the story.

In the corridor, perhaps the doors could be a backdrop that gives a moral message like “You know this is a government center and you’d never dream of just barging in to one of the offices for fear of being arrested. You’d best get on your way to your appointment before you’re late.”

Think of the hour(s?) saved on behalf of the player…lest they search for keys and stuff…