Books of Mars

Having finished up the big April projects, one of the main things I want to get accomplished this month is getting the on-demand version of the Moving From Idea to Draft online writing class up along with the existing on-demand classes.

This has proven a somewhat monumental task, because the needs of the on-demand version are very different than those of the live class. In the live workshops, which are limited to eight students, everyone comes in with a two-three sentence description of their idea, and we work from there, adapting the material to what they’ve brought into class.

For the on-demand version, I started by trying to identify all the different ways there are into a story, a number that fluctuates in the realm of two dozen, depending on how finely I want to draw distinctions.

What I’ve done with each possible path is identify what it is, what it gives you as a starting point, things you will want to consider, possible pitfalls, next steps for fleshing it out, and a set of exercises (with basic and overachievers’ versions) to help explore the starting point. I finish, in what I am still worried may be an excessively egotistic move, by providing a story of mine that started in that way and some notes on its development from the starting point.

Here’s a recently finished example from the section on beginning with various fragments, specifically where to go when all you have is a scene and you’re not sure where it goes in the story (as opposed to knowing the beginning or ending of the story, which I cover separately).

What it is:

A scene is usually a moment in time that has come to you. It usually has strong visual elements, and something is usually happening, such as a battle, or has just happened in it (a battlefield after the fighting is done). It is probably something that would appear at a significant moment of a story and not be peripheral to it.

What it gives you:

• Everything but the plot. But actually, that’s not true. What is the main source of tension in the scene, what is the conflict that is driving things? That is probably a version of the overall plot.
• A scene gives you a strong slice of the world and all that is implicit in that, including history and culture.
• If characters are included in your scene, they are usually doing or have just done something more purposeful than just milling about. You have some sense of their occupation, their economic circumstances, and often some nuances of their relationship.

What you need to think about:

• Why would this scene matter? As noted earlier, it’s something that is significant to the story. Does it appear near the beginning and spark things into motion, or does it appear at the end and sum up the action of the story?
• What are the circumstances behind the scene? If it’s a visual splendor, there is usually some technology or magic underlying it and creating it.
• What is the context in which it’s being viewed? Who is seeing it and why are they there?
• What is striking about the image to you and how can you best convey that to a reader?

Possible pitfalls:

• Is your scene just some sort of natural vista? That’s going to be hard to develop something from. In that case, think about what might make that vista unusual or unexpected.
• Make it more than just a pretty picture. Something has to happen in a story and moments where there is just description slow narrative down drastically. If the camera is lingering on something, make it something riveting. Use interesting and lively verbs as well as paying attention to sentence length and paragraphing in order to counteract the slowing of the motion.

Possible next steps:

• Consider the viewpoint. Who is seeing the scene? What is their relationship to it? What do they know about it and what questions do they have about it?
• Write the accompanying dialogue. What’s being said in the scene, and why does it matter? Who is speaking and why?
• The moment may be brief or extended; generally the longer it lasts, the more it gives you. Think about what happens immediately before and after the scene that you have; should some of that be included in the story?

Exercises:

1. Sometimes it’s helpful to expand the idea of the visual. How might you convey this scene in a graphic novel? Write it out as though it were a script. Overachievers: Write the entire story this way.
2. Describe same scene with two different moods, preferably ones as different from each other as they can be, such as a joyous description of the scene versus a saddened or enraged one. Overachievers: Expand to 3-4 moods and/or combine several moods in a single description.
3. Construct a mirror scene, a second scene in which many elements of the first are repeated, but different actions take place. Overachievers: Figure out where in the story your scene takes place and put your scene in a spot that would balance it in the story. For example, if your story is at the beginning, create one at the end, or vice versa. (If it falls in the middle, create something at either the beginning or end, but contemplate making the task even more complicated by doing both.)

Case study: Magnificent Pigs

For me the story “Magnificent Pigs” began with an image of its final scene, with the pigs flying away bearing Jilly’s bed into the night. Once I had that, I knew she was important, but also that she was not the protagonist. That would be whoever was watching her fly away into the night, which turned out to be her brother.

“Magnificent Pigs” is a good example of how, once you have a scene, you can begin to accrete details that flesh the story out. I had read about a recent art project that involved tattooing pigs; this became the way that they acquire their wings. A trip to the tattoo parlor with my friend Kris, who was getting a tattoo, lent some details for verisimilitude, and on the way back as we were discussing the story, she told me the anecdote about her mother telling her Charlotte was always alive in the book in order to console her (and gave me permission to use it in the story). To me, that’s a lovely little note, because of course it has a parallel — Jilly will also always be alive in the story.

This is an early story, which appeared in Strange Horizons, and was one of my SFWA qualifying sales. It appeared in audio form on Podcastle and inspired one of my favorite reviews, in which the reviewer talks about driving along with tears streaming down their face because they were listening to this story. That’s a heady thing for a writer and remains something I cherish.

