Writer wanted for a "Conversational Storytelling" project

Dear fellow enthusiasts,

I have to admit that I find Interactive Fiction both remarkably intriguing and fatally disconcerting at the same time. I’ve enjoyed reading all sorts of books and articles that have been written on the subject, but I hardly ever play (or read, or whatever one is said to do with) the stuff. And why is this? I think because, most of the time, I can never quite figure out what I’m supposed to be picturing. And I don’t mean “white houses” or “brass lanterns”; I can picture those just fine. It’s when I say things like “GO NORTH” and “EXAMINE THE SACK”. To whom am I speaking? Who is this remarkably submissive minion who has nothing better to do than obey my commands?

Now I have to admit that the whole thing works better (at least for me) when I’m commanding, say, robots on a far-off planet. And there was a time many years ago when I think I caught a glimpse of what Interactive Fiction just might grow up to be (though, as far as I know, it hasn’t): I was playing a game where I was communicating with an astronaut in a broken spaceship over an intermittent radio. Ah! I thought. This is more like it. Two people talking, much like they might in a similar real-life situation. The radio was a good idea, too: commands outside the scope of the game were simply rejected on the ground that there was too much static.

Conversational Storytelling is the name I give to this particular subset of Interactive Fiction: works that attempt to tell a story simply by simulating a conversation between two people. (Conversational Storytelling can, of course, include any number of characters – but they will all be seen and interacted with through the main character.)

Having thus reached the (personal) conclusion that the Conversational Storytelling paradigm just might be the most plausible form of Interactive Fiction (not to mention the most engrossing, since it focuses on human-to-human relationships), I decided to try my hand at authoring such a work. So I took a look at Inform, which by any standard is a very remarkable product; unfortunately, it was much too complicated for a minimalist like myself. Then I looked at TADS, but I was quite certain that I didn’t want to be thinking like a C-language programmer while I was trying to write a story. After looking at a few others, I concluded that they were all approaching the problem from a distinctly different perspective: they all appeared to be “world building tools” rather than “human interaction tools”. Their focus seemed to be the description of real-world places and things (a kitchen with a drawer with an empty roll of tape in it) rather than people (like a child who has been abducted or a woman caught in a bad marriage). It thus seemed clear that I’d have to write my own development system.

So I got out my favorite programming tool and wrote a little interpreter that could compile and run a story composed in Conversational Storytelling format. Input to the interpreter looks like this:

[code]TITLE
< GUILT BY ASSOCIATION
< An Experiment in Conversational Storytelling

PROLOG
< Text message:
< Help me, please!
< I want to go home.

SCENE

REQUIRED EXCHANGE

Who are you?
What is your name?
< Samantha. My friends call me Sam.
< I already told you. I’m Sam.
< Sam. Don’t ask again.

REQUIRED EXCHANGE

What’s the problem?
What’s wrong?
Help you with what?
Help you how?
< They kidnapped me.
< I want to go home.

REQUIRED EXCHANGE

Look around.
What can you see?
Are there any weapons nearby?
< There’s a dresser here with a gun in the drawer.
< I’ve already told you what’s here.

OPTIONAL EXCHANGE

Why can’t you go home?
< Because I’ve been kidnapped!

OPTIONAL EXCHANGE

How old are you?
< I’m 14. Well, I will be next month.
< Why do you keep asking? Are you some kind of perv?

SCENE

OPTIONAL EXCHANGE

Take the gun.
Take the gun out of the drawer.
Take the gun out of the dresser.
< Okay, I got it. Big sucker.
< I told you, I’ve got it.

REQUIRED EXCHANGE

Shoot the kidnappers with the gun.
Shoot the kidnappers.
< Okay. That worked.

EPILOG
< Free at last. Thanks.
< I can see now they had me in a white house.
< There’s a mailbox here…
[/code]

This is the kind of thing you’ll be writing if you choose to partner up on this project.

As you can see, a story in this format consists of a TITLE, a PROLOG, one or more SCENES (with EXCHANGES that are either required or optional), and an EPILOG at the end. The left arrows (<) precede text that is to be output by the interpreter; the right arrows (>) are used to indicate possible user inputs.

