Yesterday, Chris Crawford put up a post with the following plea:
I’m asking everybody to consider an important post I have made at erasmatazz.com/library/intera…. There’s 25 years of work hanging on this.
He also emailed me the same message directly. So I had a look.
The basic premise is as follows: Chris’ long-running Storytron system, designed to make interactive storyworlds, needs a lot more content in order to show off its hypothesized strengths. In particular, it needs content that feels handcrafted to some degree, to go with the procedural descriptions of characters gossiping, falling in love, and fighting. Or, as Chris puts it,
After many years of trying, I have learned the hard way that the procedurally intense interactions provided by the Storytron technology lack the color that most people expect from traditional storytelling. There’s a repetitive, mechanical feel to those interactions, and while they are dramatically more intense, more significant, they are like the skeleton of the story, the core elements, in need to fleshing out with muscle and skin. That’s the purpose of Encounters. They provide a more data-intense form of interaction that is shallower in dramatic significance, but more colorful.
To build this, he created an encounter editor. The Encounter Editor lets people design encounters that:
- are locked or unlocked by certain prerequisites consisting of other encounters
- start with a description of a meeting with another character
- let the player make a choice in response
- provide several possible reactions for NPCs, including some variable-based probability around which of those reactions they’re most likely to choose
In other words, the encounter bears a strong resemblance to storylets in StoryNexus. The editor looks like this:
It’s a little more constrained than StoryNexus about how prerequisites work — they can only depend on what other encounters the player has run into, not on the whole range of variables in the world state.
Conversely, there’s a more math-y approach to reactions, which are now not a stats-based roll against some threshold, but can instead be based on a blend of multiple character stats. (You could achieve something like this in StoryNexus given that you can write in equations to describe thresholds for story outcomes, but in practice one usually doesn’t; it’s very hard to get players to understand complex requirements in SN, which lowers their sense of agency over the whole situation.)
And of course the math here involves floating point arithmetic rather than integers, because in Crawford’s view floating point is required to express the concept of nuance in interpersonal relationships.
The system also provides some basic name/pronoun replacement, and requires that every encounter have an antagonist. So it’s inherently more relationship-focused than storylets, because it focuses the writer on the variables controlling the interaction with another character, rather than player-v-world state.
The final major point is that all this is designed to plug into a Storytron world, with (I assume? it’s hard to know without playing a sample) other processes mediating the characters’ variable states, and a fuller palette of verbs. Crawford has written elsewhere that a good storyworld requires a hundred or more verbs to work.
Or, as he says:
The ultimate goal of the Encounter Editor is to have lots of people like you writing Encounters that we will include in the final game. There will be no payment of any kind for your services. This entire project is a non-profit community effort in which NOBODY gets paid. We have been getting some money from a Patreon group, but so far it’s not enough to provide a month’s pay for a decent programmer. But hey — we’re starting a revolution here, and we got no room for no stinkin’ capitalists!
With this in mind, Crawford’s prospective writers are instructed to read the enclosed two novels (one in PDF form, the other in Pages and ominously titled “Novel Draft 13”) in order to get up to speed on the background of this story world so that they can begin contributing story elements that will go into a gameplay context that they can’t actually directly experience themselves. As far as I can tell, the names of Crawford’s characters are in fact baked into the tool, so you couldn’t use it to build anything else.
The PDF novel is 230 pages long and begins with the sentence “Once upon a time there was an ordinary nebula.” Considering that it starts with this astronomical grounding, 230 pages is really on the trim side; the novel spends twenty pages on moons, continents, and extinction events before you get characters. It’s not a hook-y read, and in particular it doesn’t perform the key mission it has in this particular context: to get prospective writers excited about writing for this universe. What is there (cool setting? inciting incident? unrevealed mystery?) to get my mind spinning about the narrative possibilities?
If it were me doing this, I think I’d provide either a starter piece of game (as I did with Alabaster), or else something akin to a short RPG manual: something designed to communicate the key setting and story hook, and to lay out the meaning of the core stats.
Curiously, Chris’ manual goes into relatively little detail about how stats are to be understood. There’s a good/bad stat, but how is “goodness” measured in this universe? Not stated; potential writers should presumably share this value intuitively. Honesty is separately measured, so presumably honesty and goodness are not the same. Are they orthogonal? Maybe they could be, but many people’s value systems would describe honesty as a form of goodness. If I were trying to work with this myself, I’d probably use honesty to describe truth-telling and interpret “goodness” to mean something more like empathy, since it’s possible to be an empathetic liar or an honest sociopath. But that’s a construction I’d be placing on the instructions, not included in the actual document.
This may sound like a bit of pedantry on my part, but it’s actually centrally important, when trying to build story systematically around a set of stat mechanics, to understand what those stats mean and why they’re vital to the story you’re telling.
So, in short: salience/QBN-style approaches are useful and under-explored in IF, and it would be good to play with more systems that use them. (I’m not completely sure how these encounters are triggered; it’s possible that the selection of the player’s next encounter is controlled by the system rather than the player.) And embedding salience/QBN content in a more generic simulation is an approach with some history, and which might produce further interesting results. It feels like it’s not a million miles off from something like Black Closet, for that matter.
Whether this particular exercise actually gets the uptake Chris hopes for is another question. The results may say more about specific skinning and marketing choices than about the conceptual merits of a relationship simulator with embedded storylets.
Emily Short's Interactive Storytelling 
I once heard a piece of advice about getting married that went something like: whatever issue you have with your potential spouse, it’s not going to go away and if anything it’ll become more of an issue twenty-five years later.
Not sure what made me think of that.
“And of course the math here involves floating point arithmetic rather than integers.”
I don’t think this is a statement on relationships. It’s a programmer staring into the abyss with their hand on the volume knob of interaction. Perhaps all it will take is a small nudge. You can do this in integers but as soon as you get into double figures it gets very confusing. When the sum of all input should land us roughly around 1.0, things get much easier to debug.
As I make more games I find my stats better represented by floats. Not because of any advantage in representation, but to preserve my sanity.
At this point we’ve got a generation of IF authors who are used to ChoiceScript, in which stats are represented on a 0-100 scale. (By convention, and also there are language features which normalize computations onto that scale.) So that’s clearly workable. And (I’m pretty sure) it doesn’t matter whether those are integers or floats; the difference between 75.5 and (rounded) 75 is well below the player’s threshold of perception.
There are very good transparency reasons why you wouldn’t want to have 65.232343 as a stat number, anyway. There’s going to have to be at least some smoothing over to convey the info to the player (either by rounding or using pictoral form) and that potentially leads to inconsistent situations where action X leads the user to see the same action interpreted in two ways from what appears to be the same starting point.
Well, but whether a stat ranges from -1 to 1, 1 to 99, or -32768 to 32767, as long as the population can plausibly have any value on that continuum, the effect is roughly the same. It’s all mapping the same universe of qualitative values to a numeric range, and the only real difference is quantization effects caused by mapping to a very small range of integers.
That said, I would argue that the quantization effect is even more pronounced with CS than its 1-99 range would suggest. Much like Storytron’s bounded numbers, the fairmath algorithms tend to keep a player’s stats somewhere near the midpoint—50, in CS—unless they make a concerted effort to focus on only raising or lowering a particular stat. This makes the extreme high and low values almost off-limits, reducing the possible outcomes from fairmath calculations somewhat.
Perhaps ameliorating this to an extent, Choice of Games titles tend to adjust stats less often. I’d wager each choice, in a typical title, changes an average of one stat. In comparison, Storytron adjusts several stats every turn, mostly regarding
perceived personality traits and epistemology.
Using anything other than a float just seems unnatural, unless there’s a damn good reason to do so.
The number of frogs in a box is an int. A measure of my current level of despair is a float. It’s not made up of individual quanta, so anything other than a float would just be weird.
Sure, there’s no real practical difference to the end result, and hence no real point stressing over it one way or the other. But the programmer in me would be slightly distressed by using the wrong data type for no apparent reason.
For what it’s worth, in my latest game I also represent stats as a number from 0 to 1, largely so I can use the typical rnd() function as percentile dice. Having seen how easy that makes balancing the game, I now have much more respect for tabletop RPG designers who prefer percentile…
Chris Conley wrote: “That said, I would argue that the quantization effect is even more pronounced with CS than its 1-99 range would suggest. Much like Storytron’s bounded numbers, the fairmath algorithms tend to keep a player’s stats somewhere near the midpoint—50, in CS—unless they make a concerted effort to focus on only raising or lowering a particular stat.”
This partly depends on the author’s deliberate decisions about tuning the game (something I wrote quite a bit about here: https://emshort.blog/2017/05/09/loose-tight-flat-and-bumpy-stats-in-choicescript-games/ ). The short version is that it’s possible, by changing the size and frequency of stat change steps, to achieve lots of different possible distributions; it just takes some attention to that issue, and it’s something that ChoiceScript as a language doesn’t really make *easy* for you unless you do a bit of plumbing for yourself.
To be clear, I’m not saying floating point is terrible. As it happens, though, I don’t think it is either necessary or sufficient for gradual development of relationships that have dramatic cumulative outcomes.
Not necessary: because a 1-100 or 1-1000 scale in practice typically captures as much nuance along any one relationship quality line as can be conveyed to the player, so at most I’d think you’d need fixed point of about three places between 0 and 1 or -1 and 1 or whatever you’re doing there. For nuance beyond that it typically reads better to have multiple stats (how much does this person like me + how much do they trust me, e.g.).
Not sufficient: a subtler point, but dramatically you also want the player to have warning when they’re approaching a tipping point of some kind, and for the quality of the interaction to change in that region. So in addition to these numbers, you need some additional features in your storytelling model to account for communicating stakes to the player.
And at this point I’ve seen Chris reject a number of storytelling systems that were doing interesting things because “does it have floating point” is a litmus test for him.
One time Randy Smith told me: “Well, I think your question quickly gets pretty metaphysical if you pursue it. ”
That is, I think Chris has been running deeper and deeper in the metaphysical tunnel without a possible way out. In the meantime, more practical people has been advancing the medium, one tangible game at a time.
And that fallacy could be seen just in the final section of that seminal conference of 1993.
It just don’t matter that the world has continuing spinning and approaching the Dragon in a broad different ways, for the people inside the metaphysical tunnel it will never be enough: “That’s not true interactive storytelling!”
Anyway, the only way to discern the value of the system is with actual examples, and yes, that was a bad marketing choice in every level. A better way could be a jam, a jam of encounters, or a contest, providing a brief intro to the world, as you suggested, like in Alabaster. Or a contest of Intros to storyworlds… That would be funny and compelling to try. Also more encounters editors for more storyworlds, shorter in scope.
Anyway, I think the community has solved the marketing question for this kind of things long ago.
Good luck!
https://www.youtube.com/watch?v=VwZi58u1FjI has the whole dragon speech, incidentally, for those who haven’t seen it.
I have lots of respect for Chris – he’s done some of my favorite games, and I’ll always enjoy the Dragon Speech, and the ideas he espouses in it.
I think the Storytron project would be doing a lot better, though, if there was a bit more humility, and a lot less implied arrogance/condescension in the approach. If you want to build a community, you don’t start out by saying that most people are terrible at telling stories (a point which I disagree with, but that’s another discussion) – that’s pretty much the best way to ensure that no one wants to write for you. The best way to build a community is to be welcoming to all, and try to keep discussion civil. For sure, not everyone is going to be Shakespeare, but the bigger your community, the more likely you’ll garner the interest of the good writers. Who knows – one might even catch a few of these mythical people who excel at interactive storytelling.
It sometimes seems like he doesn’t follow what’s going on in the game dev community at all. StoryNexus, Ink, Twine, Choicescript etc. – these might not all solve the problems he wants to solve, but there is a lot that can be gained from studying what they’ve done right – and what they’ve gotten “wrong”. And for sure, there are few better examples of how to build a fantastic community than what the Choice of Games guys have done.
In Mr. Crawford’s defense, I also used to believe that storytelling was hard. Moreover, I wrote an entire article blaming Storytron’s failure on the mechanical feel of its generated text, exactly as he does now. That line of thinking makes a whole lot of sense… and therein lies the danger. Having learned a lot more in the mean time, mainly by working my way up to writing a novel, it’s obvious to me now that the problem with procedural generation of any kind is the lack of significance. You can generate billions of perfectly realistic and plausible tropical islands, ancient temples, modern cities… heck, entire worlds with a geology and nations and history like Dwarf Fortress does, and all of them will blend into an amorphous mass the moment you take a step back from the monitor. Why? Because they don’t emotionally involve the audience in any way. While a stick figure on a blank page can make you cry simply by managing to convey a human experience you can relate to. That’s how the dwarves in the aforementioned game work — by making you care. Once that’s taken care of, the stories proper we can all easily build in our own heads.
It’s interesting. I’m a television screenwriter and have spent a lot of time trying to unpack what it is about Dwarf Fortress that makes it’s procedural generation qualitatively different than most others. Mostly, it seems to me to be about scale and scope. It’s like if we think of stories as the picture that emerges from a connect-the-dots? DF has just right the number of dots, spread out at just right the distances. Most procedural engines put the dots in immediately obvious patterns so we don’t even need to connect them, we can see the picture instantly (these are systems we usually call mechanical). And there are some systems that put a bunch of dots down but no matter how you draw the lines they don’t actually make a picture (this is how I feel whenever I play one of those Japanese story games). But DF manages to often drop the right number at the right distances so that the picture we get after we start connecting them is surprising and interesting. Anyway, obviously just a metaphorical lens, I’m not sure it reveals anything about how to do it well.
I think there are approaches to help this work better — https://www.youtube.com/watch?v=narjui3em1k is a talk I gave last year about some of my thoughts on the problem.
Chris writes: “Thanks, Emily, for the charitable comments and the useful criticisms — as well as the advertising! Rather than scatter replies throughout the commentary here, I’ll just present some overall reactions.
You have nailed the central problem that has bedeviled the entire Storytron project since the earliest days: it’s just too complicated. It reflects my own peculiar, process-intensive style of thinking that is so foreign to storytellers. The very first incarnation of the technology was the Erasmatron, and NOBODY went anywhere with it. It was completely incomprehensible. I redesigned it a few years later and produced a much easier version, but it was still too hairy for anybody to grasp.
I started all over with Storytron, dramatically simplifying many of the components of the technology and working especially hard on making the user interface less “programmery”. Storytron also went through a number of versions, each one cleaner than the previous one, but the result was still sad: only a handful of people attempted to do anything with it, and they weren’t able to complete their work. And the demo I built was crap because I tried to reach two completely different audiences: educational and entertainment.
The whole point of the Encounter Editor is that with it I have stripped away everything to the absolute simplest form. Any further simplification would have to remove a fundamental concept. My ambition here is to attract a small group of people who are willing to put up with the intellectual abstraction and mathematical form used in my interactive storytelling technology. I figure that, if I can’t get even a handful of people interested, then the technology is simply inappropriate for people. I retain the expectation that, at some point in the future, the process-intensity concepts that underlie my technology will become so familiar that some future generation that happens upon my work in an archaeological dig might be interested in it, if only as a historical curiosity. “Gadzooks! This fellow was talking about process intensity all those years ago!”
As to the raging debate on the merits of floats versus integers, I think that the key point is that human relationships do not develop in quantum leaps, as would be required by integers. Ofttimes the process is a slow one with many tiny steps. With integers there is such a thing as the smallest possible step. It’s not too bad if you have a large enough integer range, but the only reason to use integers is to keep things small and simple.
Here’s an example of the problems with using integers. Joe is courting Mary. He brings her flowers. That induces her to increase her affection for him by the absolute minimum step: 1. If the range of integers is 0-100, then Joe need merely bring Mary flowers 99 more times and Ta-da! Joe beds Mary! How do you reduce the impact of Joe bringing flowers to Mary if you can’t go below 1? Do you just drop it to 0 at some point?
But there’s an even more important reason to use floats. I don’t actually use floats — I use a special contrivance I call “bounded numbers” or “BNumbers” which have their own mathematical system with its own special operator called “Blend”. At this point, millions of storytellers’ eyes glaze over. If you don’t enjoy mathematics, what in the world could induce you to learn a completely new and highly unorthodox mathematical system?
Yet BNumbers are the only way to solve a killer problem in interactive storytelling: dealing with the natural limits of character traits and personal relationships. If you represent affection with a number ranging from 0-100, then what happens if we try to increase the affection of somebody who is already at the top of the scale? We can’t have a value of 101. Yet we cannot declare that some actions have no consequences. There are all sorts of clever little mathematical tricks you can introduce that will deal with this problem, but it gets tedious inserting those tricks into every single step of every single calculation you do. The BNumber system neatly solves the entire problem without imposing as much of a cognitive load on the user.
Lastly, I’ll address the several plaints that something was unclear in the materials. Yes, they are all first drafts and I expect to revise them considerably as I collect more criticisms. However, there’s an additional problem that I call “The Page 888 Problem”. Programmers have to deal with huge, immensely complicated programming systems that are all carefully described in the documentation — all 2,000 pages of it. The programmer encounters a problem that appears insoluble. {He|she} pores over the documentation, and {his|her} code should work perfectly, but it doesn’t. Eventually, {he|she} goes to a help website and moans over the apparently insoluble problem. Somebody pipes up, “Oh, that’s handled on page 888!” — which just happens to be in a completely different section in the manual where nobody would expect to look.
How many people do you think will actually watch all three of the introductory lectures carefully enough to grasp all the concepts? I packed a LOT of material into those lectures, because they would have stretched on for hours had I explained each point from multiple angles.
How many actually read the user’s manual with the same care that one reads entire books about programming languages? How many would even bother to try if it were the length of a book? What’s the right balance between conciseness and completeness?
It’s easy to document a simple system, but as a system gets more and more complex, the documentation must expand to the point of near-incomprehensibility. If I recall correctly, every one of the points made here about something missing in the documentation was in fact covered in either the manual or the lectures. I was brutal in stripping away details, yet the three lectures still take too long, and the manual is intimidatingly long.
I will not claim that the Storytron system is the answer to our dreams, but I will insist that interactive storytelling is an immensely complex task, and whatever system eventually solves the problem will be at least as complicated as the Storytron system.
I fear that the only way I can motivate people to put up with all the crap they would have to learn to use my technology, I will simply have to release an actual working storyworld. That has been my task for the last four years, and it continues to grind along slowly. As I wrote, interactive storytelling is immensely complex, and hence it takes a long time for one guy to build the whole thing. I am hoping that I can get a little help with the Encounters. If not, I shall have to soldier on alone, and somehow get this thing done before I shuffle off.
Anyway, I’m happy to answer any questions or challenges the readership wishes to pose.”
Bounded numbers make plenty of sense — ChoiceScript’s fairmath and a number of other systems are designed to try to do something similar. And I have no particular issue with understanding the blend concept, either.
I do think it’s worth distinguishing author-facing representation, player-facing representation, and the degree of detail needed within the machine.
I find that in authoring, I think in terms of three to five sizes of effect (from “this is a tiny action but enough of them will add up in the end” ranging to “this is so drastic an action that it will override all prior history with the NPC”), and then possibly some multipliers on these when appropriate. If you’re handling that with fairmath, it does mean you tend to need two to three decimal points inside the system to handle it, because you’re taking percentages of the distance within your numberline. More than 1-100 or 1-1000 is typically irrelevant, and definitely outside what you can actually display back to the player in any meaningful way.
I’m pretty sure the solution to “the player can grind an action to improve relationships,” however, is not “make the resulting numbers really tiny”! It’s “enrich the mechanics so that it’s no longer possible to GIVE MARY FLOWERS 350 times in a row.” This is something we had to deal with in Versu, too; we experimented with various approaches. One thing we tried was a cool-down on any given action so that you couldn’t, for instance, spam another character with compliments until they fell for you. In practice, that was okay, but not great; it didn’t make for great dramatic moments, for several reasons.
One, it’s neither fun nor convincing to do the same thing repeatedly until you fall over some threshold:
>GIVE FLOWERS
She looks happy.
>G
She looks happy.
>G
She looks happy.
>G
She looks happy.
>G
She’s seduced! Yay!
What you want, instead, is an awareness of stakes and probable consequences; you want the game world to hint back to you when you’re on the verge of breaking the camel’s back with the addition of a straw. And you want characters who respond differently to a single sincere compliment than to a barrage of unconvincing flattery. This requires that the narration (or the phrasing of choices, depending on how this is designed) convey to the player when they’re close to a major change.
Re. marketing, what’s missing is not quantity. It’s a hook, combined with the conviction that you’re doing something that will really work in an interesting new way. Gameplay-wise, that probably means a vertical slice: give people a powerful, emotional, dramatic experience they’ve never had before, even if it’s short, and they’ll want to try their own hands. And when it comes to writer-recruitment, give writers a rich, memorable, fertile story concept they want to write for. Once they’re sold, they’ll read the manual more thoroughly. I’ve taught myself an assortment of programming languages, tools, and design methods, but the ones I bothered to work hard on were the ones that demonstrated they could do something cool.
And finally: I’m not afraid of numbers. Neither are loads of other people working in this space. It’s true that I think the ideal authoring system will be one that makes it possible for non-technical people to express themselves non-numerically, but I completely accept that the design of such a system involves a willingness to deal with numbers and algorithms.
Agree 100% with the comments on grinding relationships. It’s awful gameplay, and most importantly, it’s 100% mechanical and anyone who plays the game will instantly recognize the game mechanics beating them over the head.
Heck, I’ll just +1 on every point you make in that post; it agrees with every experience I’ve had with people in the IF community.
Just reiterating one of Emily’s points: you need a systems hook and a narrative hook.
You need a systems hook so designers and players think “Wow, I want to use this system one day! I’m willing to put in the work now, so that down the line this system might actually be used to make loads of cool stuff.”
Right now, my feeling is “Ok, so we have a story system. So what? It’s not the only one.” What sets it apart from Versu? (Or maybe it’s very similar to Versu but is actually, you know, usable? That’d be awesome.) Or Storynexus? Or Ink? Or Choicescript? On a basic level, what can it *do*?
And you need a narrative hook. Reading Emily’s post, I get the impression there’s… some space stuff? Maybe? Compare that to Fallen London: “Discover a dark and hilarious Gothic underworld where all your actions have consequences.” Or Alcyone: “Alcyone: The Last City is a sci-fi interactive fiction game set in the last City in the universe.” Or 80 Days: “Phileas Fogg has wagered he can circumnavigate the globe. Hundreds of journeys, thousands of routes. Travel by steamer, express train, airship, hover-car, hydrofoil, gyrocopter, camel, horse-back, hot-air balloon…”
Each of those short, one-or-two-sentence summaries told me enough about the game to get me interested and cobble together a basic idea of where/what/who I’ll explore/do/be.
Like Emily says, you don’t need an entire game. Just a playable 15-minute section – an enclosed scene – that shows us what the system does, what it’s capable of, what kind of story world this is. It can be a little short story set in this big novel-sized world you’ve made.
Forgot to ask: if anyone has a brief summary of bounded numbers and how to use them, could you post a link here? I’m curious about this fancy new math/stat thing.
You add to and subtract from your stats using a normal number (can go from -infinity to +infinity). But to check it, you convert to a value in the range from -1 to 1. If I recall correctly, the conversion he uses (from normal number to bounded number) is sign(x)*(1-1/(1+abs(x)))? Note that it rises very rapidly from zero to near one (an input of 10 gives you 0.91-ish) and then has a long very slow tail. So you’d have to set your thresholds much higher than with something like Choice Script’s Fairmath, where (I think?) I’ve seen people (maybe Emily?) use thresholds around 30 and 70 percent (with 50 being neutral). But it’s basically trying to be a cheap, very rough approximation of a bell curve sort of distribution.
Huh. Actually, I take that back about the thresholds. I scaled Fairmath to the -1/+1 interval and solved the differential equation to make it a continuous curve, and bounded numbers actually have a pretty similar shape. So you might think of it as fairmath with a different range and that doesn’t penalize you for choices against your nature (that move a stat back toward neutral). It’s just harder to move in *either* direction as you get towards the extremes.
So as usual, how you want to implement a stat probably depends heavily on how you want it to work in your story. Counting up/down works like money, which we’re all familiar with. Separating the up-count and the down-count and treating them as a fraction makes it harder to change the stat the more choices you make which affect that stat. Fairmath makes it harder to become more extreme and easier to become neutral. Bounded numbers make it harder to change a stat the more extreme it is.
Chris wrote: “I will insist that interactive storytelling is an immensely complex task, and whatever system eventually solves the problem will be at least as complicated as the Storytron system.”
This sentence seems to be the beating heart of the problem. There’s a short, succinct essay by Richard P. Gabriel called “Worse is Better” which presents the counterargument to this approach to software development: https://www.jwz.org/doc/worse-is-better.html
It’s hard to TL;DR something that’s already pretty short, but here goes: To become popular and adopted, a piece of software doesn’t have to be perfect. It doesn’t have to be the best of its type. It doesn’t even have to be good! It only has to be simple, and _just good enough to work_. The extra effort spent on making something perfect from the beginning is actually wasted effort if you’re trying to get something adopted by a community. It’s a depressing conclusion for idealists and perfectionists, but seems to be borne out by the 28 years of software development history since it was written.
But looked at in the right way, it doesn’t have to be depressing! Consider something like Twine. Is it a perfect storytelling system? Hahahaha… nope. So much nope. It’s the equivalent of a pair of roller skates versus Storytron’s Ferrari. But I have played Twine games that have actually moved me to tears. It’s a great example of “just good enough”, where its simplicity is a downside in some ways (imposing a limit on the complexity of stories that can feasibly be built with it), but a major upside in others (anyone can pick it up and tell their stories without a huge barrier of up-front learning, ensuring interesting short content and a large community). If one looks at the success of Twine and thinks “Imagine how much better it would be if it were complex enough to express _real_ interactive stories!”, one is missing the point — it was successful _because_ it wasn’t complex. Any sufficiently complex “perfect” storytelling system will probably end up being as much of a historical footnote to interactive storytellers as Gabriel’s Lisp Machine is nowadays to programmers, because complexity and having a healthy community are fundamentally at odds.
In short, whatever system eventually solves the problem (inasmuch as it can ever be “solved”, rather than just endlessly iterated on), will almost certainly not be as complicated as Storytron. It will probably be _just good enough to work_.