The Murder Mystery: Black Box and White Box

Another post? Well, I found my inspiration again. Turns out it was laying on dust under my bed... nah, actually, lying around in a hospital bed with nothing to do gives you a lot of time to get bored. Also, reading all the crime novels and thrillers got me thinking about my own ideas. This, in turn, got me thinking about the very thing I kept getting stuck on: The murder mystery itself. Who did it, why did they do it, and how the hell do the cops find them?

This post is about two basic ways of finding that out.

Thinking in Boxes

The terms I use here are something I unabashedly pulled from software testing. There, a White Box test refers to testing the product with knowledge of its inner working and free look at the source code itself. A Black Box test, on the other hand, gives you none of that, leaving you to test it under the same conditions as the eventual user. The same principle can be applied to the murder mystery.

Definitions

White Box Plot

As with the software testing example above, you have all the information. You have plans on who did it, why they did it, who lies and who tells the truth. You follow the murderer, so you know where the evidence is, why they did it, and so on and so forth.

Black Box Plot

The Black Box Plot is best described as "follow the cops". You start out with just the things the cops see at the crime scene and basically do the same thing in your story planning as the cops do in their investigation.

Pro/Con/Black/White

Of course, both Black and White Box have their advantages and disadvantages. Also, not everybody can pull off both things equally well.

White Box Plot

The biggest pro of the White Box Plot is that you start out knowing who did it in the end. You don't pull things out of thin air as you go along, since you already have a fixed set of characters, pieces of evidence and other things where you want to end up. It's hard to get stuck when you already know something that's going to happen.

The biggest con of the White Box Plot is actually the downside of its biggest pro. You know who did it. It's easy to have your investigators jump to conclusions that sound a bit farfetched or have them find things by accident a few times too often. It's possible to ignore that extra knowledge you have, but it's harder than it seems.

Black Box Plot
The Black Box Plot basically writes your story for you. As I wrote above, you follow the cops, who are most likely going to be your main point of view characters. Sure, there's enough stories that include the culprit's point of view, too, but the main focus is still on solving the crime. So you're basically swimming with the stream here.
And again, looking at this from the other side reveals the problems. Following the cops will lead you the same problems as them. You'll find yourself endlessly meandering until you figure out what your next step is. Sometimes, you need to take leaps of faith and see if the story works out the way you want it to.

Plot and Story

Up until now, I've always talked about a something something plot. That was because I was talking about the raw "what is going on" of the story, not necessarily what is written down. Just because you develop the plot white box, that doesn't mean that you have any culprit POV segments in it, and vice versa. Because once you have your plot, you can write your story around it, and that doesn't need to have the same structure as your internal plot notes.
Of course, I'm not telling anyone how to make their murder mysteries, but I think I've done a decent job outlining black/white box differences for writing here. Because I'm preeetty sure you can apply this to other types of plots, too. Make of that what you will.

Publishing And NaNoWriMo Novels

It's still more than half a year until November and until NaNoWriMo. If you don't know it, it's a self-imposed challenge of writing a 50k words long novel. In a month. If you make it, you win. If you don't, you don't. If you cheat, you're only cheating yourself.

There's also people who can't stand NaNoWriMo because of those who think that what they wrote during it is ready for publishing. There's also talking about how publishers and agents are flooded with NaNovel queries in December. Since I'm neither, I don't know how true that is, but that's more of a problem with the writers. Because, and here comes the topic for this post:

Your NaNovel is not publishable.

I hear the sounds of bubbles being burst, but it is very, very, very unlikely that your NaNovel, as it is, is publishable. To those of you who point at Water for Elephants or any of the other titles that came from NaNoWriMo, I highly doubt that any of them were sent out the way they were. And even if one of them was, that's one (1) book, of who knows how many.

I'm not saying it's impossible, but there's a number of things in NaNovels that just don't work for publishing.

50,000 Words

Sure, there's longer ones, but the minimum for a winner NaNovel is 50,000 words. That's Middle Grade/Young Adult length. The shortest I've heard as the starting point for adult novels is 60k for mundane settings, and even more for Sci-Fi and Fantasy. Yes, that's a whopping 10,000 words more than you have. So from 1666.6... words per day, you go up to at least 2000. Or 2500, better.

