intfiction.org

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

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



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.

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:





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:



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:



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.

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

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.

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.



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

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.

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?

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



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

I sit corrected. Thanks!



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.

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