Category: Inform 7

Computers extension, v2

“Computers” is an extension I wrote some time ago, but the hiatus of the extension website meant that it wasn’t posted, so I didn’t announce it. However, it’s available now, and may interest some people.

The extension provides kinds for generic computers, as well as more specific implementations for desktops and laptops; some generic support for removable storage devices such as USB drives, CDs, and disks; and several kinds of software, including email and search engine programs, menus and operating systems, and password locks. (The behavior of the email and search portions are similar to those of the computers in Floatpoint.)

So, for example, we could set up a laptop with a password lockdown and an email delivery system thus:

Include Computers by Emily Short.

Conference room is a room. The conference table is a thing in the Conference Room. The small laptop is a laptop on the conference table.

The small laptop runs a password lock program called laptop security. Laptop security is privately-named. The password of laptop security is “mulderxox”.

The small laptop runs an email program called laptop email. Laptop email is privately-named.

The message table of laptop email is Table of Laptop Messages.

Table of Laptop Messages
topic message arrival time read answered description
“memo” “Memo” 9:00 AM false false “Your boss would like to see you in his office right away.”
“SPAM” “SPAM” — false false “Money for you from Nigeria!”
with 10 blank rows.

At 9:10 AM:
deliver “SPAM” to laptop email.

Test me with “turn on laptop / x laptop / x screen / type mulderxox / read memo / read spam / z / z / z / z / z / x screen / read spam / reply to spam”.

Version 2 fixes a couple of stupid little bugs and also introduces two new examples, one simple one demonstrating a computer with a removable drive, where the drive’s presence adjusts what can be found with the search engine, and a more complex one demonstrating the implementation of an ATM that must be accessed using both a debit card and a PIN, and has several different input modes.

Version 2 is available here.

Modeling conversation flow: multiple people conversing; some closing caveats

[This is part of a series of discussions on the craft of modeling conversation. For previous installments, see my original Homer in Silicon article which lays out the basic elements of the model, and previous blog posts on the issue.]

Modeling conversation flow gets more challenging when there are multiple participants in the scene. I’ve tried two approaches to this.

Model the group as a single entity. If you have a scene where the same set of three or four people are going to be talking — no one entering or leaving at an unpredictable time, everyone involved throughout — then it’s possible to model the conversation much as though it were a conversation with one interlocutor. Quip responses contain whatever is said by every character who isn’t the player. Any member of the group may be narratively responsible for moving the conversation forward.

I’m only partway through writing the game that uses this method a lot, but I would say that it works (where it does work) because the game has a strong narrative shape that isn’t up to the player. The player can affect the outcomes of scenes, certainly, and has considerable agency over what ultimately happens, but has little influence on pacing.

Model each character individually, and allow everyone at least the chance to speak after the player speaks. This is what I did with Fugue, an experimental mini piece in which the protagonist is having a conversation with several friends (who are really several internal voices of her own). Each NPC, once addressed, continues to contribute to the conversation, until all three of their voices are engaged.

Fugue really doesn’t attempt many of the interesting things that could be done with this, because on the technical side it really was just playing with whether I could get the characters to have planned conversation that ran in tandem.

However, the same model is what I’d want if I were writing a conversational sandbox in which the point is to have a number of characters wandering around exchanging information. Conversational facts are known by everyone who has heard them spoken, which means that it’s possible to have characters react to things said in their presence but not said “to” them.

To make a compelling game of this would require a considerable amount of modeling to do underlying the quips, though. The quip model I’ve discussed here is designed to create a sense of context; interpret the player’s input based on that context and provide conversation hints if desired; manage pacing; and assemble the various statements, interruptions, and pauses into continuous prose. It doesn’t provide any kind of conversational goal-seeking, though. It leaves it up to the author to decide by hand what quips should be added to a character’s planned conversation. It allows the author to mark up text to indicate mood changes and facts discovered, but it doesn’t require the use of those elements, and it doesn’t assume anything about the modeled psychology of the characters.

The more sandbox-like the game, the more we’ll need another model beneath the quip model — one that does deal systematically with moods, factual knowledge, and goal-seeking.

Modeling conversation flow: beginnings and endings using scenes

