Category: craft

Current playing: Infidel

infidelI’ve tried to play this a couple of times before and never gotten anywhere with it, in at least one case because I didn’t realize I needed the feelies. This time I’ve actually gotten inside the pyramid.

I usually find Infocom a curious mix these days: I loved them at the time but now I have ingrained habits that make me impatient. Infidel doesn’t understand “X” for examine, or accept UNDO at all; needs to be manually set to a fixed-width font because it doesn’t have separate parameters for font types; and features food, thirst, and inventory management to a degree I’ve never liked. (Admittedly, given the setting, I find it more convincing than in many another game that the protagonist really might die from not having water frequently enough. But it still makes for a frustrating experience.) Oh, and did I mention the inadequately-clued sudden deaths? And the object you can ATTACK over and over for many snarky messages, when the solution is to BREAK it?

Still, I have to say that (even though I’m only a little way into it), I really like the hieroglyph puzzles: the player encounters ASCII art messages on the wall, and has in the feelies a glossary of a few of the symbols, but must construct an understanding of the rest from context and comparison.

This is (obviously) a very old technique and yet still sadly uncommon. I very much want to see more of systematic puzzles in IF — ones that rely on some consistent physical or magical principle, or build up some knowledge base, or have a nifty gadget that can be used in a variety of clever ways. There are already some great examples: the magic grammar in Suveh Nux, the orgy of physical destruction/elimination puzzles in Conan Kill Everything and To Hell in a Hamper, the superpowers in Earth and Sky and Heroine’s Mantle, the alliteration puzzles in Ad Verbum, the linguistic recognition puzzles in Letters From Home, the combat puzzles in Gun Mute and its ilk, and the diverse uses of the main device in Adventurer’s Consumer Guide. The learnable spells in Enchanter and its sequels sort of qualify, but only sort of, because most of the spells are so specialized and so few of the spells interact; but Balances offers a satisfying twist on this idea. Sam Kabo Ashwell also has a list of “Distinctive Puzzle Style” games based on similar criteria, though it only partly overlaps with mine.

Yet for every one of these, there are distressingly many games with very ordinary puzzles.

Continue reading “Current playing: Infidel”

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.

Exercises in Generated Prose

What follows is an overview of some ways I7 can be used to generate more writerly prose, especially in the context of room descriptions. It refers to several extensions; of these, “Complex Listing” and “Plurality” are bundled with Inform and part of the standard distribution, but “Room Description Control“, “Tailored Room Description“, “Introductions“, “Assorted Text Generation“, and “Automated Drawers” are available from the I7 extensions site.

Continue reading “Exercises in Generated Prose”

Putting together a play-test

Recently read an interesting article by some Microsoft playtesters that suggests playtesting studies using 25-35 participants focusing on a single hour of gameplay, followed up with standardized surveys. The idea is that this could be done repeatedly during the course of a game’s development in order to drive gameplay improvements and then confirm that the changes have had the desired effect. This method contrasts with usability tests (an hour to two-hour interview one-on-one with testers, usually conducted with a group of eight or so) in that it is more statistically reliable though not so in-depth.

This is something I’ve been thinking about a lot lately.

Continue reading “Putting together a play-test”

Alabaster feedback

As Alabaster is in large part an experiment with the underlying conversation system, I would very much welcome feedback about how the system behaves so that I can refine it for future use.

As background: how much the system prompts the player is already an adjustable feature (up to turning off quip prompts entirely, for a standard unprompted ASK/TELL experience). Likewise, it will be possible in the final version of the library, though not demonstrated here, to use a numeric menu to offer the player options.

So what I’m particularly interested in at the moment is how to improve the player experience when the game is using the same library settings as Alabaster. Some things that have come up already:

A common misapprehension seems to be that it’s necessary to retype an entire quip name verbatim, whereas in fact the game parses quip names in the same way that it parses object names: the first few words of the quip, or any unique word, will do. The system does not, perhaps, do a good enough job of teaching new players this fact, especially when the tutorial mode is turned off; so perhaps there should be a mechanism to notice if the player is typing in very long commands and mention (once) that these can be shortened. (Also, perhaps, to point out that the whole ASK INTERLOCUTOR ABOUT structure can be shortened to A.)

I’ve also had a request for tolerance of spare question marks (which some players find themselves typing even after an indirect question such as ASK ABOUT WHETHER SHE IS COLD).

Another point is that Alabaster doesn’t give good feedback when the input is

>SNOW WHITE, [valid quip name here]

In general, I’m not sure I want to encourage players to approach things that way because it encourages them to think there’s actual natural language processing happening — which there isn’t. But there could be better error messages in response.

Anyway, comments are welcome; it would also be useful to have transcripts that demonstrate interaction with the game, since these would provide also some idea of how often commands are failing, and what kinds of commands. If you have one you’d like to send in, I’d appreciate it: emshort@mindspring.com.

In Praise of the Glorious Practice of Beta-Testing

Juhana Leinonen has just announced a new site for IF authors seeking testers and vice versa. It takes a slightly different approach from the IF betatesters’ mailing list, in that you can subscribe to an RSS feed rather than getting email at times of year when you might not be in the mood for testing. There’s also a small selection of articles on the art of testing, and the opportunity to specify what kinds of games you’re willing to test.

I mention this not so much because I have a vested interest in pushing one site or another, but because it’s worth reminding prospective authors as we head into summer and the season of comp-game writing:

Please test your game and credit your testers.

It makes your game better, and it offers your players some kind of promise that you made an effort. Also, please give your testers enough time to work that you will be able to fix what they find — ideally get the game into testing a month or more ahead of the comp deadline. This especially applies if you’ve never written IF before. It takes a lot more testing time than you think.

(My personal plan for the coming competition is not to bother reviewing games that don’t credit any testers, just to spare myself the annoyance of writing the same dull rant ten or fifteen times. I realize this isn’t foolproof and that someone could stuff in the names of a half dozen imaginary friends, but still. Worth a try.)