The TITLE, PROLOG, and EPILOG sections contain only output statements; the EXCHANGEs contain both possible user inputs and main character responses. User inputs (preceded by “>”) define the various ways a particular question or command might be expressed by the user; the responses (indicated by “<”) are displayed sequentially, one at a time, as user inputs are entered and processed (and possibly re-entered and re-processed). The final response in each EXCHANGE repeats as necessary.

The interpreter begins by displaying both the TITLE and the PROLOG. The CURRENT SCENE is set to the first SCENE, and the user is prompted for INPUT. If the user’s INPUT is found in the CURRENT SCENE’S EXCHANGES, the appropriate OUTPUT response is displayed. If it is not found, the interpreter mumbles that it doesn’t understand and the user (presumably) tries something else. The story advances to the next SCENE when all the required EXCHANGES in the CURRENT SCENE have been exercised (though not necessarily exhausted).

And that’s the gist of it. Remarkably simple and concise, if I do say so myself. The question you’re probably asking yourself is whether a convincing and engrossing story can actually be written with such a trivial tool. I think so (and I’ve given it quite a bit of thought). But two heads, as we all know, are better than one, and frankly I don’t find the writing as much fun as the programming. Which is why I need your help. I’d also like to know if there’s any real interest in this kind of thing before I spend the time and effort polishing up my as-yet not-ready-for-prime-time development system.

Please write here on the forum if you have thoughts on the matter; responding will help me clarify the concept to myself as well as others.

Please write to me directly (gerry.rzeppa@pobox.com) if you’re seriously interested in the job. The story we create together will be entered in the 2015 Interactive Fiction Competition. The development system will be open source and will be offered free to all (with donations being gladly accepted). I’m offering $100 (US) upon successful completion of our task (even if we lose the Competition), plus a 50% interest in any profits from donations received.

Thanks!

UPDATE UPDATE UPDATE

[size=150]The Conversational Storyteller prototype is now ready for writers![/size]

It includes a very tiny sample story in the form we’ve been discussing here, plus the code needed to run it on almost any kind of device with a recent browser. (It’s been tested on the latest versions of Chrome, Safari, IE, and Firefox on a PC, a Mac, an iPhone, an iPad, and an Android tablet.) Don’t expect much of the story; it’s only there so you can see where the pieces go in the file. You can get it here:

filedropper.com/cst2goodone

I had hoped to simply attach it to this post, but apparently files with a “.html” extension are not allowed.

THE TECHNICAL DETAILS:

To write your own Conversational Story:

  1. Open the file in your favorite text editor or word processor and edit/extend the various sections (TITLE, PROLOG, SCENES, REQUIRED and OPTIONAL EXCHANGES, EPILOG, GENERAL RESPONSES, INVISIBLES, and SYNONYMS) as necessary to say what you want to say in your story. But don’t mess with that one ugly line of HTML at the very top.

  2. Save the file; you can give it any file name you like as long as it has a “.html” on the end. (Some systems may object to spaces in the name.) If you’re using a word processor, make sure you save it as text only.

  3. Open your browser and enter the full path name of your file in the address bar; hit ENTER or click GO (or whatever your browser’s equivalent happens to be). Now you’re running; play away.

Repeat Steps 1-3 as required. For convenience, you can leave both your editor and browser open in different windows as you work; just make sure you save in the editor before you refresh in the browser each time around.

When your story is finished, you can make it accessible to others by emailing your file to them, copying it to a thumb drive, hosting it on a server with a link, etc.

FOR THE SERIOUSLY SERIOUS:

