By day, I am a software engineer. And once a week for a handful of hours, I am a Game Master. For me, they are very similar jobs! As a software engineer, I apply the principles of engineering to design, develop, document, test, and scale a solution to fit a particular need. As a GM, I must also design, develop, document, test, and scale a campaign to fit my gaming group’s needs. Because this is such a close parallel, I am still in engineering mode when I develop my campaigns — even if they are sandbox campaigns.

In fact, developing a sandbox campaign is more similar to the type of software I develop at work: The solution must put power in the hands of the user and be highly configurable and therefore, customizable. So here’s where I start at work, when I’m presented with a “need”:

This “need” should be formally translated into a REQUIREMENT, or set of requirements. I want, essentially, an itemized list of everything required to fulfill this need. From here on out, all the work I do will be judged against these requirements. I also need to understand the context of the requirements, or more specifically, the way they relate to the user. We call these USE CASES. I make a matrix that illustrates which requirements fulfill which use cases. To be clear, a use case is not every conceivable way my solution can be used; a use case is a business process, ie a procedure that directly performs a business operation. For instance, at an ATM, you can insert your card, and enter an invalid pin number, and be rejected. That is not a business case, as no business was performed. A business case would be inserting your card, entering a valid pin number, being authenticated, and seeing your account options. Now that I know which requirements relate to which use cases, I can prioritize my work. The requirements that fulfill the most use cases get the highest priority, etc etc. At this point, I can estimate my roadmap for developing a solution. Now I need some designs. I start with a high level design. What major components of my solution will I need? For instance, I might need a UI component, a Hardware component, and a Communication component. I also need to think about scalability — users may have tiny databases, or enormous databases. We may have two customers, we may have a thousand customers. My solution needs to be able to adjust accordingly. I continue to work down to details in my designs. What classes or objects will I need to code to create the UI component, for instance? Now, I can do my actual coding. Once coding is complete, I need to test to verify it works. We have a Quality Assurance analyst on our team at work, and this is largely her responsibility. But I need to do my due diligence before I hand her my code. I can create unit tests and also do some component testing. But the QA will need to verify that every use case works as designed, and that every requirement is really fulfilled.

Did any GMs out there see a resemblance to how you create campaigns?

Talk to your group. Discuss the setting, the balance of roleplaying vs combat vs skills. Agree on a setting. Talk about what character concepts they’re thinking of. These are the requirements! Character goals will play a large part here, but also NPC goals. What is the villain’s objective? What about other factions at play? This is where we define the context of the campaign: Our use cases. A very effective and popular piece of advice for newer GMs is to create just a “skeleton” plot or outline of major plot points — these are, essentially, your use cases. Yes, there are a bazillion things the players could want to do in the big city in your campaign, but you’ll want to focus on things that directly influence your plot or major factions. What if the players side with the prince? What if the players meet the general of the army? You can pretty much make a plot map now. The players will have to start somewhere. And when they go somewhere else, you’ll know which use cases they can fulfill. Design time! Start high level. You’ll need Cities, you’ll need Dungeons, and you’ll need NPCs. These are your components, to name a few. Keep in mind scalability, because your players may be higher or lower level than you expected when they encounter these elements. Leave yourself some wiggle room throughout your design process. Dig deeper in your designs – how many cities are there? Which are villages, and which are bustling metropolises? Which of your NPCs are allies, and which are hostile? What environments are your dungeons? Now comes the nitty gritty – rolling up or manually creating all these elements. Lay out the dungeon, salt it with monsters and treasure. On and on! This should be a snap, since you know your use cases and requirements! Verify! A lot of you do component tests via Reddit by posting your dungeon designs and asking “How does this look for a level 4 party?” Discuss scenarios with other GMs. Testing a campaign isn’t necessarily as easy as testing software, but it IS possible. But the most important thing to do is, after each session, ask your players: “How are things going so far?” You can adjust next session accordingly, because, hey, you kept an eye on scalability!

For me, this process is so natural and comfortable. And I imagine that a lot of great GMs out there go through the same process without even realizing it. I’ve heard it said that GMs need to be highly creative, right-brained types… but I’ll always argue that having a left-brained, engineering perspective is equally as important.