So, you have a finished draft of a game project. You’ve checked that it meets your wordcount requirements (neither too much nor too little off the mark – I try to hit within 5% of the exact wordcount total, and I consider being off by 10%–whether over or under—to be a failure to hit wordcount), the formatting is what your publisher has asked for (so if you used ANY table function of your program, you have replaced it with what the publisher’s style guide calls for), and you’ve hit all the required topics.

Now what? Now, you get ready for revision.

Revisions can have a number of steps for game writing, depending on the project, time, and circumstance, but here are some common types. A project may have all of these, just a few, or none… though try to avoid not even having time for a reread.

The Re-Read

The best way to get a good revision on your own is to put your writing down for a couple of weeks, work on other projects and then, when it’s no longer fresh in your mind, reread it from the beginning. You are likely to catch a few places where the wording got muddled, or you didn’t type exactly what you were thinking. But you may also find some more systemic problems, such as discussing concepts in length before introducing them in brief, or contradicting yourself because ideas evolved as you wrote them (or you wrote two parts of the same section days apart, and misremembered what you said the first time).

This is also a good time to play developer with your own material. Do you see a simpler way to express the same idea? Is a rule system too complex for the value it gives the game? Is an option obviously overpowered, or under-powered, and you can see a way to fix it? Does something you thought was awesome now seem dull? This is a good chance to fix all those issues.

And if you aren’t sure about something? Just flag it for your developer/editor/producer. Leave a comment explaining your thought process and concern, and that you weren’t sure one way or another. Having comments and thoughts from the author can be a huge help when a developer is first tackling a project, and it shows you’re cognizant of potential issues in your work, but trust the people you are working with. While you are at it, put notes in about anything else that might be useful for your developer. A list of resources that need to be mentioned in a OGL section 15. Which bits of continuity are canon (and where you found them), and which are new elements you made up yourself. Anything that’s an Easter Egg (or even clearly inspired by existing IP—homage CAN be fine, but let your publisher know what you are riffing off of, so they can make that decision for themselves).

Playtest

If at all possible get at least SOME playtest in of any gameable elements. An adventure can be easy to do a quick playtest of—grab some friends (with your publisher’s permission to have people you are sharing the unpublished material with, if under NDA or similar restriction) and run through it once. Single stand-alone elements such as spells or feats can be trickier, but having people other than you use them in character builds can show if they are unexpected synergies, or are valued much more or less highly than similar options. Larger elements, such as entire character classes, can take months to properly playtest, but at minimum it can be useful to run a Rules Rumble playtest – have one set of players make characters without access to the new rules, and a second group make characters required to use the new rules, and pit them against each other.

If you find any glaring issues, fix them. If you find potential issues, leave comments for your developer/editor/producer.

Beta Readers

It can be useful to have people you trust take a look at your work to highlight any potential problems they see. Again, if you are under NDA or similar constraint, get your publisher’s permission for this. Sometimes projects with multiple freelancers working on it provide a way for those freelancers to go over each other’s work as it is created, which can be a great resource (but be sure you give back – if someone gives you useful feedback in that kind of environment, read through their stuff too). You don’t have to take a Beta Reader’s opinion over your own of course, but do consider their point of view. If a Beta Reader says something is unclear, for example, then no matter how obvious it is to you, you know it’s unclear to at least SOME other people.

Publisher Feedback

Publisher feedback is extremely important on any project they have the time and energy to give it to you, which is my experience isn’t that often. Ultimately if you don’t work with your publisher on their feedback, you may not get published. But the degree of how important this is varies from ‘crucial” to only “very important.”

Most freelance work written for the tabletop game industry is done Work for Hire, which means once you are paid you have no further rights to the work. You aren’t even considered the creator, for copyright purposes. When I am working on that kind of project, if the publisher gives me feedback, I consider it part of my job to incorporate that feedback, even if I disagree with it.

I ALSO consider it part of my job to point out why I think bad feedback is bad, but in the end if this is something for which I am providing content using someone else’s sandbox, and I have been hired to fill a certain amount of it with the kind of sand they want, I consider my job to be to give the publisher what they want. I often call this kind of work “content provider” rather than “author,” to remind myself of what my end goal is.

Things are slightly different if a publisher is partnering with you to publish something you retain the copyright to. It’s still crucial to consider the publisher’s feedback—one presumes you picked this publisher to be the venue for your work for a reason, but if it’s ultimately your project any feedback should ultimately be your call. (Though, you know, check your contract. Preferably before signing it.)

In Summation

The point of a First Draft is to get it done. The point of a Revision is to get it right. This can vary from tweaking a few things to realizing you have to tear out the heart of what you have written and start over (which can feel a lot like tearing out your own heart). In tabletop RPG design you often don’t have time for more than one revisions (though a developer may be coming along behind you to make another, out of your sight), so try to get as much feedback as you can, then apply what you have learned, make notes…

And move on to the next project. Never finishing revisions is a form of never finishing, and it’s often said “Game designs are never finished, they just escape their designers.”

Don’t be afraid to change things in revision, but also don’t be afraid to leave them alone if you think they’re good.

Patreon
Heya folks–I am back to being a full-time freelancer. Which means, every word I write has to justify itself in time taken vs. benefit to my freelance career and/or money made.
So if you found any of this useful and you’d like to support the creation of more such content, check out my Patreon!

Just a couple of dollars a month from each of you will make a huge difference.