Page 1 of 8

A Reconstruction of Production Mechanics

Posted: Sun May 11, 2014 12:12 pm
by ThymineC
This proposal addresses the issues surrounding the recent topic (as of the time of writing) of production.

OUTLINE
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.

THEORY
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.

IMPLEMENTATION
We propose that the manufacture of a product from the highest level (conceptual) to the lowest level (fabrication) is divided into three phases:
  • BlueprintAssemblerProduct
BLUEPRINT PHASE
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
Spoiler:      SHOW
Assemblers are essentially 3D printers that are hardwired to help fabricate and maintain products based on precisely one kind of product design, which they form the cores of. When plugged into a production module, they cooperate with it by requesting raw materials and specialised procedures that they themselves are not capable of doing alone to build the associated product. When plugged into a repair module (if these are distinct from production modules), they similarly cooperate with it in order to repair any damage to the product they form the core of. This approach markedly reduces the probability that a corporation's trade secrets will leak to a third-party who can then produce versions of the corporation's products illegally, because the data needed to build the product is stored within the assembler and the assembler only makes vague requests to the production module.

Most of the alternative systems that have been proposed would be analogous to Josh distributing the source code to Limit Theory so that we could compile the game on our computers and hoping that none of us abuse that trust by distributing versions of LT ourselves illegally.
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.
PRODUCT PHASE
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.
Consequently, the system leaves your production chain with only one weak spot: the unique blueprint. An enemy faction will need to physically steal your blueprints in order for them to gain full access to the manufacture of that product and to conduct research based upon it. Because the blueprint is unique, this also deprives you of the ability to continue to manufacture that product. Without the blueprint, you can no longer transmit the 50% of the data over the network necessary for your production modules to produce assemblers.

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.

Re: A Reconstruction of Production Mechanics

Posted: Sun May 11, 2014 12:24 pm
by Cha0zz
As discussed; great idea :thumbup:

Re: A Reconstruction of Production Mechanics

Posted: Sun May 11, 2014 12:54 pm
by Idunno
Can there be a mechanic where, once a certain number of blueprints are in circulation, you no longer need the assemblers? Because someone is going to leak the info on what ever information network that the universe has. :shifty:

Re: A Reconstruction of Production Mechanics

Posted: Sun May 11, 2014 1:15 pm
by ThymineC
Idunno wrote:Can there be a mechanic where, once a certain number of blueprints are in circulation, you no longer need the assemblers? Because someone is going to leak the info on what ever information network that the universe has. :shifty:
I don't understand what you mean. I'm not sure how to parse your last sentence.

Re: A Reconstruction of Production Mechanics

Posted: Sun May 11, 2014 1:53 pm
by DWMagus
I'm going to just be blunt about this, but it almost sounds like you're recreating the system that Josh has already implemented.
ThymineC wrote:We attempt to stick true to the ideas Josh originally proposed within that dev log and not the amendments he made...
This along with some of the other phrasing almost makes it sound like you're (re)designing the whole system for him.

There are also assumptions that you would be using things that is not technically 'canon' in order to make this work.

...Unless I'm misunderstanding this?

Re: A Reconstruction of Production Mechanics

Posted: Sun May 11, 2014 1:59 pm
by ThymineC
DWMagus wrote:I'm going to just be blunt about this, but it almost sounds like you're recreating the system that Josh has already implemented.
Well it's based on his ideas but there's quite a lot different about it.
DWMagus wrote:There are also assumptions that you would be using things that is not technically 'canon' in order to make this work.
Yes, it assumes Cornflakes' and my communication system. If suggestions had to be based on what's canon, this subforum would have substantially fewer threads. :P Systems need to be suggested first and with luck they later become canon.

