DM and SD Parrellels

My "make money to support gaming habit" activity is Software Development. Over the last decade or so I've migrated toward Agile "practices". My RPG preferences have also migrated towards simpler, looser, "lite". What is commonly called old-school. I, maybe erroneously, see striking similarities between Software Development (esp the Agile flavor) and Dungeon Mastering (esp the "old-school" flavor).

It's interesting. Both "disciplines" have various competing "methodologies" each with flame-thrower wielding religious adherents. Both indulge in a metric ass load of meta discussion over process/philosophy/origins/bike sheds. And both groups are over represented by what is generally known as "geeks" or "nerds".


YAGNI

You're Not Gonna Need It, agile definition. I and many other developers have wasted lots and lots of man-years designing and coding elaborate frameworks and libraries that we believe will (but never do) anticipate all needs and use cases. We had hoped these edifices of engineering would be reused over and over. But, each problem/customer/environment we wrote software for was slightly different and the reuse rarely paned out. Now, I try to solve exactly the problem at hand. No more, no less.

All the rules, YAGNI, DM adjudication/freedom from rule tyranny. Balance, YAGNI, in fact it gets in the way and it's never actually achieved. The hyper detailed Kingdom of Freedonia, YAGNI, the players will invariable never visit Freedonia unless they board a railroad. Four hour character creation complete with detailed background woven into the campaign history, YAGNI, character eaten by lions 30min into 1st session. A plot, YAGNI, this isn't story time, it's a game. Players are free to act as they wish. Perhaps creating plot through game play, perhaps just robbing some local merchants. Grognadia discusses DM minimalism a bit here and in other Dwimmermount posts.


Just In Time

Is the answer to the question "When should we write the code we thought we weren't gonna need but now realize that we do?" This idea is diffused throughout Agile Software. Just in time originated with general business, JIT compiliers are a concrete if tangential example. "Release early, release often", Test Driven Development, backlogs and iterations of Scrum, are all predicated on the JIT premise.

In RPGs it is called "winging it" or DMing by the "seat of your pants". Random encounter tables, random dungeon/monster/treasure/npc generator, old school terse one line descriptions of dungeon rooms/monsters/spells are all examples. So, is the oft repeated mega-dungeon / sandbox advice of fleshing out just the 1st few levels or just area around player's home base. Let the rest evolve during/from game play.


Iterative Development

I see each game session being akin to a scrum iteration. The ideas and activities of players during each session adds to the campaign backlog. They will be investigated (worked on) in future sessions (iterations), according to the the priorities set by players (customers). Sorry, if you don't know Scrum that might not make a lot of sense. It's about growing the game (campaign/houserules/style) incrementally over time through play. Growth driven by the players actions, rather than at the "speed of plot" and/or via simulation. Players decide what, DM decides outcome of that what.


Final Thoughts

Software Development, at a high level, is about managing complexity. A successful DM must also manage complexity. Running an entire imaginary world (or multiple worlds) in which you can't even rely on some basics such as the laws of physics is INSANELY complex. No one even comes close. Although, hard core simulationists foolishly try. SD/DMing have evolved similar tools for managing complexity. Some of which I discussed above. There are three primary schools of thought when it comes to managing RPG complexity;

1) ignore it. In the 80's this was roll up character, pick monster and duke it out. Repeat until you've killed all the gods in D&DG and have to write into Dragon Magazine to ask for new challange. Today, more of the same combat focused games only slightly obscured with light RP trappings. These are joined by the new breed of miniature/tactical focused games.

2) plot railroad. Choo choo! Complexity is limited because what will happen, when it's gonna happen, and how it's gonna happen are more or less known. Linear, perhaps with a few branches for alternatives. But, pretty much a simple directed graph (probably tree shaped) with a limited set of possible outcomes. (limited by amount of complexity DM can handle). This is design up front Waterfall SD.

3) old-school. Loose, agile, JIT. Dealing with where/what the players are doing now and largely ignoring the rest of the world (complexity) until/unless it becomes "what the players are doing now".

Like their software development counterparts they each are best in different situations. I hope to avoid situations where #2 is the right choice for either RPG or SD.