Black boxes

[IWonderWhatThisAPIDoes]

Idea for a mechanic: Black boxes that perform reversible operations on a set of inputs and outputs (Swap, Clone, and possibly others).

[IQuick143]

Design requirements for black boxes: A) They are invertible operations mapping N objects (incl. empty tiles) to N objects B) Because it is difficult to tell and convey the ordering of the inputs, the operation should commute with permutations of the input N-tuple. C) In order to accomodate things like various objects (Players/Boxes/Other), coloured objects, etc., in a non-contrived way, the operation should commute with object permutations (ex: swap all Player <-> Box). C1) A possible exception could be made to create something like convert Player <-> Box, keeping the colour or something, but that requires some careful consideration. D) Because it is difficult/annoying to specify a "forwards" direction for the box, the inverse of the operation should be the original operation.

For N = 1, this means a blackbox has to be the identity, so it's pointless (unless you weaken C) For N = 2, this means a blackbox has to be either the identity or a swap For N = 3, there may be more options, but the two I found are: Identity (duh) A "duplicator" described by: let x,y,z be distinct objects, then: F(xxx) = xxx F(xyy) = yxx F(yxy) = xyx F(yyx) = xxy F(xyz) = xyz So 3 same or 3 distinct objects get identity mapped (this is a necessary conclusion for any black box N > 2 btw), but two same and one different swap, duplicating the single and destroying the double.

N > 3 has not been so far considered on account of requiring too many inputs / outputs.

More design considerations: Each cycle intersecting a blackbox MUST turn in sync (esp. important in regards to one-way linkages). Theoretically a single cycle can intersect a blackbox multiple times (which would probably make level design easier, given that arranging 3 cycles turning in sync is

UI considerations: The blackbox could perhaps be split into individual boxes, connected with a wire or something, to avoid level layout difficulties of trying to shove 2+ cycles through a single rectangle, if each blackbox is just 2 or 3 individual boxes, they can be easily laid out on the cycles like vertices, instead of forcing yet more geometric constraints. Only downside is it makes it more difficult to parse that all segments of a blackbox are connected, especially in levels with potentially multiple blackboxes.

[IWonderWhatThisAPIDoes]

Don't have a proof of this, but it seems that the mechanical constraints are actually very tight. In particular, they only allow mappings that unambiguously pick two (groups of identical) arguments and swap them. That can only be done when the arguments come in different amounts (at most two groups of equal size may be present, and if so, it must be those two that will be swapped). This gives us a very short list of possible mappings.

2 inputs

• xy -> swap x and y

3 inputs

• xyy (and necessarily all permutations of this) -> swap x and y (and this is actually the only option)

4 inputs

• xxyy -> swap x and y
• xyyy -> swap x and y
• xyzz -> swap x and y (cannot swap either of them with z because that would be ambiguous) Or Any combination of the above, resulting in a total of 8 different configurations (including identity).

5 inputs

• xxyyy -> swap x and y
• xyyyy -> swap x and y
• xxyyz -> swap x and y
• xyzzz -> swap x and y This gives a total of 16 options.

6 inputs

• xyyyyy -> x <-> y
• xxyyyy -> x <-> y
• xxxyyy -> x <-> y
• xyzzzz -> x <-> y
• xyyzzz -> x <-> y xor x <-> z xor y <-> z
• xxyyzw -> x <-> y or z <-> w For a total of 256 options, I think.

You get the general idea. For a given input count, there is a fixed number of bits that uniquely describe the configuration of the black box (unless the xor conditions start doing weird things for large inputs). This gives us a way of dynamically (in-game) configuring them - e.g. with a set of special buttons that toggle each particular bit (= swapping).

[IQuick143]

The constraints are very tight indeed. This is intentional: A) It makes for less arbitrary mechanics (ex: Mechanics based on weird interaction between pictograms) B) Our levels are already geometrically very complex, so we can't really introduce more geometric constraints to specify black-box inputs without input-permutation ambiguity), also I think we can completely dodge things such as labelled black-boxes: Each blackbox is simply a gizmo attached to a cycle segment, if the cycle turns, the blackbox works as I/O for the turn. If 3 cycles with blackboxes turn, we run the logic for a triple box etc...

Anyway, I think your analysis is generally correct.

The question is how do we pick a unique and systematic blackbox operation? A potential candidate is this procedure: Compute all possible swaps, disregard all XOR clauses with more than 1 (ie: drop all ambiguous choices), greedily use all remaining swaps.

Seems to me like it would produce a rich variety of behaviour, although I'm not sure how the shell do you explain this to anyone without a math/compsci degree.

[IQuick143]

Also: Cycles attached to blackboxes do not have to turn in sync, for the reason I mentioned (blackboxes which don't turn simply are not used), this enables: A) trivial application of multiple black-box machines in a level (just place the black boxes, no need to label them or anything, they get activated by linkages triggering them in sync.) B) unique interaction with one-way linkages: OWL's allow different sets of blackboxes to trigger at different times.

Also it's one less thing to validate.

Another idea: Multiple blackboxes can be placed on a single cycle, that sounds evil.