So this is an idea meant to be broadly applicable across systems and genres. It's the beginning of some work on it, and might require additional elaboration when it's applied to a specific game or campaign.
The idea is: projects.
Making-stuff-as-adventure-element, including but not limited to: MacGyvering gadgets, building siege engines, creating strongholds and fortifications, surveying frontiers a la Mason & Dixon, developing super-gadgets, etc.
This is meant to be a way to make this kind of thing interesting in a game, including if it's initiated by the players. With some kind of guidelines in place it's easier to accommodate players who decide to build some adventure on their own because they get their not just signing up for "Make my life hell then tell me if it works".
I've used a 5e-style d20 base but it should be pretty easy to adapt to any other traditional system from Traveller to Cthulhu to Dark Heresy or Star Wars. Here we go...
SOME BASIC PRINCIPLES
Principle One: There Are Two Kinds of Projects...
The first type of project is usually fantastic in nature (taking an inventory of an occult library, inventing a chemical regime to give people super powers, manufacturing 7 rings of power, etc) and its main characteristic is:
the project itself serially spawns adventure hooks even in an otherwise dull environment. Every few weeks a librarian accidentally summons a wound in the architecture of reality or a test subject runs amok and begins using its adaptive abilities to devour baby brains, assistants mutate, etc.
These projects are easiest to conceptualize as mini-settings in themselves: "places" with their own random encounter tables checked periodically with the roll perhaps modified by the nature of the PCs' decisions about micro risk-reward involved in the project. Their design is a lot like a normal adventure and don't necessarily even need these rules, but might benefit from them.
A PC who initiates one of these is asking for trouble
and they know it. I'm going to call these kinds of projects "Hook Factories".
The second type of project, the much more common kind, is half an adventure--it is simply something hard to do which becomes an adventure
because it is interacting with an adventure set-up.
You're building an opera house
in the middle of the Amazon, you're fixing your spaceship so you can get off
Carcosa, you're building a bridge, but it's over a river in
Qelong, you're trying to make a flame-thrower while the terrorists are breaking down the door, etc.
I'm calling these "Regular Projects".
Principle Two: You Can Only Mechanize So Much...
The whole point of playing with these projects is they're novel and that novelty means they have hiccups and bumps specific to themselves. This means when designing the project you might nee to google up a real project on the internet that's broadly equivalent and use some of the information there to model the project in the adventure or make up some stuff I can't give you a formula for.
If this system were only for one narrow task, say, crafting magic items or building starships or making buildings or supercomputers or Great Walls of Chna there might be more formulae we could apply, but the idea here is to encompass a variety of projects--so you'll have to do a little research or imagining or both.
Principle Three: There's The Problem and There's The Solution
Projects consist of attempts by someone to solve a problem. This means there's always at least two things to mechanically define: what the problem is and who is trying to solve it.
They will have different, interacting stats.
Principle Four: Steal From TNG
Being inherently humanistic and optimistic
, Star Trek: The Next Generation plots often concern exactly this kind of problem structure. A positive and constructive project is envisioned, it encounters a speed-bump, the solution requires adventure.
Steal ideas from it.
DEFINING THE PROBLEM
The problem by itself has 3 basic stats: Working Time, Magnitude, and Complexity. (If you're reminded of the
Iron Triangle or "You can have fast, cheap or good, but you can only pick two", this is no coincedence.)
Step One: Working Time
The first thing you want to do is figure out how long the project would take by googling a similar project or, if the task is something completely fantastic and invented (indexing the Black Library on the Eldar Craftworld) read through this but don't do anything until step two.
You want to
broadly estimate this in straight labour-hours (what they used to call man-hours back when they thought you had to be bitten by an hour when the moon was full to get any work done) using tools typical of the era and setting for one person with a median income. Since it's in labour-hours not regular time, for large projects this will be way longer than it actually takes to do it. The Brooklyn Bridge took 600 workers 14 years, so: 8400 years of woking time, give or take a decent amount depending on whether they worked at night, whether all those people were on the project at the same time, etc. But 8400 years is close enough.
The number will also be way longer than the time it takes to manufacture something on an assembly line--a car can be made in less than 24 hours, but not by one person alone working on a middle-class budget.
The most important thing is to get a handle on the order of magnitude: days, weeks, months, etc. which leads us to our next step:
Step Two: Magnitude
“Magnitude” is a stat measuring how big and ambitious the project is, boiled down to a score between 1 and 10 using the Working Time estimate you just got in Step One (or just pick one if the project has no real-world model). Some examples of projects that fit (when executed with modern tools by one person alone) are listed after.
Magnitude 1 --Seconds (Carving an improvised knife)
2 --Minutes (Making a box out of cardboard or wood scraps)
3 --Hours (Making a table or chair)
4 --Days (Build a room, fix minor damage to a car)
5 --Weeks (High-end luxury watch, building a kitchen)
6 --Months (Custom period costume, index a small library)
7 --Years (Feature-length indie film, Viking longship at the time)
8 --Decades (Watts Towers, World's largest model railroad, Sistine Chapel)
9 --Centuries (Large-scale corporate IT projects, Research studies)
10 --Millennia (Castle, Mount Rushmore, Great Wall of China, Brooklyn Bridge)
Step Three: Complexity
"Complexity" is how technologically involved the project is under normal conditions for the setting (no time crunch, contemporary materials, etc). It doesn't include the logistical complexity of organizing people to do it, just the technology and know-how required. The examples given are complexities from a 2017 point of view.
1 Requires only common sense (turning a melon into a bowl)
2 A 101-level project for a specialized skill (making an ashtray out of wood or clay)
3 An advanced hobby project using common information (pinewood derby racer, professional-looking website)
4 A well-informed amateur or student could make it (zip gun, pipe bomb, patio with a hot tub)
5 Requires professional-level ability in a common technical field—normal industry assumes it can be regularly be done (drug interaction study, building a skyscraper)
6 Requires unusually high professional competence (recovering and reconstructing an ancient archaelogical site)
7 Requires application of an unusual technical skill or specialty within a field (designing next-generation hypercar, forging an illuminated manuscript)
8 An impressive achievement that informed critics might doubt will work (brain-activated prosthetics)
9 Cutting-edge—as advanced as the most advanced tech in the setting, things that aren't yet fully understood or viable (facial recognition, self-driving cars)
10 The technology does not yet exist in the setting (teleportation, reliable inkjet printers)
...if you're dealing with a lot of super-science or magic, feel free to make things that are 11, 12, 13 complexity.
Step Four: Who's In Charge And How Good Are They? (Relevant Skill)
Now that the problem's defined with three stats, we're going to move on to define whoever is solving it.
The most important person is the Project Manager. In the real world, this can be hard to nail down--is the person in charge of the movie the director? Or is it the producer who decides how much money the director gets to spend and demands certain stars appear in the film? Or is it the studio head who the producer reports to? Or shareholders? In the game none of this is important now: just pick the NPC or PC who is going to be, for dramatic purposes, the boss of the project.
They will then get a skill stat (if they don't already have one) to define how good they are at doing the thing the project is about.
In 5e you have stats which give you a modifier (+4 for an 18 stat) and then proficiency bonuses for special skills that go up as you level (up to +6 at 20th level). These combine to make your total bonus to do the skill thing. So for a human with an 18 Int at 20th level using an Int based skill like (say) Genetic Resequencing, the total bonus is +10.
The point here is the skill of the person directing the project can, just like project Complexity, be rated on an approximately 10-point scale (going a little higher if they have some superhuman ability).
For other systems, the idea is to derive a number with a soft maximum of +10 for the skill the project's based on.
Either way--if the system doesn't have the skill, invent it and just give it to whoever's in charge. Since this is a pretty specialized task it won't unbalance the game much, just enable this subsystem to work--if it were that important to the game normally it'd already be on the sheet.
The scale for these skills is just like the "Complexity" scale above, so:
a +1 means they can normally execute projects requiring only common sense (turning a melon into a bowl)
a +2 means they can normally a execute 101-level project for a specialized skill (building an ashtray)
etc.
We'll call this number the Relevant Skill.
This measurement for the project includes anything brought to bear on the project--anything currency can easily buy in the era the project is being executed, including extra workers, better tools, better materials, but also including things like factoring in help or other PCs and NPCs, as if they were being paid a wage (even if they're working for free). Literally anything that's a "resource" being brought to bear should be factored in, as if it were paid for.
1 Whatever’s right there now
2 What can be cheaply and quickly scavenged in an hour or two
3 A collection of scavenged or secondhand parts
4 Lower class income
5 Middle class income
6 Upper class income (6 figures)
7 Large business, town, millionaire
8 Corporation, small city budget, multi-millionaire
9 Multinational or medium country, billions, major city budget
10 Super-power or largest multi-national, trillions
Step Six: Calculate Difficulty Class
The Difficulty Class of a project is like the DC of anything else--a target number to be hit with a skill roll on a d20, with that skill roll modified by the project manager's Relevant Skill bonus.
The DC is calculated like this:
Difficulty Class = Magnitude + Complexity - Resources + 10
There can also be modifiers to this DC at GM's discretion mid-project due to the difficulties imposed due to the What Could Go Wrong? table or other things that happen mid-project. For example, if a bad unicorn eats your laptop then maybe the DC goes up by one 'cause you lost some files.
Step Seven: Calculate Estimated Project Time
This is about how long the project will actually take.
Start with the Magnitude--so for the Brooklyn Bridge (8400 years in Work Time) that'd be a 10.
Modify the Magnitude number as follows:
-1 if Resources are greater than 5
+1 if Resources are less than 5
-1 if Relevant Skill is greater than 5
+1 if Relevant Skill is less than 5
-1 if Complexity is less than 5
+1 if Complexity is greater than 5
-1 if the project is to be fragile but the basic project it's modeled on isn't--that is, it can be physically destroyed by an attacker in a round without even rolling a die (like a MacGuyver ad hoc flamethrower held together with paperclips)
-1 if the project is single-use but the thing its modeled on isn't (like a temporary pontoon bridge, or an alarm system that knocks over a bell)
-1 if the project involves modifying an existing thing that almost does what you want
+1 if the project has a secondary function the thing it's modeled on doesn't (like it's a space shuttle but also a cruise ship). The secondary function needs to be a lower Complexity level than the primary function.
Once you've done that, read off the description--days, weeks, months, whatever--that's the unit of how long it'll take assuming nothing goes catastrophically wrong. Very low numbers generally indicate enough resources are brought to bear that the thing can be automated, but the GM can feel free to put a common sense floor on the time dimension.
The estimated time starts halfway through the sequence to the next unit:
Time 1: 30 seconds (halfway to a minute)
2: 30 minutes (halfway to an hour)
3: 12 hours (halfway to a day)
4: 3.5 days (halfway to a week)
5: 2.5 weeks (halfway to a month)
6: 6 months (halfway to a year)
7: 5 years (halfway to a decade)
8: 50 years (halfway to a century)
9: 500 years (halfway to a millennium)
10: 500 millennia (seriously what the fuck 40k Pendragon shit are you running?)
Between Seven and Eight: Checking Progress
This isn't a step to execute, just something you should know now:
"Checking Progress" is when the player rolls on their Project Skill against the Project Difficulty Class to see how things are going.
Critical success (natural 20) means:
-If the project time is elapsed, the thing is finished and works, or
-If it's not, a subpart of the project of the player's choice that could conceivably be done and functional this fast is (like the laser on the Death Star)
plus:
-If the project is finished, an unexpected discovery has been made, things have turned out better than expected, or
-If this is mid-project it means the remaining project time is 1/3 the current estimate.
Any other success of 20 or more (with modifiers) means:
-If the project time is elapsed, the thing is finished and works, or
-If it's not, a subpart of the project of the player's choice that could conceivably be done and functional this fast is, and
-If this is mid-project it means the remaining project time is 1/2 the current estimate.
Any other success means:
-If the project time is elapsed, the thing is finished and works,
-If it's not, the GM picks one:
-A subpart of the project of the GM's choice that could conceivably be done and functional this fast is, or
-The remaining project time is 1/2 the current estimate, or
-The project has its path clear and the time to completion can't be adjusted again until the thing is supposedly finished and actually tested
Failure means:
If the project is supposedly finished and being tested, it means it doesn't work and needs more work equal to 1/4 of the time already spent--plus the most interesting possible consequence the GM can imagine of the thing failing at this point occurs.
If it isn't, Roll on the What Could Go Wrong? Table
Crit failure means:
First:
The most interesting possible consequence the GM can imagine of the thing failing at this point occurs.
Plus, GM's choice:
Someone seriously fucked up. Start over from scratch.
or
If it can conceivably blow up or otherwise hurt you--it does.
Checking Progress happens at a few different times during the game:
-When the project is actually used for the first time, after it's finished (or, in the case of a failure, supposedly finished)
-Whenever the PC in charge wants to check progress. Why would they do that? To see if they can shave time off or finish a subsection.
-At the beginning of any other event happening in the campaign that the PCs will play out their reactions to (that is: if a wandering monster shows up, then also check progress, if a new adventure hook shows up, then also check progress, if the PCs strike out in search of water, then also check progress, etc)
-If the project is a Hook Factory, it also happens whenever the GM wants it to.
Step Eight: What Could Go Wrong?
This, like Step One, can't be mechanized. It might be possible to list everything that could go wrong with the project by following a formula, but we don't actually need that--what we need is a list of everything interesting that could go wrong with the project--especially if it interacts with other events outside the project in the setting.
The idea is the GM lists theses things and build them into a table that you roll on if the Project Manager rolls a failure.
If the project is going to be done relatively quickly (improvising an explosive in a few minutes) anything more than thinking up d4 disasters that could happen if a roll fails is probably overkill, but for longer-term projects you'll want to work up a full list, bespoke to the project. The table of things that could go wrong will be hidden from the players, though intelligent ones might have their PCs roll to figure out what some of them might be.
Here are some broad categories to think about, you should probably be able to think of multiple specific problems that can go wrong for each category of problem that makes sense for your project:
Supply Problems (Regular)
Something you assumed would be plentiful during the project suddenly isn't. This isn't usually just money/resources, it's some specific substance or affordance (copper, office space, guttapercha, latex, dilithium).
You
shouldn't put it on your table if, because of the nature of the set-up, it would logically just mean the way to deal with this is you pay more or it takes longer, or delegate the getting a new source of supply to some underling. That can be handled by the failed roll itself, which already abstracts that by telling you the project takes longer now. I know all the different-colored pushpins makes going to Staples seem like an adventure but it isn't.
This
is interesting and should go on your table if you can think of a way that getting it would require going somewhere interesting or through somewhere interesting, negotiating with some interesting NPCs, or otherwise engaging the setting in a new way. Or if you can think of a way to create an interesting choice that might have knock-on effects down the line (extend the project by three months or source snail mucin from the ferocious insurgents of the Jade Inquisition, thus de facto taking sides in the Impudent Wars?).
Supply Problems (Exotic)
It has become clear the project now requires the Eye of Nachryllax from Planet Oob, Negaplasm from beneath the Orparinth, a manuscript jealously guarded by an unscrupulous collector with a dark reputation, a kind of rocket fuel currently only in the hands of the Axis, etc.
Basically something unique and germane to the project that obviously requires a perilous journey, investigation, quest, heist, etc.
This should go on your table if you can possibly think of a reason to get it on there.
Personnel Problems (Regular)
Some NPC on the project is a jerk. Or sucks at their job. Or their face is melting. Or 200 of them are jerks or suck at their job. Or it's hard to say what's wrong with them, but they walk 3 feet off the ground now and only speak in Masonic cyphers and it's weird and needs to be investigated.
These can range from "the workers are bored so morale is low and nothing's getting done" (so built a little movie theater on base) to "mutiny" (so kill them).
This shouldn't be put on the table if there are no NPCs working on the project, or if the obvious solution would be "fire them and get someone else" or "pay them more" or "protracted union negotiations". This is all abstracted into "The project takes longer".
This should go on your table if dealing with the person(s) is gonna be weird and/or dangerous, or will force the PCs to make a choice that (like with Supply Problems, Regular) may have interesting knock-on effects down the line.
Personnel Problems (Specialist)
The project requires a specific lithographer to the stars, the only living translator of the Tongue of the Greening Clay, a girl with green eyes, a foe known for their fangs and furled talons, etc.
Basically someone that obviously requires a perilous journey, investigation, quest, kidnapping, negotiation, etc.
This should go on your table if you can possibly think of a reason to get it on there.
Weather and Natural Disasters
Some random encounter tables have weather and natural disasters on them already--if they're not and could affect your project, put them on there now.
Don't use this if the only effect would be work takes longer.
Do use this if it might damage safety measures on the project, thus exposing it to new and interesting dangers, or if navigating the natural disaster or weather would be an interesting problem in itself.
Competition
Somebody else is doing the same thing you are--or something similar.
Don't include this if nothing they do can actually affect you getting your project done, or if there's nothing the players could conceivable do about this competition that would be fun to play out or make decisions about.
Do include it if this means crucial personnel, supplies, etc disappear, if it would inspire sabotage, if it would force interesting choices for the PCs about how to continue that might change things down the line for them.
Politics
Some Fred Hicks has decided the project is
bad and should be condemned or some Jessica Hammer has decided the project is interesting but
has some concerns they'd like to discuss.
Don't include this if the concerned parties have zero power to fuck the project up, if addressing their fuckery can be accomplished by simply by spending more time/money (already addressed by the fact the failure is costing the PCs time) or if there is nothing the PCs could do about the fuckery.
Do include this if the politicker presents interesting choices, might be converted to an ally or pawn if you play your cards right, or would present an interesting foe.
Patron Failure
Whoever's funding the project is threatening to stop. This is different than politics because there doesn't even have to be a reason related to the project--whoever's bankrolling could suddenly have an unexpected baby on the way.
Don't include this if there's no patron (obviously), if there's nothing the PCs could do about it, if what they'd have to do about it amounts to walking over there and making a Charisma roll, or if the playess aren't the ones who are invested in the project getting done.
Do include this if you can make the patron's problem an adventure to solve or can find a way the patron's issues can force an interesting decision.
Patron Meddling
The people funding the project want to do something fucked up with your research.
Do's and don'ts here are a lot like Patron Failure.
This is one of the things that may lead to a...
Moral Dilemma
Like politics, above, only the issue raised by the project is
real. The Forbidden Tomes are forbidden for a reason, getting enough whatever the fuck shit out of the ground to power your whatsit endangers the native spotted whatsit, etc.
Do not include this if either of the choices presented basically ends the campaign, or if either of the choices would not genuinely have any effect on what will occur going forward, or if the dilemma would basically force the players to choose between having fun by playing out the interesting game scenario or playing the kinds of characters they like. Like: don't make Not Killing The Orcs the
only morally appropriate course for the appropriateness-obsessed cleric player if not killing them must mean the cleric doesn't get to do the cathedral-building project they think is so fun.
Do include this if both the dilemma choices have interesting consequences down the line or the dilemma has at least one hidden solution you can think of requiring adventure or bravery or cleverness. If you've got one the players probably have more.
Hidden Depths
The project results in discoveries :) That are kind of a pain in the ass :( The grimoire reveals the king is not the real king, the warp engine opens a rift to a dimension of sentient ice crystals, the cure turns your sister into a wereleopard, etc.
Do not include this if it just means the campaign is now all about the new thing (unless it seem like everyone would be into abandoning the current plot to go check it out) or if the discovery just means the whole project takes more time, or if it would make the players go "Fuck this let's do something else".
Do include this if you've got a good idea for a way the discovery is both inconvenient and an adventure hook.
The Adventure Reacts
An important thing to remember: unless this is a Hook Factory, this list is going to be employed
in addition to the random encounter table for the campaign or whatever other event-engine is running simultaneously. So this table does not itself need to include things like "Goblins notice your site and begin to attack your half-constructed barber shop" because presumably if hostile goblins are in the area you've already accounted for that somewhere else in the adventure design--or if there's already a rebellion against your empire they might notice you're building another orbiting genocide satellite.
What the foes
do once they show up may change, though, and the hubbub of activity may force you to roll on the random encounter table more often. Also: there may be some creatures or events on the random encounter table that are
less likely--jaguars don't like the sound of power drills.
Hook Factory Effects
This is where you build in any possible weirdness directly caused by the project itself existing or half-existing. If the half-built dimension gate has a chance of bringing in Demogorgon or turning people into xanhthan gum, here is where you put that.
Step Nine: Get Started
You have all the info you need to begin the project in the campaign. You know how long it'll take, you know when to check progress, you know what that roll looks like, and you know what the consequences are of things not going smoothly.
Step Ten: Keep Thinking of Consequences
At any given point, the PCs could get to the end of the building phase and make that final test roll.
If that test roll is a failure, you the GM want to be ready with the most interesting possible consequence of failure that you can imagine.
If that test roll is a success, make sure you have something for them to do with their new toy.
As the situation develops over the game sessions, keep refining your ideas of what these two scenarios could be based on what's happened so far.
Enjoy!
------
This idea was
sponsored by Paolo Marino and is part of a consultation job for him he wanted me to do.
If you need me to consult on your game stuff: zakzsmith AT hawt mayle
