A Storm of Forms - Character Sheets, Settings & More

Some days I just can't get into the writing part of writing. In particular, during the rewrite/second draft editing process, it can be very hard to get into the creative side of things. I do my best, like everyone, to push through that. But there are some other aspects of a novel-writing project that are worth doing, even necessary, and I do see it as worthwhile to spend some of those can't-do-the-actual-writing days doing them instead.

One of the most important sort of side projects needed for any novel is character design. The tool I've seen most used for guiding this effort is character sheets. Every writer's workbook has them, and you'll see hundreds of tips all over the place as to what to put in them. I spent a couple of days a while back consolidating every idea I found out there in the ether with my own ideas, and the result was a very long form with all sorts of interesting things I could fill out for each of my characters.

Of course there are different types of characters. You've got your main characters, which in my case are generally synonymous with viewpoint characters. Those are the ones you're most likely to want to go into serious detail about. Then there are secondary characters, which I tend to think of as supporting characters. Some of these might get as much design work as the main characters, but most would have a middling amount. Finally you've got your tertiary characters, which are usually some form of stock character (the impatient taxi driver, the mindless thug, subway rider #3 in the credits). Those might have a couple of physical features and one line of dialogue suggesting a common world view. They might not even have names.

Personally I figured it was best to get everything together, organize it into logical categories, and fill out as much of it as I felt like doing for each character. If a given character ends up needing more, I can fill it in whenever I need to. If I get an idea for a particular characteristic for a certain character, I can fill it in at that time. The idea is that when you write about the character later, or edit a part of the text where the character appears, you can refer to the character sheet later to keep things consistent. Even if you choose to make a change, this tool helps find all the places you've deployed the character and propagate the change across the board as necessary. (I'll explain that part later.)

In practice, I implemented character sheets as a set of refinements to my Scrivener project and the underlying template that I've been developing in parallel for future use. This particular wad of administrative delight manifests as a file in the "Templates" part of the Scrivener tree entitled Character.

In the body of the file I created a series of two-column tables, where the first column is about 1/3 wide and the second is the rest of the width. I tried using one big table, but Scrivener's table manipulation features are not very good and the flexibility sucked. It reduced the amount of work involved in copying a section from the template into other files, in case I were to later think of a better way to do something after basing some actual character sheets on the template. Of course this has since happened many times, and is the reason I focused on this for a few days rather than letting it evolve entirely on its own over time.

Each table contains a group of related characteristics. The first column is the name of the characteristic, and the second starts out with examples unless it's totally obvious. Maybe I'll share my character sheet or overall Scrivener template once the book is done and the character sheet therefore fully tested. But without getting into a huge amount of detail right now, some of the groups I used were as follows:

• Role - Character's function in the story. Includes symbolism, archetype, key flaw, that sort of thing.
• Vitals - driver's license type attributes.
• Social Impressions - what other characters think of this character
• Sensual Impressions - what other characters feel about this character
• Action - how the character operates in the action
• Depths - world view, Myers-Briggs type, Enneagram type, and lots of below-the-surface type stuff

Each section contains several specific relevant characteristics.Obviously you'd never want to fill out every blank for any particular character. I tend to fill out somewhere between 75% and 200% of the characteristics I need for a given character, rather than the 1000%-2000% I'd have if I filled out the entire form for every single one.

There's a section in the overall Scrivener project called Reference, and under that is a subtree called Characters. I set the Characters tree to use the Character template as its Default New Subdocument Type (that's in the Documents menu). When I want to define a new character in the project, I just select the Characters subtree and hit the Add/+ button on the toolbar. I name the new document with the character's name, and then fill out as much of the character sheet as I want to.

Next, I wanted a record of where each character appears in the text of the book itself. Scrivener doesn't seem to offer a very good way of linking documents to each other for reference purposes, so I had to use the keywords feature to do a 2-way tie between the Scene Stage files (the main content of the book) and the character sheets. I created a keyword section called CHARACTERS and a keyword in that section for each character, named the same as their respective character sheets. Then I linked the keyword to the corresponding character sheet.

Finally I linked both the keyword section and the keyword for each character to each Scene Stage document that contained the characters. This is a lot of work in a complex project but it's not that bad, and it becomes really easy to build collections (saved searches) that will show you all the documents in which a given character appears. This gives you the fairly unique opportunity to read any character's individual story from beginning to end, scene by scene.

Once I'd done this for characters, I found there were a few other types of story world elements it made sense to give forms of their own. I'll talk more about those later.

Self-Publishing Blog: How to Successfully Self-Publish

Self-Publishing Blog: How to Successfully Self-Publish:
The Alliance of Independent Authors site is built around the idea of indie authors banding together, which might sound a little like the Anarchists’ Foundation (or herding cats). There’s good info, here, though: Different sections function as group blogs pertaining to different stages of the writing-to-publication process.

Self-Publishing Blog: Corey's Notebook

Link: Self-Publishing Blog: Corey's Notebook

Corey J. Popp writes on a variety of topics about writing craft and publishing, mixed in with unusually analytical reviews of books and other media.

