Hello! If you’re interested in pitching in to help make my games the best they can be, you’re in the right place! I’ve written up a comprehensive explanation of everything you’d need to know about the position below to get an idea of why proofers are needed, whether you should sign up, what it would involve, and how you get started. I hope you’ll consider joining the project, we’re always short on hands!

Why I need Proofers

The main content of MVOL comes to over a million words. Some of that is code, but the bulk of it is text the players can see, and a lot of it is swapped out in unique ways depending on decisions the player has made over the course of the game. What this means is that there is not only a massive amount of text that needs to be proofread, but that it also can be read in dozens or, in places, hundreds of different possible combinations. Most of these combinations should be okay, but as the writer/coder is only human, it is inevitable that there will be typos, glitches, or just patches that don’t sound very good when they’re slapped together. My other projects aren’t near this scale yet, but the potential for problems is just as great.

No matter how much time I spend going over the game from the inside, it’s what actually comes out that counts. I try to craft my games carefully so that they will be stimulating and well-written, and every time a player encounters a stumbling sentence or a misspelled word, it damages the experience. Very few players will take the time to come tell me when they see something like this, too, so without proofers, a lot of mistakes can be left in the code over the course of several versions of the game.

I want to make sure each release is as close to a perfect experience as we can reasonably manage. There’s a span of about a week at the end of each development cycle where I switch from creating content to going over it making sure it’s ready for release, and I want to make sure I’m not dealing with lots of random little issues only discovered after release for weeks after.

Writing and coding these games is an intensive process, and while I like to think I prevent most glitches and mistakes in the first place with a searing, almost self-destructive focus on self-criticism and perfectionism, some things still get through. Proofers are there to pick up where I leave off, for the sake of my sanity.

What Proofers Look For

This is your primary reference list for what to be actively searching for when proofing MVOL. Other projects will vary to some degree but often have the same or similar issues, and I’ll give specific instructions on what to look out for with each release we work on. All of these are things to keep an eye out for, but I’ve put them in a rough order of priority.

  1. Errors: “whoopssorry,” missing or extra chunks of text, sudden starts or stops, broken buttons
  2. Spelling and punctuation
  3. Mistaken variables: gets your species wrong, lists Lith’s gender wrong, etc.
  4. Broken grammar
  5. Achievement glitches
  6. Broken pacing/sentence structure, anything that forces you to go back and read again to understand it
  7. Text walls: ideally, there should be at least two line breaks visible on the screen at all times
  8. Save file problems, such as importing from an older file, loading different files mid-game
  9. Anything that just seems off or distracting; general feedback on new content

How to become a proofer

A lot of folks offer to become proofers because they’re interested in getting a sneak peek at the game before it comes out. And while that is the big perk of the job, proofing is still a demanding task, and I’ve come to offer a basic test to folks interested in becoming proofers. This serves several purposes: it gives you an idea of what you’re getting yourself into; it saves both of us frustration and embarrassment if it turns out you don’t have the time or focus to be a proofer right now; it gives me a better idea of what your strengths are at proofing and how well you follow instructions; and, of course, it helps refine the game further.

The test is simple: go through MVOL as it stands right now– I recommend downloading a fresh copy from the download page here on my website, as that will guarantee you get the very latest version of the game. Look for any of the errors I listed above, make up a list of them, and email them to me at lithiers@gmail.com with a subject along the lines of “Proofing application MVOL v1.01”. With how big and complicated this game has become, I know for a fact there will always be problems that need rooting out, no matter how many proofers I have– that’s why I want to have as many as possible. So send me what you can find, and if it’s enough to convince me you’re serious about helping make MVOL a better game, you’ll go on the list to receive test copies as they start coming out. That’s all there is to it!

What to Do When You’re a Proofer

When your name’s on the list, you basically just keep an eye on your email, and maybe the news feed. Typically I’ll send out test copies a week or so before the supporter release, meaning usually near the end of the month. Read whatever special instructions I have (and please, even if it sounds simple or easy, make sure to test it! Some functionalities work differently on different devices and such.), open up the game, and get cracking. Usually, the new content (which I’ll generally list out, possibly with basic instructions on how to get to it) will be the main focus, but every new version is likely to have a few alterations to the old code in it, so even just running through the basics can turn up surprising results.

Compile a list of what you find and email it to me, with the version you played in the subject, i.e. “Proof report v1.02t2.” You don’t need to send in reports more often than once a day. Once I’ve started sending out test versions, I’ll probably send out a new one every 1-3 days as I fix things proofers have reported, usually with a summary of what’s been fixed, so you can know what’s been found and fixed already if you’re just getting ready to send me your report for the last test version.

Finally, I should note that, in joining my stable of proofers, you’re expected to treat any materials you get as private– if I see or hear about test copies of the game being shared around, I will be very sad, and maybe even a little mad.

Tips and Tricks

Proofing can be tough work, and there are a number of things that make it challenging, as well as things you can do to make it easier. Make sure you keep these things in mind as you proof!

  • Some text is read much more often, and has been proofed many more times than other text. Try starting games with combinations you don’t think others have tried to see less commonly read combinations of text.
  • When you’re looking at grammar, keep in mind that I like to fancy myself an artist when I’m writing, and as such, I can tend to do some crazy things with my grammar here and there. If you’ve read most of the game’s material already, you should have a decent feel for my “style.” The goal is to find spots where either I messed up my grammar without meaning to, or where what I tried to pull off simply didn’t work. A rule of thumb is that if it breaks the flow of the reading and forces you to go back and read it again, that’s probably a muckup that should be reported. The exception is that occasionally, I’ll write something specifically meant to make the reader feel uncomfortable, but that should usually be pretty obvious by context.
  • You might find it helpful to copy whole scenes into a word processor and run a spellcheck or similar. I won’t resent this– indeed, you’re still checking out your own specific combination of text outcomes, so it’s still valuable. However, I don’t need people just dumping their word processor results on me– use it as an aid to find little errors we might otherwise skim over. I can guarantee you that MS Word will have about a bajillion issues with my grammar, or words like “footpaw” and “cocksleeve,” but that’s not what I’m looking for here.
  • Some switches in the text switch out small segments– as little as a single word, or half a sentence, while others switch out full paragraphs, multiple paragraphs, or the entire outcome of the scene. Further, even for multi-paragraph passages that switch out, the break won’t always be between paragraphs, but often right in the middle of one. So always keep a close eye on your text– you never know where something new might pop up, and you might see something you missed before besides.
  • When you’re reporting typos and grammar problems, context may be helpful, but usually the most helpful part of the report will simply be a snippet of the area with the problem– half a line to a full line of text should let me search the problem spot down almost instantly. If the problem isn’t immediately obvious, a little explanation would probably help.

 

And that should be everything you need to know to be a huge help to the project! If you do have any questions or need clarification, you’re welcome to shoot me an email and I’ll try to help. I’m looking forward to working with you!