Here’s the process of writing a Conversational Story as I see it, in 7 steps:

  1. Dream up a problem (say, kidnapping), with an emotion-evoking protagonist (innocent young girl), a reprobate and hateful antagonist (big hairy goon), and an ambivalent someone caught in the middle (the goon’s abused but submissive ladyfriend). Make sure the problem has an obvious solution for the protagonist (freeing the innocent young girl) with not-so-obvious side effects for the other characters (see below).

  2. Dream up a believable communication link (a cellphone, smashed by the goon, but with the text-messaging capability still intact).

  3. Dream up a setting (say, an attic) where the protagonist can (a) communicate with the user “offstage” and more-or-less “sotto voce”, while (b) maintaining contact with the other characters. The former is important because it helps the user bond with the protagonist; the latter gives the story breadth.

  4. Outline the obvious solution with a series of exchanges: the most obvious questions/commands with appropriately leading answers/responses (ie, responses with keywords that prompt the next question. These keywords are the subliminal clues that we persistently feed the user to keep him on – or return him to – the right track. They’re in italics, below.)

Who are you? Samantha. Help me.
Help you with what? I’ve been kidnapped.
Who kidnapped you? A big hairy goon and his ladyfriend.
Tell me about the goon. He smells. But his ladyfriend doesn’t seem that bad.
Tell me about the lady. He hits her, but she’s nice to me. Help me. This place is awful.
Where are you? I’m in an attic.
Can you get out? Maybe. There’s a hole in the floor.
What can you see through the hole? There’s a bed under the hole. The lady is sleeping in it.
Where’s the goon? He went out. Said he’d be back in an hour. Help me.
Can you fit through the hole? Yes. But I’d wake the lady. Help me. This place is awful.
What’s in the attic? Nothing but me and this concrete block I’m sitting on.

[At this point the user sees the solution but has to convince the protagonist to do it]
[The protagonist goes through the five Kübler-Ross stages of accepting an unwelcome reality]

Drop the concrete block on the lady. No! She’s been nice to me. [denial stage]
But she helped kidnap you; drop the block. You’re sick. [anger stage]
It’s called guilt by association, kid; drop the block. Maybe later. [bargaining stage]
The goon is coming back; drop the block. I’ll never get out of here. [depression stage]
No time to waste, kid; drop the block. Okay, I guess you’re right. [acceptance stage]
Drop the block.

[This is the climax of the story; the user’s job is done; action, as described by the protagonist, follows]

I dropped it. It missed.
Now the lady’s got a gun. She’s going to kill me!
I can hear the goon coming back. I’m in big trouble now.
Wait! She’s pointing the gun at the goon.
BLAM!

  1. The questions/commands above constitute the required exchanges of the story; label them as such. Then insert a scene break wherever a subsequent question requires information from a preceding exchange.

  2. Add in the optional exchanges. Include who, what, when, where, why, and how questions for every noun in the primary question/command set above. Also include any reasonable action commands for each of those nouns. Make sure (a) the responses do not introduce new nouns; and (b) the responses include the keywords from the primary question/command set.

  3. Beta test with at least three people of differing personality types. Focus on tightening up the primary question/command set first; make sure the obvious path is actually obvious. Then add in the color provided by optional exchanges. Collect synonym definitions and unusual expressions throughout and provide for them in the source.

Questions and comments can be posted here or sent to me directly: gerry.rzeppa@pobox.com. I’m still looking for a writer who wants to work seriously with me on a piece for entry in the 2015 Interactive Fiction Competition; we’ll improve the interpreter and gather the data we need for The Art of Conversational Storytelling manual (an extended version of the above) as we go along.

FYI, you can also interpret it mentally as “Now I shall… EXAMINE THE SACK.” “I’ll… GO NORTH”. “What do you want to do? > TAKE INVENTORY”.

That’s Fail-Safe, and you might wish to remove the parenthesised spoiler. :wink:

Finally, there are gazillion ways of inputting the smallest thing, and if you do away with the usual verb-noun, you’re left with unlimited possibilities, and the player faced with unlimited choices. And if you do present the choices, it becomes CYOA. This is the first remark anyone says in these projects so I thought I’d get it out of the way at once. :wink:

I’m pretty sure you can imitate this with inform.

You might look at versu.com/ – it sounds like what you’re reaching towards.