Later edit: the class is now done and available online! Find it here.

#mc_embed_signup{background:#fff; clear:left; font:14px Helvetica,Arial,sans-serif; }
/* Add your own MailChimp form style overrides in your site stylesheet or in this style block.
We recommend moving this block and the preceding CSS link to the HEAD of your HTML file. */

This article originally appeared in the now-defunct online magazine Imaginary Realities. It talks about MUD administration, and draws on my experience working with Armageddon MUD, the world of Zalanthas. For those who don’t know what a MUD is, it’s a text-based roleplaying game. Here’s the wikipedia article on MUDs.

One of the sad truths of the mud world is that there are never enough coders. Builders aplenty, brimming with fresh idealism and plans for entire zones, appear (and sometimes disappear) at the drop of a hat. But coders are the unicorns of the mudding world, seldom glimpsed and ardently pursued. We are lucky enough to have three dedicated coders on Armageddon MUD: Morgenes, Tenebrius and Tiernan, as well as a few other staff members willing and able to wade through the bugs file and tinker with things upon occasion. How, then, does an administrator keep these rare beasts happy? The following four steps may help.

1) Communicate: When asking for new code, try to let the coders know exactly what is desired. For example, instead of ‘Let’s make archery more complicated,” a staff member might propose “Let’s put a range on archery, so the farther away the target is, the harder it is to shoot it.” A full description of the the idea, perhaps including examples, such as fake logs showing what the idea will look like when being used, helps make sure the originator of the idea and the coder are on the same track as far as things like syntax and usage are concerned.

The same holds true for bugs. Describing how it’s supposed to work as well to how it’s working right now helps clarify ideas. Coders want to know if the bug is REALLY a bug, or something being reported because it doesn’t work as the reporter feels it should.

With bugs, give the coders as much information as possible, including how to reproduce the bug. Examples by way of logs are great, and if they include some form of error message (or message that they’re getting that shows it’s an error), it often allows the coder to track down what section of the code needs to be worked on.

Make sure people aren’t bumping into each other. On Armageddon, we’ve got a coder’s board, where people post changes as they make them. This alerts fellow team members to what they’re doing and is also helpful if unexpected bugs crop up, enabling people to track exactly what got changed and when. Two people should not be working on the same idea at once unless they know it, and can divvy up the work accordingly.

2) Have a purpose: Will it get used? Is it something players are asking for? This one is a matter of ego, but we’re all human and we all do have egos. Seeing their work getting used, regularly and as envisioned, is a reward beyond any thanks or congratulations other staff members can give a coder. Track player requests, through entries in the bugs/ideas/typos files as well as emails to the account and posts on the general discussion board in order to convince a coder that the players want, and will use, something.

Generally, with new ideas figure out how they are moving towards some goal. A piece of code like a new skill is going to sound more interesting if it fits into some overall purpose, such as a master plan of non-combat related skills for the economy than it would if it is just a random idea. You are also going to end up getting more out of the idea if it is part of a greater whole.

Make it innovative. Some coders like to be trail breakers, to feel that they’re not just playing catch-up with another mud, but are creating ideas and concepts new to the mud community. Some ideas get requested to ‘balance’ things out between groups: guilds, or races, or mount speed. When a coder starts to feel like the code they’re doing that day only works to nullify a change made last week, then they’re going to start wondering what they will be asked to implement tomorrow.

3) Share the work: Do as much of the grunt work as you can for the coders, including helping thoroughly test, providing help files and documentation, and fleshing things out. In testing, give coders information about what is not working and how to recreate the result. Be precise about what needs to be changed: not ‘the plague of locusts spell needs to do more damage’, but ‘it needs to do about twice the damage it is now.’ When something requires a new help file or modification of an existing help file, do not expect the coder to do it, but supply it yourself. If it is something that requires building, provide the items. Teamwork of this kind, when it is working well, is terrific, and will often produce amazingly cool results.

4) Appreciate: Good coders can never be praised sufficiently. We try to make sure that players know who is responsible for new and interesting changes, by posting information about them in the news as well as in our weekly update, which is a mailing our players can subscribe to, which provides information about changes, staff and world news, upcoming recommended playing times, etc. When players write in with compliments or feedback on a code change, make sure that the note gets passed along to the person , as well as that the coder knows how cool or slick you think the ideas they have implemented are as well.

There is a tendency sometimes to regard coders as resources that spit out code at request. But the fact of the matter is that treating coders in that way will frustrate both sides, leading coders to become discouraged and unmotivated to implement new ideas and builders to feel that their coding needs are not being met. These four points may help avoid such frustration.

This article originally appeared in the April 2001 issue of Imaginary Realities.
© 2002 Cat Rambo. All rights reserved.