Big Technical Project

An engineering module for MOSAIC Strict by Dan Maruschak

This module is for collaboratively working on a large technical project. It could be used for software developers coding
a new app or a plucky team of inventors trying to build a mech to save their city from kaiju attacks. Players who have
characters working on the project can't know for sure how well the project works until it's tried, so one person will play
a TechMaster™ role and maintain some mechanics that remain secret from the other players.

Spec the Project Use Cases

Work collaboratively to map the contours of the project
onto the mechanics. You'll need 5, 7, 9, or 11 individual
modules as well as one "integration" module that
represents hooking them all together into a unified whole.
Develop a short abbreviation for each module for
concise notation (and it also feels more technical). For
example, a website project might have User Interface (UI),
Database (DB), Backend (BKND), Security (SECR), and
© 2021 – Dan Maruschak – All rights reserved.
The basic mechanical building block for determining
whether the project works is a USE CASE. A USE CASE has
two parts, a quality threshold and a list of one or more
matrix cells. For example, 3: UI-3 DB-2 INTG-4. If all of
the cells in the list have a quality greater than or equal
to the threshold then the project works for the case in
question, otherwise it doesn't. The TM never shares the
particulars of a USE CASE with players, only higher-level

User Authorization (AUTH) modules all joined by the information like whether something works or not.
Integration (INTG) module. Level of delicacy Woops Die
For each module, decide how delicate it is to work on: for Competent d4
some you'd expect anyone with the appropriate technical Specialized d6
competence to be able to work on it, some you'd expect to
World Class Experise d8
require specialized training, and some you'd expect world-
class expertise to be needed. (You're not forbidden by the Working on the Project
rules from working on something beyond your skill, but be
When you devote significant time and e ort to the project roll
aware that it's risky.) Not all projects have all types, work
to see how much progress you make. The dice you roll are
together to figure out what's right for the particular project in
based on how skillful your character is at this type of work:
your game.
The TM maintains a matrix of cells to track the project. The Novice d4
rows are the modules of the project (put INTG at the Competent d4 d6
end). The number of modules maps to the range of a d6, Expert d4 d6 d8
d8, d10, or d12 so you can use it to select one at random World Class d4 d6 d8 d10
when necessary. Note the WOOPS DIE for each module. The
You roll your dice in the open and the TM secretly rolls the
columns of the matrix are four cells for each module to
WOOPS DIE for the module you're working on. Any of
track the “quality” within that module. Set the initial
your dice that come up greater than or equal to the
values of the matrix based on the starting situation:
WOOPS DIE will increase the quality of a cell in the
zero for building from scratch, roll a d4 for each cell if
TM's matrix. However, any die that rolls less than
you're modifying, tweaking, or repairing something
the WOOPS DIE will cause the quality of a random cell in
that already exists, and set to fours across the board if
the module to decrease, representing bugs or other
it's something that already exists and is known to work well
problems introduced by your tinkering. The TM rolls d4s
and the rest of the project will be built around it.
for each increase or decrease to determine which cell in
To get everyone on the same page, discuss how granular the module to modify, being careful not to reveal how
the group will be when it comes to the USING THE PROJECT many were increases or decreases.
mechanics, and what kinds of things would count as
typical versus being pushed to the limits.
 Tests
If it's possible to test things before use, either via
simulation or in a controlled environment, the test results
can be determined by evaluating the USE CASES in a test
suite. When you spend time and e ort developing tests
you can choose to generate 2d4 cases for a single module
or 1d4 cases for the entire project. Choose a die size for
the intended intensity of the tests, bounded by your
expertise: d4 for novices, d6 for the competent, d8
for experts, and d10s for world-class. The TM
secretly rolls dice to generate the USE CASES, which go
into a test suite you specify. For module-specific tests the
TM rolls the intensity die and a d4 for the cell of that
module. For full-project tests you can either specify one
module that must be included or leave it to randomness.
A full-project USE CASE includes two modules as well as
the INTG module, with a separate d4 roll for each one.
Since only the TM knows the precise results you can never
know for sure how well the USE CASES in your test suite
correspond to the di culties of getting the project to work
in the real world, but since you know the die rolls that went
into them you aren't completely in the dark. Only trying it in
the real world can tell you whether your project actually
works, until then the best you can do is relying on your
judgment about how well you've tried to test. When you
run a test suite the TM will tell you what percentage of USE
CASES pass, and for full-project tests will give an indication
of at least one of the modules causing failures.
Using the project
To see whether the project works in a particular situation,
the TM generates a set of use cases to compare it to.
Once you generate the USE CASES for a particular purpose
they're fixed, you'll always use the same set of USE CASES
to see if the project works in the situation – the quality of
the project might change but not how di cult or easy
it is to accomplish this task with the project. Each
time the project is used in a way that's di erent from
something it's been used for before, the TM should
generate a new set of cases for that situation. Whether
something is di erent enough to require a di erent set of
cases is a judgment call, which will be related to how
granular you want these mechanics to be.
Trying the project in the real world always
requires three-module USE CASES, at least one of
which is the INTG module. If the way the project is
being used suggests that some modules are
especially relevant then intentionally include at least
one of them in each USE CASE, and randomly
determine the others. Use d4+1 to set the threshold
for these USE CASES. Generate eight full-project USE
CASES for a typical usage of the project, and
sixteen for a situation where the project is being
pushed to its limits.
The number of USE CASES that work relative to the
total number can be used to gauge how well the
project works. If the quality exceeds all the
thresholds then it works perfectly, if none of them do
then it's a disaster, and if some pass but others don't
then it's somewhere in between. For a complex
system even a small amount of nonfunctionality can
be a big problem. The TM should figure out what the
degree of success or failure translates to in the game-
world for this project and describe it in those terms.
The TM should use the modules involved in the non-
passing USE CASES to think of a way that the bug or
problem actually manifests, and should be clear
enough that the players can understand which
modules are involved in the problems (and clarifying
explicitly if there's confusion). This lets the characters
engage with fixing the bugs or working out the kinks, if
that's possible.
Damage
If the project is damaged in some way, the TM can
use dice to update the quality levels to reflect the
problems caused by the damage. Roll a pool of d4s,
and each one will show which cell of the module
should be reduced. Sixteen d4's would be equivalent
to catastrophic damage to a module, 1 or 2 would
be something that called for minor repairs.
Choose a number of dice based on how
intense the damage is compared to those
extremes.
4
1 1
3
2 3 2
1
1 1 1
4) 4
( d 3
I 4) 2
2
4
1. U B ( d ) 2
( d4 1 0
D 1
2. K ND d6) 4 0
B (
) 0
3. E CR (d4 0
S
4. TH 4)
. A U G (d
5 T
IN
6.