Being a Proofer

Testing and proofreading MVOL is a demanding task. If you're interested in helping make MVOL a better game, read below!

1. Why MVOL needs proofers
2. What proofers look for
3. How to become a proofer
4. What to do when you're a proofer
5. Tips & Tricks

Why MVOL needs proofers

The main chunk of the game comes to about 200 pages in a word editor, or 110,000 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 needs to be proofread 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.

We need proofers for MVOL because, 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 MVOL carefully so that it 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.

More importantly, it is essential to catch the majority of problems with a new version of the game before it's actually released. While some sites allow me to quietly replace the game with a fixed version when problems come up, many others do not-- so if the copy on e621 has a glitch, everyone playing there is stuck with that glitch unless I upload a whole new version entirely, which I'd very much like to avoid. And many of the game's supporters receive copies of the game by email the day it is released, and the ideal would be for that copy to be complete and relatively problem-free, such that I don't have to bombard their emails with secondary and tertiary copies.

Writing and coding this game is an intensive process, and while I like to think I prevent most glitches and mistakes getting into the game 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. With each version of the game, there may also be other specifics I'm concerned about and will specify as we begin. 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 & 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 one line break 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

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 the game as it stands right now-- I recommend downloading a force-refreshed copy from the link on the blog, as that will guarantee you 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 v0.12." 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 blog. Usually, when I'm around 1/2 to 4/5 done with the next version, I'll start sending out test versions to the folks on my proofer list. 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 regular game 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 v0.13t2." 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 & 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. The common variables for switching out bits of text are species, breasts (for Lith and avatar), dominance, dick size, presence or absence of dick/vagina, your focus on sexuality, and presence or absence of pants. Less common variables that still switch out some text include wearing a shirt, your horniness, Lith's horniness, your nice/naughty, how your nice/naughty compare to each other, your nicest/naughtiest and how they compare, what collar Lith is wearing, and Lith's cock lust.
  • 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 sometimes. 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.
  • In a recent update, I switched on selectable text. This means that, technically, you could get a hand with this process by copying the whole thing into a word processor and searching for errors. 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-- go through your own results and discard things that are obviously intentional. I can guarantee you that MS Word will have about a bajillion issues with my grammar, most of which I won't be interested in hearing about. Similarly, words such as "footpaw" and "cocksleeve" aren't likely to get through the process unmolested. You are welcome to use spellcheckers and such as tools to supplement your efforts, but they should be a beginning point to the process, not an endpoint.
  • 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 glitches such as missing chunks or buttons that don't work, context is important. A quick run down of your species and equipment and how Lith is configured may be very helpful depending on the bug, as I often have to try to replicate the bug myself to fully understand it. If you want to report a particular scene with a problem, referring to the button that opens the scene is most effective-- i.e. [Offer Yourself] or [Grab]>[Kiss].
  • 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.

No comments:

Post a Comment