Post navigation

Inform 5U92

…is now out. To people who were not waiting for bugs to be fixed, this may seem like a pretty low-key build: a huge amount of work went into it, but much of that work had to do with improving internal code in preparation for an eventual release of the Inform source, rather than with producing new features. Assorted things are now more cleanly implemented and a better foundation for future improvements, but that doesn’t make for glamor in the change log.

However, of possible note to readers here: the latest build does (as I mentioned in an earlier post) allow for scenes to be given properties, which means that it is now possible to make rules about what is allowed to happen during a type of scene — as in

Instead of going somewhere during a restrictive scene: …

We do not yet have the ability to write generic rules about when types of scene begin and end, which I would also like; but this may improve matters somewhat for heavy users of Inform scenes.

In other news, it is now possible to define new directions freely — something that we felt was an omission from the outset, so I am glad that is checked off the list.

Great! The release notes make me very happy; not just because some bugs were fixed that bothered me, but at least as much because some long-standing annoyances that I had always simply regarded as “limitations of the system” have been removed. Things like this:

The same adjective can now have multiple independent meanings, and there is
no difficulty provided that these apply to different things. Thus a
definition of “fancy” for a colour would not obstruct a definition of
“fancy” for a door, for instance.

or like the fact that you could always only define one unnamed set of mutually exclusive properties for a kind. Very good to see these limitations removed.

I was very excited when I saw that you’ve added the capability to add new directions. This is something that I’ve been wanting for quite some time to implement a labyrinth. But I was disappointed to see that every direction needs an opposite direction. That kind of ruins the idea I was having in mind. Why do directions need to have opposites? Is is because of the path finding algorithm you use? Or is it for how you generate the map given the description of how rooms are connected? Anyhow, if it is possible to lift the restriction I would be a very happy customer.

Or is it for how you generate the map given the description of how rooms are connected?

Yes. It’s so that there can be automated reciprocal directions.

Now, that being said: there is nothing to stop you from creating directions in pairs and then using only one of each pair, while setting each map connection as one-way, like

Wiggle is a direction. Antiwiggle is a direction. The opposite of wiggle is antiwiggle.

Antiwiggle is privately-named. [thus even if the player stumbles upon the name of your fake opposite direction, the game will pretend not to understand it.]

The Seven-Sided Room is a room. The Flooded Room is wiggle from the Seven-Sided Room. Nowhere is antiwiggle from the Flooded Room.

…and so on. It’s a bit more work, I realize, but the current design is meant to ensure that two-sided map directions continue to work for the games that do want that effect (which we assume to be the majority of games creating new directions).