Our Motto

It is very easy to be blinded to the essential uselessness of [the products of the Sirius Cybernetics Corporation] by the sense of achievement you get from getting them to work at all.

In other words — and this is the rock solid principle on which the whole of the Corporation’s Galaxy-wide success is founded — their fundamental design flaws are completely hidden by their superficial design flaws.

— Douglas Adams: The Hitchhiker’s Guide to the Galaxy


How do Doors Work in Inform 6?

Central porch of Chartres cathedrale Chartre 041130 Melusin (GFDL)Since I was having a bit of trouble lately in making doors in Inform 6 work, I thought it might be a nice idea to write down my experiences for my own memory, and of course for the benefit of other I6 novices who could find some advice useful.

Doors are I6′ way of connecting rooms in any non-trivial way. As such, a bridge, a teleport system or such should be implemented as doors, too.

Since I’m writing such a sequence right now, let’s assume you are at an inn on the upstairs floor, which is aptly named inn_upstairs, and there is one other room to the east, namely chamber.
The trivial way would be to connect those simply with an exit from inn_upstairs:
e_to chamber
which gives you ready access from inn_upstairs to chamber — but this is of course not what we want.

Rather, we’d like to have a door. First of all, we need to create it — which is done by inserting an object with the attribute has door and placing it in the room which we want to leave through said door (we’ll call this the “source room”) — in our exmaple, the room to leave is inn_upstairs. Now we need to implement the actual door behaviour, which is a three-step process:

  1. Define the door as the exit of the source room in the direction of the adjoining room, which in our case lies to the east — hence:
    e_to the_door
    replaces the previous direct exit in its definition.
  2. Secondly, we need to declare to which room the door will lead, provided it’s open — ie, define the door with
    door_to chamber
  3. Finally, we must also state into which “direction” the door is leading, namely
    door_dir e_to

I’m still a bit puzzled as to the purpose of the third step. My guess is it has to do with the behaviour that once a door is open, you can walk through it like through a regular exit without re-opening it every time, ie the original’s room e_to is now replaced by the door_dir.

Your door needs to be given the attribute openable so that it can be opened and closed and will behave as expected. To determine its initial state, you can give it the attribute open. (Without that it will initially be considered closed.)

To spice things up a bit more, you can define the door lockable (and locked, at your whim). It can then be locked or unlocked with any object you may have defined elsewhere, by defining it as the key for the door: with_key room_key, for example.

The complete code for rooms, door and key looks like this: (Note that the key is defined elsewhere, but since really anything can be the key, there’s nothing special about it.)

!##########################################################################
object inn_upstairs "A tiny landing"
with initial "You climb up the narrow stairs -- hardly more than a
ladder -- to arrive on the landing.",

description "A tiny landing on the tavern's first floor. While the
stairs lead down to the hall of the inn, one door leads to a room
south of you.",

e_to the_door,
d_to inn,

has light;

!##########################################################################
object the_door "room door" inn_upstairs
with name "door",

description "A door to one of the guest's chambers.",
when_closed "Another locked door bars your way to a room east.",
when_open "An open door leads east to the chamber behind.",

after[;
unlock: give self open;
],
door_to chamber,
door_dir e_to,
with_key room_key,

has door lockable openable locked static;

!##########################################################################
object chamber "A chamber in the inn"
with initial "You enter the modest small room and wait for a second,
until your eyes are accommodated to the bit of light coming
through a little window.",

description "The room is obviously occupied by a female guest, but
the lady isn't present.",

w_to inn_upstairs,

has light;

The lines
after[;
unlock: give self open;
],
may require a bit of extra explanation:

Per default, locking/unlocking and closing/opening a door (or any container, for that matter) are two seperate actions. With the after rule the opening follows the unlocking automatically, to make it easier and quicker on the player, and since it can be assumed that if the player unlocks the door, he’ll also want to open it (in this scenario).

Note that trivial exits and doors have one thing in common: Per default, they’re one-way in I6, which means that a door which connects room A to B does not automatically also give access from room B to A. Rather, you must implement a second door back from B to A (and ideally one which shares its locked/open state with the first door…). (In my example I went the easy way and simply gave the chamber visited through the door a “regular” exit back to inn_upstairs. In the current scenario, it makes little sense for the player to for example lock himself in the chamber.) I presume the one-way feature was designed with “unusual” doors like trap-doors in mind. You can also find libraries for I6 out there which help in implementing two-way doors.


