The Stone Quarry
I’ve been thinking a bit about the future of IF lately. The IF is mired in a perpetual adolescence, awkward and gangly, depredated by clique-gangs which relentlessly attack even the raising of issues, much moreso real criticism. This thin-skinned xenophobic intolerance has the illusion of preserving the status quo, even as it catalyzes change.
The systems and tools available today are largely the contribution of a few people, who closed the door behind them through social leverage. That is, once an Inform or TADS is developed, it remains a monolithic island, never branching or mutating (Platypus is the sole exception). Consider how barren the IF world is compared to the multiplicity of Linux distros or web CMS systems. Why is this?
The tools that generate IF have become confused with the art generated using them. The language of choice and the tools that support it are viewed as foundational and protected so jealously that they cannot be modified except with great dudgeon. Whatever an Old One develops is birthed in teflon, and jealously barricaded by other Old Ones to forbid modification or improvement except by kin. In short, intellectual incest rules the day; contributions are ignored, and suggestions are poo-pooed.
Now the community idolizes the tools only rarely, but fashions towers of idolatry to the tool-makers and their idosyncratic worldviews, often. The communal landscape is just one angry tower of deformed kobolds yelling across the darkling plain at another tower of differently-misshapen beasts. And for those who bow to none, certain death rains down from every parapet. The results are predictable for such a poisonous clime — a slow but steady caravan of people departing, with remaining congratulating themselves on surviving, hurling down silly threats and derision on the fleeing, like the French in Monty Python’s Quest For the Holy Grail. Yet their schoolyard machismo and fixation over minor issues can be chilling in its tiny-mindedness, and reminds me distantly of the dead-eye stares of underage gang members. Absent is any concern over what causes people to leave, and introspection is rare. Puerile self-justification rules the day.
Yet, I propound no hopeless manifesto. I have a galvanizing image: the penultimate pages of David Macaulay’s book, Castle, that show a ruined and disassembled castle underneath a stormy sky. The book details the construction of a castle and all of the challenges therein. The bustling town that had flourished in its shadow soon came to dominate it, and eventually saw the castle as nothing but a good source of building blocks. Let me emphasize this — the town used the castle as a stone quarry.
The ossified systems of IF, both social and technological, will be used as a stone quarry by the next wave of developers. In fact, this has already begun, with a majority of the discussion about contests occurring away from RGIF and RAIF. “Blog flight” is real, with many examples (including this blog) as testaments. With a thousand thousand clattering keyboards absent of the social pressures transmitted through newsgroups, the social power wielded by the Old Ones attenuates, stone by stone. The attack on the towers has begun quietly and unnamed, but it has begun.
The bloom is threatening to the old, dour keepers of the status quo, but in the words of Sinai Beach, “The world is ours to take, so let us take it.”
The Mortification of Conversation
If you can design you game without conversation, do it. Nothing has caused me more grief than designing a realistic method of conversation. It’s not really the concepts that I’ve had to wrestle with, but rather the implementation. It’s been one of those bad days extended over several months. You know those days, that after you’ve broken your arm, been dumped, lost your keys, and got in a wreck, it finally looks like it’s stopped raining — and then you get hit by lightning.
I’m using the ORLibrary, and it’s pretty darn amazing for what it lets you do. Conversation pools, related topics, NPCs that can talk on their own — heady stuff. I’ve spent a long while learning how to speak its language and I’ve made it to the advanced tourist level, where I’m going into restaurants outside of the major cities and ordering local cuisine.
Anyhow, I thought I’d share a few code samples to show you what a few good topics look like if you’re using the various NPC conversational modules and Inform 6.
class topic_c class ORKnowledgeWeb;
!-- For talking to James topics
topic_c pctopics_c
with
KnownBy manexp,
context cbman;
!-- James' topics talking to player
topic_c cbtopics
with
KnownBy cbman,
context manexp;
What we’ve done up above is create topic pools for all the topics the player will use to talk to James, and for all the topics that James will use to talk to the player (James is cbman; the player is manexp). This is a good thing, because if you ever need to forbid a character from talking about a topic, you can simply move it out of that character’s pool. On a related note, say that you have a topic that needs to be discussed by an NPC, but not until certain other things happen first. You keep this topic in some other location and move it into the NPC’s pool at that time.
Here’s how individual topics that the player can talk about look:
topic_c names_c "names" cbtopics
with
name 'name' 'his' 'himself' 'man',
query "~Who are you?~ you ask.",
topicinformation [;
!-- Prevents PC from talking about topic he just asked about.
if ((action == ##AskTopic) && (manexp.prevact == action))
move who_p to hldclz;
print "He looks you up and down and extends a hand.
~The name is James. Yours?~";
],
initiatable false,
RelatedTopics nam_p;
topic_c who_p "who" pctopics_c
with
name 'who',
topicinformation "~Who are you?~ you ask.",
RelatedTopics names_c;
If that looks complex, don’t worry. It is. 
The way conversation works in the ORLibrary is that you can either Tell an NPC <topic>, or you can Ask an NPC <topic>. I’ve rejiggered it so that the Talk command tells the NPC a topic that the PC currently knows. This saves the player from having to think, “What do I say now?” However, that still leaves open Ask. Hence, the complexity.
First, note the multiplicity of names for the names_c topic, known by the NPC James. Having many names for a topic is critical for the asking to work well. In this example, “Ask man about his name”, “Ask man about himself” and “Ask man about man” all cause this topic to be chosen. Once this topic is chosen, its query (what the PC actually says to the NPC) is printed.
The topicinformation is the response of the NPC, the main text that you want to display. Like any other property, it can be a text string or a routine. Here, I needed to make it a routine to handle the fact that the player could get to this topic through two ways: Talking or Asking. That is to say, the player could type:
Ask man about his name
Talk to man
And this topic could display either way. The first way directly calls this topic; the second finds a topic that the PC currently knows (which could very well be who_p, and that in turn causes the NPC to respond with names_c).
I needed to make sure that if the player asks the man his name, that this topic doesn’t hang around for the player to stumble across through ordinary Talking interaction. Thus, the comparison line:
if ((action == ##AskTopic) && (manexp.prevact == action)) move who_p to hldclz;
If the PC is asking the NPC this question, then the who_p topic must be moved out of the PC’s topic pool. (Otherwise, you have the embarrassing situation where the PC asks a direct question and gets the NPC’s response, and then the PC can Talk to the NPC and the same topic displays.) Hldclz is a generic hidden room with no entrances and no exits that I’ve used to store objects no longer used by the game.
Lastly, the topic’s print statement fires no matter how the topic was reached.
Of course, this is just the beginning. Sometimes you’ll need a topic to change based on what the player has done or said previously. Say if the player has broken his arm climbing a tree, you’d want to change the response that an NPC says about climbing the tree for a better view. If you brain hasn’t exploded yet, hang around. I’ll put up a more involved example eventually that will definitely cause cranial detonation.
Songs in IF
There is a part of me that wants to fill a game with all kinds of secret little nooks and crannies, each stuffed with inside jokes and secret references that add to the atmosphere of a game. Doing this with music is a bad idea, though, because musical references (unless they are to something lasting such as Beethoven) lose their relevance quickly.
Let’s say that I use popular band A’s song. Given that most IF games take a while to complete, the band may have broken up by the time the game is released! Or take the long-range view. What if the band remains together for twenty years, but their music changes over time? People familiar with the band’s late period may have a wholly different impression than those who gave up on them after their fifth album. Additionally, I’d be banking on the assumption that everyone who plays the game — or enough people who play the game — will remember or even know the band or song. If you favor obscure music (as I do), the odds are violently against this. If you favor mainstream acts, the chances are still slim.
Think what Zork I would be like if Dave Lebling referenced bands popular in the early 80′s. Some people would love it; others would hate it; but the fact remains is that it would be both out of place and it would date the game horribly. So unless you’re aiming to craft a period piece, referencing music isn’t the way to go.
Now I’m not arguing against characterization. Your game could feature NPC named Ed Flattery, a retired steelworker, who owns every single record that George Thorogood and the Destroyers ever made. That works; however, quoting George Thorogood’s lyrics at the beginning of the game doesn’t. Neither does scattering references to bands you enjoyed growing up throughout the game add to the atmosphere. The latter functions as red herrings which fewer and fewer people will get as the years march on, and serves more as artistic ego than fidelity to the game’s vision.
I need to remind myself of this when creating games. In fact, just writing this has made me realize that a few objects in Seasons really should change.
A Rather Bloodless Divorce
This morning, I quit the IF Workshop. It’s my policy to just say my piece and move on, but late last night I read one of the threads that had gone on for quite a while. Turns out that the workshop admin was flaying the skin off some guy’s game because the game wasn’t morally ambiguous. I blinked and protested. As you might expect, the cat-o-nine-tails met my back next. Well, I’ve got enough self-esteem to not stand for that kind of treatment. I also knew that because my games tend towards the moral, that a similar review was awaiting my game. In two words: no thanks.
I’m still in love with concept of a workshop, though. I might even do one myself some day.
Motivations of a Workshop
One thing that I find increasingly important as a solo creator is motivation. Lately it’s all been of the self-motivation variety: time-tracking and date-setting. I’ve only begun to crack open the door on that subject, but so far that seems to be working. Now I track how much time I spend on the game every day and my target date of summer is still in sight.
However, being in a workshop brings a different sort of motivation. It’s more of an immediate, clarifying, focusing motivation that drives you to make sure that the puzzles work. After all, you do want the game to be at some level, playable. When it’s just you poring over the problems for the 22nd Wednesday, you tend to lose sight of how players experience the game. They won’t appreciate all the technical breakthroughs that finally pass your obscure tests, but they will be spun into quite a tizzy if the first puzzle is not solvable. It’s a kind of linear focusing, which is very useful.
I don’t know how my experiences with this will turn out, but I think it’s a good thing just to get together people who are interested in creating this kind of art/game and to allow us to spur each other on towards good works, after a fashion. The same sort of thing works in the real world when it comes to artist workshops, retreats, and so forth. It’s kind of surprising that it’s taken this long for us to try it in the IF world. But I’m getting the feeling that it would be a good thing to do yearly, if not more often than that. Think of how encouraging it might be for new writers, for instance.
There’s a whole nurturing aspect of the artist/programmer that I feel is lacking in IF, and this is a good start. We need to do more of this kind of thing.
On My Way to the IF Workshop
It never fails. As soon as I confidently declare some percentage done to anyone but myself, something awful goes wrong. Here I am, feeling that all’s well in my corner of the world and I go on bragging to Jim Aiken (IF Workshop leader) that I’m X% done and have conquered the game’s technical problems. Then BAM! The conversation system goes belly-up, and that’s the first puzzle.
Actually, it had gone belly-up some time before, but I just assumed that it would work if I made it more like the conversation system in Medusa (y’know, with queries). Wrong. It turns out that the only way I can make it work is if every topic is a Tell topic, and that no queries are used at all. That was my original design, but it felt hollow. I guess I have to go with it now and see if I can stomp out the bugs swirling around it by Saturday at the latest.
I’m going to tell people to focus on Spring, I think. It’s not done, but it has more solvable puzzles than any other season. I still think I’m right around the half-way mark, but most of my work has been technical and not plot or characterization, yet. That still fits with what I’m going to ask for help on, because I’d like for Seasons to turn out with a stronger narrative than Building.
And I lied. I now have 214 rooms. *chagrined stare*.