Yes, I think that’s better. Thanks. But the fact that I have to mentally preface all my commands still, I think, reveals the unnatural quality of the paradigm.

Right! Spoiler removed. I should have thought of that.

Here I must respectfully disagree. Some years ago my elder son and I wrote a compiler for a “Plain English” programming language in the interest of answering three questions:

  1. Is it easier to program when you don’t have to translate your natural language thoughts into an alternate syntax? and

  2. Can English be parsed in a relatively “sloppy” manner and still provide a sufficiently precise and unambiguous environment for programming? and

  3. Can complex low-level programs (like compilers) be conveniently and efficiently written in high-level languages (like English)?

Our direct and extensive experience has demonstrated (at least to us!) that the answer to each of these three questions is an emphatic “Yes!” In fact, I used that compiler to develop the Conversational Storytelling interpreter. (If you’re interested, you can get our Plain English development system here: osmosian.com/cal-3040.zip . Just download and unzip; no installation necessary. Start with the “instructions.pdf” in the “documentation” directory and you’ll quickly see what we’re talking about. There’s a brief summary of our “sloppy” parsing technique on page 11.)

But back to your question. What we’ve found is that while it’s true that “there are gazillion ways of inputting the smallest thing”, the practical fact is that most of those ways don’t typically occur in normal conversation. And when you combine that fact with a “sloppy” parser that eliminates the extraneous and allows for numerous automatic substitutions and rearrangements, you find that the set of statements that must be anticipated by a story author (or programming language compiler writer, for that matter) shrinks considerably. I realize that the sample code in my original post gives the wrong impression in this area; but I wanted to focus on the overall structure of the thing in that post.

Thanks, Peter, for the input.

No doubt. The problem (for me) was the learning curve – Inform (marvelous product that it is) is serious overkill for this kind of thing.

Thanks for the link. Versu appears to be more of a third-person simulator like “The Sims” than the strictly-conversational terse-input-and-response first-person-perspective paradigm I’m proposing here.

You make some good theoretical points. I don’t know how they would stand up to practice, which is where I believe you’ll find problems as players who wish to deviate from the “obvious choices” will almost surely get frustrated that a) what they wanted to do wasn’t foreseen by the programmer, or b) what they wanted to do was foreseen by the programmer but they phrased it differently so it didn’t work, so they will not deviate, and so the work becomes a convoluted CYOA.

But feel free to prove me wrong. :slight_smile: I’m only naysaying in the sense that I don’t think it’ll really work - but I do want my points to weigh in your choices so you can evade the worst pitfalls of what you’re trying to do, making it better, making it work.

Your point (a), I think, is common to all interactive fiction. The best answer I have for it is extensive beta testing. The advantage we have is that our “exchanges” are relatively independent of each other and any number of additional exchanges can be easily added.

Regarding your point (b), one of the things we consistently find when teaching people to program in our Plain English programming language is that people quickly (and more-or-less subconsciously) adapt to expected modes of communication. As in real life, for example, when you realize that you’re conversing with someone who is (or is not) technically savvy, you immediately restrict (or expand) your vocabulary to accommodate them. I suspect the same thing will happen with our works of Conversational Fiction: the user will subconsciously adapt to modes of expression that were anticipated by the author. (Unless, of course, the user is simply obnoxious and is actively trying to break the thing; but those users are not part of our intended audience.) Our “sloppy” parsing with automatic re-arrangements and substitutions, as mentioned before, will also help significantly in this area.

Thanks again for the input.

Another game I can think of in this style is “Suspended” by Infocom. Any others?

“Suspended” is what I had in mind when I mentioned robots in the original post.

But I think the best and most common example of the genre I’m picturing is simply people texting each other on their phones: short query, short response, repeat. (A very popular and apparently highly addictive activity.) To help along these lines, our input parser will automatically expand common “text message abbreviatons” to make them compatible with the author’s story definition. Or perhaps vice-versa LOL.

