One of the things I’ve decided to do over the next six months is release a number of my stories in small mini-collections in electronic form. Each of these will consist of 2-3 already published stories, with 1-2 ones original to the collection. The first is Halloween Quartet, which contains “Whose Face This Is I Do Not Know” (appeared originally in Clarkesworld), “Niobe in the Rain” (appeared originally in Serpentarius), “So Glad We Had This Time Together” (appeared originally in Apex Digest), and “Pumpkin Knight,” which is original to the collection.
The next one will be Desert Quartet, which will contain “Aquila’s Ring,” (originally appeared in Light and Shadow II), “Karaluvian Fale” (appeared originally in Giganotasaurus), “Her Eyes Like Sky and Coal and Moonlight” (the title story from my second collection), and “Mirabai the Twice-Lived,” which is original to that collection. It’ll also contain an essay about the world in which all of those stories are set, that of Armageddon MUD, and my experience working with it.
Other e-projects in the works: a mini-collection of flash, a mini-collection of superhero stories, and something collecting blog musings about fiction.
Why do this? Because I do think electronic publishing is clearly the way the industry is going. I’m curious about the power to sell one’s work that it promises the author and I’d like to get in on what seems to be at least the first or second, if not ground, floor of the movement.
I’m lucky in that I have a little bit of a name, acquired through publishing short stories. I don’t know that this would work for someone with no already established platform. And I don’t expect to make a vast sum of money from them. But I do expect there to be a slow trickle. At least – that’s my hope.
How will I spread the word of them? I’ve learned a little from publicizing Near + Far, but I’m not sure how relentless I want to be about pushing these. I’ll certainly talk about the experience of putting them together on here, and will be mentioning them on social networks as well as on my mailing list. Suggestions are welcome, as always 😉
If you want to sign up for that mailing list, by the way, which will come no more than once a month and mention new publications and classes, fill it out here:
Want access to a lively community of writers and readers, free writing classes, co-working sessions, special speakers, weekly writing games, random pictures and MORE for as little as $2? Check out Cat’s Patreon campaign.
Want to get some new fiction? Support my Patreon campaign.
"(On the writing F&SF workshop) Wanted to crow and say thanks: the first story I wrote after taking your class was my very first sale. Coincidence? nah….thanks so much."
~K. Richardson
You may also like...
Using SFWA Effectively for Book Publicity
People sometimes ask whether or not the membership fee for the Science Fiction & Fantasy Writers of America is worth it. I think it is, but mileage will vary. That mileage is certainly dependent on how effectively you use it. So here’s a sample action plan I’m putting together for my next book.
4-6 months ahead of time
Look to see what upcoming events, such as local reading series, conferences, and conventions work with your schedule. For example, if your book were being released in May, you might want to supply some ARCs for the Nebula Conference swag bags. Or if you’re in the Pacific Northwest area, you might contact the local organizers of the readings series in order to set up a reading.
Look at the SFWA boards to see if there’s any upcoming cooperative efforts you might become part of, or propose your own, along the lines of “Hey, I’ve got a book coming out on this date, anyone else got something coming out around then that wants to coordinate publicity?
If you’re doing that cooperative effort, make sure all your items are lined up!
The day of the release
Make sure you say something on your personal thread in the Discussion Forums so people know to spread the word! Give them as many resources to do so as you can, such as supplying a graphic or a pre-composed tweet.
Tag @SFWA in a tweet or two to get them to RT it.
After the release
Keep an eye open for the next SFWA Storybundle; they appear every six months or so.
Make sure there are copies in .mobi, .epub, and .pdf forms in the appropriate forums on the discussion boards if you want members to be able to read it when thinking about making Nebula nominations.
Coders can seem like odd creatures sometimes. Under that ladybug costume, though, they're as human as you or I.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.
One of the things I’ve decided to do over the next six months is release a number of my stories in small mini-collections in electronic form. Each of these will consist of 2-3 already published stories, with 1-2 ones original to the collection. The first is Halloween Quartet, which contains “Whose Face This Is I Do Not Know” (appeared originally in Clarkesworld), “Niobe in the Rain” (appeared originally in Serpentarius), “So Glad We Had This Time Together” (appeared originally in Apex Digest), and “Pumpkin Knight,” which is original to the collection.
