Cha0zz, mcsven and I have developed a system in IRC based upon the gameplay ideas that Josh proposed in the Wednesday, May 7, 2014 dev log. We attempt to stick true to the ideas Josh originally proposed within that dev log and not the amendments he made in the Research and prototypes thread, as we feel the originally proposed mechanics are superior. Namely: "Prototypes are unique and non-copyable, so if you manage to steal or destroy one, you cripple the owning faction's technology."
We believe our system encapsulates the great gameplay potential of the mechanics Josh proposed while maintaining sufficiently high plausibility and allowing for additional fun gameplay mechanics.
The major part of the lore aspect of this proposal is short; all that needs to be said is that this proposal is based on an assumption that hacking and data theft are significant concerns within the Limit Theory universe, such that corporations go to fairly extreme measures in order to protect valuable information, such as blueprints that they develop after investing considerable amounts of money to produce and are currently securing their position in various markets.
We propose that the manufacture of a product from the highest level (conceptual) to the lowest level (fabrication) is divided into three phases:
- Blueprint → Assembler → Product
A blueprint is an encapsulation of the research that an agent or corporation has done into the design of a product, and contains all the information about a product necessary for its manufacture and the development of new technology based upon it.
Blueprints are unique and non-copyable: for security reasons, there is only ever one copy of a blueprint made associated with a particular product design, and it is typically kept in a secure location.
ASSEMBLER PHASE Assemblers are built according to the specifications of one particular blueprint. They essentially encode the information of a blueprint into a highly-secure form and with the potency to physically manufacture one unit of the product.
Assemblers are produced just like any other physical product - at production modules using raw materials. Therefore, production modules can be used to do one of two things:
- They can be used to produce ordinary physical goods by consuming assemblers along with the necessary raw materials.
- They can be used to produce assemblers themselves using the necessary raw materials.
A product is built at any production module by supplying the appropriate assembler and raw materials to it. The process takes some amount of time and then the product is outputted into storage.
Production modules can build any kind of ordinary physical good at any time so long as you give them the correct raw materials and power necessary to do so. They can only be used to produce at most one type of assembler at any given time, and this is based upon a security precaution. In order for a production module to begin manufacturing a specific type of assembler, it needs to be physically transported to the location of the blueprint, or vice versa, and the blueprint needs to be applied to the production module.
Applying a blueprint to a production module causes a certain fraction (say, 50%) of the blueprint data to be loaded into the production module. The production module is said to be configured to producing assemblers based on that blueprint. As stated above, a production module can only be configured to producing one kind of assembler at a time.
The other fraction (50%?) of the blueprint data is broadcasted over existing communication infrastructure (that Cornflakes and I have developed the theory of) to all accessible production modules that are configured to create assemblers based upon that blueprint. The security advantages of this system are substantial:
- If all blueprint data were loaded into every production module configured to produce the corresponding kind of assembler, then an enemy faction could steal the blueprint information just by capturing one of the production modules.
- If all blueprint data were transmitted over communication infrastructure, then the blueprint information could be stolen by an enemy faction that bugs the comm lines. In Cornflakes' and my proposal, communications instructure can be hacked.
- By splitting up the blueprint data into two sets, one containing data that is stored locally on every production module and the other that contains data that is transmitted over the network, it makes it impossible for enemy factions to obtain the original blueprint data by either of the above methods.
- Enemy factions can potentially steal some of your pre-configured production modules and bug your comms lines. This should allow them to produce assemblers based on your blueprints using the captured production modules. However, it is assumed that the data stored on the production modules and sent across the network are encrypted in such a way that it's impossible for a third-party to recombine the data to get the original blueprint even with access to both. Enemy factions can produce your products only through pre-configured production modules that they capture using this method.
In our discussion we assumed that production modules come in different sizes, with larger production modules having the capability to produce assemblers (and other physical goods) at a higher rate, but being more difficult to transport. For instance, station-scale production modules might offer a very high rate of production but might be too large to build in one spot and then relocate to the station site later. In these cases, you would have to build the production modules in situ.
As well as this, we discussed how, even if a production module might be originally configured to produce one kind of assembler, the controlling agent might wish to switch production to a different kind of assembler later on.
Both of these cases would necessitate the physical transportation of the blueprint to the site of a production module at some other location, in order that the blueprint can be applied to the module. While the blueprint is being transported, it is likely going to be more vulnerable. An escort will need to carry the blueprint, and if your comm lines are bugged, enemy factions might be aware of that. In this case, they may try to set up an ambush to intercept the escort, especially if the blueprint being transported corresponds to a high-tech and highly valuable product on the market.
We also discussed the possibility that enemy factions might be able to reverse engineer assemblers (not the physical end-goods) to obtain the original blueprints with a certain probability of success. For instance, if say every assembler of a given type could be successfully reverse engineered to obtain the original BP with 0.0001% probability, then modelling the problem as a geometric distribution, an enemy faction would need to acquire and attempt to reverse engineer an estimated 1000000 assemblers before they succeeded. Assemblers can usually be bought en masse off of the market since they are necessary for manufacturers to consume to produce a given kind of product. We raised the idea that assembler tech itself can be researched to reduce the probability that any one assembler can be reverse engineered to obtain the original design.