[] Training Hazou : Research Sealing Modularization
Edit: This entire thing is longer and more detailed than I intended, but I think there's a lot of things deserving critique in here and would appreciate anyone with the patience to read it all. If you're not one of those people, feel free to skip to the
Research Plan and
the orange bits.
Introduction: At the moment, sealing looks like the good old days of programming or electrical engineering. Where each program or circuit has to be lovingly crafted bit by bit in order to work efficiently within the constraints of the system at the time, whether those constraints are imposed by memory, power, die space, or inefficient components. These constraints don't seem to exist in the same sense for sealing. Instead our constraints are correctness and reproducibility. Sealmasters have to be extremely careful and efficient because every additional stroke in a design is another place where things could go wrong, and when things go wrong in sealing they go extremely wrong.
Thing is, Hazou has Iron Nerve. Iron nerve makes it easy to reproduce mechanical actions perfectly. If Hazou can get a seal right once, he can get it right every time. However, if he follows the standard paradigm of sealing he still has to perform a slow and dangerous development process in order to create the first seal of any kind.
Instead we want Hazou to change his style of sealing and his design process to make it more modular. This would allow him to create small seal components with his current process, but combine them into more complex assemblies cheaply and easily, with significantly less risk.
Goals: Convert Hazou's sealing style into one focused around small, simple components that can be connected together into larger assemblies. Ideally each new component can be researched as a new seal with the standard rules, but any seals made up of already existing components can be created very quickly with a significant bonus to safety during their creation and testing.
Details: Components are treated as discrete functional blocks, with well defined interfaces that govern how they can interact with each other. These components will have a notion of composition, much like a strong type system in a modern programming language, that will allow him to examine the seal and efficiently catch errors
before any live testing.
All components will have the following properties:
- Core Function: This is just the main thing the component does.
- Configuration Properties: These are properties that are set when the component is written down, but are designed to be easily chosen and to work over a lange of possible values. Like the color of a light emitting component, or the radius of an explosive component. It's assumed that there's an output corresponding to each configuration property, so that other components can see how other portions of the seal are configured.
- Interfaces: These are inputs and outputs to each component that can be connected to other components, and can carry signals of various types. Output interfaces can be left unconnected without any issue, and input interfaces should always be tied to some output.
When designing a component, it should be tested to work over the entire range of configuration properties and inputs, so that even when a larger seal fails, it fails because the components were doing the correct task at the wrong time. For instance, a chakra based alarm would fail by triggering at the wrong time, rather than causing horrors from beyond space and time to appear.
Component Research Options:
Light Output (Fixed Color):
- Core Function: Displays a light when the input says so.
- Configuration Properties:
- Color: The color of the light to display.
- Interfaces:
- Brightness: An analog signal input that ranges from 0% to 100%, and controls the current displayed brightness of the light.
Logic:
- Core Function: A lot of them, this covers all sorts of logic gates, constant values, analog signal amplifiers and filters, threshold detectors, hysteresis, stored values, etc..
Chakra Pulse Input (Singular):
- Core Function: A way for users of a seal to input certain configuration parameters on the fly. A chakra pulse by the user sets an internal analog value output. There's no way for a user to direct a pulse to a particular chakra seal input, so all inputs on a seal act the same.
- Configuration Properties: None.
- Interfaces:
- Hold: A digital signal input that tells the seal whether it should accept new inputs or not.
- Trigger Output: Trigger signal output that sends a signal when a chakra pulse is detected.
- Value Output: An analog signal output that captures the value of the last chakra pulse detected.
State Machine:
- Core Function: Allows Hazou to define an arbitrary state machine, with various input triggers causing state transitions and state transitions triggering output signals. This is primarily a convenient abstraction over the basic logic components that makes life easier for everyone. It's easier than doing the full on digital logic translation, since we could build a generic block that uses a configurable transition matrix rather than creating completely new circuit every time.
- Configuration Properties:
- The state machine itself.
- Interfaces: Arbitrary, changes based on the state machine itself. All inputs and outputs are trigger signals.
Delay Timer:
- Core Function: Delays signals from set input to trigger output. Has an internal countdown, and a waiting state where it's just waiting for a trigger to occur. Always starts in the waiting state.
- Configuration Properties: None.
- Interfaces:
- Set Input: Accepts trigger signals, internally starts counting down. If there's already a countdown, it starts the countdown again.
- Reset Input: When a trigger signal is sent and there's a current countdown, stops counting down and sets the seal into a waiting state. Otherwise, sets the seal into waiting state.
- Trigger Output: Sends a trigger signal when the countdown finishes, then moves into a waiting state.
- Countdown Speed: An analog signal input that defines the speed at the which the countdown progress. Allows for a range of minutes to milliseconds for the countdown to complete. This would be connected to a chakra pulse input in order to provide on-the-fly timing configurability.
- Current Countdown: An analog signal output that allows other components to see the current state of the countdown.
- Is Waiting: A digital signal output that allows other components to see whether the timer is in the waiting state or not.
Sound Output (Frequency-based):
- Core Function: Plays a tone of the specific frequency at some input volume.
- Configuration Properties: None.
- Interfaces:
- Frequency: An analog signal input that controls the frequency the seal should be using. Range from 10Hz to 30kHz.
- Amplitude: An analog signal input that controls the amplitude of the output sound. Should range from 0% to 100%
Sound Output (Sampling-based):
- Core Function: Plays a sound by modulating local air-pressure somehow, in much the same way as a modern speaker.
- Configuration Properties: None.
- Interfaces:
- Position: An analog signal that ranges from 0% to 100% that is analogous to the position of the vibrating membrane in a real world speaker. No matter what the actual method of action is.
Implosion:
- Core Function: Seals all air in a radius around the seal. If destroyed, will release the currently stored air. If the sealed volume is large enough that the inrush shock destroys the component, this acts like a standard implosion explosive seal.
- Configuration Properties:
- Radius: The radius of air to be sealed and the
- Interfaces:
- Store: When a trigger signal is sent while the seal is empty it will store the air within the specified radius. Otherwise does nothing.
- Release: If a trigger signal is sent when the seal is full, it will release the currently stored air. Otherwise does nothing.
- State:A digital signal output for whether the seal is storing air at the current moment or not.
Storage:
- Core Function: Stores objects placed on top of it. When full, a portion of the component displays a kanji symbol.
- Configuration Properties: None, unless the current storage seal has config parameters.
- Interfaces:
- Store: When a trigger signal is sent while the seal is empty it will store the items on top the seal. Otherwise does nothing.
- Release: If a trigger signal is sent when the seal is full, it will release the currently stored items. Otherwise does nothing.
- State: A digital signal output for whether the seal is storing anything at the current moment or not.
Macerator:
- Core Function: Stores items placed upon it, shredding them into pieces. Can release the pieces as a cloud in the surrounding air, and while moving at a chosen velocity. Depending on exact settings and stored objects, can be used to create mist (stored water), fuel-air mixtures (dry wood, coal, or other flammable material), poison cloud (poison), pepper clouds (extremely spicy mixtures), shrapnel bombs (rocks, metal, or other hard things), etc..
- Configuration Properties:
- Particle size: The size for resulting particles of shredded materials. Should be able to hit range from tens of nanometers (talcum powder) to centimeters.
- Aeration Fraction: When released, controls the size of the resulting cloud such that the particles make up some percent of resulting mixture and air the rest. Range from 1% to 100% of the mixture, by density.
- Particle Velocity: The velocity of particles upon release. Should be configurable from a range of 0m/s (still) to ~300m/s (shrapnel).
- Interfaces:
- Store: When a trigger signal is sent while the seal is empty it will store the items on top the seal. Otherwise does nothing.
- Release: If a trigger signal is sent when the seal is full, it will release the currently stored items in a cloud as per the configuration parameters. Otherwise does nothing.
- State: A digital signal output for whether the seal is storing anything at the current moment or not.
Chakra Detection (Spherical,Indiscriminate):
- Core Function: Detects chakra use in the local vicinity. It should ignore the chakra in the seal itself. This version does not attempt to distinguish between chakra users, or other chakra sources.
- Configuration Properties:
- Radius: The radius within which to detect chakra use. Range should go from 0m to as large as possible. Explore possible trade offs with accuracy. Make this an interface if it's easy for shenanigans w/ scanning and triangulation.
- Interfaces:
- Detection: An analog signal output that captures the amount of chakra use detected within the radius. Possibly modulated by the position of the chakra source, relative to the seal.
Sealcrafting IDE: The final step of the seal modularization project is a project to make it easier to develop seals quickly, a basic development environment for seals that allows for very rapid prototyping and possibly testing.
Inert Prototyping: The inert prototyping tool is a board with slots for components that are shaped as squares or rectangles with a minimum 'pixel size'. It looks like the board for a
Klotski puzzle, with grooves that can hold tiles in place securely. Each tile can have a diagram representing a component on it, with inputs and outputs on its various faces.
Because inputs and outputs have specific types, that can't be mixed in a number of well-defined ways, we can design squares like jigsaw puzzle pieces. By carefully choosing the shape of tiles we can enforce design constraints. For instance we can make analog IO interfaces have circular projections/notions, and digital IO interfaces have square ones. That way you cannot connect a digital interface to an analog one without breaking the tile. We could color the inputs on components red, and shape them in such a way that the red bit is covered when there's something connected to it, making it easy to find when we've left unconnected inputs for various components.
This gives us a quick way to sketch out design ideas, and make sure we're not doing anything hugely stupid. If we get a design we like, we can copy it into a notebook and convert it to an active seal.
Akane can help us build this.
Live Prototyping: Admittedly, there's not much benefit to the inert prototyping method over a notebook or chalkboard. However we might be able to take the idea a step further by making the tiles actual seal components, designed so that when the click together they actual seals connect together. To do this we'd use a
pantograph to inscribe actual components onto the tiles from an inert version of the IDE. That way we can click tiles together, and immediately test.
We should also probably find a way to make the boards and tiles cheaply, since we're going to be losing many of them to testing.
Research Plan: Here's a basic plan for converting our sealing style into something significantly more modular and efficient. The intention is that each bullet is an intermediate research goal, and that we can make partial progress as we research getting the benefits of each step as they become available. Likewise, if we roll really well for a research project, we should just move onto the next step in the list and start working on that. I'm also optimizing for safety here, under the assumption that seals with small effects are much more likely to have small failure modes
1, hence getting the light first and testing with that.
- Show the in-character version of this entire plan to Kagome for comments and critique.
- Reverse engineer the casino seal to design the basic light output component. Try to allow choice of color, don't worry about it if it's not easy though.
- Incrementally develop the basic suite of logic components and the chakra pulse input, use the light output component as an output element for testing. A lot of the basics here should already be part of existing seals, just need to be encapsulated better.
- Develop the delay timer and state machine component, using the chakra pulse and light components as input and output. Test each component rigorously.
- Get Akane to help with making an inert version of the Searcrafting IDE for the speed bonus to developing assemblies of components into larger seals.
- Develop assemblies that mimic storage seals, explosive seals, PMYFv1, and Macerator, albeit with lights blinking instead of any actual action.
- Reverse engineer the casino seals to develop whichever sound output component is closest to what's actually available. Again, try to allow things choosing the frequency, but focus on just getting something working, even if we don't get as much versatility as the spec above.
- Convert Implosion into a component that fits into our framework easily, then develop the complete modular Implosion seal. Mind, we already made blinky light versions of the full seal, so this should just have us replace the lights with the actual implosion seal.
- Convert Storage into a component that fits into our framework easily, then develop the complete modular Storage seal using the blinky light version as the base.
- Develop the modular version of the PMYFv1 seal using the blinky light version as the base.
- Convert Macerator into a component that fits into our framework easily, then develop the complete modular macerator seal using the blinky light version as the base.
- Reverse engineer casino seals to develop chakra detection component. Focus on extracting basic chakra sensing component, but keep an eye out for whether the original seals have any directionality and ability to discriminate between seals, friendlies, etc...
- Develop a few other seals as a further test of the modular development process:
- Explosive Mines: You set a timer on them, after which they're armed and any chakra use above a certain threshold within the radius triggers them. Test this with lights and sounds before making genuinely explosive versions.
- Warning Lights: Simple, basically just the casino seals but modified so that they detect chakra use within a shell, rather than a sphere. Two chakra detectors of different radius, where the light comes on when the 'chakra use in the large shell' minus 'chakra use in the small shell' is greater than some threshold.
- Extrasensory: Seals meant to be worn tight against the skin, under padding. When chakra use is detected within radius, they vibrate at a low frequency (using the sound seal) and a low amplitude corresponding to the degree of chakra use. If the chakra sensor detects a lower amount of chakra based on distance, wear a ring of them constantly on thin cloth belt. Otherwise, probably still wear a ring of them constantly on a thin cloth belt, for redundancy and the tinier amount of direction info you get. (See Northpaw) If we can find a way to channel chakra in patterns then we can get basic silent comms.
- Teraport Denial: Time-delayed sealing scrolls. Slap them onto kawarimi capable objects, or throw kunai with them attached into kawarimi capable objects. They get stored right before an enemy can use them, tripping them up. Hell, when mixed with our other kunai+seal based shenanigans this could be Roki v2. Not only will our enemy be confused by our taijutsu, but we're constantly changing the landscape for tacmove in unpredictable ways, since each kunai could do a number of things. Maybe make versions that use the macerator seal instead, creating clouds of sawdust for no particularly good reason. (We can choose macerator settings that are unlikely to create flammable clouds, just lots of wood/stone confetti.)
- Test miniaturization of seals/components with a pantograph, see how small we can get them without them failing or major redesign being needed.
- Test and develop the live IDE for further bonuses to research speed for seals using components that already exist. Be very careful with this.
Proposed Crunch: This will hopefully do two things to the sealing process, reduce research time and increase safety.
If the research project is for a completely new component, then the research requirement is calculated as it is now, taking into account similarity to existing seals and access to similar seals that we can reverse engineer. Likewise, all rolls for safety during R&D stay the same.
If the research project is for a new seal, made up of components that we have already developed, then shrink the base research requirement by some factor corresponding to the testing resources we have, give us some additional dice when testing. You might also want to consider toning down the weird-ass failure modes on these projects, since those bugs should be worked out as we develop and test the components.
Proposed modifiers:
- After modularization:
- research cost = base research cost x 0.4
- testing safety dice = base testing safety dice * 1.5
- After modularization and with inert IDE:
- research cost = base research cost x 0.3
- testing safety dice = base testing safety dice * 2
We also expect a fluffier research time gain simply because new components will be simpler than the entire seal which uses them, and are reusable.
For instance, PMYFv2 would ask for a multi-storage component which doesn't contain any of the other logic the complete PMYFv2 seal has. Developing this component would benefit from the fact that we already know how to make storage seals and the fact that it doesn't include the control logic, but not from modularity. Once we have the multi-storage component, making the surrounding control logic for PMYFv2 will take advantage of the above bonuses.
Voting: Much of the plan is optional, so there's a few things that can be dropped without too much loss.
Here's a quick list of things we can drop: Sound, Chakra Sensing, IDE, Explosive Mines, Warning Lights, Extrasensory, Teraport Denial, Miniaturization, Live IDE. Though you could always change it a bit and see if others copy you, or just ask to stop at a certain step of the research plan.
Vote for versions the research without components like follows:
[] Training Hazou : Research Sealing Modularization (w/o Sound)
[] Training Hazou : Research Sealing Modularization (w/o Sound, IDE)
At the moment my favorite version of the plan drops the Live IDE. It requires a ton of discussion with Kagome and very very careful testing of getting tiles to work well together. It might be worthwhile if it's easy, but we have no idea at the moment. I'm generally leaving it in though, because I think it's a cool idea that might be worth exploring in the future.
[] Training Hazou : Research Sealing Modularization (w/o Live IDE)
1 This is heavily implied by Kagome's last rant. The fact that all the common effects centered on manipulating the strawberry paste, rather than just picking completely randomly from the critical failure table, is very suggesting. This doesn't mean large bad effects are impossible, just less likely.