:words:

NaNovels are full of :words: (or , as Something Awful puts it). They are what happens when it's 10 o'clock and you've still got a three-digit amount of words to write. You start to pad the thing like there was no tomorrow. :words: are the first thing that has to go in December editing. They don't do anything, except for said padding.

Word Count Tricks

Aside from just :words:ing around, there's a whole number of word count tricks. There is avoiding contractions, giving things overly long names and writing them out every single time, writing out things that are abbreviated in any other situation (like the Federal Bureau of Investigations), having characters talk in a really unnatural and stilted way, and also having them address other characters with their full overly long names. None of this is in any way good writing. It is just another way of padding and belongs to the thing you should edit out or, even better, leave out entirely.

In(s)anity

NaNoWriMo likes to take Chandler's Law and turn it up to eleven. When in doubt, use ninjas. When in doubt, have the Traveling Shovel of Death show up. Throw in a new subplot. Do this, do that. While some of these techniques are relatively tame, some (NINJAS!) really aren't. If you attempt to write a publishable novel during NaNoWriMo, stay the hell away from these in(s)anities. Because while you can always edit out pointless side plots and happenings later on, these things are bigger. You might just end up cutting a lot and end up with even less useful plot.

The First Draft of Everything is Crap

I think Hemmingway said that. At least people say he did. And that's what your NaNovel is. A first draft. If it's clean enough to be sent out... uh, congratulations? Writing instantly usable first drafts does not get you anything other than time. Everything you do to your novel before you send it out doesn't matter. What matters is the thing you eventually do send out. Being able to write good stuff from the get-go is just as valid as being able to turn mediocre stuff into good stuff through editing.

Sometimes, it's Just Crap

Not everything can be turned into a great book that people will love. Some things just don't work. That doesn't mean you should give up immediately, but sometimes... yeah. Some things just don't get better. It's up to you to figure out if that's the case.

Be a Rebel

If you can't get past your 50,000 words a month quote, start earlier. Or stop earlier. NaNo means 50,000 words, written in a month, to form a lengthy work of fiction. No one hates you for being a rebel. They even have their own forums for that kind of thing, so why not try that?

After All That's Said...

Even though I said a lot of negative things about the novel you're going to write during November, I'm not saying you shouldn't try. A daily deadline is a great motivator. But remember that the things we write during NaNoWriMo are often less than stellar. Your job for December is to fix that.

In-Game Tutorials

After a while, just rambling about things I have an opinion got boring. I'll now also ramble about things with the intent to teach you something! ...hey, where did all of you go?

Why Tutorials?

There's so many things you can get wrong when you put tutorials into your game. Actually, this kind of segues into my last post. I covered the Kitchen Sink Design aspect of that game pretty well, but there were other things it did wrong. One of them was the tutorials. Oh god, the tutorials. They were everywhere, mandatory and didn't teach me anything I wouldn't have been able to figure out on my own.

Tutorial Fallacies

This is going to be another post where I list things. These things might sound incredibly matter-of-factually to you, but they're way too present in games.

Press WASD to walk
Exactly what it says on the tin. For some reason, games decide to explain to you how the most basic controls work. Okay, the worst offenders here are RPG Maker games. Come on. We all know that we use space to confirm, Esc to cancel and the arrow keys to walk. "But what about the people who're not familiar with the engine?" If you wanted to ask this now, I'm glaring at you through the internet. Hard. People aren't stupid. If you have a game with keyboard controls, what are you going to try first? Either WASD or the arrow keys. Even Esc/Space (or Enter) are kind of self-explaining, since all over the operating system itself, these are used to confirm or cancel things. So, again, these are the things that are going to come to mind first, and even if not, the player can try around and find the action key on their own. People aren't stupid!

It's dangerous to go alone. Take this tutorial!
This one is more of a placement fallacy than a content fallacy. Sure, you might have some ultra-awesome game mechanics to show to the player. So you hand them out at the beginning. All of them. And expect the player to get all that and remember it until it's actually brought up. Spoiler: Most won't, because at the moment of the tutorial, that information is completely irrelevant. The human brain is wired to ignore things that are irrelevant and not necessary for survival (of the player character). Bring the information up when it's necessary and when the element is actually first used.