850 lines: Hard fight, but I won

Most of tonights wrestling with Inform concerned doors, but I finally have finished the first correct implementation.

To Inform, there’s a big difference between unlocking and opening a door…


740 lines

The girls do my (or the player’s… ;-)) bidding, and I think they do so with a bit of charm.

The nun and the blind beggar have also been put into action.

It’s fun learning your way around Inform 6, and slowly, but surely getting the hang of it — I even “refactored” (ie, rewrote) a few old lines of code because I’ve learnt since how to better achieve what I want.


600 lines

I was a little distracted over the last few days.

But now, the Doge and Guido, the guard, have been written for the better part.

Today I need to make the girls by the fountain do what I want.


440 Lines of Code already for “Sinners and Saints”

Not bad. Not at all.

Most of the code is even already functional.


It’s been quite quiet

Yes, but after some two years now I’m back from my long search, and of course I’m where all long odysseys end, namely at square 1.

I had decided to look into writing my own IF authoring system — tentatively called Stardust — and to this end I looked for a suitable programming language.

After dabbling around with JavaScript and Ruby, among others, finally two candidates remained — Lua, and SmallBASIC (not the Microsoft variant, but a charming little piece of open source). In the course of getting acquainted with the latter, I even got sucked into a documentation project, to which I still devote some time, since documentation is apparently SmallBASIC’s Achilles’ heel. The poor documentation was also the reason why I finally decided against using it and opted for Lua, and simultaneously with the SM documentation started to work on a protoype of Stardust.

After about 500 lines of code, I began to see the immense amount of work I had ahead of me. For the first time, I understood concretely what designing and implementing an IF authoring system means — which in turn lead me to look back on Inform 6 to see how Graham Nelson had dealt with the questions which reared their countless ugly heads. I didn’t exactly despair, but now I grasped that with the limited amount of spare time to assign to this hobby, I’d never get anything worthwhile together, so I decided to give up on Stardust.

But it wasn’t all for nothing (otherwise I wouldn’t revive this blog); first of all I got a bit of insight into several programming languages which had been black boxes to me before. Secondly and more importantly I now also understand Inform 6 much better. One confronted with the questions and problems programming an IF system entails, I now much better understand Nelson’s concepts and why he choose to design I6 the way he did. This in return makes it much easier for me to program in I6, because I can follow Nelson’s “trains of thought.”

To make a long story short, I’m pouring and sweating over my first “real” work of IF, after the Isle of Statues, which always was only a prototype. The new story will be called Sinners and Saints, more story- than puzzle-driven.*) Currently, work on it is going at a good pace (note, I have to re-learn much detail of what I had already understood once three years ago…), and due to my exploration of the IF authoring world, I daresay I encounter less blocks and bottlenecks than back then. So, the odyssey wasn’t all for nothing. ;-)

Here’s the intro to Sinners and Saints in it’s nascent state:

“The time: 1525, a sunny spring morning. The location: A city which shall remain nameless, in the northern regions of Italy. You are Fortunato di Carazza, a young cavaliere, quick with the rapier and the wit — a renaissance gentleman.

You have been summoned to the palace of the town’s Doge, the almost absolute ruler of the community. The summon was friendly but positive, so you decided not to keep the Doge waiting, though you have no idea what he wants from you. You arrived at the appointed time at the palace, but now you’re waiting in the antechamber for the Doge to finish his other, apparently more important businesses.”


*) I never really got the hang of most puzzles, and found them endlessly and needlessly frustrating. YMMV.


The Search Continues

In the long term I plan to write my own IF authoring system and am still looking for the proper programming language to do the job in. Sadly, none of the languages I’m proficient in seems to be well suited to this project.

I’ve had my eyes on Lua for some time, but it’s far too eclectic for me. Smalltalk looked good, but doesn’t seem to be able to provide standalone applications. I’ll check out Ruby next…


Follow

Get every new post delivered to your Inbox.

Join 155 other followers