3 things to consider when making narrative tools
So you’re making a narrative tool. Very quickly you find out it has to do a lot of things: Write dialogue, set dialogue choices, clarify what characters say which lines, check values for which line is active, check on what choices can be made, what the active quests are, what states those quests have, where characters are located, what audio files are played for each option, what quest items need to be tracked, what the relationship levels of characters are, what each character is currently wearing, at what level of health they are, etc.
That is a lot to deal with. It’s very easy to scope creep, and depending on your project, some of those aren’t even considered scope creep but are plain base level features needed to ship the game. Narrative tools can sometimes simply be that complicated, because they are interconnected to everything else.
Over the years at conferences like the Game UX Summit, Gamescom, Devcom, GDC, Quo Vadis, and more, I have had discussions about narrative tools with many developers. I have been wanting to write down the results of some of the discussions, conclusions, and thoughts that were mentioned in those conversations, as three particular elements have continually come forward.
1. Every writer has their own technique
Writers write in very specific personal ways that creatively work for them. Word, Excel, node based systems, YarnSpinner, Ink, etc. Maybe they even use LaTeX? Which is pronounced ‘Lah-tekh’ by the way. That’s good to know because if you literally say ‘Latex’ near anyone that uses it you will immediately be sternly corrected. Don’t make the mistakes I have already made.
If you have experienced writers used to working in specific ways, then constraining them to work one specific way is exceedingly difficult, and very costly in time. It is like asking a professional Maya artist to pick up Blender and instantly make something beautiful. Just because they know and can make amazing 3D things in Maya, does not mean they can quickly pick up and use Blender to its own fully unique extent. It is possible for them to switch tools, but to get to the level of ease and workflow they are used to can take weeks, months, or years. Especially when it comes to working smoothly with hotkeys. When someone first joins a studio you will ask folks to work with your in-house tools, and sometimes that works out fine, but it can also take a lot of precious time you may not have, and lower the quality of content you need until then. For artists this is an established fact that folks will ask about: What are you used to using? Well, get ready to use what we use in-house. For writers, this does not come up that easily, even though their workflow revolves around it.
All writers, like all artists, are unique. Some writers love jotting things down in an empty word file. Others need an explicit script writing interface as if they are writing a Hollywood movie. There are different needs all over, so you need to work with your writers. Find out how they like to write, in what format that writing is saved, how that writing is displayed and used, etc. Writers are the user base of your tool, and so you need to do user research to find out what works for them. Giving them a ‘visual scripting interface with nodes’ isn’t always the best idea. How technical are your writers? Can they become technical? How long will that take? Of course we would all like to hire unicorns, but do you have the budget and time to do that? Sometimes you will have to force them to learn how your node graph editor works, but watch out that this is not the ‘quick and easy’ solution you jump to. As it usually does not end up being a quick transition, much like a Maya artist being forced to pick up Blender.
From your user research you can sometimes find out that the best writing software is a third party app from which you need to do an import/export loop to your in-house engine and editor. Importing and exporting is complicated. It may be lossy. It may be time consuming. Then again, would you rather your expert technical engineers solve a deeply technical problem of proper import-export, or would you want your non-technical writers to suddenly have to learn how to script? Depending on your user base, one may be much easier than the other! A node graph editor is still scripting, no matter how many times you call it ‘no code’. I am not saying it is impossible to teach users new tools, but it costs a large amount of time and energy, so it is important to consider your users when weighing whether to use a third party tool or make a new in-house one.
If you do try to create an in-house narrative tool, realize you will not be able to get all the features the narrative folks want. You would not try to fully recreate all of Maya’s or Blender’s features in your own 3D editor, right? So you have to ask yourself: Do you have the time to create and maintain a professional narrative or screenwriting tool? If you are a big AAA studio then you may be able to do that, and that is great! If you’re a smaller studio, you will have to make hard concessions on feature sets.
All roads here lead to Rome, but you have to realise every writer has their own technique. Their own ways of being creative. Find out what your narrative folks need. A big part of tool UX design is figuring out what you do not need to do, and should not be doing. Discuss what is necessary with your userbase, as well as find out from your programmers what is doable in your timeline, and always keep asking why.
2. Writers should be able to ‘just write’
Paper on the floor. Post-it notes. Scraps all around. Crossed out pieces of text, and the one bit of info they need to remember for later. Writers need to have a scratch pad! Somewhere they can write where they do not have to think about what they wrote down, or where they wrote it. Similar to how a programmer can write comments in code, writers need to be able to write comments on their writing. A ‘commenting’ feature is relatively normal in node graph editors, as well as multi-user editing environments like Figma, Google docs, etc, but often not thought of when creating a narrative tool.
It’s not just about comments though. Narrative folks should be able to write what is necessary for your project without breaking anything. Without the system throwing warnings or errors. Without them having to figure out complicated technical steps of debugging content in combat scripts and 3D content. Without having to worry that they can break the build. They should just be able to put their thoughts down, especially if they are not structured yet. Think of a 3D artist trying to create a model: Would you want their tool to complain to them when there is a separately floating mesh in the middle of their creative workflow? What about a loose triangle, an ngon, or an unsmoothed surface? Yes, those should not exist in the final export, but in the middle of creation those may just be a natural part of a workflow. Yet, when writers ‘just want to write’, often the text has to be typed in a specific way, with specific jargon, and with existing beginning and end points. As if a writing process is always the same, and always structured.
Sometimes to write a good story you have to start at the end, then go back to the beginning, then back to the end, and then fill in the middle. If the narrative tool’s structure and systems do not allow for this, and force a user into a ‘beginning-to-end’ approach’, then you have lost out on the fun and creativity your narrative folks can give you. Constraining creativity is not helpful, as your stories will be less good for it, even if it’s under the guise of ‘The system expects it this way!’.
Allow your writers to write into empty nodes that do not do anything. Allow them to write half finished thoughts. Allow them to create a dialogue tree that isn’t connected to anything, but gives them a good visual and mental reference that the conversation needs. Allow them to ‘just write’, just like you would expect an artist to ‘just paint’, or ‘just model’, without having constant popups and warnings telling them they’re not doing it right.
3. Writing is interconnected
Writing is part of everything else. If a burning building gets changed to a flooding building due to a VFX reason, but for gameplay purposes the building still gets destroyed regardless, the gameplay and VFX teams may be totally happy to move that change through, but narrative and dialogue may now need to heavily be edited and changed if it references any burning thing. Who is going to tell them? How will they know? If the narrative folks aren’t playing through the game, not looking in the 3D editor, or not part of that one meeting where that was decided, they may never know.
If you have worked in the development of any project with art and level design, you have seen this before. An environment artist gets a gameplay tested whitebox from a level designer, and then proceeds to move a pillar because it will look better. With that pillar moved, a giant sniper line has been opened up that ruins gameplay and balance. Sometimes a small change like that has a minute effect, and sometimes it can be immensely limiting creativity by not allowing a single change. It can be too restrictive to not be allowed to touch anything, and on the other hand allowing big changes can be too destructive. The contextual need for changes has to be continually communicated well. Preferably inside the 3D editor, within the context where the work happens.
The overly simple answer to this problem is ‘More meetings! More emails! More Slack messages! More rigid process!” so that we can inform the whole team into the infinite boredom and mental load of constantly being up to date about everything everywhere, until they no longer read any messages, and are then scolded for not being up to date. It sounds like a simple solution, but think of the immense load you put on folks to always be aware of everything. In a gigantic game with tens of thousands of moving pieces, it simply isn’t possible for everyone to be aware of everything. Besides, barely anyone likes meetings, emails are almost never read, and the sheer amount of Slack messages sooner or later causes them to be more noise than signal. So what can you do to make sure content stays interconnected, especially with narrative folks?
At GDC I asked Josh Sawyer about it (Director of Pentiment, Studio Design Director at Obsidian, Project Director and Lead Designer on Fallout: New Vegas, and rider of classic bikes), and he mentioned the importance of core strike teams getting context together. Playing through the level with key folks from art, design, narrative, programming, QA, etc, together, and only as a small strike team. Also, making sure those strike team meetings and play sessions are tightly structured so no time is wasted with those core and expensive folks. Getting critical folks of those teams into a meeting is costly, but worthwhile with the amount of time and money it saves the entire rest of the team, as they can inform whoever is necessary of the changes that have happened or will happen. So if you play through it as a small strike team, the whole team gets context when they need to. Any particular needs are then much less communicated in silos, as the core strike team is always informed, which avoids the issues of changes happening that are not reflected in the content of other disciplines. I think these are great ideas too, if your project and team structure can allow it. Thanks Josh!
I think that is also important to consider when making any tool, but especially a narrative tool. The narrative tool itself is not the sole part of the narrative content. The content is used all over the place, in conjunction with design, art, cinematics, VFX, and programming, everywhere! It isn’t a closed system, and should not be treated as such. So when you make a narrative tool, keep the workflows that relate to it in mind. How do folks in the team and project inform each other? How are changes communicated? If a writer says something is in a characters’ left hand, how does the cinematic animator know this for their animation to work well? Is that workflow a part of the tool, or a part of the production system of the project? These choices have to be made, even if they can be unclear or change throughout development, so that you have made a choice and know how the communication happens that affects the content inside the tool.
Conclusion
The three things above are not the only things to keep in mind when making a narrative tool, but they are the ones I have continually heard about and have had experience with over the years. They are the thread that binds the needs and workflows together of narrative tools, and all the other tools being used within your toolsets:
Let writers write in the way they are used to, for maximum creativity. Learn how your users work.
Let writers ‘just write’ in your tool, without making them worry about errors or crashes. Support creativity and free flowing thought.
The writing of a game is interconnected to everything else. Keep this in mind when designing workflows.
And of course: These things are just as true for other workflows as they are for narrative workflows. They are basic UX principles! For some reason they seem more easily forgotten when it comes to narrative tools though.
Lastly: I am incredibly curious as to whether these things have also been your experience, or whether there are more things you would add to this list. Please feel free to reach out to me at @RYStorm on Twitter or Mastodon, or email me at storm@rystorm.com.
Thank you for reading! Thank you as well to Brenden Gibbons and Ben Schroder for proofreading. If you enjoyed this post, please subscribe below to get updates when a new post is published.