When Infodumps Go Right

on Tuesday, December 20, 2011
This was the second image I found when I Googled "infodump." In retrospect, I'm very grateful SafeSearch was on. 

Infodumps. We all know what they are (but here's an infodump about infodumps anyway). Basically, it's when somebody in the story (either the narrator, another character, or the main character him/herself) buckles down and blabs about everything the reader needs to know. I put emphasis on reader here because a common stigma (and problem) with infodumps is they dump stuff the characters already know. Essentially, it's a paragraph, chapter, or section that focuses on explaining things that will need to be known in order for the rest of the book to progress. Usually this entails a bit of foreshadowing, a lot of expository dialogue, and loads of text while people don't do things.

A classic example is the chapter The Council of Elrond from The Lord of the Rings. Basically, Tolkien needed his readers to be up to speed on the world's events, the significance of the ring, and the exact details regarding the quest. Unlike the movies, The Fellowship of the Ring didn't start with the backstory regarding Sauron getting his finger cut off and the importance of the ring of power. While Gandalf does provide a bit of information to Frodo back in Hobbiton, it's more of a mini-infodump to tide him over until he's in Rivendell and can get the whole thing.

Growing up I hated this chapter, especially on re-reads. I already knew everything Elrond was saying, and the chapter is really really long. There is very little in terms of actual story progression: basically we are getting a history lesson that is capped off by finally saying what everybody should do. You'll note that in the movie (as mentioned above) they essentially broke this scene into two pieces: gave the history as a prologue, explained what needed to be done during the actual scene. This helped the movie flow faster.

So how do we "fix" infodumps? Well, there's several ways. The first is to just forego them completely. A clever enough writer can explain everything the reader needs to know about their world, characters, and magic through scenes and dialogue. This way the action keeps flowing without heavy explanation. The Way of Kings, despite being an incredibly wordy book, does this fantastically. The Name of the Wind, despite having several scenes set in schools and with instructors, never falls into the trap of straight infodumping: something is always happening that caused the infodump. It's that other trope scene we all love: where Luke is being trained by Obi-Wan or Yoda, and they are actually teaching the audience lots about the Force rather than just Luke.

It's worth noting, however, that doing this wrong can make your book extremely difficult to read. Many readers like having it told to them straight; it gives them the big picture and makes everything fall into place. Having to extrapolate everything from scenes and dialogue can be difficult, especially if you are trying to cater to a younger audience, so you might have to throw in some little, more concrete infodumps as a foundation for your explanations set through dialogue and scene.

The obvious trap to avoid (as I've said already) is to just spout information about your world for a chapter without anything interesting happening. Sometimes it's necessary, and if your world is interesting enough it's easier to forgive. If you are doing it as a long dialogue, having characters interject or ask questions can also keep the pacing and make it less of "storytime for the sake of the reader." This seems to be a common problem with new authors. You have this awesome world, awesome magic, and you are just dying to let that cat out of the bag. You've waited five chapters, dropping hints and subtle references, but now you can't hold out any longer. You explain everything in great detail, your awesome ideas and fantastic world down to the minute detail, and your audience all puts your book down and goes back to playing Skyrim.


Last point: determining what goes into an infodump. Eventually, no matter how good you are, you'll probably have to give in and explain some stuff eventually. Tolkien did it, so that means it's totally legit. What isn't legit is over-explaining, or giving too much information. As stated above: fantasy writers often are planners, with grandiose visions of worlds and magics and races and all sorts of things. It's hard to restrain yourself from just explaining everything at once (after all, you are doing an infodump anyway, what could it hurt? Right?). Don't. It's a universal rule to only tell characters (and the reader) exactly what they need to know right then, and then trickle down the rest of the details throughout. Provide the foundation for the house, and maybe a few walls, but don't furnish the whole thing in one go. Give only what is needed, and the rest will come throughout the rest of the story.

-----

The only reason I brought this up is I'm in the middle of an infodump chapter in Death's Aria. I usually hate writing these. I'm bored by infodumps, and so writing them is doubly painful. However, I'm really enjoying it this time around. Questions I've had about the world are being answered (this might be the fault of discovery writing, to be honest), a stage is being set for the rest of the novel, and after the infodump is dropped the second act kicks in full swing. It's an exciting time (especially since the characters dumping all this info are interesting), and it's (finally) getting me pumped to write this novel.

The first chapters are still awful, in case you were wondering, but we'll get back to those later.

4 comments:

Derek Bown said...

And of course you can always have a wattson character that needs things explained to them, so you can avoid characters explaining things they already know.

Nathan Major said...

Yeah, I'm filing that under "bad example," since it's now a massive cliche. :P

John said...

Stopped reading the infodump halfway through, when I realized I didn't care.

John said...

I started reading mainly because I originally thought you were referring to the stack traces and debugging info that is dumped out when a computer crashes though.

Post a Comment