- Joined
- Feb 16, 2016
- Messages
- 67
- Reaction score
- 42
First post, yet a lengthy proposal.... Several proposals, actually...
1. Inspired by the Logic space proposal:
A new entity type called 'circuit' to place logics in. It's blueprint could be saved in the catalog for copying, sharing, moving. It will use it's own space. The logic gates inside will be invisible from the outside world. All other blocks should be visible and use normal space (activators, buttons, non-logic blocks). Two new blocks should be created: input and output pin. These should be visible too because they will be the way the circuit interacts with the rest of the universe.
A circuit will be a black box for the outside world. It's state will be hidden, only the pins are exposed. Thus a potentially large (in terms of logic block count) piece of circuitry will be replaced by a structured entity with a few contact pins. This will lead to potentially big, even huge, performance and stability boost when the game evaluates logic blocks. The outside world won't depend on the states of a circuit's internal elements, but only on the states of it's output pins. On the other hand, the circuit depends only on the states of it's input pins, not on the rest of the universe.
Example:
Not everyone makes huge circuitry but everyone needs some repeating logic elements like gate controllers. One can save a generic gate controller in their catalog and reuse a good design multiple times.
The performance and stability boost will be significant. The entire logic graph will be split into several smaller graphs and since graph algorithms are usually more complex than O(x), the computing cost of logic will be reduced significantly. In case a circuit doesn't contain circular dependencies and is a pure binary function, its evaluation could be even reduced to constant complexity by 'pre-compiling' its truth table in the blueprint.
2. Factories, storages and logic: The ability to control and detect factory and storage blocks like rails.
Adding an activation block next to a factory could become 'on' on factory cycle end, a button block could emit a signal. The same could be applied to inventories on pull events.
A logic element as master should be able to start/pause the factory/storage.
Example:
3. The ability to see the masters of the selected block:
Much like when you select a block its slaves appear in purple boxes, it would come handy to be able to see its masters too (for example -- in white boxes). This should apply not only to logic blocks.
Sorry if these proposals are not new to you, thanks for your patience and attention.
1. Inspired by the Logic space proposal:
A new entity type called 'circuit' to place logics in. It's blueprint could be saved in the catalog for copying, sharing, moving. It will use it's own space. The logic gates inside will be invisible from the outside world. All other blocks should be visible and use normal space (activators, buttons, non-logic blocks). Two new blocks should be created: input and output pin. These should be visible too because they will be the way the circuit interacts with the rest of the universe.
A circuit will be a black box for the outside world. It's state will be hidden, only the pins are exposed. Thus a potentially large (in terms of logic block count) piece of circuitry will be replaced by a structured entity with a few contact pins. This will lead to potentially big, even huge, performance and stability boost when the game evaluates logic blocks. The outside world won't depend on the states of a circuit's internal elements, but only on the states of it's output pins. On the other hand, the circuit depends only on the states of it's input pins, not on the rest of the universe.
Example:
a. Create a 'memory cell' circuit: some gates for a flip-flop, write input, control input, read output. A total of like 10 logic blocks.
b. Create a 'byte chip' circuit: 8 instances of the memory cell, 8 read outputs, 8 write inputs, control input -- about 8 circuits + like 20 blocks more for a total of 100 blocks (if inner circuits are expanded).
c. Create a 'memory' circuit: 8+ instances of byte chip, 8 inputs, 8 outputs, 3+ address inputs. A total of like 800+ blocks (if expanded).
Thus almost a thousand of blocks in the world are replaced with a single entity. It's further divided into smaller entities. Every circuit in this tree is not so complex on it's own and is evaluated easily. On the other hand -- evaluation of 800 blocks at the same time, over and over again, is not very easy. Assuming the logic evaluation algorithm is O(n^x), x>1, this will improve performance (drastically, even). Gameplay-wise , this replaces a mess of hundreds of blocks with a structure of well-defined sub-units.
b. Create a 'byte chip' circuit: 8 instances of the memory cell, 8 read outputs, 8 write inputs, control input -- about 8 circuits + like 20 blocks more for a total of 100 blocks (if inner circuits are expanded).
c. Create a 'memory' circuit: 8+ instances of byte chip, 8 inputs, 8 outputs, 3+ address inputs. A total of like 800+ blocks (if expanded).
Thus almost a thousand of blocks in the world are replaced with a single entity. It's further divided into smaller entities. Every circuit in this tree is not so complex on it's own and is evaluated easily. On the other hand -- evaluation of 800 blocks at the same time, over and over again, is not very easy. Assuming the logic evaluation algorithm is O(n^x), x>1, this will improve performance (drastically, even). Gameplay-wise , this replaces a mess of hundreds of blocks with a structure of well-defined sub-units.
Not everyone makes huge circuitry but everyone needs some repeating logic elements like gate controllers. One can save a generic gate controller in their catalog and reuse a good design multiple times.
The performance and stability boost will be significant. The entire logic graph will be split into several smaller graphs and since graph algorithms are usually more complex than O(x), the computing cost of logic will be reduced significantly. In case a circuit doesn't contain circular dependencies and is a pure binary function, its evaluation could be even reduced to constant complexity by 'pre-compiling' its truth table in the blueprint.
2. Factories, storages and logic: The ability to control and detect factory and storage blocks like rails.
Adding an activation block next to a factory could become 'on' on factory cycle end, a button block could emit a signal. The same could be applied to inventories on pull events.
A logic element as master should be able to start/pause the factory/storage.
Example:
Consider you want to mass produce fighters and bombers for your big carrier. Each requires some small amount of different build blocks in strict proportions. Factories could be automated so no overproduction of a single block would occur. Thus a clever assembly line won't let you with hundreds of blue cubes and no white heptas or capacitors or whatever. The assembly line will be able to make the most out of the resources you supply it. This will require some extra logics and here logic entities (the circuits from above) will come pretty handy.
3. The ability to see the masters of the selected block:
Much like when you select a block its slaves appear in purple boxes, it would come handy to be able to see its masters too (for example -- in white boxes). This should apply not only to logic blocks.
Sorry if these proposals are not new to you, thanks for your patience and attention.
