Last time, on let’s make IF…
Yesterday, I continued building technical framework for my story. I was also able to get some more text written. Highlights:
- Technical design:
- Added a new relation, curiosity, to track what Marbles’s friend D was currently interested in.
- Devised a method for using both the curiosity relation and the currently active scene (in a set series) to print descriptive text every turn, dramatizing D’s interactions with whatever currently interests him.
- Text and narrative:
- Shifted focus of the prologue from examining a large box onstage to investigating the doors at the back of the theater. Modified the opening crawl and room description (with a “one of… stopping” construction) to accommodate this.
- Wrote my first text about an interest of D’s: the exit door at the back of the theater.
- Craft:
- A wrote a bit about “railroading” and narrative urgency.
- Things to do:
- Choose a way to report D’s movement across Among the Seats to the Main Exit (I’ve decided to rename Main Entrance to Main Exit).
- Get Marbles and D together at the back of the stage, then have D turn on the lights to reveal more visual detail about the world (ending the prologue).
Tracking D’s movements
I don’t picture D moving around a lot. In fact, during the last third or so of the story, he’ll be in one place. However, when it happens, the player needs to be told about it. The first thing that comes to mind is the protagonist in Deadline seeing characters in other rooms moving around. We don’t want that level of simulation, obviously, but ideally we can do something that we just fire and forget about. There’s a pretty comprehensible recipe from the documentation, Latris Theon (be aware that the web docs contain spaces instead of tabs, so you’ll need to tidy those up). I sometimes–even after a couple of years of practice–have a hard time using the recipes, but I was almost able to just drop this code in.
I’ve never really messed with this, and I don’t see myself going further than I’m going now, but Inform has rather elaborate and extensive support for simulating the actions of NPCs, as well as for players bossing them around (this possibility is called “persuasion”). As we saw yesterday, when we used a variable for “a table name that varies,” we can use variables to track a lot more than numbers and texts. We can store a room in a variable, too:
the destination is a room that varies.
or, for our purposes, we can treat it as a value:
a person has a room called the destination.
the example left the starting value blank, which I assume is a [nothing] value, but I went ahead and game D one. If we had a bunch of characters that moved around, I would probably do a “when play begins” rule that gave them a destination of their starting location. It’s not necessary, so why? Whether it matters or not, I don’t like empty values. If it’s easy to fill them in, I will. And it is definitely easy. If I wanted to do something special with the player, I’d just append it to this rule:
when play begins:
repeat with individual running through persons:
now the destination of the individual is the location of the individual.
The example makes use of an “every turn” rule that checks against the NPC’s destination against their location, If they don’t match, Inform has language for sending them on their way.
let the right direction be the best route from the location of d to the destination of d;
try d going the right direction;
It’s worth noting that many people have found Inform 7’s pathfinding insufficient. There is a toggle between “fast” and “slow” modes. Glulx games are fast by default, and this is a blog about making Glulx games. With only four rooms in our little map, I’m not going to worry too much about pathfinding efficiency. You can read the relevant section of the docs here.
I want a little more out of my rule. While D may be moving, Inform doesn’t tell the player about it unless they are entering or leaving the player’s location. That isn’t good enough for this game, where looking into other rooms is business as usual. I think the best way to handle this is to add feedback to D’s travel rule, rather than mess with scoping or weird stuff.
When D initially starts moving, Inform fires a baked-in reporting rule to say, in very few words, that D has left. I want to customize that. I also don’t want our feedback about D’s movements to trip over it. This is one of those tricky timing things. D is going to leave, and then he’ll be in another room. We don’t want to say he’s leaving and say he’s moving somewhere else all in the same turn. Thinking it over, what we want is a condition that prevents us from giving additional feedback when he has arrived just one turn away from his starting point. That way, players will hear that he moved but not that he’s moving when he’s just left. Let’s iron that out. I’ll start by adding another variable.
the point of departure is a room that varies.
the point of departure is the mystery zone.
I have a room in all of my games called the mystery zone. It’s a kind of parking lot. Inform has “nowhere,” which I also use, but some things–the player, for instance–can’t go there. It’s also good for scenarios like this.
every turn when the destination of d is not the location of d:
if the point of departure is the mystery zone:
now the point of departure is the location of d;
We’ll change the point of departure to D’s location at the start of his journey, and change it back to the mystery zone when he arrives. Next, D moves. The first bit of code is straight from the documentation, but then I start doing my own thing.
let the right direction be best route from the location of d to the destination of d;
try d going the right direction;
let the distance travelled be the number of moves from the the point of departure to the location of d;
if the distance travelled is 1:
rule succeeds;
That “distance travelled” number is the count of steps from D’s starting point. If it’s only one, the rule stops and nothing other than his initial exit message is printed.
otherwise if d is not in the location:
if the location of d is the destination of d:
say "D arrived at [location of D] and began looking at the [fascination of d].";
now the point of departure is the mystery zone;
otherwise:
say "Off in the distance, I saw D headed in the direction of [destination of D].".
Now it all comes down to text. There’s one message for D’s arrival, and one for when he is in-transit. If he’s arrived, we change the point of departure back to mystery zone. He’s ready for his next trip!
Some notes: this will get us to the end of the prologue, but we haven’t really finished. This code assumes that D will always start in the player’s location, which won’t always be the case. It also assumes that he will arrive somewhere that the player is not. I’m fairly certain that won’t always apply, either. So there’s more to do!
Here’s a snippet demonstrating the method.
Whew! I may do some text over the weekend, but I’m done for now. We’ve had six days of coding, and even though we don’t have anything playable, this is the kind of up-front work that saves time (and errors) later.
next.
What’s next? It really depends on what happens over the weekend. I’d really like to get to the end of the prologue. It’s reachable with only two actions from Marbles! It has to be an interesting two actions, though, doesn’t it?
Thanks for riding along. It’s been a good week, and I hope you’ll stick around.
top expert 