For me and many of my co-workers, The Year Two Thousand signified more than just the beginning of a new millennium according to some measuring system. The Year Two Thousand brought us D&D's 3rd edition and its Open Gaming License (or OGL for short) which swept the roleplaying world off to a new era of creative blooming and to a wealth of new material that hadn't been seen since the good old days of the 1990's.
Although few know the conceptual forefathers of the OGL, it was not born out of thin air. Free gaming licenses existed long before D&D 3rd edition, like FUDGE or Fuzion for example, but they were free only for non-commercial distribution. They did not give the end user, to borrow a term from the software world, the option to modify, expand or commercially distribute the game by himself. Only the combination of those ideas with the concepts of open-source software and the GPL license made the OGL possible.
The Year Two Thousand was also a turning point in the world of software engineering. Although the eXtreme Programming Development Process (or XP for short) was "invented" back in 1999, the year 2000 really brought it into the light, effectively dividing the software development world into two - those who use XP, and those that haven't yet heard about it.
Why bother you with this long introduction? Wizards of the Coast took the first step when they began using software development terms to describe the roleplaying world, both with the OGL concept and with the 3.5 version, which like any good piece of software is backwards compatible to its last major release (i.e., the 3rd), but adds an assortment of new features and bugfixes. But, as noted, that is only the first step. If the connection between these two creative disciplines has already been established, wouldn't it be appropriate to explore the knowledge and wisdom of one field and check whether it could be applied in the other?
One of eXtreme Programming corner stones is Pair Programming. Under this methodology, two programmers sit at the same computer and work together on a given piece of code. The one doing the typing (i.e., programming) is called The Driver. The other one, called The Observer, holds a double role - to identify tactical errors (such as syntax errors, typos and hidden bugs) in The Driver's work and to think about the strategic considerations of the given task. Since the two switch roles constantly, the situation that is created is that of two equals working together on developing a better product.
The advantages of this methodology may be obvious, but I'll state a few of the more prominent ones, just to lay the foundations for the rest of this article. Programmers, no matter how much some of them may protest, are still human. And humans tend to make mistakes, to get lazy or just not to see all the aspects of a certain problem. The combination of two programmers working together, with one of them freed from the need to actively type and program, addresses this issue, and ultimately helps them produce better code.
I first took the idea of Pair Programming and implemented it as Pair GMing in a scenario that was supposed to be a One Shot a couple of years back. However, it ended up running so smoothly and was so enjoyable that we decided to expand it to a full-blown campaign. This campaign has been running strong for the last two years, and is making no signs of ending anytime soon. I'd like to use this article to share with you the experience I've gathered running that campaign.
So how does it actually work? Exactly the way it sounds - two GMs working together as a team. One GM takes care of the actual gamemastering while the other makes sure the scenario runs smoothly, looks up statistics and charts the active GM may need, makes secret roles so the active GM doesn't need to break his dramatic sequence, points out facts the active GM might overlook, etc. I can't stress enough that these two GMs must act as a team, not as an actual GM and his butler. They must be full and equal partners in the task of GMing, and should switch roles constantly during the scenario.
To take this notion further, the two GMs should be partners already in the creation phase of the campaign. Both of them should know the campaign inside out, and moreover - consider themselves its owners. Pair GMing leaves no place for ego struggles, only for maturity and cooperation.
No matter how great the advantages of Pair GMing might seem in normal times, they are amplified ten fold when every GM's nightmare occurs - the party splits up. When such an event occurs, the GMs simply split up themselves, each GMing to half the party as a single GM. There is a minor overhead of the two GMs filling in each other when the party reunites, but it is negligible compared to the confusion of a single GM forced to juggle between two parties.
I'll finish with a warning I insinuated to in one of the previous paragraphs - Pair GMing is not a magic solution for GMs who lack experience, GMs who are lazy enough to hope they could master only half the scenario or GMs suffering from ego problems. In order for Pair GMing to actually work, both GMs must function together as a single unit with two heads and four hands, not two separate GMs. Both GMs must understand that they are the Game Masters in every sense of the word. They cannot argue or contradict each other during the game session. If they disagree on something - they can work it out after the game, not during it.
eXtreme Programming, as a methodology, is based upon four values - Simplicity, Communication, Feedback and Courage. Simplicity may be arguable, but the other three values are also the basis of effective Pair GMing. Communication and Feedback should exist not only between the GMs and the players, but also, and perhaps, mostly, between themselves. The better they communicate with each other, the easier they would find working together, and the better the feedback between them is, the easier it would be to establish their own style of Pairing. But undoubtedly, the most important value is Courage - the courage to try something different, the courage to step out of the spotlight for a while and the courage to allow your partner to take over every once in a while.
This article first appeared in issue #18 of The Orc.