I've been reading Story Engineering by Larry Brooks. The book is extremely practical and I highly recommend it for any and all would-be authors. It talks about his six core competencies of successful storytelling.
Recently, I was rereading The Snowflake Method of Story Design by Randy Ingermanson and thinking about how the two fit together. A key point that Mr. Brooks makes is that the information he provides is not new, and it is the same sort of thing all other writing advice talks about -- but most other writing advice doesn't mention the whole picture.
So the Snowflake method has nine (or ten -- but Mr. Ingermanson doesn't do the tenth step anymore) steps. Here are how they relate to the terms Mr. Brooks uses:
1. Write a killer concept. Concept is one of Mr. Brooks "core competencies of story-telling." He has a lot of articles about concept, as it is very important to get right.
The recommendations for the wording between the two descriptions are significantly different. Mr. Brooks recommends phrasing it as a "what if?" question. Mr. Ingermanson recommends a one sentence summary no longer than fifteen words. The underlying meaning is the same: This is the most abstract representation of the story, and in exploring this we get the entire story.
2. Expand the concept in to the five key moments: opening, first plot point, midpoint, second plot point, ending. These are key transition points in Larry Brooks' story structure. His story structure is based upon a four act design. (Which is the same as a three act design with the second act split down the middle.) The opening is act 1, the first plot point is the transition between act 1 and act 2. The midpoint is the transition between act 2 and act 3. The second plot point is the transition between act 3 and act 4. The ending is act 4.
At this point each of these five key moments should be just a sentence. Mr. Ingermanson uses paragraph form, but I prefer a list.
It is important to note that Mr. Ingermanson uses a traditional three act structure with the setup, three disasters and an ending for this step. These "disasters" map directly to (and are placed so as to exactly align with) Mr. Brooks' first plot point, midpoint, and second plot point. He uses the same structure, but doesn't have an explanation as to why that is the best structure.
3a. Mr. Ingermanson is a big proponent of the idea that character is the most important part of a story. (He's wrong, conflict is the most important part of a story.)
The heavy focus on characterization, means that Mr. Ingermanson is taking care of theme by way of character arc. There is likely to be a clear theme present simply due to the rich characterization, even when it wasn't explicitly defined.
You need to know your theme. Some concepts are instantly thematic on their own, others less so. In some cases a theme is implied by character background, setting, etc.
3b. For your main characters (at least the protagonist and antagonist) you need to start working on characterization. The character's development through her or his character arc changes as the act of the overall story moves along. You want to write three-dimensional characters but don't go overboard. It is okay to have one-dimensional minor characters.
To map with Mr. Ingermanson's snowflake design, you need enough characterization that you know the conflict each main character will be facing (inner and external) and can develop a short description of the character arc for the main characters. The characterization details can -- and should -- be brief at this point as we'll come back to fill them in later.
4. Take the five key moments written in step 2, and rough out one paragraph descriptions of each of the four acts. (The second through the fifth key moment goes -- perhaps in an enhanced form -- at the end of each of the four paragraphs. The first key moment can disappear in to the first paragraph.)
5. Go back to your characterization information and add more details. Fill more in. Add a richer back-story and a more detailed character arc. At this point a brief description of the character's arc can be expanded to four sentences describing what will happen in each of the four acts of the book.
Mr. Ingermanson recommends a page for main characters and a half-page for other important characters.
6. Now take each of the four paragraphs you wrote in step 4 and expand each out to a full page. With knowledge of character arc, you can include subplots and points of characterization.
7. Go back to your characterization information and fill out any/all additional information.
8. Take the four page synopsis created in step 6, and turn it in to a beat sheet.
Mr. Ingermanson strongly recommends a spreadsheet. Mr. Brooks does not particularly recommend a spreadsheet. (His provided blank sample is a simple list.)
Conclusion:
Mr. Ingermanson uses different language when he talks about the concept in step 1. The specific recommendations about the language are different, but the meaning of the words are the same. In both cases it is a concise description which, when explored leads to the story. The other big difference is Mr. Ingermanson doesn't mention theme at all. Reading Mr. Brooks' advice on theme, it is clear that Mr. Ingermanson is implicitly covering theme. He may not be explicitly defining it, but if you looked for it in Mr. Ingermanson's works you would probably be able to find it.
The overlap is extensive. There is only one omission (theme) and it's the one that Mr. Brooks describes as something you don't need to actively concentrate on: if you use thematic elements it takes care of itself. You only need to be aware of it in as much as you can only steer the theme if you have a place to steer it toward. The rich characterization advocated by Mr. Ingermanson would pull in thematic elements for characters even when they were not inherent in the plot or setting.
The four that mostly overlap are the "elemental" core competencies: concept, theme, character, and structure. The last two that Mr. Brooks has are "executional" and are scene construction and writing voice. The executional competencies mean that none of the elemental competencies by-pass the need for well written prose. Mr. Brooks is very clear in that you need to master all six to get your novel published.
Monday, January 23, 2012
Wednesday, January 4, 2012
DRM doesn't work and annoys readers
Is your book only available in the US Amazon store? If so, it uses DRM to prevent customers in other parts of the world from reading your book. The DRM won't work and may drive potential readers to piracy.
DRM (digital restrictions management) restricts readers ability to read your book in all regions of the world, and prevents legal fair-use. (Such fair-use may even be for reviews and fan sites -- things you may want to encourage.) With region-based restrictions it can mean it is faster and easier to import a used physical copy of a book from overseas than it is to get a legal electronic copy -- even though international shipping can be quite expensive. If it is faster and cheaper for someone to buy it illegally the chances are they will do so. With copy-and-paste it is something that is quite legal (under fair-use) with physical books, but it is considered theft when it is done with an eBook.
The problem is that for people who actually want to steal an eBook DRM is an inconvenience at worst. Do you want to know how easy it is?
Google the following things:
This is on-par with real DVD pirates using analog techniques to copy DVDs instead of violating the DRM. (They make exact copies of the pits on the disc -- much like they used to pirate LPs.) The DRM is a non-issue to folks actually committed to piracy. It only impacts law-abiding citizens.
To be explicit: I do not support or approve of violating current laws. The list of Google terms was provided as an example of how the reliance on DRM software is flawed. I will not help you with any questions about violating copyright law, and I will instead forward any such emails to the FBI.
Oh, and if you think that it is possible for the operating system to do something about this, I have two more terms for you to Google: "digital camera" and "tripod".
The only way to prevent illegal distribution is to not distribute it at all. Even then it isn't reliable. That said, when things are priced right and have good service associated with legitimate purchase it isn't viable to pirate.
In particular, your English-language book should be available world-wide to all readers of English. Make it easy and affordable to buy across the globe and few people will bother with piracy.
DRM (digital restrictions management) restricts readers ability to read your book in all regions of the world, and prevents legal fair-use. (Such fair-use may even be for reviews and fan sites -- things you may want to encourage.) With region-based restrictions it can mean it is faster and easier to import a used physical copy of a book from overseas than it is to get a legal electronic copy -- even though international shipping can be quite expensive. If it is faster and cheaper for someone to buy it illegally the chances are they will do so. With copy-and-paste it is something that is quite legal (under fair-use) with physical books, but it is considered theft when it is done with an eBook.
The problem is that for people who actually want to steal an eBook DRM is an inconvenience at worst. Do you want to know how easy it is?
Google the following things:
- "keyboard mouse recorder"
- "screen shot keyboard shortcut"
- "batch processing images"
- "OCR software"
This is on-par with real DVD pirates using analog techniques to copy DVDs instead of violating the DRM. (They make exact copies of the pits on the disc -- much like they used to pirate LPs.) The DRM is a non-issue to folks actually committed to piracy. It only impacts law-abiding citizens.
To be explicit: I do not support or approve of violating current laws. The list of Google terms was provided as an example of how the reliance on DRM software is flawed. I will not help you with any questions about violating copyright law, and I will instead forward any such emails to the FBI.
Oh, and if you think that it is possible for the operating system to do something about this, I have two more terms for you to Google: "digital camera" and "tripod".
The only way to prevent illegal distribution is to not distribute it at all. Even then it isn't reliable. That said, when things are priced right and have good service associated with legitimate purchase it isn't viable to pirate.
In particular, your English-language book should be available world-wide to all readers of English. Make it easy and affordable to buy across the globe and few people will bother with piracy.
Monday, January 2, 2012
A general purpose writing tracker
I've written a general-purpose writing tracker. (You know, because I'm masterful at procrastinating.)
It is designed for a single project, but it will work with any number of days and any number of words. You can either specify an end-date or you can specify the number of days. You can also specify a "Daily Bonus Goal" to clarify that you're really hoping to write more than the minimum required every day. (You know, to support bad word-count days and days when family interferes. By default I set this to 333.33 as my daily personal goal is at least 2K words.)
It supports entering word-count both in "words written in session" (incremental) and "words written total" (total) forms. This is specified in the "Word Count Mode" setting.
It allows you to keep track of the time you write, so you can see how fast you write. You enter the start and end times and it figures out how long you were writing. (These support starting at 10pm and ending at 2am -- and it correctly marks the duration of 4 hours.) It also has a "more" section that allows you to enter the duration directly in hours -- the idea is that it would primarily be used when you have more than two writing sessions a day and you'd use it by migrating the duration/word count information to the "more" section (so even then you never need to calculate how long you were writing).
https://docs.google.com/spreadsheet/ccc?key=0Am6TqLoUVuS7dFhNQlhRYS1tdElob18wLS1JWXBVU3c
It has a functional chart, showing where you are at, where you should be, if you met your daily bonus goal every day where you would be, and the average for your overall rate. During the month of NaNo (or Camp NaNo) the number of data-points on the graph will increase as more days are added to the chart. If a day hasn't happened yet, it doesn't show on the chart.
Unfortunately, the chart doesn't work on my Android phone, but the document itself does. This is the benefit of using a Google document.
The number of rows expands based upon the day. If the project hasn't started only the first row will be shown. To get a feel for it, tweak the start date to something two weeks ago -- you'll see a lot of things auto-populate when that happens. The last entry in the list is typically the one you want to edit.
It has a few computed fields that don't show up until a project has been started.
I do just use the default number of rows (100) so if you're going to need more than 90 days, you'll need to tweak some things. This should more than fit most people's needs. If you're tracking a whole year, the changes should be straight-forward (I hope).
It was inspired by the "NaNoWriMo Word Count Tracker" from http://particulars.laurensoffer.com/wordcount-tracker/ (An XSL file which also has the capacity to track morale. -- I don't track my morale because when I'm writing I am always in a good mood.)
I've thought about writing a version that could be added to using a Google Form. I started on it, but I've lost interest -- probably because I'll never actually use it.
It is designed for a single project, but it will work with any number of days and any number of words. You can either specify an end-date or you can specify the number of days. You can also specify a "Daily Bonus Goal" to clarify that you're really hoping to write more than the minimum required every day. (You know, to support bad word-count days and days when family interferes. By default I set this to 333.33 as my daily personal goal is at least 2K words.)
It supports entering word-count both in "words written in session" (incremental) and "words written total" (total) forms. This is specified in the "Word Count Mode" setting.
It allows you to keep track of the time you write, so you can see how fast you write. You enter the start and end times and it figures out how long you were writing. (These support starting at 10pm and ending at 2am -- and it correctly marks the duration of 4 hours.) It also has a "more" section that allows you to enter the duration directly in hours -- the idea is that it would primarily be used when you have more than two writing sessions a day and you'd use it by migrating the duration/word count information to the "more" section (so even then you never need to calculate how long you were writing).
https://docs.google.com/spreadsheet/ccc?key=0Am6TqLoUVuS7dFhNQlhRYS1tdElob18wLS1JWXBVU3c
It has a functional chart, showing where you are at, where you should be, if you met your daily bonus goal every day where you would be, and the average for your overall rate. During the month of NaNo (or Camp NaNo) the number of data-points on the graph will increase as more days are added to the chart. If a day hasn't happened yet, it doesn't show on the chart.
Unfortunately, the chart doesn't work on my Android phone, but the document itself does. This is the benefit of using a Google document.
The number of rows expands based upon the day. If the project hasn't started only the first row will be shown. To get a feel for it, tweak the start date to something two weeks ago -- you'll see a lot of things auto-populate when that happens. The last entry in the list is typically the one you want to edit.
It has a few computed fields that don't show up until a project has been started.
I do just use the default number of rows (100) so if you're going to need more than 90 days, you'll need to tweak some things. This should more than fit most people's needs. If you're tracking a whole year, the changes should be straight-forward (I hope).
It was inspired by the "NaNoWriMo Word Count Tracker" from http://particulars.laurensoffer.com/wordcount-tracker/ (An XSL file which also has the capacity to track morale. -- I don't track my morale because when I'm writing I am always in a good mood.)
I've thought about writing a version that could be added to using a Google Form. I started on it, but I've lost interest -- probably because I'll never actually use it.
Sunday, December 11, 2011
Examples of professional story design
During a recent bout of procrastination from finishing and editing my current novel, I found myself listening to music from old Sierra adventure games. (It appears Quest Studios is the place to go to get copies of the music from the Sierra games.) I played a number of the Sierra games back in the day, so -- in my procrastination-heady state -- I was interested in finding old scores. That led me, inextricably, to Al Lowe's Humor Site.
Al Lowe was responsible for the Leisure Suit Larry series of "adult" adventure games. He was at Sierra for quite a long period of time, and had his hand in all of the Leisure Suit Larry games (there were seven titles in the adventure game series).
This, by itself, wouldn't have been enough to cause me to post. The thing is, he has made available the game design documents for some of his games.
I was looking at the design documents for "Freddy Pharkas, Frontier Pharmacist" and the similarities between the design of this game and the design of a story really stood out. From the plot synopsis (four act) to the section of the document titled "Story Structure," to the character descriptions and the "Walkthrough" which reads like an abbreviated story in itself. (Shoot, even the scene-by-scene break-down is something that maps to what some folks do for novels.)
Having not seen real story design documents -- except for my own attempts -- it seemed quite interesting. Larry Brooks -- the Story Fix guy -- talks about seeing story structure in things other than just books. (He specifically talks about movies, but here the structure is literally wide open to look at.) It seems unlikely that I'll ever get a chance to see design documents for real professional quality books, but this... It was a high-quality game made by experienced professionals.
You also have to remember that even click-based adventure games are really far more story driven than many types of games. The older brother of this type of game being the text-based adventure games -- a subgenre currently known as "interactive fiction."
As I said, I found it interesting.
Al Lowe was responsible for the Leisure Suit Larry series of "adult" adventure games. He was at Sierra for quite a long period of time, and had his hand in all of the Leisure Suit Larry games (there were seven titles in the adventure game series).
This, by itself, wouldn't have been enough to cause me to post. The thing is, he has made available the game design documents for some of his games.
I was looking at the design documents for "Freddy Pharkas, Frontier Pharmacist" and the similarities between the design of this game and the design of a story really stood out. From the plot synopsis (four act) to the section of the document titled "Story Structure," to the character descriptions and the "Walkthrough" which reads like an abbreviated story in itself. (Shoot, even the scene-by-scene break-down is something that maps to what some folks do for novels.)
Having not seen real story design documents -- except for my own attempts -- it seemed quite interesting. Larry Brooks -- the Story Fix guy -- talks about seeing story structure in things other than just books. (He specifically talks about movies, but here the structure is literally wide open to look at.) It seems unlikely that I'll ever get a chance to see design documents for real professional quality books, but this... It was a high-quality game made by experienced professionals.
You also have to remember that even click-based adventure games are really far more story driven than many types of games. The older brother of this type of game being the text-based adventure games -- a subgenre currently known as "interactive fiction."
As I said, I found it interesting.
Tuesday, August 31, 2010
Why authors should future-proof their notes
[Originally hosted on my tech blog prior to NaNoWriMo 2010. It has been moved here as it is writing related.]
So, I explored using OneNote to take notes for my novel. I concluded with the realization that if OneNote can not maintain compatibility with templates hosted on the official site between versions, there is no hope for any notes I take to be readable if I later upgraded.
While the integration with Windows (and MSIE) is nice, and might be beneficial in terms of research, once that research is compiled the result should be something portable and yet still modifiable. So, I may plumb the depths of the Internet with OneNote at my side, but before I move on to writing my novel, I will have converted my research in to plain-text documents.
Plain-text documents are one of the only ways to future-proof your writing. As a writer, you need to think about the future. If you're working on ideas for a new novel you may sketch out ideas for a number of different novels before you decide on the idea to use for the current project. If the sketches are written in a proprietary word-processing format you may find that in 10 years time you have no programs that can access the older documents.
Now, you might be saying to yourself, "I don't care if I don't have access to my notes from 10 years ago. Any of my ideas from then will be so out-dated I should just use a new idea." That's well and good, and is a valid perspective on the matter. There is one problem with it: Sequels. Right now you may be plotting six different major stories that don't overlap in any way. However, if one of those stories sells well, you could be asked to write sequels.
One huge example of this is the fact that Isaac Asimov wrote the Prequel to the Foundation decades after writing the original trilogy. More than that, within a few years he wound up writing books that took place both before and after the original trilogy. With modern computers and proper backups you can easily store backups of both your stories, your outlines, and your research. The expected life-span of a typical CD/DVD is only 10 years, so every so often you need to make new backups, but these backups are only useful if you have software that can read them in the future.
Already recent versions of Microsoft Office don't support as many of the older file formats of Microsoft Office as OpenOffice.org. Microsoft forced through a file standard in an attempt to gain acceptance, though there are massive things missing when it comes to how to deal with many files in their misnamed "OpenXML" file format. To go on their track record, it will be a long-shot as to whether they support any of their current file-formats ten or twenty years from now.
Then you have the second problem. When when file formats are "supported" you rarely see full format retention. Things are usually a little off if you're not dealing with the primary file format. This means that whatever formatting work you do today will be wasted in the future. You are just wasting your time.
The solution, then, is to file format that will work in the future regardless of what system or applications may occur. The safest format is plain-text using with either US-ASCII or UTF-8 encoding.
In recent years there have been a number of file-formats which use plain-text files incorporating certain unobtrusive light-weight markup. These files are easily read by humans and still able to be read by the computer and turned in to prettier formats. WikiText usually falls in to this category, though reStructuredText and MarkDown both have explicit support for converting the files to other formats., though I know others also exist.
I am not advocating the use of a particular light-weight markup, only that you consider using one. In my next post I'll be showing an example of a template for use with the Snowflake Method using reStructuredText. This example will look like plain-text because it is plain-text.
Worst case, I can directly read the text-file by any plain-text editor or word-processor in the future. Best case, whatever tool I use in the future may have direct support for reStructuredText. Now, though, I can convert it to whatever format I need (or whatever format other folks need from me).
[Instead of a separate post, the original reStructuredText (.txt) template is available as well as a rich-text version that was uploaded to Google Docs.]
So, I explored using OneNote to take notes for my novel. I concluded with the realization that if OneNote can not maintain compatibility with templates hosted on the official site between versions, there is no hope for any notes I take to be readable if I later upgraded.
While the integration with Windows (and MSIE) is nice, and might be beneficial in terms of research, once that research is compiled the result should be something portable and yet still modifiable. So, I may plumb the depths of the Internet with OneNote at my side, but before I move on to writing my novel, I will have converted my research in to plain-text documents.
Plain-text documents are one of the only ways to future-proof your writing. As a writer, you need to think about the future. If you're working on ideas for a new novel you may sketch out ideas for a number of different novels before you decide on the idea to use for the current project. If the sketches are written in a proprietary word-processing format you may find that in 10 years time you have no programs that can access the older documents.
Now, you might be saying to yourself, "I don't care if I don't have access to my notes from 10 years ago. Any of my ideas from then will be so out-dated I should just use a new idea." That's well and good, and is a valid perspective on the matter. There is one problem with it: Sequels. Right now you may be plotting six different major stories that don't overlap in any way. However, if one of those stories sells well, you could be asked to write sequels.
One huge example of this is the fact that Isaac Asimov wrote the Prequel to the Foundation decades after writing the original trilogy. More than that, within a few years he wound up writing books that took place both before and after the original trilogy. With modern computers and proper backups you can easily store backups of both your stories, your outlines, and your research. The expected life-span of a typical CD/DVD is only 10 years, so every so often you need to make new backups, but these backups are only useful if you have software that can read them in the future.
Already recent versions of Microsoft Office don't support as many of the older file formats of Microsoft Office as OpenOffice.org. Microsoft forced through a file standard in an attempt to gain acceptance, though there are massive things missing when it comes to how to deal with many files in their misnamed "OpenXML" file format. To go on their track record, it will be a long-shot as to whether they support any of their current file-formats ten or twenty years from now.
Then you have the second problem. When when file formats are "supported" you rarely see full format retention. Things are usually a little off if you're not dealing with the primary file format. This means that whatever formatting work you do today will be wasted in the future. You are just wasting your time.
The solution, then, is to file format that will work in the future regardless of what system or applications may occur. The safest format is plain-text using with either US-ASCII or UTF-8 encoding.
In recent years there have been a number of file-formats which use plain-text files incorporating certain unobtrusive light-weight markup. These files are easily read by humans and still able to be read by the computer and turned in to prettier formats. WikiText usually falls in to this category, though reStructuredText and MarkDown both have explicit support for converting the files to other formats., though I know others also exist.
I am not advocating the use of a particular light-weight markup, only that you consider using one. In my next post I'll be showing an example of a template for use with the Snowflake Method using reStructuredText. This example will look like plain-text because it is plain-text.
Worst case, I can directly read the text-file by any plain-text editor or word-processor in the future. Best case, whatever tool I use in the future may have direct support for reStructuredText. Now, though, I can convert it to whatever format I need (or whatever format other folks need from me).
[Instead of a separate post, the original reStructuredText (.txt) template is available as well as a rich-text version that was uploaded to Google Docs.]
Subscribe to:
Comments (Atom)