Reality Fault


Comments on the Demo Area




An Encounter Table


Build A Puppet

BSG Resources



RPG / Dice Math


Reality Fault




Hero System

Magic: The Gathering

New Inquisition



Star Fleet Battles


Bob's Page













Daily Goodies

Bob's Page

Reality Fault

BSG Resources


A generic term for capabilities or objects that enable or enhance a game interaction.
An asset that is used as part of an economic or production action.

Production Widets

Do widgets expire, or have a limited amount of output? This could be used to place "veins" of stuff that can be played out. (Do we care what happens to these widgets when they're empty? Can they be auto-deleted? Should they?)


A widget has at least one rule.
time [ {res} ... | res ... ] = res ...
Units of time tracked by the game. Can be zero. Time may not yet be defined wrt the game. Let's use h=hour, d=day, w=week, m=month, y=year.

A "pass through" resource. Some resources are not consumed. For example, a production widget may require trained personell to represent factory workers. They are not consumed and appear unchanged at the end of the process. If you want a resource to be "changed" by the process have the widget consume the resource and produce the desired type. For example:

w.8 {} tp =
Eight weeks, one Elite Military Trained Personell and one Trained Personell produces one Elite Military Trained Personell (pass through) and one Military Trained Personell.

a "consumed" resource


a produced resource

Default count for any resource is one (1).
w.1 {tp.1} metal.2 = mfg.stuff.1
is the same as
w {tp} metal.2 = mfg.stuff

Command line

There are two types of instructions that are associated with a widget; rules that describe input/output and commands that control when and how a widget is triggered.


There should be some way to command a widget to start a task when enough resources are in the same room. Perhaps this could be some kind of room trigger, i.e., when a new object appears in the room, the room has instructions to poke the widget. The room (per se) would not need to contain any logic associated with widgets or resources.

A room could be set up as a factory with several widgets. When resources are delivered, the room pokes all the widgets, triggering the production of a "spaceship parts" resource. When those parts are produced (delivered to the room), the room pokes all the widgets again. If one is a "build a spaceship" widget (and there are enough "parts") it starts to build a spaceship.

Resource widgets do not require constant "timewise" attention from the system. None of the interactions need to be resolved until the room is examined. (Schrodinger's Widget? :-) Let's say that there is a room designated as a "Gas Station." It contains a widget with one rule:
w {tp} chem.4 rad = mfg.fuel

Every time this rule is triggered, it consumes (if available) one trained personnel, four chem, and one rad. At the end of one week, one mfg.fuel is produced and the trained personnel "reappears."

From the widget's perspective, the sequence of events is slightly different: The trigger event occurs, and the room pokes the widget with the current date.

Widget wakes up. If not already producing something, it checks its rules to see if there are resources in the room that fufill one of the criteria. If so, it takes them and reports the completion date of the task. If not, it reports the current date.

If it is already producing something it checks to see if enough time has passed for the task to be complete. If so, it produces the item and pass-through resources. In any event, it reports the completion date of the task.

Notice that all the widgets in the room effectively "save up" time to be used later. The room trigger that pokes the widgets loops until all the widgets report "no action" and then pokes all the widgets with a "reset" that sets all widgets to the current date.

Frex, let's say that you have a widget that (given sufficient resources) consumes three "goop" resources and produces one "parts" resource in one day. It is in the same room as a widget that consumes six "parts" and produces a "thing" in one week. On day one, you put 40 "goop" resources in the room. This is more than enough "goop" to produce 12 "parts." From a human perspective, the expected result is that each day one "part" is produced. On day seven, six of the "parts" are used to start a "thing." Six days later (day 13), six "parts" are ready, but the "thing" production widget is busy. On day 14, the first "thing" is finished and a second "thing" is started. On day 21, the second "thing" is ready.

From the widget's perspective, the sequence of events is slightly different:

On day one, you put 40 "goop" resources in the room. The room pokes the widgets. The "parts" widget isn't busy, so it picks up the required resources and starts a "parts" task. Nothing else occurs until the room is re-visited.

Eight days later, someone enters the room. The room sends the current date to each widget. Each widget reports its next event date, i.e., the date it expects to be done. Any widget that is not busy reports the current date. (The date passed to the widget by the poke? Which is less system-resource wasteful?) The room sends a resolve command to the widgets with the earliest reported date. Each of the widgets "moves forward" to that date, and (at least) one new resource is produced.

This cycle repeats until all widgets report the current date. In our example, 21 of the initial 40 "goops" are gone, seven "parts" have been produced, and six of those "parts" have been used to start a "thing" task.

Sample List

A mfg.mine.metal widget:
day.10 {tp} = metal.1

A mfg.refinery.fuel widget:
d.7 {tp} chem.4 rad = mfg.fuel

A Colony Habitat:
month.6 bio.edibleflora.3 chem = person
tp chem.4 metal.6 = mfg.stuff.1

Big vs. Little projects

There are two approaches to production widgets that can be used to construct "big" items. The first kind requires that all necessary resources be available before the widget is triggered and the task usually has a significant duration.
  1. Only one action is required.
  2. All resources accounted for when task is triggered.
  3. No intermediate steps.
  1. "Parallel processing" cannot be used to reduce time.
  2. Trained personnel may not be reallocated during task.
  3. All resources must be available before triggering the task.

The second approach actually uses a series of widgets that produce intermediate resources that are used to construct the final result.
  1. Intermediate tasks can be started before all resources are available.
  2. Intermediate resources can be stored or traded.
  3. Simultaneous intermediate tasks can be used to reduce time.
  4. Trained personnel may be reallocated between tasks.
  1. Multiple actions required.
  2. Increased resource management.
  3. "Parallel processing" requires more trained personnel.
  4. Requires multiple types of widgets

m.6 {tp.4} metal.12 chem.12 rad mfg.fuel.4 tp = mfg.fighter_group

-- v.s. --
m {tp.4} metal.2 chem.2 = mfg.fighter_parts
m {tp.4} metal chem rad = mfg.HP_engine
m {tp.4} mfg.fighter_parts.4 mfg.HP_engine metal.3 chem.3 mfg.fuel.4 tp = mfg.fighter_group

Are there any ramifications for "pass through" resources? For example, is this type of relationship always true:
(m.6 {tp.4}) = 6x (m {tp.4})


  • Chem
  • Air
  • Water
  • Metal
    • Light
    • Heavy
    • Cygnite
      (Source of "Swan's Eye" gem stones. Industrial grades are used in the production of energy weapons.)
    • Zortium
      (Used to fuel advanced power plants.)
  • Rads
  • Bio
    • Edible Fauna
    • Edible Flora
    • Pharmaceuticals
  • Personnel
    (Could be broken out into: tp.pilots tp.admin tp.sci tp.lawyers)
  • Specials
    • Monopoles
    • Neutronium
      (Used in the construction of high-density materials.)
  • Mfg
    • Foodstuffs
    • Fuel
    • Medical Supplies
      • CON
        (Carbon, Oxygen, Nitrogen)
      • Meth
    • Extraction Equipment
      • Light Metal
      • Heavy Metal
      • Chem
      • Radioactives
    • Refineries
      • Light Metal
      • Heavy Metal
      • Chem
      • Radioactives
    • Fuel

Copyright © 1998 Bob Simpson. All Rights Reserved.
Last updated: 1998-Nov-07

Last modified: 2002-Jun-13 23:02:20

All material on this site is
Copyright © 2001-2018 Stormtiger, LIC
unless specifically indicated on each document.
All Rights Reserved.

Questions? Problems? Contact the site's Administrator

Valid HTML 4.01!