A well-written work of Conversational Storytelling should, in fact, be able to score respectably on a “Turing test” (en.wikipedia.org/wiki/Turing_test), at least within the confined limits of the story’s setting. In other words, a person interacting with a work of Conversational Storytelling on his phone – while intermittently texting various friends – should be quickly lulled into thinking there are real people on the other end of all the conversations.

Sounds interesting. Seems like you really could do something with this.

I think that the thing you need to figure out is: how are you structuring input? How are you limiting it? How do you reveal that structure and those limits to the player?

Most games have quite limited inputs: a small number of buttons that do stuff when you press them. The options you are given show you the scope of things you are allowed to do. Natural English, on the other hand, offers the possibility of a near-infinite variety of inputs. Even in quite constrained situations, different English-speakers can and will use very different language to express the same idea - and they won’t have the same idea, because the possibilities afforded are so broad.

In other words, this:

substantially underestimates the scale of the problem you’re dealing with here.

Conventional IF commands are expressed in a very limited, idiomatic, regular subset of natural English for a good reason: it gives both player and author a structure to work within. Which is what you’re getting at here:

That’s how interfaces are meant to work. But -as IF authors have learned through painful experience - they can only do this if the author employs and reveals a consistent, readily-learned set of rules for how input is going to be treated. ‘I’m trying to match anything that a person might possibly want to type’ is not going to lead to a consistent approach, or produce a readily-learned set of rules. It’s going to lead to mutual guesswork, read-the-author’s-mind problems of a scale far larger than you’re likely to encounter in conventional parsers.

(Possibly the closest thing to what you’re aiming to do is Facade. That was the work of several years, even without trying to turn its behaviour into a generalised system - and the result is decidedly mixed.)

This doesn’t necessarily mean that you ought to revert to a standard parser; that evidently isn’t suited to your preferences. But you should dedicate some serious thought on how to impose structure/limitation on your input, in a way that helps direct the player.

I mean, don’t take my word for it. Do some small-scale testing. Put a smallish example game in front of some flesh-and-blood players. Get transcripts. Then decide what you would need to do to make this work.

Thanks for the input.

Our parser reduces inputs, both those expected by the author and those actually entered by the user, to a minimal normalized or canonical form; this greatly reduces the number of possibilities that need to be anticipated by the author, and greatly expands the number of ways the user can say things. Consider, for example, these sentences:

OMG, hit the troll with the cinder block.
Hit that little bastard with the brick, dude!
Use that filthy concrete block to strike the man.
Bonk the guy on the head with the brick.

Given a bit of context (which our program calls a SCENE) and a knowledge of some context-sensitive synonyms (which we call SUBSTITUTIONS), all of those sentences reduce to the standard (verb/object/indirect object) form:

Hit man brick

I realize it wasn’t clear in my original post, but both the author’s text and the user’s input are reduced in the same way. This benefits the user in obvious ways; but it also benefits the author since he can write things as he naturally thinks of them and doesn’t have to think in “normalized” or “canonical” terms as he’s composing.

We don’t limit inputs in any particular way. We simply reduce them to canonical form and search for a match. But when a match isn’t found, we don’t just say “Huh?” or “I don’t understand.” Instead, we use an approach something like the old ELIZA program (en.wikipedia.org/wiki/ELIZA) to generate a response that combines the user’s input with scene-specific context – thus subtly guiding the user back into the train of thought we want him to follow while simultaneously providing life-like conversational repartee.

The same way such structure and limits are revealed in normal conversation. I mentioned in an earlier post how we all automatically and subconsciously adjust our modes of speech to accommodate our listeners; the same, I think, applies here. If we picture a person who is trying to “break” the game, of course, he’ll be able to do so. But if we picture a person who actually wants to communicate with the story’s main character, I think he’ll find it quite simple and natural to adjust his inputs appropriately.

But not in any given context. When, for example, the story’s main character says, “I’ve been kidnapped”, most of that “near-infinite variety of inputs” would simply be inappropriate. A predictable series of who, what, when, where, why and how questions might be offered as a response, but “We had spaghetti three times at our house last week” doesn’t have to be anticipated. (Our ELIZA-like generator would, however, automatically respond to such a non sequitur with “What do I care about spaghetti? I’ve been kidnapped!”)

