Mountain, a Tool for Screenwriting with Fountain
Eight months ago, I started writing a screenplay. I’ve been working on it just about every single day since.
I’ll save further details about the project for a later post, but, in short, I’ve found screenwriting to be a fantastic creative pursuit. The writing experience feels like just the right mix of exhileration and frustration. (Exhileration when that next challenging problem is finally solved. Frustration otherwise.)
Fountain is a plain text markup language for screenwriting.
The most important feature of Fountain is that it is just plain text. You’re not locked into a particular piece of software for writing the screenplay. You can, if you wish, continue to use the software that you already use for editing and working with plain text.
Writing with Fountain is significantly easier when your entire screenplay is contained within a single file, and generally it seems that that’s how everyone does it. (There is an exception – Scrivener’s Binder and Compile features – but then you’re locked into using a monolithic tool as a crucial part of your writing workflow.)
Over the course of writing, I’ve run into several workflow issues that are all related to a single root cause: file organization. In particular, there are three specific reasons why I highly prefer to split my Fountain screenplay across multiple files:
Source control: I version my screenplay with Git. There are many advantages to using source control, but some of the benefits are lost when your repository consists of a single, multi-thousand line document. For example, it’s incredibly time consuming to go back in time and see all of the previous versions of a specific scene or sequence (yet trivial, if each scene or sequence lived in a separate file). I compound this issue by abusing source control to store supplementary information in the history; when I’m working on a scene, I’ll often commit a bunch of text (for safe keeping) and then immediately delete the text and commit again. I do this to store alternate versions of scenes, extra lines of dialog (sometimes even entire exchanges) that I wrote and liked but ended up abandoning in favor of some alternative, additional ideas for how the scene could play out, etc.
Outlining: Fountain has support for sections, which can be used to document the structure of the story. I use these section elements for outlining (in lieu of index cards or an alternate system). For this screenplay, I outlined initially at a very macro level and have been frequently zooming in to fill in more specific details. It’s very cumbersome to work on the outline when your entire screenplay is part of the same document, though: if you move anything around, for example, you have to also move all of the actual scene content. More generally, the scene content gets in the way. The ideal solution is to have a separate file for the outline that can reference the other files that store the actual scenes.
Mobile: I want to experiment with writing on iPad (and iPhone, too!), which seems particularly feasible because Editorial for iOS is such a fantastic app. However, as great as Editorial is, it’s still extremely difficult to effectively navigate a very long document. (And there’s also the issue of creating conflicting copies in Dropbox when the screenplay syncs. The longer the document, and the more scenes it contains, the more likely it will conflict with the version I’m authoring on my other devices – and the more painful it will be to actually fix the conflicts, when they inevitably arise.)
Another advantage of plain text is that it’s relatively straightforward to build additional “creative tools” that operate on the plain text Fountain corpus.
Today, I’m releasing Mountain, an open source Python library that solves all of the issues enumerated above by making it easy to split a single (Fountain-formatted) screenplay across multiple physical files.
Mountain accomplishes the same goals as Scrivener’s Binder and Compile features, but in such a way that embraces the plain text nature of Fountain, and, crucially, works with any writing software that you’re already using.
Try it out and let me know what you think. (Full usage details, including a tutorial, are available in the project’s README.)