[This is part of a series of discussions on the craft of modeling conversation. For previous installments, see my original Homer in Silicon article which lays out the basic elements of the model, and previous blog posts on the issue.]

The convention that characters should greet one another before launching into other discussion is now pretty well established in realistically conversational IF; for Inform, Eric Eve’s Conversation Framework extension provides this functionality and I’m planning to use something compatible with his work.

There’s no reason, however, why the player should always get to dictate when a conversation begins and ends. Alabaster is not a very good demonstration of conversation beginnings and endings because there are relatively few transitions, but consider, say, Blue Lacuna: other characters move around, begin and end conversations, and generally behave as full partners in talky scenes.

In Inform 7, I rely a lot on the scene mechanism to manage conversations, because they allow me to write natural lead-ins and lead-outs, to set up lists of planned conversation in rules like “when heist planning begins”, and to set complicated conditions for when a scene should end. The conversation system also has a feature that allows quips to be set only to occur within a specific scene, which is a good way to protect against accidentally out-of-context remarks.

Continue reading “Modeling conversation flow: beginnings and endings using scenes”

Modeling conversation flow: silence

[This is part of a series of discussions on the craft of modeling conversation. For previous installments, see my original Homer in Silicon article which lays out the basic elements of the model, and previous blog posts on the issue.]

If we have an NPC with a long list of things to say, and the player types WAIT or LISTEN rather than selecting any of the possible responses, we might want the character to comment:

“Next, you’ll need to approach the farmhouse from the northwest under cover of darkness. Wolf-cub should already have cut the telephone wires and the electricity, but you’ll still need to be stealthy: they may be armed.”

You could ask whether the enemy will have snipers.

>LISTEN
You listen.

“Then… [stuff]”

>LISTEN
You continue to attend to The Fang’s briefing.

“Next you’ll… [more stuff]”

>Z
The Fang seems to be done.

“You catch all that, Snakemouth? You know I don’t like it when operatives have no questions. It worries me.”

>SMILE
You smile serenely. The Fang mutters something rude under his breath, but it looks like he’s going to let you break for lunch at last.

One simple approach is to keep a counter that resets every time the player speaks, and increments every time the NPC does; thus if the counter hits (say) four, that means the NPC has talked for four turns without any reply, and we can use that information to plan an immediate optional question about why the protagonist is being silent.

Modeling conversation flow: actions in conversational context

[This is part of a series of discussions on the craft of modeling conversation. For previous installments, see my original Homer in Silicon article which lays out the basic elements of the model, and previous blog posts on the issue.]

Giving and showing.

In addition to ASK and TELL, many IF games retain the convention that the player can give or show objects to other characters. Though these are not strictly conversational actions — that is, you can give or show an object without opening your mouth — they involve communication, and therefore we may want to have the NPC’s reactions be affected by the other conversational context that’s going on. Besides, we may often want ASK BOB ABOUT DAGGER to gain the same response to SHOW DAGGER TO BOB, if the point is to get Bob to reveal some specific bit of information about the object.

My preferred way to do this is to have quips to represent what Bob says about the dagger, and then redirect SHOW DAGGER TO BOB to an available quip that mentions the dagger. That means that we can write follow-up questions about the object, cue follow-up comments for Bob, and otherwise track the exchange just as though it were part of the standard conversational structure.

Continue reading “Modeling conversation flow: actions in conversational context”

Modeling conversation flow: NPC questions

[This is part of a series of discussions on the craft of modeling conversation, in particular using the conversation system I’m developing for Inform 7. For previous installments, see my original Homer in Silicon article which lays out the basic elements of the model, and previous blog posts on NPC initiative, subject changes, transitions in player speech, interruptions, and NPCs who repeat information.]

We’ve looked at the player asking the NPC questions, but that’s only part of the story: we’d also like the NPC to be able to ask the protagonist questions and remember the answers; pester the protagonist for an answer if one is not given; and refuse to move to new topics.

The basic set-up is straightforward: we give the NPC a quip posing a question. We represent the answer with quips that directly follow the question quip, which means that at most one of them can be used and that they will only be understood if the player hasn’t talked about something else instead.

The first thing we need to decide is whether the player will be allowed to change the subject without answering, or whether we want him to be forced to give one of the available responses before moving on to other topics.

Continue reading “Modeling conversation flow: NPC questions”