See above.

That’s what most people said when we started our Plain English programming language project. Turns out it was easier – way easier – than they thought. Or more accurately, it turns out they were thinking of something else. They were picturing a HAL 9000; but we just wanted to say “Clear the screen to black” instead of something like “graphics.dll>clrScr($000000,true);”.

The “consistent, readily-learned set of rules” we’re proposing has just one member: Say what you would typically say to a person like this in a situation like that – and we’ll drum up a reasonable response.

But we’re not “trying to match anything that a person might possibly want to type”; we’re only concerned with things a person might actually say to a person like this in a situation like that. It’s a smaller set. Much smaller.

I don’t think what I’m proposing is very much like Facade at all. What I’m proposing is text only, with very brief entries and responses. Like text messaging. Like a phone conversation between strangers or casual acquaintances who are just getting to know one another better. No pictures, no long histories, no monologues.

I’m thinking the sample code in my original post has given you the wrong impression. And that, possibly, you’re imagining a system that is significantly more robust than it needs to be for our audience.

That’s exactly the plan. And it’s been carried out, to a small degree, already. With encouraging results. I’m posting here because I’m looking for someone else to write the sample stories so I can see how the system works not only for users, but for authors as well. I don’t want this to simply be entertaining for consumers of Conversational Storytelling; I want it to be delightful for the authors as well.

Thanks again for the input.

I was starting to think you had a leg to stand on, but this really scared me. This is a parser that pretends to be more intelligent than it is. Don’t go that way, we’ve seen it happen lots of times before. It can lead to huge messes.

You think. Any given person could have several responses to one particular situation. Different people will view it differently. Your approach seems to be so open it seems impossible - you can’t possibly capture all of them. And if you decide to strip some of them out on the basis of “it’s not what someone would do in this situation”, then a) how would YOU know, and b) then what’s the point in pretending to have this big freedom?

But strip Facade of the multimedia and you have the same basic concept - an attempt at that sort of freedom.

There’s no way that I can say this without it sounding wrong so I’ll just say it: I’m starting to think your audience is you and the people around you who share the same mind-set. In which case, everything you’re doing is just fine. But it won’t do for a wider audience.

Final thoughts: “AISLE” is an example of how mind-boggingly inifinte the possibilities are. But it’d be hard pressed to actually tell a story that way. And by sticking to the existing paradigms, it has been able to taste of infinity, instead of being stifled by a parser that pretends to know more than it does. If you’re communicating with the game, there can be no space for misunderstandings. The reason the parser as we know if has survived, and survived past examples of what you’re proposing right now (it’s by no means new), is that it works and it’s solid - the “robust” thing you seem not to care too much about.

I’m sorry to hear you say that. But trust me, we know what we’re doing in this area. Using similar “sloppy” parsing techniques we were able to develop our Plain English programming language and development system (including desktop, file manager, editor, dumper, compiler, and page-layout facility for documentation) – and the results of that kind of “sloppy” parsing were precise and unambiguous enough for even a literal and unforgiving machine to comprehend.

Okay, let’s do the math. Say a typical story in our style has 100 scenes and each scene affords the user, say, 10 different kinds of responses: that’s 1000 exchanges that need to be defined. Now a typical exchange would consist of about 6 lines: 3 defining the input (assuming there are, say, 3 different ways for the user to specify each response, plus all of the “automatically parsed” variations, which we don’t have to worry about), and 3 defining the output variations. So an author will have to write about 6,000 lines of Conversational Storytelling code for a typical tale. My experience has been that I can write this kind of code, easily, at a rate of about one line per minute, which means I could churn out a nice little story with about 100 hours of effort. Sounds reasonable to me.

(a) How would I know what someone would do in a given situation? First, I would simply guess, and (I suspect) guess reasonably well, having been not only a human, but a close observer of the human race, for over 60 years. But secondly, before I released a story, I would have a dozen or so beta-testers (of distinctly different personality types) interact with the thing and I’d study the transcripts for stuff I’d missed; then I’d add those in.

