Inform7 and other general questions

Hello there,
I have absolutely no experience in programming, but have always wanted to try writing an IF game, and after playing around, I’ve decided to go use I7 as my authoring system. Testing the waters with it, a couple of questions/problems have come up.

Firstly, say I have a room with levers A, B and C in it. I want to include these in the description of the room (say “A small room with three levers”), and not have them pop up again after that in the line “You can see Lever A, Lever B and Lever C here” since it just repeats itself.

This raises another problem however: if I DO manage to remove this, will it cause problems with the description of the room if I pick up one of those (portable) levers, or can I write it in such a way that it recognizes the removed object and prints the description with only two levers.

Secondly, if I put a torch in this room, the above line will further read “… and a lit torch (providing light)”. Is there a way to remove “(providing light)” from that?
Is this just overcomplicating things for me? It seems to me like it somehow breaks atmosphere or flow when it suddenly switches to the technical “You see objects here”. Do all authors stick with this?

Thirdly, if these levers are alligned from left to right - I wanted to name them Left Lever, Middle Lever and Right Lever, but I also want them to show up in the description (the one that I want to fully take out, but I guess it’s still good to know) as “the Left, Middle and Right Levers” not “Left Lever, Middle Lever, Right Lever”. And while we’re on this subject, when I enter ‘pull lever’ I get asked “which one, Left Lever, Middle Lever or Right Lever?” How can I add a definite article to them, or maybe even turn it into “the Left, Middle or Right one?”

My fourth question has to do with the Welcome text, Release and build notes at the start of the game. Can I remove those too? If I use the “when play begins: say…” rule, the cited text appears BEFORE the build notes, and the rest (starting room) after. Or can I move it all the way to the top so it doesn’t go in between them?

My last questions are less technical:
What is the best way to go about writing the game? I have it outlined in my head from start to finish, but I found that when putting it to paper, I tend to stray away from sticking to I7’s norms and go towards flowing prose, and when I need to apply it, I have to chop up parts of text, even rephrase much of it, and so on.
Working part by part on it seems a better way.

Regarding reading the manual: I’ve read about 7 chapters, but it’s tiresome when all I have to go on is just an explanation and a given example, and much of the information doesn’t stick to me, so I’ve found it easier to just start experimenting and learn from that (while still applying the manual’s instructions). This however is very nonlinear so I jump back and forth through chapters a lot. Is there a better way to learn and get used to I7?

Thanks a lot. I’m looking forward to discussing authoring further. Cheers :slight_smile:

hi, welcome to the forums :slight_smile:. First of all I recommend you check out some of the extensions that are designed to address many of the questions you have.

inform7.com/extensions/all-extensions-by-title/

I’d start with Room Description Control especially.

I’m not that familiar with I7 itself so hopefully some others here can step in and give you more specific help.

Regarding the release and build notes (the banner), see example 357, ‘Bikini Atoll’, which uses:

Rule for printing the banner text: <insert your code here>

You may want to get a copy of Jim Aikin’s I7 manual, it has a different approach than the included documentation.

musicwords.net/if/i7hb.htm

I haven’t tried using any kind of extension yet, since I’ve felt intimidated by them, maybe not yet ready to deal with them, but by the looks of things it’s not something that complicated.

I’m checking out the manual too, it’s very helpful. Thanks a bunch! :slight_smile:

You can use grouping (see the documentation chapter 17.14):

[code]The lab is a room.

A lever is a kind of thing.

The left lever, the right lever and the middle lever are levers in the lab.

Before listing contents:
group levers together.

Before grouping together levers:
say “[listing group size in words] levers (”;

After grouping together levers:
say " lever)";

A lever has some text called the short name. The short name of left lever is “left”. The short name of right lever is “right”. The short name of middle lever is “middle”.

Rule for printing the name of a lever (called the current lever) while grouping together levers:
say “[the short name of the current lever]”.[/code]

It does cause problems but in a different way: what if the player picks up the levers and drops them in some other room? It’s better to have portable items handled by the game in their separate paragraphs, otherwise you’ll have to modify every room description by hand, just in case the player happens to drop the items there.

I’m not actually seeing that in the room description, only in the player’s inventory. Removing it might be a bit of a hassle (there’s an example in chapter 20.3, example 407).

No, that’s why there’s the “initial appearance” property which allows you to give special room descriptions to the objects before they are picked up (see chapter 3.1).

Inform does that automatically, but looks like you’ve omitted “the” from your code when defining the levers, so Inform thinks they are proper names. So instead of

Left Lever is in the lab. write

The left lever is in the lab.

(Also, you might want to consider dropping the capital letters from the objects, since they are not proper names. Some players find unnecessary capitalizing annoying.)

George’s method should work fine, but bear in mind it’s then polite to give credit to Inform’s creators at some other part of the game if not in the banner. You can also move the intro text after the banner by using “Before looking for the first time” rule instead of “When play begins” rule.

I would argue that there’s no universally best way to do it. What works for one person might not work for others and if you find one way of designing better than another you’re obviously right when it comes to how you should work. Here are some past conversations you could browse for tips: http://www.ifwiki.org/index.php/Past_raif_topics:_IF_Theory:_part_1#Game_design

Thank you, this is extremely helpful!