Story Manager

Posted on Wed 09 April 2014 in Articles • 5 min read

Earlier I posted about using files and folders to store my world-building content rather than in database or third-party application. In that directory structure, I included a folder for stories which is somewhat of a depature to how I've to date.

The Story So Far...

I currently manage my story ideas using the now defunct, Filemaker Bento. How I manage stories is not particularly sophisticated and I'm not especially disciplined because of the disconnect between my characters, setting and where I do my writing (Scrivener).

If you look at the screenshot below, you'll see I've got a basic table, a couple of custom views and list of related records (my characters). Bento isn't exactly a complex program and certainly doesn't offer much to a power user like it's big brother, Filemaker Pro. My problem with Bento is it's been discontinued (and it really shows on anything newer than Snow Leopard), it's not a relational database nor does it support any way to script the application in a way that would be useful for me.

Story management in Filemaker Bento
Story management in Filemaker Bento

Where I'm Going

My crude database in Bento was fine for storing notes and ideas but I now want to combine basic story and idea management with guided story development using the Snowflake method. I want to be able to automate some of the more repetitive tasks particularly as I make the transition from planning to drafting.

Now, I want to record stories within a world rather than dumping all stories regardless of setting and genre in the same table; this is just how I'd prefer to work but others may differ. Part of this reason is that my new development won't be in a big monolithic database as I noted in the last post; again this a personal choice.

I want to incorporate a structural design pattern like the Snowflake Method. I say like the Snowflake Method, because I want to combine it a few others that I like and modify to suit the way I like to write and the way I like to world-build. Snowflake is an awesome place to start but as with any design pattern or template, one size does not fit all, which even Snowflake's creator, Randy Ingermanson admits.

I'm also now looking to work in plain text instead of a database so I'm looking at either using json or CSV or most likely, I'll use both formats for different purposes.

So builing on the directory structure I outlined in the last post, my stories folder will look like the following:

        -story 1
                narative description

        +story 2

content: in this folder I'll store (or link to) the chapters of the book. Note that I say link, because I want the flexibility to draft and edit in any markdown compatible program that I choose, and that may include the excellent easybook-project which is more particular about where it expects to find the markdown files of each chapter. I'll post about this later.

output: is where I'll target builds of my stories into various formats and this should be self-explanatary. The preview folder deserves a mention however because that will contain PHP files (accessable from a webserver) that I'll use to convert much of the planning content into something more readily digestable, i.e. a nicely styled website. I'll post about that at a later date.

plan: this folder is what I'm mostly concerned with today and how I want the content to tie into the snowflake method.

Starting with, this file will contain the:

  • one-sentence summary (Snowflake Stage 1)
  • one-paragraph summary (Snowflake Stage 2)
  • one-page summary (Snowflake Stage 4)

Note that I may end up storing the first two in a top-level json file named the book title.

The characters.json file will contain a listing of all characters in the story and this corresponds to Snowflake Stages 3, 5 and 7. In Stage 7, where we flesh out the character's biography and physicaly description, I'll link to their file in the World->characters folder so I don't have to repeat myself; I'll talk about in another post.

characters.json will look something like the following:

example: characters.json

    "characters": [

            "name" : "character name",
            "type": "ie main protagonist",
            "alignment": "protagonist or antagonist",
            "bio": ""

            "name" : "character name",
            "type": "ie main antagonist",
            "alignment": "protagonist or antagonist",
            "bio": ""


It might be tempting to store that character inside the top-level book.json file, however when I have dozens of characters this might get messy.

The scenes.csv file will contain a list of all scenes in the story and correlates to Snowflake Stage 8. I could do this as a json file, however in a book with a hundred or so scenes, this would get messy. By choosing CSV, I'm still using a text-based format but with the added benefit of being able to edit it in a spreadsheet application, which is ideal for visually editing this kind of information.

Editing scenes stored as CSV in Apple Numbers
Editing scenes stored as CSV in Apple Numbers

The locations.json file will keep tabs on locations, something that the Snowflake Method doesn't explicitly mandate but doing so makes sence in a world-building project that aims to make writing fantasy novels easier. Like characters.json this will store location metadata with the bulk of the content linked to the appropriate file in the world->countries folder.

The narative description correlates to Snowflake Stage 9, which creator of Snowflake admits that he no longer does. I like the idea of doing it however; essentially it's the creation of a proto first draft where each scene is fleshed our into a couple of pages that describes at length what happens and includes snippets of dialogue. This is something would obviously benefit from automation, for example, looping through each scene in scenes.csv a producing a markdown file for each scene, appropriately numbered and tagged.


Well that pretty much covers how I want to develop stories and manage stories from now on. I've got a pretty good idea of the datamodel I'll use so now I'll start roughing out my first couple of scripts to make it a reality.

In my next post, I'll document the development of the create_world and create_story tools.

Share on: Diaspora*TwitterFacebookGoogle+Email