Remember the time I pushed that crate? It was totally awesome!
So you have your gameplay element the player won't easily grasp without a tutorial, you introduce it at the time it's first used, and then this happens:

Bob and George stand in front of a bunch of crates.
Bob: "Hey, look! Crates!"
George: "I can push them, you know? Because I'm strong."
Bob: "Cool! But can you pull them?"
George: "No." *sad*
Bob: "But I can, because I'm... reverse strong. Yeah!"

So our characters, in the middle of the action, paused in front of a bunch of crates to discuss their crate-pulling abilities. While in-universe tutorials are awesome, you have to be careful. If this came up as part of a cutscene, it would be okay. But if it comes up during gameplay, a piece of dialogue like this stops the game dead in its tracks so that the characters can explain their abilities. Again: People aren't stupid! If you need to explain it because you're using a key that hasn't been used before, give the player a blurb that says tells them what key it is. Don't stop the gameplay for something like this.

But What Should I do Then?

The tutorial fallacies I brought up are most often removed by removing the tutorial itself. But sometimes, you may want a tutorial to explain a mechanic that might be unconventional. See the nonstandard key example. Sometimes you need to explain.

In-Universe vs. The Blurb
In general, there's two categories of tutorials. Those that are explained by the characters and those that aren't. Both have their advantages and disadvantages. One of the most important things about in-universe tutorials is that the characters know about things. So either you need to wrap the mechanics into a nice flavor or you break the fourth wall and risk having a guy with a purdy hat fall onto your head.
Fourth-Wall-Breakers I remember are, for example, the kid in Link's Awakening that told you how to save. It then proclaimed that it didn't know what saving was because it was only a kid. Also, an example that takes it further, is the toad in the beginning of Super Mario RPG that warns a goomba that Mario knows about timed hits. Even further goes Mario party, where, in one part, Bowser Jr., while explaining the rules for a game, clarifies that A is, in fact, the green button.
But for everyone of these, there's at least a ton where it's not as amusing/self-aware/generally well-done. I suggest to stay consistent with the way things are explained. You don't need an in-game explanation for every button you press. But if your character's health is literally measured in hit points,  you'd better tell me how that works, and you'd better have a good explanation.

MAKE IT STAHP!!1
Tutorials for outstanding features that really need to be explained are, for many players, only needed for the first time. Every time after that, especially if the controls and inner workings are memorable (very good thing), it's only annoying. For these kinds of tutorials, unless they're really woven into the game, as explained above, you should have an option to turn them off. A good example for that was the (sadly canceled) German RPG Maker game Velsarbor. While you started with an overpowered character that just plowed through the enemies like a warm knife through butter, the real gameplay started with two ordinary dudes. From then on, you had explanations for whenever a new gameplay element was introduced. These infoblurbs could be turned off, so those who, after the first two or so blurbs, noticed that they'd get it anyways, wouldn't be bothered by it any more. Those who needed the tutorials could keep them.

Now bring me an idiot
The best way to find out if your tutorials work well is to have them tested by different people. The important thing is that you get people of various skill levels. An experienced gamer will react differently to someone who doesn't regularly play games of the genre. I refer to tests with the latter kind of person as idiot tests. These tests are done to make sure that the most ignorant person would understand your tutorial and act on it. Also, just because it's called idiot test that doesn't mean that the tester shouldn't try playing the game. For random button-mashing, see Fuzzing.

The Bottom Line

Tutorials are not necessarily evil, but they need a lot of thought. They should be appropriate for both beginners and experienced players, and should not be annoying to either one. There's many ways to incorporate them in the game universe, but this isn't always necessary and often difficult to pull off. But the bottom line to said bottom line is:

People aren't stupid!

Encourage the players to try things out on their own and you'll find that you might not need as many tutorials as you thought you would. Now, click inside the textbox underneath this article, type in your opinion on this article and click the publish button. In case you're viewing this on the main page, click the article title first.