I sometimes find it hard to identify what’s wrong with a story because I’m too close to it – a bit like trying to work out what’s wrong with the house you’re building when you’ve got your face pressed up against one brick.
It’s usually fairly easy to spot the flaws with someone else’s script because you’re experiencing it unencumbered by preconceptions (which is why it’s easier to critique than create). If your mind isn’t clouded by what it’s supposed to be, you can see what it actually is.
I find I need to get distance from the script in order to figure out what’s not working; and since physically turning around and walking away just makes the text smaller, I tend to switch from the keyboard to a piece of paper and pen. The move helps me re-gear my brain and tricks me into looking at the project objectively.
One of the techniques I use is to try and boil the problem down to one simple question or statement. In this last script, the statement I came up with was:
I just don’t believe scene x follows scene y.
In other words, I don’t believe the character, after having experienced the events of scene y, would then go on to behave like he does in scene x.
The answer then becomes simple:
Put x before y.
That may seem simplistic; but that’s the point: boil an intractable problem down to a one you can solve.
Another example which springs to mind came from listening to Jeff Goldsmith interview Ben Ripley about Source Code.
By the way, if you don’t listen to Jeff Goldsmith’s Q & A Podcast series, you really should.
***MILD SPOILERS FOR SOURCE CODE TO FOLLOW***
If you haven’t seen Source Code (I liked it) and you’re still reading, then it may help to think of it as a bit like Quantum Leap with the leaper only having eight minutes to solve a problem on a train. The difference being, after eight minutes he gets to go back and try again an (more or less) infinite number of times.
It’s been a while since I listened to the podcast, so I may get some details wrong here or even be completely making all this up; but as I recall, one of the problems Ben faced with Source Code was how to get a girl on the train to fall in love with Colter (the leaper, or Source Coder) in eight minutes.
He gets an undefined length of time spread over multiple eight minute sections to fall for her; but she doesn’t remember him from one segment to the next – why would you fall for a complete stranger in eight minutes?
The solution is simple and elegant; but perhaps only obvious to an outsider (I believe Billy Ray actually spotted it) or someone who’s seen the finished film and already knows the answer. One way to come up with that solution may have been to boil it down to this statement:
There isn’t enough time for her to fall in love.
The solution then seems simple:
She needs more time.
Obviously there are many ways you could implement that, such as making the eight minute segments longer; but how much longer do make them before sitting through them becomes a chore? And is falling in love in half an hour more believable than eight minutes?
Perhaps a better statement might be:
I don’t believe she would fall for a stranger in only eight minutes.
In which case, the solution might be better stated as:
Don’t make them strangers.
If she already knows the guy Colter is leaping into, if she already fancies him; then eight minutes is long enough to tip over into love. Or at the very least, it’s better for the film’s purposes.
The point is, the initial abstract worry that the script isn’t making sense becomes a concrete, solvable problem when I vocalise or write down my concerns. Switching to a pen and paper (or just a new document) allows me the distance I need to re-frame the problem and come up with a solution.