BSG Resources
Systems
|
BSG ResourcesGeneral
Production WidetsDo 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?)RulesA widget has at least one rule.time [ {res} ... | res ... ] = res ...
Default count for any resource is one (1).
Command lineThere 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.TriggeringThere 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:
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 ListA mfg.mine.metal widget:day.10 {tp} = metal.1
A mfg.refinery.fuel widget:
A Colony Habitat:
Big vs. Little projectsThere 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.
The second approach actually uses a series of widgets that produce intermediate resources that are used to construct the final result.
Example:
-- v.s. --
Are there any ramifications for "pass through" resources?
For example,
is this type of relationship always true:
Resources
Copyright © 1998 Bob Simpson. All Rights Reserved. |
Last modified: 2002-Jun-13 23:02:20
All material on this site is
Copyright © 2001-2025 Stormtiger, LIC
unless specifically indicated on each document.
All Rights Reserved.
Questions? Problems? Contact the site's Administrator