This is coming up in regular software engineering discussions. A martinfowler.com article (he has guest writers post to his blog), Kief Morris talks about engineering loops.
In relation to IF, the inner loop is the hard coding part where the author is leaving the low/no code world and digging into more complex programming paradigms. But Morris also changes the entire paradigm to Code → Story → Feature (How) with a Why adjacent to the How loop.
I’m seeing the same thing in GenAI circles. We’re positing that the inner how loop is no longer necessary.
It’s a fascinating article that has a direct correlation to this discussion (and the monstrous GenAI threads).
Don’t you feel that switching between narrative flow and structural logic could break the momentum?
it’s less about replacing that integrated approach, that is perfectly valid and works (for you and for a lot of writers) and more about offering an alternative workflow for a different kind of writer.
The split between story-first and structure-first creators seems to be super real— and I think you’re right that most existing tools tend to fit the second group better.
There is the room for what I was proposing with the tool, a site where writers can stay closer to the narrative flow and let structure emerge or be handled separately.
Not as a replacement for existing approaches, but as an alternative for a different way of thinking.
I agree that the hard part isn’t syntax, it’s design, an even if you remove or abstract away the coding/logic layer, still need to understand what you’re building and how it behaves.
But why should it be necessary to define and shape whole structure and behavior from the beginning or while you are trying to find the correct voice for your novel?
Could that kind of complexity be solved in a different way and at a different point of the process?
I’m more on the other side, letting writers focus on scenes first, and only later shaping the system that governs them, that probably doesn’t reduce the total complexity, but it might change how that complexity is experienced.
It’s not. I always write one room first. All the descriptions. All the interactions. Then I move on to the logical next step in the story. Works much the same in static fiction, too. That way everything follows, and the whole makes sense.
This is probably the approach I feel more comfortable with too. But somehow is exactly what I meant. Write first, shape with logic structure later, but splitting the process into rooms, scenes, or chapters. Absolutely agree with your way of handling it
That’s not been my experience with Twine at all. While I know people can write a “simple branching story” (as people tend to call it), almost everyone quickly gets into the code, probably because code and text are so easily and seamlessly mixed.
I’ve not programmed in Inform (picking that as the most natural language parser option) but I’ve seen enough examples to feel that the divide between code and text is a lot larger than in Twine. Yes, people can and do produce vast blocks of pure Javascript in their Twine games, but most people are just peppering a few macros directly into the text.
To me, that’s exactly the experience @oldskultxo wants to capture — you write primarily text, but you can easily add code as you go. It’s just that it does it in a more seamless way than switching to a graphical UI alongside your text.
Another digression: In this article, Mark Sample asserts
September 2003 Andrew Stern maps a CYOA-inspired book (Night of a Thousand Boyfriends) on the group-blog Grand Text Auto. As far as I can determine, Stern’s is the ur-map, the CYOA map that started it all. Stern modestly calls his rudimentary hand-drawn map “a fun exercise,” but as the CYOA visualizations he inspired increase in complexity over time, Stern’s map is revealed to be visionary.
I know of a much earlier CYOA-type map. John Sladek’s own map of his proto-CYOA The Lost Nose, written in the late 1960s. The original book was an elaborate collage, but the map was painstakingly reproduced in CorelDraw by David Langford in 2000:
No Sladek collection would be complete without such weird and gratuitous diagrams, and I felt I was following the obsessive footsteps of the master as I spent hours fiddling with CorelDraw software to recreate his elaborate flowchart of possible reading routes through The Lost Nose – including the restoration of a pathway he’d omitted. Quite unexpectedly, Maps now contained a map. Next I was reminded that John had written bridging passages to cover lost pages in a certain Philip K. Dick MS (Lies, Inc., 1984), since now I found myself concocting plausible sentences to replace a fragment of gummed-on Lost Nose text that came unstuck and vanished long ago.
As related elsewhere on this forum, I ported The Lost Nose to Twine a few years ago (and took great delight in recreating the above map) but was denied the pleasure of releasing the finished game for copyright reasons. While there are CYOA-type books that predate Sladek’s, this may still be the earliest diagram.
Sure, but that’s why it’s good to start with the structure before the polish. As I said: it’s easier to paint a house after it’s built.
Standard story writers already have the structure - linear from beginning to end - set when they start; if you’re writing an interactive narrative, you will naturally have to switch back and forth. If you’re building a flat train you probably don’t need to worry about lateral, positive, and negative g-forces; if you build a roller-coaster, you do.
It’s an extra skillset, and why I always find it easier to do structure first. Since the story is not linear any of the pages you spend time on could be skipped or completely removed from the story altogether if you don’t know the initial shape of the story.
To play further with this analogy, a writer of linear fiction has the option to change the order of the carriages in their train; have this scene happen before that one, put in flashbacks or flashforwards. So their structure has some flexibility. But a writer of IF might have to consider, “what happens if the player encounters this scene before encountering that one?” and write alternative versions of both scenes accordingly. This is true of both parser and choice-based IF. Thus, the IF author has to be mindful of structure throughout the process, and to be honest, it’s much easier to do the coding as you go along than it would be to write all the alternatives as prose and then go back later and try to remember how they were all supposed to fit together. I imagine you’d get into a big mess pretty quickly.
Yeah, from what I’ve seen Twine is excellent at frog-boiling people into learning and integrating progressively more code and structure into their projects! You write a simple branching story and want to do something more complicated so you learn variables and if statements, and then you get sick of copy pasting code and learn macros, and then you want to do more complicated branching and learn switch statements and how to combine logical operators, and so on and so forth. And then there’s arrays, which work the same as in JavaScript enough to be (IMHO) a major stumbling block for learners who didn’t originally set out to learn to code. (I am not going to be qualified to be a full time JavaScript dev any time soon but we did also make it into the IFComp top ten twice with a decent amount of programming involved, if that’s evidence of anything.)
But pointer issues aside, I’ve never seen why this is supposed to be a problem? Yes there are different designing styles but at the end of the day I think it’s fine that making games requires a different skill set than writing static fiction. All art forms do? And I’m just not sure how much you can shortcut that before hitting a relatively low skill ceiling.
Exactly. You don’t write a screenplay like a book. If you’re writing a movie you only describe dialogue and filmable action and any included inner monologue, direction, or world building is usually considered a waste of paper and goofs up page-timing. It doesn’t matter what the characters are thinking and you don’t direct the movie on paper, you don’t describe the sets or costumes in book-like detail other than what’s necessary because that’s not the job of the screenwriter. A screenplay is a design document for a movie where the writer doesn’t need to do all the work. This may be considered “stifling” for a novelist to cram a story in 90-100 pages, but that’s how that particular art-form works.
Yeah, people are always like “But technically you can write a work in Twine with zero code or markup other than the link markup! So it’s fair to call Twine no-code/a writing-only tool/much easier than Inform/blah blah blah.” But the thing is, of the people who are actually using Twine (and the people who say this are never users of Twine themselves and do not give the impression of having really talked to people who are), I think there are vanishingly few who are satisfied to just do the super limited thing you can do with links alone, in any case certainly not forever. It’s sort of like saying “You can write an Inform game with only the built-in actions and without customizing any of the responses”—you can, and beginners sometimes do, but that’s not the endgame for the vast majority of people. (And even my stupid garbage first Twine game had variables and conditionals!)
I think what might be ideal is: text pane with node title, body, and choices; a node list pane with just the titles that you can click on to add choices or to move to a new active node; and a map button that, when toggled, replaces the text pane with a node map. In map mode, nodes could be clicked on to return to text mode.
I am currently working on something more in that line than current, but trying to keep priority to writing experience! If you want I will let you know once it is published!
Without getting involved with the discussion of which style is better or worse, in terms of “seeing the story as prose” have you tried out InkleWriter? Technically it is a cut down Ink (and can export Ink files) but as an author you always “play the story” to the place you’re next going to write, so the view is always the story so far.
The visual style may not be what you’re looking for but I wonder if that gets closer to the authoring style you were thinking of and gives some UX ideas. It does come with its own pitfalls, of course - it makes it much easier to write text that exactly fits the current flow, but makes it harder to think about how reusable ‘nodes’ will look when reached via different routes if you aren’t an experienced IF author. You’re always being conditioned to assume you’ll get here from the paragraph right above where you’re typing which is why I don’t use InkleWriter when teaching IF even if it is a great educational tool for experimenting without guidance.
One of the main complaints about Twine as an editor is that you can’t have multiple passages open at once to compare and copy. (You used to be able to, but now you can’t).
