I recently watched the interview by "The No-Frauds Club" with Casey Muratori, and he discussed at great lengths the design and implementation of interactive fiction, which got me wondering about my own project that I've been working on for almost ten years now.
It's remarkable after all this time that someone else has been deeply interested in interactive fiction as much as I, and it is incredibly refreshing to hear someone else's opinion on what interactive fiction should be and how it should be demonstrated.
I wanted to expand on this here, in part because of StoryDev (software that I wrote in C# and WinForms (go ahead, poke and prod)) which is specifically designed for interactive story writing which takes on interactive fiction in a completely different way to traditional methods, but also to post a thread which I had wrote some time ago relating to my view on interactive fiction and how it should be written.
Unfortunately, I do not have a link because I was forced to take down the website (due to finances), but I will paste it here.
Apologies in advance for the long post.
Conceptualising Interactive Story Design
Where do you begin to understand story design in a video game, with choices that all branch out and these decisions affect how the story plays out, leading to multiple outcomes and managing it?
You can't have a full hierarchy showing all the possibilities in a complex interactive story, that would be overwhelming. But you need to have an idea on designing your story using some form of hierarchy to know what to do and where to go.
There are multiple ways we could approach this.
One to Many
Imagine relationships in databases, but hierarchically illustrated. One-to-many, what I mean by that, is having one item branch out to multiple items, then those items branch out to more items.
This is a very basic and simple approach to story design. You have a conversation and three choices are presented at the bottom, each leading to different conversations. You might have a conversation that leads to an existing conversation from before, which you could consider part of the "Many to Many" approach.
Many to Many
Not too often would we see this approach, but it is certainly possible in more complex interactive scenarios. This likely involves conditions to ensure no more than one option can be selected, or perhaps once an option is selected it can no longer be selected once we return.
Yes, the above looks complicated but it is typical of an interactive story doing multiple things at once.
You have a starting conversation which leads to another conversation at the top. The following conversation has multiple questions you can ask to a non-player character, let's call them "Person who Talks".
You reply to Person who Talks which leads to either the right or left answers. In those conversations you have choices at the end.
The conversation on the left leads to two choices:
We have one returning to the beginning of the conversation and the other going forwards. The one returning to the start is conditioned to return to a section of the story such that it doesn't feel like the beginning, but you still have that sense you have returned to a previous point. The same applies to the conversation on the right.
The conversations at the bottom lead forwards, but they create two branches of story that continues the story in two different directions.
Not only is this typical of interactive stories, but it is also more complicated. The more possibilities you create for yourself, the less creative you can be on conceptualising outcomes.
Let me explain.
You have a story where you expect to have multiple outcomes but you want to get the player to reach any one of those outcomes depending on the choices you can make. Suddenly, you have to design your story in a way that requires you to cover all possibilities, which actually hinders creativity because you already know the outcome before the story is written.
When conceptualising your story in diagrams, it is important not to overcomplicate the diagrams to prevent over-branching. Over-branching, meaning creating too many branches of the story that it becomes overwhelming, hinders story creativity and prevents meaningful progress, even if the choices to the player feels like a meaningful choice.
In the end, what you get is a story that, despite having multiple outcomes, feels underwhelming by the time that outcome is reached by the player, because all that meaning that was meant to be there in earlier chapters is wasted due to the overwhelming nature of the story design behind-the-scenes. The player doesn't know this, but they will get a sense of this as story progresses.
One to Many to One
My solution to this problem is what I call the "one-to-many-to-one" approach, meaning we have a starting conversation, we have choices leading to multiple outcomes, and then we condition a single conversation at the end to handle all these conversation choices at once but in one conversation.
What this leads to is the above.
We have a way to design our story that isn't overwhelming to ourselves and allows us to be more creative with our story without feeling hindered by overwhelming choices and over-branching. We keep our hierarchy relatively narrow but keep the feeling of choice meaningful.
Ultimately, we want to have a certain degree of outcomes, but you don't want too many outcomes. Getting the balance between the number of possibilities while keeping the story relevant and interesting is one of the most difficult things to get right in interactive story design.
Thinking in terms of writing stories overall, including novels, screenplay and the likes, interactive story design falls in the category of difficult. Novels by themselves are difficult enough since every sentence needs to be coherent, grammatically correct and perfectly paced. Screenplay is difficult since you need to follow a certain industry-standard format, descriptions need to be minimal and explanations need to be done in dialogue, and questions can't be abrupt as that would throw off viewers.
In StoryDev, we are taking the screenplay approach, similar to Ren'Py. The name "Visual Novel" is deceptive. It's not "novel" as the approach of visual novels technically lean towards screenplay than novels. The good news is that there is no industry-standard format for Visual Novels, but that doesn't mean they are any less difficult to make.
Not to put anyone off wanting to create an interactive story, but getting one right the first time takes a long time conceptualising and understanding your story.
Age of Atlantis started out as a novel. Originally, the idea was to create video games but this conception took place ten years ago! When I was 21, I wrote the outline for a series of video games and gave the idea to my dad to review. At the time, I was advised it would be best written in the form of novels, and that's when I started writing a novel for Age of Atlantis.
Concept, to writing, to concept, to writing, it went. It was an idea that was an expanded universe with multiple different ideas going on, and definitely much were incoherent, cliché and, in many cases, downright awful on paper.
A second draft started which involved refining much of what I previously had. Most of the clichés had been removed, and it was eventually narrowed down to a simpler, more coherent story.
Having written the novel four times now, my vision for the story could not be clearer.
If you want to write an interactive story, try writing it as one story with one outcome in the form of a novel first. This is my advice and I recommend doing so because the story idea you have might not work.
Why start writing a novel? The novel doesn't have to be perfect, but the point is to lay out the foundations for your story to bring clarity and coherency. You have an idea in mind you want written down into a screenplay format, but remember that most screenplays tend to be written after the novel, not before.
Successful screenplay that makes it to television screens without a novel behind it takes years of industry practice and a good understanding of telemarketing, and character interactions in dialogue needs to be perfect.
Writing a novel first means you don't just get an idea for your story and writing it down, but novels are easier to conceptualise than a screenplay for the reasons outlined above. You will have multiple characters, multiple scenes, interactions and more. You want all of that imagination in your mind pour onto paper coherently, and then you want to write it over and over and over again until you get the visualisation of the scene written down perfectly. You do this scene after scene, chapter after chapter, and then you revise.
You read through it multiple times, you understand your story inside and out, you get a feel for your characters and imagine you are them in any given situation. You feel the characters themselves as you conceptualise them and write them down. Make them be you, and you them. You are your characters.
The best way to connect to your characters as you write them is to write a novel, because novels open the right brain to so many possibilities. You are open to create, visualise and write the characters as they write themselves.
Screenplays don't open the right brain as much as a novel does, since screenplays will translate into the director's point of view eventually, which is confined to their vision and their ideas.
Despite not having to deal with a director with an interactive story, you are still your own director. When you have your computer screen on glaring at you in the dark of night, and you are constantly figuring out what to do with your story, most of that is down to not having a good idea for the story. And then it feels rushed.
Why was Harry Potter, Lord of the Rings, the Hobbit, and fantasy stories of the likes that all rise to fame and popularity? Concept, writing, concept, writing, revise, rinse and repeat. It's easier said than done, for sure.
StoryDev will prioritise the one-to-many-to-one approach When we eventually reach the point of implementing the conversation system, there will be a method of designing and conceptualising your stories. I have spent the last 5-6 years writing my novel over multiple drafts and now I have a full understanding of all my characters, story, chapters, what needs implementing, etc.
There are no doubts about how the story should progress, it is simply a matter of doing it.
Do you have a story you wish to create into an interactive story?
I'm sure you have tried multiple pieces of software to help with that. Trust me, I have tried many myself, including Articy:Draft, Twine, Ren'Py and Quest.
You have one side of the board containing the minimal amount of story design techniques that make that software what it is but offers nothing else, then on the other side you have something like Articy:Draft which offers a very unique design-conceptualisation experience but is overdone and can make reading the story difficult.
You want a mixture of both, really. You need that conceptual diagram on one side of the screen showing you how the story should come together, and on the other side of the screen you should have your document with the conversation laid out how you would like it, showing all the dialogue, narration and choices. Twine becomes the closest in this respect, but it's output is what hits the nail in the coffin for me, which is HTML5.
Not to say that building a web-based game is bad, but having multiple options is better. Yes, I'm saying that considering I'm building the editor in C# and WinForms – INITIALLY. Perhaps.
Nevertheless, we should consider all possibilities (no pun intended), and one of those is to take a shortcut to help speed up progress so we don't spend too much time on the editor.
Hopefully, this clarifies the approach we will be taking and why.
END OF ARTICLE
What do you think of this? As mentioned, I'm very curious what people think of the approach to interactive fiction. Having listened to the interview as linked above, a lot of what I had described on TwinspireFW.com (certainly before that interview took place before I took it down; apologies that you are only taking my word for this...) is very much what Casey described in the interview. But, ultimately, that doesn't matter.
What matters to me is -- would you agree that having both a design and a text editor to the side describing the scene? What would you expect from an editor for interactive story design?