Reciprocal Directions

So for the past year I’ve been wanting to do something in Inform 7, and I’ve developed the nasty habit of starting projects in I7, hitting a wall and then switching to TADS. Right now I’m actually prototyping something in both languages, and since I’ve hit problems in both, I thought I’d ask about my I7 woes.

First up, reciprocal directions: I don’t like them, and I want to turn them off. I see my project as having a large number of rooms of different kinds. Movement will typically be one way, so the idea of having to remember to set opposite directions to nowhere seems like a headache.

Consider the following:

[code]The first room is a room.

The second room is south of the first room. North of the second room is nowhere.

The third room is east of the second room. West of the third room is nowhere.

The fourth room is north of the third room. South of the fourth room is nowhere.[/code]
Now imagine there was branching and multiple ways to reach a room.

Is there a way to tell Inform not to assume that a direction one way must also go the other way? (I’ve tried saying “The opposite of south is nothing.” which seems to work for newly created directions, but not for existing ones.)

At the same time, any solution shouldn’t prevent me from adding a returning connection in the rare instances where I do want them.

I don’t think you can turn the feature off completely, but you can go around it by defining the exits at runtime:

[code]The first room is a room. The second room is a room. The third room is a room. The fourth room is a room.

When play begins:
change the south exit of the first room to the second room;
change the east exit of the second room to the third room;
change the north exit of the third room to the fourth room.[/code]

The downside is that you’ll lose the world map in the index, but if the layout is too convoluted the map doesn’t handle it very graciously anyway.

I would have expected this to work:

The no-way is a direction. When play begins: repeat with way running through directions: now the opposite of the way is no-way.

But it doesn’t. It compiles and as far as I can tell it runs through all twelve directions, but the opposites apparently are not reset.
Can anybody explain why?

I’m sure there is another way, but as a last resort I guess you could replace Section SR1/4 - Directions in the Standard Rules with something appropriate to your needs.

Would this do? Or will it lead to horrible bugs?

[rant=Non-Reciprocal Directions]Section SR1/4/custom - Non-Reciprocal Directions (in place of Section SR1/4 - Directions in Standard Rules by Graham Nelson)

The specification of direction is “Represents a direction of movement, such
as northeast or down. They always occur in opposite, matched pairs: northeast
and southwest, for instance; down and up.”

A direction can be privately-named or publically-named. A direction is usually
publically-named.
A direction can be marked for listing or unmarked for listing. A direction is
usually unmarked for listing.

A direction has a direction called an opposite. [The going action at certain rare occasions uses the opposite of direction, so don’t comment it out.]

Include (-
has scenery, ! class CompassDirection,
-) when defining a direction.

The north is a direction.
The northeast is a direction.
The northwest is a direction.
The south is a direction.
The southeast is a direction.
The southwest is a direction.
The east is a direction.
The west is a direction.
The up is a direction.
The down is a direction.
The inside is a direction.
The outside is a direction.

[Adding the following two lines.]
The no-way is a direction.
The opposite of a direction is usually no-way. [Otherwise the opposite direction will default to north.]

[The north has opposite south.] Understand “n” as north.
[The northeast has opposite southwest.] Understand “ne” as northeast.
[The northwest has opposite southeast.] Understand “nw” as northwest.
[The south has opposite north.] Understand “s” as south.
[The southeast has opposite northwest.] Understand “se” as southeast.
[The southwest has opposite northeast.] Understand “sw” as southwest.
[The east has opposite west.] Understand “e” as east.
[The west has opposite east.] Understand “w” as west.
[Up has opposite down.] Understand “u” as up.
[Down has opposite up.] Understand “d” as down.
[Inside has opposite outside.] Understand “in” as inside.
[Outside has opposite inside.] Understand “out” as outside.

The inside object translates into I6 as “in_obj”.
The outside object translates into I6 as “out_obj”.

The verb to be above implies the mapping up relation.
The verb to be mapped above implies the mapping up relation.
The verb to be below implies the mapping down relation.
The verb to be mapped below implies the mapping down relation.[/rant]

Neat idea, but I think it solves one fiddly thing by replacing it with another.

Well, it seems to work nicely. (And I was wondering what the syntax was for overriding the default library.)

The opposites do seem to get reset. Try adding this bit to your code:

Whenever you go somewhere, it’ll say “(coming from the no-way)”. What I think is happening is that the map connections, with their opposites, get defined before play begins. So resetting the opposites after play begins doesn’t prevent the original reciprocal map connections from being created.

BTW it seems that the other place the opposite gets used in the standard rules is in the rules for reporting NPC movements, though the logic there is convoluted enough that I can’t tell what’s going on and how you’d want to deal with it after resetting the opposites.