beginner questions/programming

Authoring General Design Discussions
1

Good evening everyone-

New to the board- this is my first post. I’m a long time fan of IF but I haven’t been following it for several years. I’m looking to write my own but I’m not too savvy with programming. In addition, my biggest problem with IF (aside with frustration over commands) was always a sense of disorientation and getting lost.

I was wondering if the current IF software out there would support:

A) a simple map function (i.e. a small simple outline like a blueprint next to the text simply showing where the player currently is) or;

b) an idea that occurred to me the other day that the text could be divided up into 9 different boxes composing a square and each box relates text relative to your position

Example: You’re standing in a large room with a purple couch to the north, a staue of Elvis to the south, a grue to the east, and so on. Instead of seeing just a description of the room you would see a grid with a description of each direction in the corresponding box. It would be arranged thus (each hash or letter represents a direction:
#|N|#
W|#|E
#|S|#

NW;You see blank | N: You see a purple couch | NE: You see blank
W: Nothing | C: General description of the room, item at your feet| E: A grue stands patiently
SW: A black hole | S: Elvis stands gleaming. | SE: You wish you saw Elvis standing here.

Get the idea? I think it would help alleviate disorientation since it would give more spatial awarness to the game. I would appreciate if anyone could answer these beginner questions.

Thanks,
WT

2

As far as I’m aware there is no game that does this, but it wouldn’t be impossible to code.

For a game that uses a compass rose (with changing colours depending on whether a room has already been visited), check out Bronze by Emily Short. If you were to use the Inform 7 language, you could simply copy-paste the code from ther game and have a compass rose like this as well.

Also displaying mini room descriptions would be an additional challenge, but not, as I said, impossible.

You might also want to check out The King of Shreds and Patches by Jimmy Maher, which uses a graphical map and a “GO TO” command–more work, since you need to draw a map, but very good against disorientation,

A third solution would simply be not to use too many rooms. Whether that would work will depend very much on the kind of game you wish to make.

3

If you minimize how often your room descriptions describe the relative positions of scenery to the player, this probably wouldn’t even come up. If you think about static fiction (books, whatever), it’s done without the need to stick the character at a fixed spot in the room. Granted, it’s not up to the reader to interact with the scenery in static fiction, but I think more of that kind of construction can help avoid player-confusion in IF.

In your example:

“You’re standing in a large room with a purple couch to the north, a staue of Elvis to the south, a grue to the east, and so on…”

Unless you’re micromanaging the room (a la a one-room game, where the player can “approach” various things, and the maybe the puzzles involve spatial orientation), it’s probably not necessary to tell the player exactly where in the room everything is. But even if it is, you can usually make it flow better by trying to reserve direction descriptions for room exits only, and then describing scenery as “near” that exit.

Also, and for the same reasons above, when you have to describe directions, it’s probably better to describe them in relation to the room as a whole, rather than assuming the player is standing in a certain spot and describing it in relation to the player. I.e., “near the south wall” instead of “to the south.” It seems better to describe things specifically in relation to player (i.e., “to the south”) primarily when it’s an exit or something “distant” that’s visible from the current location but not actually “in” the current location (such as being able to see mountains to the south, if standing in a field).

So:

“This large room features a statue of Elvis near the southern wall, strangely complementing a purple couch beside the open doorway leading north. A door to the east is closed, which is just as well since it’s currently blocked by a rather upset-looking Grue.”

The more complex it becomes, the harder it will be to visualize. I can remember that being a big problem in one particular scene in my Trading Punches, where the area on and around a pavilion was far more spread out and complicated than it needed to be, causing some players to completely misunderstand the layout.

It’s easier if you think of north as “forward/up”, south as “backward/down”, west as “left” and east as “right”. What would be more confusing to me than your initial example would be a game where I was sometimes facing east, sometimes facing south, and so on. Without writing as though the player is in a certain spot facing a certain direction, it will probably be easier for the player to orient themselves naturally – especially when most of the specifics aren’t important anyway.

4

ADRIFT has a built in map in its Windows interpreter. The ADRIFT parser can be annoying at times, but I do love that map.

I think Merk’s right that there are much better ways to alleviate disorientation in traditional IF games - for example structuring your map in a certain way (I’ve tried linear and circular maps, although some people were confused by the circular one).

On the other hand, I think that there might well be a use for this in a non-standard IF game of some sort. A game where it is important to know what’s around you and where it is.

5

It would be an interesting experiment, but I think it would require a custom engine. Hugo might be able to do this, since you can define multiple text windows (as long as they’re for display, and the main input/output area must come below all of them). I should try a test some time.

6

Thanks for all of the replies!

I’ll definitely check out your suggestions: The King of Shreds and Patches, Bronze, ADRIFT, etc. I have so much to learn!

I’m still interested in developing the grid idea and seeing what comes of it. At least in my mind, it would be an interesting system for maintaining orientation while removing the somewhat artificial constructions of N - S - E - W. When I walk through a house (in real life) I don’t think, “there’s a door to the north and a desk to the south”, I think of objects being positioned relative to each other rather than based on a system of cardinal direction. If I walk through a new doorway I don’t position the door N,S,E, or W I think of the door just as behind me or across from the window etc. The descriptions in each box would be fairly short just to keep unnecessary complication to a minimum.

Obviously there’s a lot of work to do- both with the merits of the concept, as well as the actual production of the code necessary to realize it. Lots of work to do! I’m sure I’ll have more questions, but in the meantime thank you!

7

P.S. I’m going to take a serious look into map structuring (circular and otherwise) as a means of alleviating disorientation. I think part of the reason I hadn’t thought of that is attributable to the fact I live in an old, somewhat labyrinthine house. It would be hell to navigate in an IF!

8

I meant to post this a week ago, but I’m pretty sure you can use HTML tables in TADS. And that would do the trick.

9

Thanks!

10

I agree with Pacian and others that the magic square configuration you’re talking about would be an interesting thing to try in a specialized game-world, but that it would probably cause more confusion than it prevented otherwise.

If you are interested in using maps in an Inform 7 game, you may want to check out my Graphical Window Sprites extension. It will get a major update/makeover soonish (probably to be released sometime after the next build of I7, whenever that happens), but at this point you’re probably interested more in ideas anyway. You can download some short example games that use the extension here:

http://www.sendspace.com/file/fowqkq

You might also try Mark Tilford’s I7 extension “Automap”, which automatically maps the world using ASCII.

–Erik

11

This is my first question on the forum. As I’m new here I wasn’t certain exactly where I should be posting, but here goes:

My player-character needs to start the game with a coat that has a pocket full of various items. I’ve followed the Inform 7’s manual for making the pocket part of the coat, but during game play it isn’t describing the conents unless you “Look at coat” or “Look in pocket.” Any advice on how to fix this?

CODE: (Inform 7)
A coat is a kind of thing. A coat is wearable. A pocket is a kind of container. A pocket is usually openable and closed.

The player is wearing a brown cotton coat. The brown cotton coat is a coat. The deep pocket is part of the brown cotton coat. The deep pocket is a pocket. Inside the deep pocket is a compass and a frost projector. The description of the brown cotton coat is “a brown cotton coat, [If the deep pocket is open]with a pocket containing [a list of things inside the deep pocket][end if].”

SAMPLE PLAY:

inventory
You are carrying:
a brown cotton coat (being worn)
a handkerchief

open pocket
You open the deep pocket, revealing a compass and a frost projector.

inventory
You are carrying:
a brown cotton coat (being worn)
a handkerchief

look in pocket
In the deep pocket are a compass and a frost projector.

drop coat
(first taking the brown cotton coat off)
Dropped.

look
Console Room
Your are in what serves as the control deck of your time machine, or rather what remains of one.

You can see a brown cotton coat here.

look at coat
a brown cotton coat, with a pocket containing a compass and a frost projector.

12

Rule for printing the name of the brown cotton coat while taking inventory:
if the number of things in the deep pocket > 0:
let L be the list of things inside the deep pocket;
repeat with n running through L:
say " [n][line break]".

13

Inform 7 replies:Problem. The phrase or rule definition ‘Rule for printing the name of the brown cotton coat while taking inventory’ is written using the ‘colon and indentation’ syntax for its 'if’s, 'repeat’s and 'while’s, where blocks of phrases grouped together are indented one tab step inward from the ‘if …:’ or similar phrase to which they belong. But the tabs here seem to be misaligned, and I can’t determine the structure. The first phrase going awry in the definition seems to be ‘If the number of things in the deep pocket > 0’ , in case that helps.

This sometimes happens even when the code looks about right, to the eye, if rows of spaces have been used to indent phrases instead of tabs.

The person who originally introduced me to Inform 7 did warn me that indentation is tricky. What’s the correct way to indent here?

14

Try it like this, but replace the indenting spaces with tabs: one tab for the second line, two tabs for the third and fourth lines, and three tabs for the last.

15

Copy and past doesn’t translate well into inform because it replaces tabs with spaces. Sorry.

16

No need for an apology; you’ve both been of imeasurable help to me and it’s very much appreciated. :slight_smile:

I’ve edited my post because I’ve slightly improved the code since before. It now reads thus:

After printing the name of the brown cotton coat while taking inventory: If the number of things in the deep pocket > 0: Say "[line break] the brown cotton coat's deep pocket contains:"; Let L be the list of things inside the deep pocket; Repeat with n running through L: Say "[line break] [a n]".

Which produces this result:

i
You are carrying:
a brown cotton coat
the brown cotton coat’s deep pocket contains:
a compass
a frost projector (being worn)
a handkerchief

(Somehow changing the last little bit [A n] to [a n] corrected the problem of the coat being described as “An brown cotton coat”)

Still no idea on how to shift “(being worn)” to the end of the coat’s description where it belongs. I’ve also tried using “Instead of printing the name of the brown cotton coat …” but Inform 7 didn’t like that. :frowning: Is there a way to re-word the rule so that it takes effect after the words “(being worn)” are printed for the coat?

17

Another approach would be to implement the coat itself as a container. The drawback is that your player can’t open the coat and the pockets separately, but unless you need this capability, you are better off faking the existence of the pocket. That way you don’t have to write so much code just to get back to the standard behavior.

A coat is a kind of container. A coat is wearable. A coat is usually openable and closed.

The player is wearing a brown cotton coat. The brown cotton coat is a coat. The brown cotton coat contains a compass and a frost projector.

Understand "pocket/pockets" as the brown cotton coat.

Instead of searching the closed brown cotton coat:
        try opening the noun.
	
Instead of examining the brown cotton coat:
        say "Lightweight and mud-colored, the coat has several deep pockets[if the noun is open], in which [is-are a list of things inside the noun][end if]."
	
After printing the name of a closed coat:
        omit contents in listing.

After opening the brown cotton coat:
        say "You search through the coat pockets, turning up [a list of things inside the noun]."

After closing the brown cotton coat:
        say "You close the pocket flaps."
18

Rule for printing the name of the brown cotton coat while taking inventory:
if yourself is wearing the brown cotton coat, say “(being worn)[line break]”;
if the number of things in the deep pocket > 0:
let L be the list of things inside the deep pocket;
repeat with n running through L:
say " [n][line break]" instead.

Putting the instead will stop it from printing again at the end.

19

It was interesting seeing that; I didn’t know that the “instead” command could be put at the end of a sentence (I have a lot to learn about the syntax of Inform 7).

However it didn’t work, this was the result:

You are carrying:
a (being worn)
compass
(being worn)
a handkerchief

The coat’s name is missing, along with the frost projector’s name and the “(being worn)” generated by Inform 7 is still there regardless.

I replaced “rule for” with “After” to bring the coat’s name in, but that “(being worn)” is still confounding me. :frowning:

Yes that approach occured to me early on as well. Strictly speaking I guess it’s not necessary to have the open/close feature, except that the player here will be gathering a lot of objects and it would have been convenient to shorten the inventory listing by closing the pocket. It’s dissapointing that such a limitation exists when you’d think that clothing with pockets would be a very common feature in interactive fiction. :frowning:

Thanks guys. :slight_smile:

20

Clothing is fairly common; this specific inventory format is not something I’ve seen asked for much, though.

Using the “rule for printing the name” hook works in many respects, but it has a few problems. The “(being worn)” tag shows up where it does because, from Inform’s point of view, all that other stuff you’ve printed about the coat is still part of the coat’s name. You can suppress it by hand using “omit contents in listing”, like this:

After printing the name of the brown cotton coat while taking inventory: if the brown cotton coat's pocket is open and the brown cotton coat's pocket contains something: say ", [if the brown cotton coat is worn]worn and [end if]containing in the pocket: "; repeat with item running through things in the brown cotton coat's pocket: say "[line break] [a item]"; omit contents in listing.

I should add, though, that the things that are in the pocket will be listed differently than the things out of the pocket, because our “[a item]”-style list doesn’t include inventory information such as “(providing light)” or “(closed)”. We could get around that by writing

After printing the name of the brown cotton coat while taking inventory: if the brown cotton coat's pocket is open and the brown cotton coat's pocket contains something: say ", [if the brown cotton coat is worn]worn and [end if]containing in the pocket: [line break]"; list the contents of the brown cotton coat's pocket, with newlines, indented, giving inventory information, including contents, with extra indentation; omit contents in listing.

But the problem here is that the formatting doesn’t work right because we’ve called the listmaker while we were already in the middle of an existing list, so it loses track of how much it needs to indent. It’s possible to fix that too, but it would require considerably more fiddly hackery.

Here are some other suggestions, from easiest to trickiest:

  1. put the pocket contents all in-line:

After printing the name of the brown cotton coat while taking inventory: if the brown cotton coat's pocket is open and the brown cotton coat's pocket contains something: say ", [if the brown cotton coat is worn]worn, [end if]with [a list of things in the brown cotton coat's pocket] in the pocket"; omit contents in listing.

  1. generate a second segment to the inventory list, like this:

After taking inventory: if the player encloses the brown cotton coat and the brown cotton coat's pocket contains something and the brown cotton coat's pocket is open: say "In the pocket of the brown cotton coat: [line break]"; list the contents of the brown cotton coat's pocket, with newlines, indented, giving inventory information, including contents, with extra indentation.

which would produce output like

with the whole pocket segment vanishing if the pocket is closed.

  1. Use the hack of making the coat itself “openable” and then disguising the fact, as suggested up-thread.

  2. Go to a more natural-English inventory listing, and use Jon Ingold’s Written Inventory extension to customize your inventory output just about however you like.

  3. Write your own custom inventory output code.