Self-Publishing Blog: True Knights Blog

Link: Self-Publishing Blog: True Knights Blog

Steven M. Vincent's blog offers an assortment of ideas for writers, and recently has been featuring a string of author interviews. Love that hair!

Writer's Resources: The Writer's Beat

Link: Writer's Resources: The Writer's Beat:

The Writer’s Beat is a high-traffic forum for writers interested in improving the level of their art. In addition to discussion and networking, subforums are in place for reference resources, practical tips and publishing Q&A.

Programming the Brain - a Writer’s Job

Before moving into the new and terrifying world of novelcraft, I spent years working as a software designer and development manager, and years before that as a developer. Along the way, I had numerous articles published in computer magazines. Although that type of writing was relatively technical in nature, it always felt like something fundamentally different from the development work itself.

Later, when I decided to move away from that background in the direction of writing fiction, it seemed at first like a major change. In many ways it has been, of course: completely different knowledge domain, community, that sort of thing. The more time I've spent on it, however, the more I've come to realize that there are at least as many similarities as differences between software creation and the creation of fiction. In particular, I find it interesting that writing fiction has more in common with developing software than it has with writing technically-focused articles.

Let's look at some points of comparison.

In software design, there are several major components that require individual conception and planning. Some examples would be defining the overall purpose of the app (including its boundaries: what it is not), user interface, internal APIs (call it a library of functions for use within your app), the core/engine that keeps things moving along in both foreground and background, add-ons that do specific tasks that are adjunct to the main application, and integrations/connections to other systems.

Planning a novel is very much like this. You've got to establish your theme, outline your plot, do your world-building (establishing the special features and parameters of the story world, especially in sci-fi/fantasy), define and distinguish your characters, weave it all into a narrative with a consistent voice (per viewpoint), and dress it up with theme and emotion. And if you're doing a series or tie-ins with your other books (or someone else's), you have to make sure your book stays consistent with canon and serves larger-scale purposes within the series while remaining able to stand on its own.

User interface aesthetic is very much like the style of a book. The purpose of an app is similar to the theme and messages of a novel. API is like world-building: what supernatural abilities do the characters have access to, and what are their limits within the world? Engine is like the plot, driving things along, and add-ons are like subplots. The overall feel of the app is like the voice of the narrative, and connections between software are like tie-ins between books.

On the practical side--the actual process of creating the end product--the similarities are even more obvious. The process of developing a complex program is very much like drafting a novel. In both cases, the old joke holds true: How do you sculpt a horse? Chip away everything that doesn't look like a horse. You create in bursts, then smooth the rough edges through iterative debugging/optimization/editing. There are area-specific skills involved in both cases. Both spheres are served by standards that evolve over time, conventions you can choose to use or ignore but that will probably help your product gain acceptance if you at least acknowledge them...unless you're the one who sets a new standard, as we see from time to time in both fields.

Programmers and writers even use similar tools these days. As one of my favorite writers, Charles Stross, pointed out on his own blog, Scrivener is basically a development environment for writers. The parallels are clear: the complex IDE's modern programmers use to build their apps include source code control (the equivalent of snapshots in Scrivener) for many small fragments of code (scenes/scene stages); an outliner to manage all the pieces; and in-line and after-the-fact syntax-checking (much like spell and grammer-checking). In software development, the final result is generated by a compiler. Scrivener is no different: its compiler takes your myriad part and chapter folders, scene (or scene stage) documents, and merges them with the formatting settings you've specified to result in a finished mobi/ePub/PDF ebook, a PoD-compatible book, or your choice of any number of other formats.

Even marketing and distribution are much the same nowadays. Most of the apps people buy these days come out of app stores on Apple, Amazon and a few other centralized markets. Of course ebookstores are very similar, having evolved nearly at the same time for overlapping market communities. In both cases you're going to either download the final result or get it mailed to you on physical media (DVD/print-on-demand book). If you want your app/indie published book to sell, you have to do a lot of the same things: tirelessly promote your product's distinctive features, arrange for reviews as best you can, buy web ads. And in both cases, it will always be easier to sell the sequel than the original, once you've established your brand.

Most working writers are just as aware as software developers that they're creating an experience for their customers. More than one writer has made this observation in print. Readers know it too: that thrill-ride sensation you get from a page-turning action sequence or climax, or the secondhand but nonetheless genuine emotion evoked by a good plot twist or heroic sacrifice. I've experienced it myself any number of times, and so have you: a book is an experience, designed for the purposes of entertainment and education. Of course, nowhere are the parallels more prevalent than in video games, where the two media have been meeting and colliding for decades now.

So if you're a writer, you're a programmer too. The computer you're programming is the human brain...or the human heart/spirit, if you want to get mushy about it. Perhaps this can help us to understand one of the greatest mysteries of our time. Why are zombies always going after brains? Some say it's because of the essential vitamins and minerals, but I'll go on record with a theory of my own. With all those juicy ideas and emotions bouncing around in there, and our endless capacity for cramming in more and more...the real surprise would be if they went for the rump roast instead.