(b) What’s the point in pretending to have this big freedom? If you mean “freedom for the user to say whatever ridiculous thing he might wish to say”, you haven’t been following the thread closely enough; that’s not at all what I’m proposing. But if you mean, as I do, “freedom to say what you might actually say to a character like the main character, in a situation like the one presented, in the way you’d normally say it,” then the point is to make the game both life-like and easy to interact with.

I’m not quite sure that’s true. The freedom to communicate on, say, a video conference call (with both audio and video and text, which is very broad) is not the same freedom that one has communicating on, say, on a forum like this (which is more restrictive), which is not the same as the (rather limited) freedom afforded by text messaging. Our stories are in the “text messaging” class.

I have no idea who the audience will ultimately be. Perhaps third-graders, just beginning to learn about programming. Or teens (not only because they can interact with these stories using nothing but their thumbs on their phones and pads, but because of the teen-specific subject matter of the stories that authors compose). Or maybe it will be bored adults who simply want to unwind with something other than Sudoku.

Don’t have enough experience with AISLE to comment. Sorry.

See above regarding our Plain English development system. “Sloppy” parsing doesn’t have to lead to misunderstandings.

I would argue that “the parser as we know it” has survived primarily as a curiosity; in fact, after Myst showed the world that there are easier ways to communicate the same kinds of thoughts and commands, the “parser as we know it” rapidly fell into near obscurity.

Sometimes a picture is worth a thousand words; sometimes not. The trick is being able to spot which application is which – and to then design your interface accordingly. We’re intentionally restricting Conversational Storytelling in ways that make a purely textual interface both convenient and engaging. And it seems to us that this just might be the one little niche where interactive fiction may actually have a chance at reaching a really broad, 21st-century audience; where it just might have a real advantage over other means of expression.

It’ll be interesting to see what you come up with. Like other people who’ve chimed in, I have my doubts, but if you’ve got a magic bullet, that would be pretty spiffy.

Thanks. But it’s starting to look like magic bullets are easier to find than interactive fiction writers! (Over 250 views on this thread so far and not a single email nibble from a writer – or a wannabe writer – interested in partnering up.) C’mon, folks! This is interesting stuff. Challenging. Creative. Fun. And who knows? It might even be “the next big thing”. A 21st-century Infocom. Might open up a whole new avenue for authors who want to tap the mobile app market; authors who have great ideas but who don’t have the time or inclination to learn to code in Objective-C.

“Too often, opportunity knocks, but by the time you take off the chain, push back the bolt, unhook the two locks and shut off the burglar alarm, it’s too late.” – Rita Coolidge

I think you need to produce a proof of concept before you can get people excited enough to sign up. It’s hard enough to get collaborators for more traditional projects, let alone something that comes out of the blue and claims to be a solution to a problem that the community (and computer science in general) has tried to solve for decades.

I mean, I agree that it would be awesome if the system could do everything you say it can do. Totally awesome. But seeing is believing: maybe you could expand the example in the first post to a working demo so people could see what the system is capable of. You’re promising things that sound almost magical and it still sounds like you’re underestimating the scope of the problem (“each scene affords the user, say, 10 different kinds of responses”…) so surely you understand that without something concrete it’s very hard to make a blind leap and commit to beautiful ideas alone.

You focus a lot on what the tools will do but not enough, I think, on how they work from the perspective of a new author. Would I have to install anything for this project? Do I need a good text editor for it? Etc., etc. These questions may sound strange to a seasoned programmer such as yourself, but when the most popular IF development systems generally come with their own IDE (and some of them are usable in a web browser), it’s generally a good idea to list the specifications and requirements of your new system upfront. Since it looks like you’ll be handling all the heavy lifting for this first project it probably doesn’t matter as much, but try to keep it in mind for the future.

Anyway, if you’re desperate for writers, you could cast a wider net and ask around places like the TIGSource forums, the Lemma Soft boards, etc. Basically any place that conceivably might be interested in IF.