Friday, November 20, 2009

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".


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.


  1. Awesome post - and I think you beat the internet today with the term "DM minimalism" - I've been really reaching for a term for this method and not found one better - and the analogy bears true also.

  2. I really like this post. It about sums up my DMing methodology. Don't worry about it until its time to worry about. If the players go there, then figure out what "there" is. You end up in far crazier places this way than if you try to foresee all the possible outcomes in advance. I am a lazy DM in terms of preperation work but a very "agile" and on the spot DM in the moment of the game. Most of my prep work I do just takes the form of thinking about what the players did and what I improved during the last session, and making sure that I have se therecent events thoroughly assimilated into my noggin so I can riff off of them during the next session. If I was trying to stick to a plot, my players would drive me crazy, but as it is, their actions drive what plot there is and we are coming up with a pretty insane universe as a result.

  3. read "improved" as improvised in the post above

  4. I too (no *%#$) work in software development. Reading this post made me think of exactly how much my brain runs games in the same way I design things.

    This_posts_insightfulness = This_posts_insightfulness + 1;

  5. The real question here is this: how can I incorporate this into my resume as a software designer to show that my GMing experience makes me a more valuable asset?

  6. Thanks for the compliments, not sure they're that deserved. Just, thought there were a few interesting parallels.

    Digging the recursion Zzarchov!

    People running large MMORPG guilds have put that on their resumes (or claim to have). But, that was for more MBA, manager type position.

    I list "games" under hobbies and interests. I don't make a point of brining it up but I have mentioned DMing experiences during interviews re conflict resolution.

    The organizational, communications, and inter-personal skills required to DM/game are big plusses as far as I'm concerned.

  7. The chatty DM has made a post along the same lines with regards to teachers and managers.


All Time Most Popular Posts