I've previously mentioned the benefits of using future-safe notes.
On the desktop-side, I've been using Scrivener. It's a great application and I generally love it. (It stores things using XML and RTF files -- future-proof even if I need to hack together something to get the data from the XML bits.) The problem? I can only use it when I'm at my desktop. With the kids, this means I'm limited in what I can do while I'm away from my desktop.
While I've had good success writing by way of "draft" emails in Gmail on my phone and copying and pasting in to Scrivener, this only works for pounding out my word-count and totally fails when it comes to actually planning what will be written. It worked great for NaNoWriMo, but when it comes to serious planning restructuring it just doesn't work.
I tried EverNote. I had two problems with it: saving a link on my phone was slow (the app is generally slow to load) and it has a lot of features I didn't need. It's a semi-pay application, and the way they charge makes relying on it problematic without paying for it. I had existing tools which covered all other needs except link synchronizing between my phone and my desktop. In the end, I uninstalled it from my phone as it wasn't useful enough for the storage space it occupied.
I recently installed DropBox, and so I've been interested in applications that can make use of it. Link-synchronization using DropBox is easy and fast on my phone. This is particularly the case because I only care about browsing pages on my phone and saving them for future reference on my desktop. It's one-way synchronization and not two-way.
Actually, I installed DropBox because I had installed Ema Personal Wiki. It's Windows and Android software that uses Markdown for light-weight text formatting. It defaults to using DropBox to synchronize between the desktop and the phone. It's a little like ikiwiki, but it sacrifices features for a GUI. Unfortunately, Ema doesn't support directories and uses a different syntax for free-links.
Now, I have had Papyrus
installed for some time. It's a super simple plain-text editor. The
thing is -- using Gmail directly was generally more convenient. It's
strictly offline, so copying things to/from Papyrus wasn't convenient. The addition of DropBox on my phone, means that copying things to my desktop got easier. However, if I'm using Markdown elsewhere, it makes sense to upgrade to a MarkDown-based editor.
On my phone, this led to the installation of Writer. It's a Markdown-based editor designed for writing documents -- complete with word-count functionality, and representing the text-formatting as-you-type. (Not quite WYSIWYG, you get things like *italic* and **bold**. Very useful if you find yourself sometimes using Markdown-special characters.) Writer currently has no preferences. It does not synchronize with anything, but there are plans to eventually support DropBox (and other) synchronization.
Compared to Epistle, Writer looks to be a little earlier on in the development process. Epistle -- while it doesn't have support for word-count -- supports DropBox to the point you can specify the folder to use, so you can have it access the same documents as Ema. (It doesn't do anything with the wikilinks.) You can enable "HTML preview of Markdown documents" which will get you a reasonably accurate representation of the rendered Markdown after it is saved -- but editing the document is purely plain-text, unlike Writer.
Of the two, I'm favoring Writer. If it had DropBox support with the capability to specify the DropBox folder, there would be no contest. I'm a little surprised I've not seen a clearly open-source Markdown file editor. (Ema is a personal wiki, not just a file editor. It just presents bare Markdown in a plain-text window. It would be nicer if it did some styling.)
Just a note, though, Papyrus, Writer, Epistle and Ema all load faster than EverNote did. They're all more responsive and more useful for general note-taking. Epistle (alone) supports "sharing" links. It does so with editable descriptions -- like EverNote provided -- except it is a ton faster. This combined with the fact I've the folder set to use my PersonalWiki folder will mean I'll keep Epistle installed for link-preservation if for no other reason.
With regards to ikiwiki...
It's generally awesome. It's a wiki-compiler that can use Markdown as
well many other light-weight formatting languages. It's plug-in based
and already has more features than many competing products. It uses a
real first-class version control system with all the functionality that
goes along with that. It's also written in Perl and has some
expectations of a Unix-like operating system.
If you used Linux or a
Mac, you would get significantly more functionality if you used ikiwiki
instead of Ema. Of course, to make it work with a phone would require a
bit of work to get it to work well with DropBox and your phone-native
Markdown editor. This would be totally doable, mind you. You need only a little more than what Ema already supports to be basically ikiwiki-compatible, and Ema is open-source. Extending it to support [[free-links]] instead of {free-links}, the .mdwn extension instead of the .txt extension, and basic directory support used by ikiwiki should be straight-forward. Most of the other ikiwiki extensions would then be handled by ikiwiki at compile-time.
Anyway, while exploring Ema, and adapting my Magic Door "beat sheet" to a format that Ema could use reasonably (it is where I need to spend some time), it occurred to me that the whole framework I use in Scrivener could be adapted toward a Markdown-based wiki. It would be better in ikiwiki, of course, but it would work in Ema. I'm going to check it out.
To convert the Scrivener notes in to something I can feed to Ema (and to convert back) I'll be using pandoc.
To create the Markdown, I've told Scrivener to export as HTML, then started off telling pandoc to convert from HTML to Markdown. (pandoc can not convert from RTF to Markdown.) The advantage here is that Markdown supports embedded HTML for things that can not be easily encoded in a lighter-weight markup. When the pandoc-generated Markdown looks incorrect, I can copy/paste directly from Scrivener's HTML.
To convert from Markdown to RTF, I'll use pandoc as well as it supports RTF as an output format. The RTF can be easily imported in to Scrivener. Of course, I'll need to verify the conversion works as expected, but the ad-hoc HTML use in Markdown is a key feature, so if that's missing it's really vastly incomplete. (And I'll have to import HTML documents in to Scrivener.)
I may not be using Ema to edit the individual files on the desktop. There are a couple other options for the (Windows) desktop. MarkdownPad is super pretty, but it looks like WriteMonkey totally wins out on features. While they both have basic word-count support, WriteMonkey supports "sprint writing" with count-down timers, a variety of customizable lookups, etc.
This is what I'm thinking so far, at least. I'll be adapting my "empty" Scrivener project with my various sections for novel development in to a set of Ema-linked Markdown-based Wiki-pages. The Ema-style-links can then be machine-converted to be usable for ikiwiki.
Saturday, February 25, 2012
Monday, January 23, 2012
Story design: Snowflake vs. Architecture
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.
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.
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:
Posts (Atom)