Mechanical Fact Sheet for Role-playing games (RPG) and Portals

Mechanical fact sheet

The mechanical fact sheet is basically like an operation manual combined with diagrams and references to other controlled documents that you will use in both game creation and game play. 

If you read schematics that’s great, but most people playing at your role-playing table won’t have a clue. So, with the majority gamers in mind, here's what you'll need to do.

As an alternative to schematics, a mechanical device/ apparatus such as a techno-portal, mechanical door, or series of levers and pulleys can be visually presented in a prepared network diagram and/ or block diagram.

Adding a chart or graph can help with indicating where thermostats, frequency adjusters are located on the device or construct (considering calibrated knobs for operating various machinery).

A block diagram tells players that ‘something’ needs to be visualized, but the system being described is readily understood. This is very important if players should happen to acquire scrolls and parchment in the game which indicate the proper usage of such devices as a draw bridge, crude elevator shaft, mechanical door, etc.
The location of secret doors may be included on both the master control document (MCD) and the mechanical fact sheet.

If there are a number of mechanical objects and secret doors within a structure, such as a building, then these should be listed in your controlled documents. Mark the MCD with the various mechanical fact sheets (abbreviate as MFS and a control number on the MCD document) for each construct or device.

Consider the map on the left, marked with the circle containing a secret door - marked S. This map contains multiple constructs which I have included in my own MCD as separate MFS documents. As a side note, the MFS could contain all of the mechanical apparatus in the entire game, but the document would become very long, and would cross reference with other maps. It is better to implement everything into the MCD, and then write up the MFS for each construct - or an MFS containing only the constructs contained or residing within a particular structure, such as the drawbridge belonging to a castle on one of your maps. The only exception to this guideline is when the construct is universal, for which you need only write one MFS, and label it. Then, you would reference that MFS by a number/ label in any future games you create.

Closed-in structuresSeen the movie Gladiator or Spartacus? Well, even the popular films like Star Wars: Attack of the Clones features a scene or two with an arena in it. So, I'll reference the same here for the sake of explaining in very simple terms how to write up an MFS for one of these structures.

First off, this is a game about portals. So, we're really concerned here with the operation of these super constructs. 

 This arena has four major portals, one secret door, a terrace encompassing the battle arena, and a pole/ pillar portal at the dead center of the arena floor. We want to remember how all of these constructs work when we're administering the game to our friends. So, we take some time and effort to chart these portals, and log their operation into our MFS!

Each portal in the example above is a death trap to the contestants--gladiators--in this particular arena. We have a fire portal, a nature node or earth portal/ tree portal, a giant portal (guess what comes out of that!), and the nefarious necro portal.

Now it is only obvious that the main point of the MFS in this instance is going to be the various monsters the players will encounter. As well, we want to know how the portals are activated (and if they can be closed by any means mechanical or magical), and exactly how for each portal. If the portals are timed, meaning that one non-player character or monster emerges from one portal at a time, then we need to note how many rounds the players have to kill the monsters before a new encounter occurs from another portal opening.

In this case, I've made a slight adjustment to the portals by adding a central pillar which triggers a trap, but also rewards the player characters with some weapons. All four portals open, should a player character remove a weapon posted on the pillar. The targeted weapon which will trigger the trap needs to be considered by the game administrator. This is something you will note specifically on your fact sheet. Believe me, it will save you from an argument when one of the players grabs the booby-trapped weapon.

 Some mechanical doors and portals require keys to open the arch to the threshold within, or to activate the portal power source. There are keys which player characters can slide through a card reader. Other doors require a twist and a turn of a metal key. And, there are heavy metal doors which require fuses to be inserted to operate their internal machinery. Panels may require player characters to acquire some idea as to the operation of various dials used to adjust pressurization within chambers, such as may be the case with a high tech gas portal, ice portal, or hydro portal (metal and water portals combined into a super science machine).

Other portals require magic to operate them, or to pass within their thresholds. See the picture below for an idea of what happens when the player character forgets to dispel a death spell on a portal made of an obelisk representing the elder gods of the greater portals.

 

The foolhardy, hasty, or ignorant player character can meet his or her end in a number of nasty ways. These means are just as fun writing up as the operation of such devices in your game design. Consider it. Revel in your wickedness when you design traps for portals. Electrocution, gas, fire, drowning, burying, spiked pits or pits filled with zombies, mind wiping spells, and teleport spells are called great fun for the dungeon master!

There will be times when you need to write up the MFS for NPC's. These rarities are reserved for robots and cyborgs, golems, and cybernetically enhanced undead.

Consider robots in a battle situation.

Robots are unmanned machines, which gives them the advantage of not feeling any pain--similar to encountering the undead in a classical Dungeons and Dragons game.

However advanced a robot is, it is still a machine in the classical sense of the word. It has a system, must follow that system, and cannot break away from its own system. Knowing this much detail about a robot is usually not necessary, unless it is beyond the players' ability to physically damage it. In such cases, you'd create a block diagram of the machine's general functionality.
Most of the time, the weak point in a machine will be something in the armor or sensory design of the machine.

 For instance, we could say that the inverted pic of this robot reveals some weak points in the armor at the back of the legs. The sensors on both sides of the head, and the antenna at the crest of the helmet, are exposed and unprotected. As well, some call-outs could be added for the pelvic area and lower torso, generally indicating where the armor is weakest.

Over on the right I've posted a diagram of a scout robot. This little bugger follows an eye sensor on short legs that it uses to hope from here to there. The back tail provides ballast for an otherwise heavy optical component on such small support legs. This combination makes the robot unit difficult to hit with projectiles, as the size is less than a foot in length, and only half that in height from the ground. A pack of these machines can scout ahead of a group of cyber rangers or hunters, and scan an entire base or space station in a very few minutes. If armed with a self destruct program, these robots are hopping hand grenades. 

The weak points you would indicate on the MFS include the lack of armor, as well as the overly large eye sensor, making it the only component readily targeted by a firearm or projectile weapon.

As well, it has a systematic drawback. It can only run a simple one mission program before it retreats or shuts down. And, there is the matter of the sensor only being able to see objects via infrared. Adding other optical changes to the sensor, such as a video feed and remote control, would thus change all of these weak points.

Drones and flying robots tend to be remote controlled or piloted by a complicated A.I. entity. These robots need to be described in as much detail as possible on your MFS.

Don't forget to include all MFS in your MCD. For more information on the creation of controlled documents for role-playing games, read my book Ultimate Portal Masters Guide.