I forgot to write this in the original proposal, but it also supports (but doesn't assume) Gazz's idea about splitting damage into "temporary" and "permanent" types. When a module sustains damage, the assembler at its core will likely be able to repair a portion of that damage by itself; that is "temporary" damage that can be repaired on the field. Other kinds of damage are more substantial and an assembler will need to cooperate with a repair module in order to fix it. That's permanent damage.

Edit: Oh and Josh came into IRC and he said "this is a very solid idea". He's also considering scrapping reverse engineering, or changing how it works at least: "<node> basically could use assemblers of enemy tech as a 'boost' to your own research, perhaps guiding it in a certain direction"

Re: A Reconstruction of Production Mechanics

Posted: Sun May 11, 2014 2:03 pm
by Behemoth
So the sent 50% of the data to any production module is unique to that? Because else somebody could just bug any line to get the first half, and steal any one of the production modules to get the rest. This system however would imply you could just tap a few lines/steal a few modules to get all of the information.

Hmm... Choices, choices.

Re: A Reconstruction of Production Mechanics

Posted: Sun May 11, 2014 2:04 pm
by ThymineC
Behemoth wrote:So the sent 50% of the data to any production module is unique to that? Because else somebody could just bug any line to get the first half, and steal any one of the production modules to get the rest. This system however would imply you could just tap a few lines/steal a few modules to get all of the information.
I cover this in the original post:
ThymineC wrote: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.

Re: A Reconstruction of Production Mechanics

Posted: Sun May 11, 2014 2:10 pm
by Idunno
Sorry, I meant that if the Blueprints are stolen enough times, say twice, an NPC, if they are involved, will leak the information on the in-universe version of the 'net. Or they will sell the information to the highest bidder. Whichever one works. :shifty:

Re: A Reconstruction of Production Mechanics

Posted: Sun May 11, 2014 2:12 pm
by DWMagus
ThymineC wrote:If suggestions had to be based on what's canon, this subforum would have substantially fewer threads. :P Systems need to be suggested first and with luck they later become canon.

...

Edit: Oh and Josh came into IRC and he said "this is a very solid idea".
I have no problem on any of this. It's just that I honestly thought the system was already implemented, fleshed out, and done with. There's a difference between that and opening up a thread in discussions that seem to go completely against what has already been established and set in stone. It's akin to someone opening a thread that says "I want horseback riding when I land on the planet", that's all. Hence why I asked "Unless I'm missing something?"

Re: A Reconstruction of Production Mechanics

Posted: Sun May 11, 2014 2:14 pm
by ThymineC
Idunno wrote:Sorry, I meant that if the Blueprints are stolen enough times, say twice, an NPC, if they are involved, will leak the information on the in-universe version of the 'net. Or they will sell the information to the highest bidder. Whichever one works. :shifty:
Blueprints are unique. You physically cannot make copies of them. You can steal a blueprint and sell it someone else if you're not interested in using it yourself, though. Or you can offer to broadcast the blueprint's data on the net to other people for money, possibly.

Re: A Reconstruction of Production Mechanics

Posted: Sun May 11, 2014 2:15 pm
by ThymineC
DWMagus wrote:I have no problem on any of this. It's just that I honestly thought the system was already implemented, fleshed out, and done with. There's a difference between that and opening up a thread in discussions that seem to go completely against what has already been established and set in stone. It's akin to someone opening a thread that says "I want horseback riding when I land on the planet", that's all. Hence why I asked "Unless I'm missing something?"
Most of it was an extension of what Josh originally proposed in the dev log but we didn't make the assumption that what he said in that dev log or elsewhere is set in stone. That being said, it was an extension so we don't think we went anything in the dev log, only built on it.

Edit: It did actually go against some aspects of the dev log. A lot of was just in how we're thinking of what these things are, but also we don't want reverse engineering in the way stated in that dev log either.

Re: A Reconstruction of Production Mechanics

Posted: Sun May 11, 2014 2:49 pm
by mcsven
In my opinion the most important aspect of this system is that it requires you to move the Blueprint around if you want to produce the item in more than one location. Otherwise there's no real reason to move it, and the natural conclusion would be the impregnable "research fortress".

The involvement of production modules apart, it naturally fits with what Josh has written about in the relevant dev logs as far as I can see. The business about broadcasting 50% of the Blueprint need not be part of the first implementation. Thymine may not like that, but I don't see it being strictly necessary to get the main benefits of this idea.

Regarding Reverse Engineering (RE): at this point in the discussion I would like to retain it, but the problem that has been raised relates to the uniqueness of Blueprints (i.e. how are Blueprints unique if you can reverse engineer them?). I think the best way to handle this would be to say that RE gives you a new blueprint that is a variation on the original (Hardenberg won't like this but oh well!). One way to enable this is to make RE an attribute of research modules or perhaps have dedicated RE modules.

The result of attempting to reverse engineer something would therefore be calculated based on relative *power* of the item and the RE module. A high power item in a low power RE module would give you a blueprint which is much weaker than the original item, and possibly not worth continuing with. The reverse would probably give you a blueprint which is better than the original.

Thoughts?

Re: A Reconstruction of Production Mechanics

Posted: Sun May 11, 2014 2:56 pm
by ThymineC
mcsven wrote:The involvement of production modules apart, it naturally fits with what Josh has written about in the relevant dev logs as far as I can see. The business about broadcasting 50% of the Blueprint need not be part of the first implementation. Thymine may not like that, but I don't see it being strictly necessary to get the main benefits of this idea.
It's necessary. Remember when Cha0zz said the same thing, and then I pointed out that without that, your already-configured production units (where you presumably now load 100% of the data onto) will still continue to produce the good as before, when it was agreed that it would be better if stealing the blueprint instantly shut down all production modules producing the assemblers. This allows for the faction to be crippled as Josh writes in the dev log.

It also makes things more secure.
mcsven wrote:Regarding Reverse Engineering (RE): at this point in the discussion I would like to retain it, but the problem that has been raised relates to the uniqueness of Blueprints (i.e. how are Blueprints unique if you can reverse engineer them?). I think the best way to handle this would be to say that RE gives you a new blueprint that is a variation on the original (Hardenberg won't like this but oh well!). One way to enable this is to make RE an attribute of research modules or perhaps have dedicated RE modules.
This is possible.

Re: A Reconstruction of Production Mechanics

Posted: Sun May 11, 2014 3:12 pm
by McDuff
So if that communication system isn't implemented, the whole thing works exactly as it does before.

Given that Josh's overarching design tweak here was to change the products of research from being abstracted data-entities to real physical things that can be moved and destroyed, isn't this in fact going against that idea so that you get to have a hacking mechanic?