I'm a general manager these days, but most of my industry experience is in IT project management. Software projects are notoriously high risk and prone to under-delivering or killing the budget. Over the past 10 to 15 years, different approaches to structuring software projects have come into vogue to help guide the creative process. I always enjoy seeing how I can apply stuff learned on the day job to the night job - campaign creation. Your campaign development is a work product.
Traditional project approaches use a structure called 'waterfall'. All the activities of a phase are completed before moving on to the next set of activities. In software terms, that would be identifying all the requirements for the software first, then creating designs and blueprints, then building it, then testing it, and so on. The work product from the previous phase is an input flowing into the next phase, usually represented through a step chart (gantt chart), therefore the term 'waterfall'. In campaign creation, you could imagine creating all the hex maps first, then maps for all the towns and cities, then descriptions of all the towns, and so on - exhausting one activity completely before moving on to the next thing.
Scrum (a type of "agile development") is focused on quickly getting a working iteration of software published, putting it in front of the customer, and moving on to the next iteration while incorporating feedback and customer insights. If the waterfall approach had you building one large layer at a time, the Scrum approach involves a 'vertical slice of the cake' that has a snapshot of all the layers accounted for in that mini product. In dungeon terms, imagine creating a few rooms, fully mapped and detailed and keyed and packaged, and then getting some players to experience those limited rooms. You'd incorporate what you learned in the first game session when you prepared for the next session. That;s a bit like a Scrum project. I'd say most just-in-time campaign creation uses that approach.
The approach I've been taking with Taenarum involves "progressive elaboration". There was a software project management approach championed by IBM in the late 90's called "RUP" - the rational unified process - that used progressive elaboration as a core method. One of the driving metaphors was developing a walking skeleton, and slowly adding on to the skeleton the way a sculptor would add clay to a metal frame.
In Taenarum, I've started with expansive maps of the dungeon levels, without adding too many details - just the layouts and number of rooms. I make some notes on the theme of the level, and a list of monsters to plug into the random stocker. Then I use a random stocker to quickly add raw content to the rooms. These few things give me that underlying 'metal frame' - the walking skeleton. Sometime later I do another pass over the level, harmonizing and rationalizing the random results to make it either coherent or interesting… (and sometimes even both). Doors, secret doors, and other map objects get added in. Treasure is added where appropriate - first as gross sums to balance the level, and then it gets decomposed into more interesting forms when time permits.
Here's an example. After the first pass through the random generator, I'd have an entry like this: Room 7, monster & treasure: Traders. Next it becomes a 'trader camp' with 5 traders and 800gp treasure. On the third pass through, I decide to give the main guy a name and personality (table driven) and change the raw treasure total into something more interesting. (Pro tip: the ACKS book has handy tables for trade goods as replacement treasures for coins - the tables are massively useful, regardless of system). Here's how the final room ended up looking in my notes:
You may wonder - why bother with all those iterative passes over the same material, when I could have jumped right to creating the entry for room 7 on the first pass? It comes down to balancing scope and detail. The barebones version of the level, with a map and raw content, lets me improvise as necessary if the players wander farther into the dungeon than are fully prepared. Any one of us could improvise a room like the Trader Room - the worst case is that it might slow the game down a little if you need to roll a bunch of dice at the table. By starting with the skeletal framework, I've been able to sit down with a couple of hundred more rooms available than otherwise - Taenarum is over 300 rooms in just a few weeks of development. The finishing details get added as time permits, or when I know there's a good chance the players will visit a given area in an upcoming session.
Back before I mused about becoming the Anti-Beedo, I was definitely a 'vertical slice of cake' kind of referee, who would have completely finished Room 7 Trader Camp before moving on to Room 8 - I developed things serially. Anti-Beedo wants to cover as much ground as possible, and is willing to leave the finer details ambiguous until time permits or it's necessary for clarity. The approach is working, and I've been happy with Anti-Beedo's results so far. I have more dungeon material in Taenarum in just a few weeks than I had in the Black City after many many months.
Traditional project approaches use a structure called 'waterfall'. All the activities of a phase are completed before moving on to the next set of activities. In software terms, that would be identifying all the requirements for the software first, then creating designs and blueprints, then building it, then testing it, and so on. The work product from the previous phase is an input flowing into the next phase, usually represented through a step chart (gantt chart), therefore the term 'waterfall'. In campaign creation, you could imagine creating all the hex maps first, then maps for all the towns and cities, then descriptions of all the towns, and so on - exhausting one activity completely before moving on to the next thing.
Scrum (a type of "agile development") is focused on quickly getting a working iteration of software published, putting it in front of the customer, and moving on to the next iteration while incorporating feedback and customer insights. If the waterfall approach had you building one large layer at a time, the Scrum approach involves a 'vertical slice of the cake' that has a snapshot of all the layers accounted for in that mini product. In dungeon terms, imagine creating a few rooms, fully mapped and detailed and keyed and packaged, and then getting some players to experience those limited rooms. You'd incorporate what you learned in the first game session when you prepared for the next session. That;s a bit like a Scrum project. I'd say most just-in-time campaign creation uses that approach.
The approach I've been taking with Taenarum involves "progressive elaboration". There was a software project management approach championed by IBM in the late 90's called "RUP" - the rational unified process - that used progressive elaboration as a core method. One of the driving metaphors was developing a walking skeleton, and slowly adding on to the skeleton the way a sculptor would add clay to a metal frame.
In Taenarum, I've started with expansive maps of the dungeon levels, without adding too many details - just the layouts and number of rooms. I make some notes on the theme of the level, and a list of monsters to plug into the random stocker. Then I use a random stocker to quickly add raw content to the rooms. These few things give me that underlying 'metal frame' - the walking skeleton. Sometime later I do another pass over the level, harmonizing and rationalizing the random results to make it either coherent or interesting… (and sometimes even both). Doors, secret doors, and other map objects get added in. Treasure is added where appropriate - first as gross sums to balance the level, and then it gets decomposed into more interesting forms when time permits.
Here's an example. After the first pass through the random generator, I'd have an entry like this: Room 7, monster & treasure: Traders. Next it becomes a 'trader camp' with 5 traders and 800gp treasure. On the third pass through, I decide to give the main guy a name and personality (table driven) and change the raw treasure total into something more interesting. (Pro tip: the ACKS book has handy tables for trade goods as replacement treasures for coins - the tables are massively useful, regardless of system). Here's how the final room ended up looking in my notes:
7. Trader Camp
---------------------
Pillared chamber used as a camp by a party of traders led by Kyriakos of Gytheio - a handsome man with earrings and the attitude of a practical joker.
5 Traders (level 1 fighters) and 3 slaves (normal men). Incidental weapons (spears, clubs) and leather armor
Trade goods:I use a little excel sheet to generate hit points on the fly, and can improvise or derive combat stats as necessary, so I'd usually never put that kind of thing in my notes.
6 bundles of fox pelts (90gp total)
2 casks of distilled wine (400gp total)
3 rugs (15gp total)
8 weeks of food, water (40gp value)
100gp, 1500sp
10 +1 arrows with bronze tips, carefully wrapped
You may wonder - why bother with all those iterative passes over the same material, when I could have jumped right to creating the entry for room 7 on the first pass? It comes down to balancing scope and detail. The barebones version of the level, with a map and raw content, lets me improvise as necessary if the players wander farther into the dungeon than are fully prepared. Any one of us could improvise a room like the Trader Room - the worst case is that it might slow the game down a little if you need to roll a bunch of dice at the table. By starting with the skeletal framework, I've been able to sit down with a couple of hundred more rooms available than otherwise - Taenarum is over 300 rooms in just a few weeks of development. The finishing details get added as time permits, or when I know there's a good chance the players will visit a given area in an upcoming session.
Back before I mused about becoming the Anti-Beedo, I was definitely a 'vertical slice of cake' kind of referee, who would have completely finished Room 7 Trader Camp before moving on to Room 8 - I developed things serially. Anti-Beedo wants to cover as much ground as possible, and is willing to leave the finer details ambiguous until time permits or it's necessary for clarity. The approach is working, and I've been happy with Anti-Beedo's results so far. I have more dungeon material in Taenarum in just a few weeks than I had in the Black City after many many months.
...And that's why I became a Business Analyst.
ReplyDeleteWell begun is half done. A good BA saves a ton of grief down the road.
ReplyDeleteInteresting approach. I think it makes a lot of sense.
ReplyDeleteI took your idea and slammed it into a post I was writing. Thanks!
ReplyDeleteMegadungeon Best Practices XIII
I have been approaching my current mini-mega dungeon campaign in this way, although I've felt guilty about it until just now - having previously been a waterfall type.
ReplyDeleteIt seems to me this method maximizes the value of what little prep time I have.
Many of the levels only have details for the areas nearest the level connectors - knowing that more likely than not, these are the rooms the PCs will encounter first. The closer a room is to a connector the more likely it is to have details filled-in, while the further away they are, the more likely they are to remain in the bare-bones status, possibly forever if the party never explores the level.
This comment has been removed by the author.
ReplyDeleteJust wanted to chime in and say thank you for sharing your processes. They really help energize my own thinking.
ReplyDeleteVery inspiring! I've also stumbled in the past when attempting to create large dungeon levels with fully fleshed out rooms. This sounds like an interesting alternate approach.
ReplyDeleteWould it possible for you to show some your iterations on the maps? I was curious as to what your layout maps look like versus the finished maps.
ReplyDelete