"(Engineering is) the application of science to the needs of humanity"
A couple of weeks ago I found one of my old software engineering textbooks while cleaning out my closet. Software engineering is, as Fritz Bauer defined it in 1969 and that book quoted, "The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines". Software development is not what The Ogmios Project is about, but the concept of learning from different disciplines is always appealing. In this article I'll attempt to take another step in the journey I began in the article Two Heads are Better Than One?, and see how we, the Game Masters can make use of the principles of engineering.
1. Plan Before You Build
As Benjamin Franklin put it so eloquently, "in failing to prepare – you are preparing to fail". This might go without saying, but you'd be surprised to see how many GMs fail already here, before they've even started creating. Before you begin, define what you are trying to create, and for what use. Are you writing a campaign, an adventure that would be part of an ongoing campaign, or just a one-shot scenario? What genre should this adventure be in? who are you going to play it with? Ask yourself these questions before you sit down to write, and make sure you don't cross the boundaries you've set for yourself.
2. Make Sure All The Parts Fit Together
This simple principle is true on every scale you may wish to apply it. When writing an adventure, make sure that all the scenes fit together.
And what does fit together mean? Make sure they all follow the same theme and the same atmosphere you're trying to create for your adventure. A comic scene would be out of place in a horror adventure, and an epic battle between the republican army and the imperial guard may seem in place in a fantasy campaign, but wouldn't fit well in a detective adventure that sends the characters off to find The Sleeping Beauty's lost ring. Moreover, make sure that your adventure contains no plot-gaps or untied threads that could only be resolved by using knowledge held by the GM. It isn't enough that all the pieces fit together, it should also be clear to the players how they do.
On a larger scale, this principle is still applicable - Make sure that all the adventures the characters have past fit together in a logical way, that important NPCs haven't just disappeared, that empires haven't risen over night and that the world's cosmology hasn't changed without any notice.
3. Design The Tests Before You Build
One of the most important aspects of engineering, that usually does not come into play (pun intended) with writing, is quality assurance. I won't go into philosophical debates how quality can be defined, and instead I'll do with a simple (not to mention simplistic) definition of quality: "A quality product is a product that accomplishes the objectives it was designed to accomplish". Together with planning what you want to achieve, as you did in Rule #1, also plan how you are going to test that you've accomplished these objectives.
Since we are not dealing with software engineering or even apple-cider engineering, any method or technique you could devise would do fine - from giving your work a second reading (either by yourself, or preferably by an external critic) to a demo-running (AKA a testplay) of the entire adventure or of selected scenes.
4. Check The Design Before Entering Commitment
In simpler terms, this rule states that before entering each stage of the work, your should make sure that the previous stage was completed successfully. Translating it to our world, the world of roleplaying, it simply states that you should "Check Your Assumptions before Acting Upon Them".
Before you sit down and start writing, make sure that your assumptions about the number of players, their ages, experience, background, and the end of their previous adventure (if any) comply with reality. If they don't, adjust your objectives to fit with these new-found facts.
5. Monitor Changes in the Design
A roleplaying games is a dynamic being, to which change is a second nature. And because of that it is especially important that the GM constantly monitor changes and variations made to his initial design, not only while writing the adventure, but more importantly, while running it.
Were these changes introduced since one of the GM's assumptions turned out to be wrong (e.g. "This encounter should be easy enough for the characters to win without any help" or "By now the characters should have figured out that Lord Omberon is withholding information from them"), or did the GM simply get a better idea than his original one (and in this case, a GM striving for self-improvement will later try and understand how he hadn't considered this idea in the first place)?
Both cases a valid, but they still must be monitored and kept track of, so their affects on the campaign can be dealt with easier later.
6. Make Sure You Deliver The Right Quality
These generic words of wisdom make this rule the twin of Rule #3. Back then you designed your tests, now you should run them.
Remember - since you don't have a formal definition of a client as software engineers (or apple-cider engineers) do, only you can define the required quality. The tests are your tool to ensure you've delivered that quality.
7. Learn From Your Mistakes, And Improve The Next Time
It doesn't matter how much time and effort you'll put into testing, sooner or later you will make a mistake. There is no shame in making mistakes, as long as you don't make the same mistake twice.
Some GMs devote a couple of minutes at the end of each session to getting feedbacks from their players, but even without such formal tools, a good GM should be able to understand from his players' reactions where he went wrong. Write down these points, and the next time you write or run an adventure, take a couple of minutes to think how not to make the same mistakes again.
8. Know Where You're Going
This principle returns to what Rule #1 stated. It isn't enough to define what you're trying to do, you must also define where you're going.
What is the ultimate objective of the adventure? How can you use it to further your campaign? Or are you using it to a different end, such as conveying a message, or even giving a new idea or style a field test?
In conclusion, the main idea I tried to convey in this article, is that good ideas can be found everywhere, even in fields that seemingly have nothing in common with roleplaying, like engineering. So next time someone starts talking to you about a subject you know nothing about, take a minute and listen to them. You might learn something interesting, or even useful.
This article first appeared in issue #22 of The Orc.