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.