Blog Archives

Creating With Mental illness: Prioritizing And Impossibilities

I’ve made no secret of the fact I have multiple mental health challenges, including civilian PTSD and depression. This has been true for my entire nearly-25-year career, and I’ve faced a lot of difficulties as a result. As a ttRPG writer and developer, I deal with deadlines a great deal. As someone who can suffer executive disfunction, the core tasks needed to hit deadlines are sometimes impossible for me. There are days I am literally unable to multitask, plan, organize, and, yeah, prioritize.

If I were smarter, I’d have gotten out of the deadline business. But I am stubborn and strongly, weirdly, dedicated to creating (and trying to promote and improve) tabletop roleplaying games.

Which means over a quarter-century, I have developed some coping mechanisms. None work all the time. Many make only a marginal difference. But deadlines, budgets, projects, and deadlines are often won or lost in the margins. If something lets you average 2,050 words per day rather than 2,000, over 52 five-day workweeks, that’s an extra 13,000-word project done every year.

One of the things I have to deal with is the conflict between prioritizing, and the things at the top of the priority list being impossible. I can’t fix that conflict, even though it happens over and over, but I can work to mitigate its impact. In no particular order (see #2), here are some coping mechanisms

1. Don’t Wait To the Last Moment

Your deadline is 4 weeks away and you think you need 2 weeks to do it? See if you can be done in the first 2 weeks. If yes, then you can get a jump on the next thing, and no mental health issues in that last two weeks can make you late. If not, you at least have a feel for what the project is really going to take, and two more weeks to try to get it done. If you wait until the time needed is the time left, a mental health issue sidelining (or even just slowing) you means you will be late.

It’s also helpful if some issue means you are radically wrong when you estimate how much time you need.

2. Don’t Get Sucked Into Doing Work You Don’t Need To

Making a list of coping mechanisms on your blog? You may be tempted to prioritize them to present them in the best possible order. But if that is taking more thought cycles that just tying them out in any order does, maybe you are making work for yourself when you don’t need to.

I have found myself making outlines longer than the final product is supposed to be, spending days researching something that is going to be relevant for just one line of text, and writing the same thing four different ways to see which one is better. If you have the time for that and are ahead on everything else and have no the projects you’d like to start, that’s fine. But in the real world, there are better ways to spend to your time.

3. Attack Any Task You Can From Any Angle You Can Whenever You Can

Sometimes my brain works best by carefully planning ahead, making lists, figuring out what I need to do when and for how long… and sometimes the only thing it can focus on is writing about halfling battle cheese. That’s fine if halfling battle cheese projects are my priority, but even when they aren’t, that may be the only thing I can work on. If I have multiple projects, and I simply cannot make my brain do any of the work three of them need, then I need to prioritize among those things I CAN do.

This is crucial, at least for me. Spending time psychically flagellating myself for not working on the 1st, 2nd, or 3rd most important thing is NOT more useful than actually getting work done on the 4th, 5th, or 6th most important thing. Depending on how disastrously close to failure those 1st three projects are, I may ramp up the internal pressure to try to force myself to get them done — but if I can’t, then I can’t. Acknowledging what is impossible, and then still prioritizing among what isn’t impossible, is the best route forward for me.

Of course, this means I also must regularly re-assess what’s impossible for me. Just because I began work on a lower-priority task doesn’t mean I need to finish it before moving on to something else. Indeed, sometimes there mere act of accomplishing something gives me the strength and focus I need to tackle something harder and more important. My contribution to more than one award-winning game came not in one smooth run, but in jerks and jolts as I tackled some crucial part of it, then had to go away to work on less-important things until I could do the next difficult bit of writing.

4. Be Honest With Yourself

You can’t fix every shortcoming you acknowledge to yourself, but you can’t even try to fix any lie to yourself about. It hurts to say “I am going to miss this deadline, because my cPTSD won’t let me work on it, again, for the fifth day in a row.” But that’s still better than trying to believe you can write 15,000 words of quality work in 24 hours, with enough caffeine and snack food to keep you going the whole time.

And if you USED to be able to do that, in your 20s, 30s, and 4s, and now that you are in your 50s you can’t anymore? You need to be honest about that too.

5. Be Honest With People You Are Working With

This is super-hard some days, but it is the ethical, practical, empathetic option. You can’t build a sustainable, long-lasting career on just not communicating when things go bad (it’s often called “going turtle” in the ttRPG industry, and it’s a well-known bad sign), or constantly claiming the dog ate your hard drive.

Things DO happen sometimes. If you got driven out of your home by a hurricane a day before a turnover was due, by all means tell the people you are working with what happened while you can. But honesty is always the best policy.

6. Track The Impact Different Kinds Of Projects have On Your Mental Health

For many creators, not all creative work is created equal. I, for example, can more easily write about my process and mental health and industry insights than I can write descriptions of fictional worlds and their societies. I can much, MUCH, more easily write crunchy player option game rules within an existing ruleset than I can write an encounter for a GM to run as part of a published adventure. And writing some things is more likely to leave me depressed, fatigued, or dysfunctional.

You often won’t know about these differences until you have done several different kinds of writing. But as you go through the career of a creator with mental health issues, keep track. Was the War Clans of the Half-Pint Bakery a nightmare because you were having a bad month and other factors in life impacted you? Or does any project focusing on warfare set off mental blocks you don’t get on other assignments?

7. Forgive Yourself

All the best intentions, your strongest efforts, and the smartest coping mechanisms may fail you from time to time. If you beat yourself up over that, it’s just more fuel for the next round of executive disfunction. There are plenty of other people ready to castigate you for every delay, dip in quality, shuffled schedule, and dropped ball. They don’t need your help to point out your flaws. Keep an eye on #4 and #5… but then forgive yourself.

Patreon

This writing is work, and it takes time from my other paying projects. If you got any use out of this article, or have enjoyed any of my content, please consider supporting my Patreon to cover the cost of my doing it. You can join for the cost of a cup of coffee a month.

Your Developer as a Resource, 1. Running Short

If you are a freelance writer working on a ttRPG assignment, your developer (or editor, publisher, producer — whatever title the contact person you have for the assignment uses) can be a valuable resource. After all, they want you to produce something that meets their needs, so they are motivated to help you give them the text they want.

So if you are having problems with a project, it’s a good idea to write to your developer and see if they can offer advice or guidance. If you think you need to deviate from your outline, it’s absolutely crucial you talk to your developer first. You don’t want to be constantly bothering your developer with issues (they’re paying you to do work for them), but when you are having trouble that is going to impact the quality of your project, better to ask than not.

One common issue that can come up is feeling you have been asked to provide more words on a given subject than the subject needs, or can even support. If you are “running short” on a section, there are better and worse ways to rach out to your developer about it.

Here are some examples:

Good: “I’m having trouble finding enough material to fill out 5,000 words on Halfling Battle Toast. I could use some guidance.”

Better: “I’m having trouble coming up with enough material to fill out 5,000 words on Halfling Battle Toast without just padding it out in obvious and unhelpful ways. If we could expand the topic to cover all halfling war-based baked goods, that would give me a wider range of things to cover. Alternatively, I could do 2,500 words on this, and add 2,500 words to the section on Dwarven Axe-Beer. Or if you have ideas for what I am missing in the Battle Toast section (current draft attached), I can fill that out. How would you like me to proceed?”

Bad: “It is not possible to write 5,000 words on Halfling Battle Toast, so you need to tell me if I am just turning it in short, or if I can use those words elsewhere.”

Worse: “Here is the turnover. I took 2,500 words from Halfling Battle Toast, which didn’t need that much, and used them in other sections.”

Worst: “Since you assigned my more words than needed for Halfling Battle Toast, I moved 1,500 of them to the Monsters of the Bakery section, and contacted your CFO to have my contract reissued for 1,000 fewer words.”

And, yeah, all of those examples are fictional, but they are based on actual ways I have seen different freelance writers handle the issue of being short on wordcount.

Also, sooner is better for something like this. Don’t wait to tell your developer you are short on a section 2 days before the due date. The more time you give them, the more flexible they may be to help you get your section done, and get paid for it.

Supported by Patreon!

All my articles are possible due to support from my patrons, and many are suggested by those patrons! If you want to encourage more writing basics articles, or just stick some money in a tip jar, check out my Patreon!

Writing Basics. Keeping it Short

A LOT of freelance ttRPG writing is paid by the word… sort of. Generally a per-word rate is capped at the assigned wordcount. It’s not really “5 cents a word,” it’s “$50 for 1,000 words, and don’t go too far over or under 1,000 words.” That means that if you overwrite a project, you are getting paid less for your labor, and you’re not doing your developer a favor.

Of course, you can overwrite a project, then trim your writing to come in under wordcount. But then you are doing even MORE labor–both writing more than you need, AND spending additional time trimming it back. While this can potentially lead to more work at higher pay rates in the future if you end up with a really well-written final draft that’s extremely close to wordcount (I prefer to be within 1% of my assigned wordcount), that’s an at-best “maybe,” and there’s no reason you can’t have that same end result by hitting your assigned wordcount in your first draft.
For a lot of people, this is something that gets easier with experience. It can be amazing how fast wordcount goes by sometimes—I know nowadays that if something is supposed to be 100 words long, I have very little room for asides or flowery language to boost the poetry of a phrase. But there are also things you can do to help hitting wordcount on the first draft easier and smoother.

Decide On Your Topics and Their Wordcounts

There’s very little as frustrating as checking to see you’ve used 80% of a project’s wordcount, but only hit 20% of the topics you need to cover. While you may not know everything you need to cover when you start a project, pretty early in the process you should sit down and list out everything you believe you need to spend words on for a given project.

For example, if you are writing up a nation, think about every general description, city, region, ecology, point of interest, and adventure seed you want to cover. You don’t need to go into detail about them at this point, just breakdown what subjects you’ll be writing about, so you can estimate each section’s wordcount. I often find it useful to organize this information by thinking about the headers I’ll use.

This can also be a useful way to decide what’s important. If you have 300 words to describe 6 cities, maybe you want to spend 100 words on the capitol, and just 40 each on the smaller settlements.

Monitor Your Progress

Monitor your total wordcount as your write, as well as how closely you are hitting the wordcount of each topic. If something goes long, you can decide to cut it down immediately, adjust other estimated wordcounts per topic, or even cut topics maybe you didn’t need, adjusting as you go.

Just remember to leave wordcount for an introduction and a wrap-up, if your project needs them. Otherwise, the start and stop can feel very abrupt.

Supported by Patreon!

All my articles are possible due to support from my patrons, and many are suggested by those patrons! If you want to encourage more writing basics articles, or just stick some money in a tip jar, check out my Patreon!

Letters from a ttRPG Dev to a Freelancer, 5. The Polite Inquiry about Work.

This entry in the Letters from a Dev series is adapted from a direct message I sent to a freelancer I had a good relationship with, when they asked how to contact other developers and ask them for work.

They hadn’t needed to contact me for work through formal written channels, because we had arranged the first freelance writing they did for me at a convention when they were introduced to me by a mutual friend and had since then discussed the next thing they’d do each time they finished the last one. We also became friends, and often chatted in nonformal online venues, so it was easy for them to ask me if there was anything upcoming they might get to work on.

But given it is best to have multiple venues to get work from when you want to be a full-time freelancer, and the relatively high turnover in the ttRPG industry, it’s a good idea to branch outfrom just one person who may assign you projects. That left this freelancer wondering –if they wanted to contact someone OTHER than me for work, what were best practices for doing so?

My response, in a Facebook Messenger window, form the basis for the following:

“First, do NOT contact people on Facebook or Twitter for ttRPG work unless they specifically say somewhere that is okay. I’m fine with it, but many other developers and publishers are not. And if someone has said they want all inquires to come in from some official email, or follow a specific format, and you don’t do that you;ve already not put your best foot forward. If you can’t follow those instructions, why should the developer think you’ll follow the instructions of a writing assignment.

That goes with the next important point, DO YOUR HOMEWORK. If you want to contact someone at Paizo about writing or them, read their forums first. Look for the “about us” section to see if there are emails you should use, specific people you should write to, open calls you should try for first, and so on.

After that, do not use form messages. Customize for each developer. If you are on good, friendly terms with them, you can keep it super short and informal, but still on-point and professional. For example:

“Hi Owen!

Hope you are doing well.

I just finished a Project for another developer at Paizo, and wanted to let you know I have availability if you have anything coming up to be assigned. I’d especially love to get to work on some worldbuilding or adventures, but am happy to take any project that could use another writer.

Thanks!

Freelancer Name
Freelancer Email
Freelancer Web Site or Other Social media Link if you have it”

If you don’t already know the developer quite well, especially if you have never worked for them or anyone else at their company of on their game line, you should be both more formal, and more informative. Such as:

“Dear Mr. Stephens,

My name if Freelancer McFreelanceface, and I am a freelance ttRPG writer. I have worked on numerous d20-based games, and the Halfling War Cheese boardgame. I’m a fan of Pathfinder, especially the Player Companion line, and wanted to reach out and see if there was any projects coming up you might be interested in having be write some part of. I am especially skilled with adventures and worldbuilding, and am familiar with your formats for both, but am also happy to take on any part of any project.

If there is an open call or tryout procedure coming up you think might be a better place for me to start doing things for Paizo, I’d be happy to do that first.

Thanks for your time,

Freelancer Name
Freelancer Email
Freelancer Web Site or Other Social media Link if you have it”

Also, make sure all those things are true! If you haven’t cracked open a lot more than one game book from a company, you likely shouldn’t be reaching out to them for freelance work.

Also, if you have other devs or editors or publishers you are on good terms with, or other freelancers, hit them up for suggestions, recommendations, and even references. Always keep the ask at a level appropriate with your actual connection and level of experience with them, but it’s generally cool to ask if someone knows if a publisher is looking to hire freelancers, and if anyone knows who to get in touch there and how. (And, sadly, to learn if anyone has had bad experiences with anyone you should watch out for, though as with anything, you have to decide how to weigh such concerns.)”

My personal rule of thumb is once you ping someone, if you don’t hear from them or they seem open to the idea of you working for them but note they don’t have anything at the moment, it is appropriate to drop them a note again in 90 days. Some people are okay with more frequent pokes (I have people prod me about things I have said I’d LIKE to get around to doing with them once or twice a week, and if done politely that doesn’t bother *me* at all), and if anyone ever replies with something like ‘I’ll contact you when I have something,” that’s a good sign to politely reply that you look forward to it, then stop cold contacting them.”

Support My Patreon
The more support I get, the more time I can spend on writing things like this. 

If you enjoy any of my articles, please sign up, for as little as the cost of one cup of coffee a month!

Writing Basics: Saying No

Early in my ttRPG writing career, I never wanted to say no to any project I was offered. Add free content to the “Netbook of Spells” for AD&D? Sure. Do unpaid reviews of multiple Alternity supplements? Of course. Read over a friend’s 75,000 word manuscript and offer edits and critiques? Always. Write a 128 page book on super-spies in WWII at 1/10th of one cent per word? On it.

While that method did work for me, eventually, I can’t recommend it. Looking back, I see so many times when saying yes pushed me away from being a successful game industry pro. And eventually, I discovered I had more projects offered to me than I could possibly complete.

Even after I knew I was at least marginally established within the industry, for a long time I used to say yes when I shouldn’t because I was afraid if I tuned someone down when they offered me work, they’d never offer me work again. Not only has that turned out not to be the case, I have had many more people tell me how much the appreciate my knowing my own limits to what I can produce in time (when I do know — it’s not like I don’t still get that wrong all too often), but agreeing to too many things makes it more likely I’ll do a bad job, or be late, or worse, and that will harm your chances of getting more work from the same people.

So whether you are fully booked, not interested, have ethical issues, or are just smarter than me, as your creator career takes off eventually you’re going to have to say no to someone.

For some people, that’s easy and natural. For me, it’s a source of social anxiety and worry. So, I have kept track of what refusals seem to have been taken well, and considered how I felt with rejections sent to me when I offered work to others. These are my best practice pointers on how to say no without creating confusion or bad feelings.

These are all keyed to assuming you are saying no in a written form, be that email, Discord, or direct message. Generally if I am offered work in person and I need to say no I’ll use similar structure, but I also often have to say “Ah… I am honestly not sure. Can you email me about it and I’ll get back to you?” (Because without my schedule and some time to think about it, I often am NOT sure. If I am certain it’s a no, I’ll say no. And unless I am 100% sure I can do it, I never, ever say something that might sound like a yes if it’s not written down. I prefer to go to email asap, because then there is a written record of what was and was not agreed to. And then, of course, to contract.)

Be Polite and Maybe Formal

I never want to be rude or abrupt in business communications, even with people I don’t like or plan to ever work with. This isn’t about obsequiousness, just clear, professional behavior. If I want someone to keep me in mind for the future, this helps make sure I don’t seem to be given a brush-off. If I don’t want to ever work with someone in the future, or actively dislike them, this helps make sure I don’t say something I would regret becoming public.

Be Honest

If I’m not going to accept an offer or work, or pursue a opportunity, I want to make sure I’m honest about why… or say nothing. If the question is I am too busy, saying so can open discussions of being more free in the future. If a given system isn’t something I am familiar with, that leaves open the possibility I’ll learn it. If pay is too low, saying so puts it in the employers court to decide if they want to offer more. If I think I am a bad choice for a specific game system or type of project, that can both leave open options for different projects and possibly lead to the employer asking me who I think IS a good option, which can lead to good networking possibilities.

If, for whatever reason, I don’t want to go into why I am saying no to something, I just give no reason at all. There’s nothing wrong with that, if you are being polite and professional.

Open With Thanks

Again, assuming I can do so honestly, I like to open most rejections by thanking the potential employer for considering me. This is often a case of saying, “Hello [Person], thanks for thinking of me for this.” If there’s more to it and I have some real context I would like to add, I might go into that for a sentence or so. “I’m a big fan of what you are doing with [Game Line], and really enjoyed [Last Release].”

I like to build relationships where I can, and even saying no is an opportunity to open a dialog and get to know someone.

Be Clear

Make sure if you are saying no that you actually say no, and only connect it to why if changing the why might mean a yes.

“It’d be tough to fit this in” is waffling, not saying no.

“I can’t take on another project with that deadline at the moment.” is saying no, but if the deadline was later then maybe.

“I need to pass on this project” is saying no.

Sign Off

I don’t know why, but I just feel better if I use some kind of sign off, be that “Maybe next time” or just a “Sincerely” before signing my name to a rejection. Again, I make sure that sign-off is honest (I don’t say “Maybe Next Time” if I am sure that no, I won’t be taking a project like this in the future, either). There’s a good chance this is just for me–that saying no to work is so foreign to my instincts that having a definitive end to a message doing so helps me not ramble on.

Patron Support

All my articles are possible due to support from my patrons, and many are suggested by those patrons! If you want to encourage more writing basics articles, or just stick some money in a tip jar, check out my Patreon!

Letters from a ttRPG Dev to a Freelancer, 4. Post-Publication Activities.

This entry in the Letters from a Dev series is adapted from a letter about what is, and maybe isn’t, a good idea to do after a project you have a credit in gets published and is available to the public. I’ve given similar advice to numerous freelancers, and prospective freelancers over the years (and even have a file on my hard drive that has some snippets of those to borrow from when I am asked about this topic), but I don’t think I’ve ever publicly published any significant portion of the advice itself.

I *try* to always open such letters with congratulations for getting published–creatives in this industry see criticism SO much more than praise or well-wishing, so I like to celebrate those moments of success if possible. Then, I break down my main suggestions for things to do with a project, now that it’s out in the world in its (presumably) final state.

“First, let me say that all this advice comes with a huge proviso — never follow these suggestions if they conflict with your own ethics, morals, best practices, comfort level, or mental well-being. For example, I mention looking for opportunities to talk about your work, including podcasts, but if your mental health will suffer from doing that, don’t. Similarly I suggest keeping praise for your publisher public, and criticism private, but there I am talking about things like typos, or inferences the publisher may not have meant. If you feel you have an ethical mandate to call out a publisher publicly for things such as racism, bigotry, misogyny, and so on, I am in no way telling you not to do that. No one is paying you enough to sell out your ethical code, and I believe we all have a responsibility to try to make the world a better place. Any such instance is going to be too complex for some general advice that doesn’t know all the nuances of that specific situation to apply in any more than the vaguest sense. You’ll need to take those actions you feel most appropriate and/or most effective. That might mean publicly raising your objections, at least eventually if private notes do not seem to be making any difference. It also might not.

I wish I could tell you that any criticism you make, publicly or privately, will be taken as a reasoned, well-intentioned, good-faith effort on your part to make the hobby as a whole better. And, some folks will take it that way. But at both the professional and consumer level, many may not. It’s a risk, and you need to be realistic with yourself about the impact of possibly blowback on your life. If you have specific concerns in this area, please feel free to ask me about them. If you want my private, confidential take on a specific situation I am happy to give it. I might even be able to help.

That huge caveat aside, my general advise for what to do when a product you have a credit in comes along is pretty simple.

Read It

Do this first. You never know what may change from your final turnover to the printed page, and there are two good reasons to find out. First, seeing how things you wrote have changed may give you a better idea what that publisher is looking for, which can help you get more work with them. It may even give you insight into haw to be a better writer. If you don’t understand why a change was made, a short, polite note to your contact who got you the contract for the gig and to who you turned over your draft isn’t a bad idea.

Second, if you begin talking about the book, you want to talk about what is actually in it, rather than what you turned over. You neither want to promise people something that has been removed, nor seem uninformed if people ask you questions about things you have no familiarity with.

I sometimes sit with a PDF of the final release on one screen, and my draft on the other, and look line-by-line at differences. Yes, it would be easier for a developer to send you feedback, but that’s all-too-rare in this industry.

Check your NDA

Assuming, of course, you have an NDA. (Check your contract.) Most likely once the book is out you are free to talk about it, but if it’s one part of a multipart project you may be surprised by what hasn’t been revealed yet. Again, if in doubt, a short note asking for clarification to you contact with the publisher normally goes well.

Promote Your Credit

This is a great chance to promote yourself. Make a post talking about having a credit. if there’s some interesting anecdote about the process, that may be worth including as long as it doesn’t put anyone in a bad light (though see the proviso, above). For most social media platforms, including a picture of the cover of the product is a good idea.

This can help get your name out into the industry, remind people you are alive if you are already pretty well known (I still do this, for example), and convince publishers you are a good partner that will help advertise their product once it is out, driving engagement and interest.

Add It To Your Credits Sheet

Ideally, you have a list of all your credits already. If not, time to start! You want to be able to tell people what you worked on, and how you were credited, in case it ever comes up. Seriously, there is a big difference between having one credit, having ten, having 100, and having 1,000. Start keeping track now if you aren’t already, and make time to keep it up to date as things are published. I personally have all the print products I have worked on as a Facebook album, and people finding that has lead to things like consulting work.

Investigate Interviews

Often podcasts and blogs are looking for content related to new releases, and you helped make this one! You don’t want to steal the thunder from the publisher (again, looking like a good partner makes it more like both this publisher and others will want to work with you in the future… but yeah, see the proviso above), but in my experience if you send a note saying “The podcast ‘Second Level Spell’ wanted to interview me about the Battle Pie rules I wrote for the Orkenpie adventure,” they’ll be enthusiastic in their support, and may even boost that on their social media.

Move On

I’m bad at this one, so I include it here. You may have no issue with it at all. When I look at my old work I can… obsess over perceived failings. I want to figure out why I didn’t do what the developer did, make sure I learn all possible lessons from the project, and consider all the ways I could have done a better job.

A little of that is fine.

But then it’s time to put it down, and move on. Of course you can do a better job now than you did then–we are all learning and improving all the time. Instead of worrying about what past-you got wrong, turn to what current you is doing that you can apply those lessons to.

Don’t Take Reviews to Heart

For a lot of people, this may mean just don’t read the reviews. I personally am unable to do that, so instead I try to restrict myself to weighing their opinions against my own. Did they find something unclear? Fair enough, do I see their point or not? Is it full of typos? Well, that might mean my turnover was too error-ridden for even professional editors to save it, I can look at that. Do they not like it? Okay, but that’s, like, just their opinion man.

Dissatisfied people tend to be much more vocal than satisfied ones. So if you have to read the reviews, take them with a huge grain of salt. And never let them get you down.”

Support My Patreon
The more support I get, the more time I can spend on writing things like this. 

If you enjoy any of my articles, please sign up, for as little as the cost of one cup of coffee a month!

Random Idea Generation Methods. 1. The Reverse and Twist

Sometimes, I just need an idea to play with. I may need a starting point for a new project, or some color and side-thoughts for a bigger ongoing work. Often I just generate new random ideas as a palate-cleanser when I need a break from something I am grinding on. Other times I want to throw ideas out to other people, either for fun or to jump-start their creative processes.

Now if I am lucky, a random idea just comes to me when I need it. Or, if one comes when I don’t need it, I can jot it down with just enough detail to come pick it back up later.

But more often than not, i have to generate an idea, and when i have to come up with dozens at a time, I have verious methods I use to do that. Here’s one”

Reverse/Twist The Starting Point

This is one of my favorites, and it’s a good way to use inspiration without turning everything into a pastiche (or rip-off). The basic idea is to take the core premise of an existing setting or story you like, and make a major change to it. Then, you follow the permutations of your new set-up.

For example, take Moby Dick. It’s a captain’s obsession with getting revenge on a whale. It’s compelling, but it’s also been done and redone hundreds of times. So, what if we reverse a number of elements.

Our Captain is still a whale hunter, but he has not a care in the world. The Red Demon, which may or may not be a whale but is certainly a sea creature, seeks to destroy the captain as revenge for the captain slaying the Demon’s mother. We still have stories of obsession and revenge, but now our focal human point is ignoring the risks, his arrogance convincing him that even if the Red Demon is real, it’s a brute animal, and he has all the advantages of human civilization and intellect to overcome it if it ever finds him.

Now, the inspiration for that idea are pretty clear. That’s fine–the starting place of a story, setting, or even writing prompt is only a small part of the work of making something. But once you have that nugget, you can twist and add/alter as you see fit. Instead of a whale-hunting captain hunting you could have a famous ivory poacher, clearly a villain and an up-and-coming local warlord–who does worry about human threats (and perhaps kidnaps a journalist to tell “his side” of his story, giving us our narrator), but ignores local legends of a Red Demon elephant out to get him, even when other poachers are slain by it.

The further we get from the trappings of the original idea, the more our end product will be clearly its own thing.

Support My Patreon
The more support I get, the more time I can spend on writing things like this. 

If you enjoy any of my articles, please sign up, for as little as the cost of one cup of coffee a month!

Letters from a ttRPG Dev to a Freelancer, 3. Bad Words

This entry in the Letters from a Dev series is adapted from a letter about doing research on words and terms you want to use in a game manuscript. I have sent variations on this same letter to numerous freelancers as part of their feedback, as it has come up surprisingly often.

(As an aside, it has come up so often I have considered making it part of a “packet” of advice I send to all freelancers I contract. The reasons I haven’t yet is twofold. First, while it comes up “often,” in the grand scheme of things that’s less than 1-in-10 assignments. Second, the more stuff I ask ALL freelancers to read, the more burden I am putting on then and the more likely it is they’ll skip some of it. Since 90% of the time freelancers don’t need this advice, it hasn’t ever actually made the cut for me to consider it crucial to ask everyone to read every time they work for me. So, instead, it goes here where people can check it out if they want to, and I can easily point to it if needed.)

Also, I want to say that when I refer to “bad words” in the title, I don’t mean morally repugnant words. I mean bad word choices, often for reasons we don’t realize, which is the entire point of this letter.

So, here’s the letter, taken from one specific example.

“On another matter, I want to recommend you get in the habit of doing an internet search every time you create a new word, or borrow a word from another language (even just archaic versions of existing languages) to use in your manuscript.

It turns out, a surprising percentage of the time “new” words are identical to existing words that have meanings and context very different from what we want be associated with the concept we are trying to name. Sometimes, we even run into trademarked terms that were created in various industries using the same sources of inspiration that lead to our “new” words.

Another risk is finding a term in a specific context and not checking to see if it has a broader or more common meaning that is very, very different. To wit, I see you used the term “Kanchō” as a classification of ninja spy. And, sure enough, if I go looking for “types of ninja” or similar online searches, the Kanchō-as-spy turns up fairly often.

However:

If I just do a search for the term “Kanchō,” by FAR the more common meaning is a highly inappropriate form of “goosing” common as an East Asian children’s ‘prank.’ And then, after that meaning, it’s used as the medical term for an enema in Japan. Neither of those conveys the implications we want for a ninja spy, and sources that use the word for a kind of ninja don’t generally warn of its more common meanings.

Also, I recommend you keep a “clean” browser for such searches, by which I mean one that hasn’t been tied to your search history and involves an algorithm trying to give you the results you most want to see. Sometimes Google is too good at guessing that I am doing research for game content, and skews its results towards those sources, rather than give me the most common meanings and context.

So in my experience, it’s best practices to carry out a search for any term or word you think up, or borrow from other languages or dialects. I have also come to consider this a form of due diligence when working outside my home dialect and experience, even if I think the terms I am using are new and fictional.”

Support My Patreon
The more support I get, the more time I can spend on writing things like this. 

If you enjoy any of my articles, please sign up, for as little as the cost of one cup of coffee a month!

On Sticking To Word Counts

So, here is one of the very few things I ever told a room full of freelancers, that made one of them cry. (I felt terrible, btw).

“A note to freelancers, writing for print books. If I contract you for 10,150 words, and you give me 11,800, you are *not* doing me a favor. You are instead forcing me to figure out which 1,650 words to cut. Print books only have so much room, and while going over by 1%-3% isn’t a major issue (though I’ll love you more if you don’t), exceeding your word-count by 10% or more is creating a lot more work for me.

Don’t under-write by more than 1%-3% either!

Now for pdfs and blog entries, things are significantly more lax. But print products have finite space, and your writing has to fit in that space and look good.”

Apparently, one freelancer in the room had been told by a different developer, working for a different company, that overwriting by 10-20% was “always” good.

And there ARE things I contract extra words for. Mostly, crunchy, rules-heavy things with lots of chances to get it wrong. If I know I want 3,000 words of new spells of feats or specializations in a book, I often contract (and pay for) 4,250-or-so words, so I can cut needless extra verbiage and entire bad ideas (or badly executed ideas), and still have what I need.

But mostly? This is yet another way it’s important for freelancers to ask their contractors what is preferred, and have a high level of communication.

Support My Patreon
I enjoy offering these behind-the-scenes look at professional ttRPG communications, but it does take time. And time is money. 

If you enjoy any of my articles, please support my Patreon. You can help me keep publishing these pro-level articles for as little as the cost of one cup of coffee a month!

Letters to a Dev from various Publishers. 1. Post-Development Developer Checklist

This post is part of the “Letters from a ttRPG Dev to a Freelancer” line of articles, but in this case it’s taken from letters I have received from publishers and producers in my role as game developer. Since many freelance writers hope to become on-staff ttRPG game developers someday in their career, I thought looking at some less talked-about parts of that job might be useful.

Though the role of developer is often not well understood (or well defined), and varies from company to company, generally a ttRPG developer is seen as being responsible for conceiving, outlining, assigning, overseeing, and gathering the text for a ttRPG game book, and adjusting (or sometimes replacing) that text as needed to make sure is is uniform in tone, voice, wordcount, and theme; and meets the publisher’s standards for writing guidelines, rules language, and rule design. A developer is also generally the topic expert on question about that book for any questions about it that must be answered before some other person in the company to do their job (such as a marketing person, or customer service).

But there are more jobs that developers often have to do above and beyond anything involving just the text of the book.

This checklist is far from complete, nor does every company need every developer to do this for every project. But all of these are drawn from checklists I have been asked to follow in my duties as a developer for various published game books, taken from emails and physical checklists I have received from publishers. I’ve removed any identifying information, collated similar tasks described differently by different publishers, and added a touch of context where appropriate.

The Checklist

*Is the art order done? (Art directors generally actually assign the actual creation of the art, but the art director can’t know what art is needed without either the developer creating an art order, or reading through the manuscript themselves, and they rarely have time for that. Also, the developer often has to look at sketches to make sure they’ll meet the text and needs of the game.)

*Are the maps done. (As above, someone else usually orders them from cartographers, but a developer must make sure sketches for the cartographer are accurate, match the style of the company, and have all the needed text, things like a rose compass, scale, room markers, colors, and so on).

*Are the contracts handled? (The developer is often supposed to track that all freelancers get their contracts, and/or that all freelancers return their contracts, and/or that all freelancers have fulfilled the terms of their contract.)

*Is there back cover copy? (If the developer doesn’t write this themselves, they may be asked to give whoever is writing it bullet points of things to hit, and check the final for accuracy with what is in the book.)

*Is there a foreword/introduction/etc? (Just like back cover copy, sometimes the developer is supposed to do this, sometimes they just give info and check the end result.)

*Are the internal marketing text, ad text, catalog text, and solicitation text all written. (As with back cover and forwards.)

*Are the inside covers handled? (If they are supposed to be blank, great. If not… )

*Is any needed legal text done? (For example, if it’s an OGL product, a completed section 15 must be completed by someone.)

*Is the entire Table of Contents page updated (including the cover blurb, etc.)?

*Have any problems discovered during layout been addressed? (Sometimes, even if you make the wordcount right, a book solicited for 160 page pages turns out to be 150 or 170 once it’s laid out. Or monster entries designed to fill exactly one or exactly two pages go way short… or way long. Layout often does what they can, but if the text cannot be made to fit, it’s the developer who has to fix it by adding or cutting.)

*Are all credits correct? (Often books are done in text templates, and old credits may sit around and look “done” even if they are for a different book. Or someone may want their name listed in a specific way. It’s often the developers’ jobs to make sure the credits are correct and current.)

*Have supporting articles been written? (Not always, nor for every product, but it’s often the developers job. Same with interviews, podcast appearances, and so on.)

*Is the budget correct? (On-staff developers often have a specific budget, for both time and money, for the cover, the interior art, all text, all editing, and so on. Meeting that budget is then usually the developers job.)

There’s more, of course, depending on the product line, specific project, venue, publisher, company, and so on. But these are a big part of the most typical beyond-the-book’s text workload.

Support My Patreon
The more support I get, the more time I can spend on writing things like this. 

If you enjoy any of my articles, please sign up, for as little as the cost of one cup of coffee a month!