--- title: Integrated Circuits tags: Science --- # Integrated Circuits - /tg/ edition (Mothblocks) ## Abstract Integrated Circuits (henceforth known as circuits) are a Wiremod-like system to allow for creative players to interact with the world through the use of custom built automated machinery. The machines are limited by time to create, evaluation time, and power consumption. Players are encouraged to spend time experimenting with imaginative designs, while also needing to optimize their works. ## Goals 1. Avoid "cook booking", and encourage creativity. While useful circuit designs will make their way around, players should feel inspired to create designs of their own, and feel like it is easy to do so. 2. Be deep, not needlessly complex. The mechanics should be easy to pick up, and the UI should be easy to use. The challenge should come from optimization (power usage, evaluation time) and from thinking through the logistics of a design, the same challenges that come through traditional engineering. 3. Aim to provide general functionality. Components that are too specific will feel like they constrict design. 4. Assemblies that interact with the world must be in shells that cannot be picked up (oranges requirement). ## Non-goals 1. Attempt to be directly comparable to old Hippie circuits, or whatever other circuit systems exist. /tg/ circuits are going to be implemented in a clean room manner to help avoid the problems brought on by other systems. 2. Persisting circuitry. Hippie circuits had the circuit printers, which created circuitry through JSON. This will not exist at all in a player accessible form. <sup>(This should be a given from non-goal #1, but I thought it was worth noting)</sup> <sup>PERSISTING_CIRCUITRY_ADMINS</sup> 3. Provide weaponry. While it is completely fine, and even encouraged, for players to use circuits for antagonistic purposes, these should come from designs that make clever use of their environment (such as a circuit that locks people in a room and gases them) rather than unimaginative weapon components. ## Envisioned Designs These are designs that are not necessarily expected to be created, but rather are focuses on things that *should* be creatable. - Suit sensor alerter - Arcade game player - Vibebot - Clap activated lights ## Overview Circuits comprise of a shell and components. Shells dictate form factor (wall mounted, handheld remote, etc), component capacity, usable components, and builtin signals (e.g. remotes provide a button when used). Components comprise the logic of a circuit. Components represent individual operations, such as a circuit for adding two numbers, or a circuit for saying something. Components have inputs, outputs, input signals, and output signals. The user wires the outputs of components into the inputs of others. Input signals are used to tell the component to act, and are fired by output signals, which are fired through the component itself. Some components must be "hard coded", meaning their behavior is influenced by the user *before* putting it in the circuit and cannot be manipulated by other components, such as the "constant value" component. <sup>HARDCODED_COMPONENTS</sup> For example, a component to add 2 + 3 and speak the sum when pressing a button in a remote control shell would look like: <sup>CONSTANT_VALUES_HARDCODING</sup> ![](https://i.imgur.com/lFP6zLi.png) ## Shells Shell capacities are not explicitly defined (and are subject to change) in this document, as numbers will be tweaked through playtesting. This is simply to provide an explanation of the vision. ### Compact Remote A handheld device with one big button. **Portability:** Normal item **Capacity:** Small **Output signals:** Pressed ### Controller A handheld device with several buttons. In game, this translates to having different signals for normal usage, alt-clicking, and ctrl-clicking when in your hand. **Portability:** Normal item **Capacity:** Medium **Output signals:** Triggered (used in hand), Alternate trigger (alt-click), BIKESHED_ME trigger (ctrl-click). ### Wall Mounted Device A shell that can be attached to the wall to fire a signal when pressed. **Portability:** Wall mounted. Normal item beforehand, but will not process logic. Can be unmounted with basic tools. **Capacity:** Large **Inputs:** `Display: string[5000]` (5000 is the max length of paper) **Output signals:** Pressed **Special:** When `Display` is non-empty, using the wall mounted device will open a screen with the display text as markdown. ### Bot Immobile (but not dense) shells that can interact with computers using a USB cable (see Computer/Machinery Interactivity). **Portability:** Cannot be picked up. **Capacity:** Large **Special:** The only shells that can use USB cables. ### Drone **Portability:** Cannot be picked up. **Capacity:** Large **Input signals:** Move North, Move East, Move South, Move West<sup>DRONE_INPUTS</sup> **Special:** The only shells that can move on their own. ### Server The largest shell possible, but must be kept in one place. Useful as a single source of truth (for example, housing the database of a chatroom server) or for housing logic in one place so its more efficient to create extra circuits that would simply perform I/O with the server. **Portability:** Cannot be picked up. Must be wrenched down in order to function. **Capacity:** Very large ## Components The brains of the circuits. This is an incomplete list of whatever comes to my mind at the time of writing. Components should be plentiful to provide a vast array of unique designs. --- ### Logical Utility ### Binary Operators Condensed for clarity's sake. Think add, subtract, multiply, and divide. #### Inputs - A: number - B: number ### Constant Value Produces a constant, hard coded output. #### Outputs - Value: any ### Delayed Signal When fired, fires a signal after a given delay. #### Inputs - Delay: number { >= 0.9 seconds, the standard delay for signals } #### Input Signals - Fire #### Output Signals - Fired #### Outputs - Result (called Sum, Product, etc): number, or null if either A or B is null/non-numeric ### Equals/Not Equals Checks if two values are equal or not equal (two separate components). #### Inputs - A: any - B: any #### Outputs - Equal/Not Equal: boolean ### Index List Outputs the value at a given index in a list, counting from 1. #### Inputs - Index: K - List: V[] | Map<K, V> #### Outputs - Value: V | undefined ### List Length Gets the length of the array part of the list. #### Inputs - List: any[] #### Outputs - Value: number ### Numerical Comparison Condensed for clarity's sake. Think <=, >=, etc. #### Inputs - A: number - B: number #### Outputs - Result: boolean, or null if either A or B is null/non-numeric ### Signal A basic signal that can be fired and hooked onto. #### Input Signals - Fire #### Output Signals - Fired ### If/Else When fired, checks if the given condition is truthy (not 0, false, or null), and fires an appropriate signal. #### Inputs - Condition: any #### Input Signals - Compare #### Output Signals - True (fired when condition is truthy) - False (fired when condition is falsy) ### Is List/Number/String/Bla bla bla Condensed for clarity's sake. #### Inputs - Input: any #### Outputs: - Is (Whatever): boolean ### To String Converts the input to a string. For example, references will give their name. #### Inputs - Input: any #### Outputs - String: string ### Random Number Produces a random number in the given range where x has the domain of min <= x <= max. Will not produce an output until rolled. #### Inputs - Minimum: number - Maximum: number #### Outputs - Output: number #### Input Signals - Roll ### RAM Stores a value that can be retrieved later. #### Inputs - Value: any #### Outputs - Value: any #### Input Signals - Update stored value --- ### SS13 Utility ### Get Species Gets the species of the input. #### Inputs - Input: Reference[Mob] #### Outputs - Species: string, or null if the reference is null/invalid ### Is Mob/Humanoid/Object/Structure/Bla bla bla Condensed for clarity's sake. Analogous to `ishuman` etc. #### Inputs - Input: any #### Outputs: - Is (Whatever): boolean --- ### World ### AI Vox Uses the same vox system as the AI to speak text. Sets an output for any words that couldn't be spoken. Has a long cooldown. #### Inputs - Text: string #### Outputs: - Failed: string[] #### Input Signals - Speak #### Output Signals: - Speak failed ### Emote Recognition Fires a signal when something emotes, and updates its state. (Name pending) #### Outputs - Actor: Reference[Atom] - Emote: string #### Output Signals - Emote seen ### Light Comes in the form of a radial light and a directional flashlight. #### Inputs - Red: number { 0 to 255 } - Green: number { 0 to 255 } - Blue: number { 0 to 255 } - Brightness: number { 0 to BIKESHED_ME } ### NTNet Chip Can send and receive messages over NTNet. Larger messages take longer to send. #### Inputs - Data: any - Network Name: string - Network Tag: string | null #### Input Signals - Send #### Output Signals - Received ### Radio Functions like a normal signaller. Fires a signal when something else fires with the same frequency and code, as well as providing a signal to also fire. #### Inputs - Frequency: number - Code: number #### Input Signals - Send #### Output Signals - Received ### Text to Speech Produces a message from the circuit (i.e. "the remote control beeps, '...'") #### Inputs - Message: string #### Input Signals - Speak ### Voice Activator Fires a signal when the circuit hears someone say something, and updates its state. #### Outputs - Message: string - Language: string - Speaker: Reference[Atom] #### Output Signals - Speech heard ## Computer/Machinery Interactivity Circuits will be able to communicate I/O on computers and machinery by connecting a USB cable. Computers and machines that opt in will be able to send signals to components when the state of the device updates (for example, something connected to a supply console might be informed when the computer learns the budget has updated) as well as provide signals for performing actions (such as changing cameras on a security camera console). **As per goal #4, this will only be on bot shells.** USB interaction is opt in only, and some devices will explicitly *not* have USB functionality for the sake of the game, such as the communications console (it would be very annoying for things to automatically call/recall or send cross communications). USB cables provide the following interface, no matter the device, and only one can be in a circuit at a time: --- ### USB Cable #### Inputs - Data: any[] #### Outputs - Most Recent Data: any[] #### Input Signals - Send Data #### Output Signals - Data Received --- The API is very generic, this is intentional. Players are encouraged to reverse engineer the devices they are interested in.<sup>USB_API</sup> ## Optimization To encourage optimization (and to ensure that circuits don't crash the server), any signal fired has a minimum delay of 0.9s, though this can be configured to be higher by the component. Signals will also incur the usage of power from the cell of the circuit, further requiring optimization. Along with the need to optimize signal usage, the limited space of shells should encourage players to create refined, compact designs, rather than sloppy ones. ## Uncategorized notes Components and shells should almost definitely be locked behind some tech nodes. In the prototyping phase, these will be done mostly arbitrarily, though focus should be put during playtesting on how these should be organized. For instance, we may want to provide a lite version of each distinct shell type in one node, going to more powerful versions later on. However, we may also want to provide distinct shell types in different nodes (for example--remotes in one, bots in one, etc). The types of inputs should be rather lax, such as numbers being able to be passed for strings. While it would be easy to enforce people to use components to switch types, I don't think this is particularly interesting. <sup>CONSTANT_VALUES_HARDCODING</sup> - It's more likely that hardcoding will be used instead of constant values in this use case. <sup>DRONE_INPUTS</sup> - There's no real technical reason not to support moving diagonally as well, but is it more fun as a player to solve that problem yourself? <sup>HARDCODED_COMPONENTS</sup> - The actual method of doing this is undecided. It could be just with a multitool, but it might be more intuitive to have a tool dedicated to it. <sup>PERSISTING_CIRCUITRY_ADMINS</sup> - Circuit printers will not be available to players in any form, full stop. However, circuits provide an interesting administration problem without a robust replay system. Thus, it would be a good idea to let *admins* copy circuits in order to inspect for themselves their inner workings. <sup>USB_API</sup> - This seems more likely to me that it would encourage players to look at the wiki (something I want to avoid) or scare them off from making their own circuits.