Saturday, December 20, 2014

Taking to Pieces

Spent a little time seeking a definition of deconstructionism online and came up short.  Apparently, this is one of those subjects that has been co-opted by scholars who are more interested in obfuscating process than it's practice.  Looking at the straight dictionary definition tells you very little; wikipedia is such a mess that the website itself is encouraging users to simplify and make sense of the page.

Normally, in a situation like this I would jump back in time fifty years and locate an older, more judiciously edited article about the subject - but deconstruction is a relatively recent philosophical approach, lacking a clear, agreed-upon central premise.  This has not stopped it from being applied to virtually every field of study.  In other words, deconstruction is now a soup with a million cooks, all of which are ready to defend this or that principle of deconstructionism as though it were a giant academic internet flame war.

Result:  I can't tell you what it means.

I mean, I could try, but some dunce with an undergraduate philosophy degree would soon be carping about how I missed including the important perspective of Hartman, Miller and De Man, plus whatever other precious scholar of the moment is right now in ascendency.  It's always good to remember that the bullshit argument was invented in a shiny ivory tower.

Still, I'd like to argue the value of deconstruction, which is difficult without a definition.  Shall we try, then, to get a working framework, one that doesn't incorporate all the crapology of the linked wikipedia argument?  Yeah, what the hell.

This etymological dictionary tells us that, prior to 1973, the word was used primarily in reference to building and architecture.  That brings us back to the google dictionary in the link above, which uses the phrase "taking to pieces."  This is a sufficient framework for me.  Deconstruction is "taking to pieces."  With that, we can toss Derrida and the whole incestual butt-fuck investigation of these three words into the dumpster out back, then move on.

Why take things apart?  VeronaKid expressed half the reason for doing so in a post I wrote Thursday, the comment that started this post.  We take things apart so that we can understand what went wrong.  What, in the coroner's opinion, killed the patient?  Obviously, this can be helpful, as it can suggest ways that we could avoid creating a similar circumstance that would cause another patient to die.  More to the point, if the event is something that is ongoing - such as the patient is dying right now - then deconstructing the body in various ways will tell us what we need to be doing to suspend the inevitable result.

These are not reasons, however, that I would give for deconstructing a module (the idea I proposed).  I'm not interested in where the module "went wrong."  I am, however, interested in the examination of how the module was designed to solve certain problems - problems that face the DM whether or not a module is employed.

I find myself wondering if the average DM, involved in the creation of their own adventures, is even aware of the problems the module solves.  If that is the case, then, of course, many a personally-created adventure will fail.  The problem wasn't solved - or perhaps it was solved in a manner that never directly considered the problem - and the ensuing adventure suffers from the oversight.

Let's take the first problem - and one that continues to annoy and be insurmountable for everyone, not just RPGers.  The party is here, in the town, and the dungeon is there, somewhere outside the town, in an unspecified location.  Technically, the players don't know where it is, so they must somehow learn of the dungeon if they're going to go there.  How does this learning take place.

Modules have no doubt tried most everything, but the most common solution early on was the 'rumour.'  This was supposed to relay the necessary information by chance; the party overhears some people at the next table talking about the horrible events going on near such-and-such mountain caves.  Overuse of this idea, however, led to such stupidities as parties approaching the bartender to learn if there were any 'rumours' (try it with a modern bartender sometime) . . . and that in turn led to post-it adventure boards that parties could check whenever they were in town.  Metagaming of this kind solves the problem of getting the party to the dungeon - but at the same time, it begs the question, why have a world at all?  Why not just have pathways between dungeons?  Why not have a glowing sign that says, 'This Way to Dungeon'?  Why not a series of hawkers and stalls all along the route to the dungeon, selling potions, magic items, maps, medieval cheat codes and so on?  Why not have a dungeoneer's market place right in the dungeon?

Things we have all seen.

Medieval Romantic poets solved the problem (player + dungeon) by simply having their subjects roaming all the time, so that dungeons would be stumbled across at the start of the tale.  Since these poets did not have to account for many of the things that an RPG campaign does, it was convenient enough to create a quest for an item that could not be found, thus justifying the endless, itinerant wanderings of knights and wizards through endless empty forests.  The Robin Hood myths solved this problem by stuffing the merry men into Sherwood Forest, which then became a general crossroads of the world where everything ultimately came to them.  Both of these methods continue to work as platforms to support episodic television.

You, the creator, are faced with no less a problem.  You may try having an NPC anviliciously tell the players where to go, try to hire the players to go there, threaten the players if they don't go there or ask the players to come along.  I've often used the last option.  The rumour can be expanded into something that is more prevalent than a myth or a story by the fact that the creature is right now attacking the town, such as Beowulf or Smaug.  When the creature retreats, the party naturally follows.

Whatever you try to do, it will help if you view the matter as a problem to be solved, rather than simply inventing a set of circumstances to initiate the adventure.  You can't produce unique situations until you understand what technical difficulty each situation is meant to overcome - and that is what the player + dungeon problem is: a technical difficulty.

I suggest, for now, that you simply relax, remove the trappings of a possible adventure from your mind, then consider how to solve the problem.  The party is here.  They need to be there.  How do we do that - preferably without the party noticing?

The very best solutions, obviously, are when the party starts off without thinking about it - when they themselves are focused on the outcome and not the instrumental process of getting there.  How are you going to manage that?  What will work in this instance?

Take some time.  Think about it.


  1. Re: definition of deconstruction, I personally like the TVTropes approach:

    "Deconstruction" literally means "to take something apart." When applied to tropes or other aspects of fiction, deconstruction means to take apart a trope so as to better understand its meaning and relevance to us in Real Life. This often means pursuing a trope's inherent contradictions and the difference between how the trope appears in this one work and how it compares to other relevant tropes or ideas both in fiction and Real Life.

    The simplest and most common method of applying Deconstruction to tropes in fiction among general audiences and fan bases, and the method most relevant to TV Tropes, takes the form of questioning "How would this trope play out with Real Life consequences applied to it?" or "What would cause this trope to appear in Real Life?"

  2. Alexis, I coincidentally just posted this elsewhere, and it seems relevant. In particular, if you're not familiar with the Sokal hoax, you will find it mordantly funny.

    "One of my BAs is in philosophy and the other is in English. In my case, each degree required a high degree of familiarity with Continental philosophy and “postmodernism.” Never assume that someone arguing from a “postmodern” position respects any axioms of classical logic.

    (Google “Sokal affair.”)"

  3. "You can't produce unique situations until you understand what technical difficulty each situation is meant to overcome - and that is what the player + dungeon problem is: a technical difficulty."

    Oh, baby. Now we're really getting somewhere. Feeling pretty stoked about things in these parts, lately. . .

  4. You can't produce unique situations until you understand what technical difficulty each situation is meant to overcome - and that is what the player + dungeon problem is: a technical difficulty.

    The very best solutions, obviously, are when the party starts off without thinking about it - when they themselves are focused on the outcome and not the instrumental process of getting there. How are you going to manage that? What will work in this instance?

    Take some time. Think about it.

    I did as you suggested. The only scenario I came up with that removed the technical difficulties from your player+dungeon equation is when the players' themselves are focused on the outcome of getting to the dungeon. As I see it, if the players are focused on any other outcome: technical difficulty exists for the DM.

    However, if we eliminate the dungeon as the DM's chosen outcome and actively choose to present outcomes the players are focused on, we can eliminate technical difficulty from the equation. We are left with player+.

    This assumes that as a DM, you have to wait until the players' focus is 'going to your prepared dungeon' before commiting the dungeon on the next adventure's agenda. It requires a fair amount of patience. This would be like waiting weeks for an unreachable apple to plump and ripen so that gravity bends its branch down, lowering the apple to within your reach. Furthering the analogy, to avoid technical difficulty, the DM is obligated to pick and use only the low hanging fruit that the players' current focus provides.

    This means that a DM would have to observe, listen to, and ask their players in order to understand what they are currently focused on. Something you don't ever need to do with a module.

    A DM would also need to considerably empower their players, encouraging players to produce fruit that the DM can feed off of. This would means keep diverting focus back onto the player. For example, when a player strolls to the Tavern and asks the barkeep, "heard any rumors lately?" What the player is really saying, "climb (or rail road) all over me and cherry pick your favorite module." I guess the DM has an obligation not to engage this type of player inquiry into the world.

    I will stop here because I may be totally off base, its happened before. Though your post has made me rethink a fair amount. I also want to think more on the types of player inquiry into my world. How would you respond to a player asking about rumors?

  5. You're not off base, Barrow. You pretty much have it. Add to what you've said the ability to predict the players' choices based upon their created needs, just as you know a fruit will ripen, and you have the whole picture.

  6. Sorry, I skipped your last question, didn't I Barrow?

    Bartender: "Wha' the - Friend, I serve drinks here. If you want something to eat, sit at a table and one of the wenches will serve you." Leans in close and looks angry. "And take some advice - you mind your own business, see?"


If you wish to leave a comment on this blog, contact with a direct message. Comments, agreed upon by reader and author, are published every Saturday.

Note: Only a member of this blog may post a comment.