- Joined
- Jun 23, 2013
- Messages
- 504
- Reaction score
- 127
After finding this game a about a week ago, I've had quite a few ideas for new gameplay elements. I decided to post the ones I've written down so far, mainly because I saw liitle reason not to. I'm not sure how much of this has been suggested before, I'm afraid. I found a brief mention of nanotechnology from the late summer of 2012, but that's about it. As for the rest, I have no idea, but I hope not too much of this is already out there. Should I find that this is not the case, I'll look over the post and see if something should be removed.
For a variety of reasons, it's all written in present tense. Sorry about that.
Why not begin with the concept of Stem mass, which is a basic component for on-board specialized fabrication, including nanobots and advanced missiles.
The Stem materializer is the unit responsible for stem mass generation. It functions rather simply, it requires a certain amount of power and generates a certain amount of stem mass per unit of time.
The Nanobot dispenser unit manufactures basic nanobots from stem mass and power. These can then be used for basic ship repairs, but also as highly intelligent offensive weapons and defence against them. All functions do however require a specialized nanobot coordinator.
There are two main classes of nanobot coordinators, external and internal. These do in turn have subclasses like repair, tactical infestation, anti-infestation and direct offensive. These are controlled by some form of gui-ish feature in the ship core. Using this, you assign different precentages/amounts of your total nanobot stack to the different coordination units, a proccess which is not instantaneous due to each nanobot needing to be reconfigured for a split millisecond or so when transferred between coordinators. They can only coordinate a certain amount of bots at a time, depending on how advanced they are, forcing you to have several of each class on larger ships.
The coordinators will then preform different tasks with their assigned nanobots. Basic repair coordinators will make them restore damaged blocks at the cost of some stem mass. They will prioritize blocks according to some smart and possibly upgradeable pattern, preferrably along the lines of beginning with the outer and most damgaged hull blocks, and working their way inwards. More advanced coordinators should be able to replace fully destroyed blocks as well, though only through a significantly more costly and time-consuming proccess.
External coordinators are all tactical and require the ship to be equipped with a nanobot vent exposed to space in order to function. Anti-projectile coordinators will have the bots intercept incoming missiles, detonating them at a distance as soon as enought bots have reached them. Bots that have reached it when it detonates are destroyed, and quite a lot of them are required to set it off.
Bots coordinated for direct offensive will seek out enemy ships and detonate on impact, in many ways like tiny SD-KB missiles would. They can however tell(or at least be told) friend from foe, and aim for vulnerable hull spots.
Infestation bots are the by far most advanced and destructive kind, and as such the most expensive to maintain. When launched, they will seek out or be directed to a target, to which's hull they will then attatch themselves, and attempt to lock on to the ship's shield frequency. This may take a while, especially if the target has active countermeasures. Once done, however, they will be able to pass through them unimpaired, and begin consuming the ship. If there are no open ways to the inside of the ship, as many as possible will try to get in through microfractures in the ship's hull, while the rest will remain outside and eat their way in. While the radiation will keep them away from the ship core, they will heavily damage the rest of the ship, decimating it's tactical capabilities beyond extreme vulnerability.
Fortunately, there are also anti-infestation coordinators. Bots controlled by these will attack enemy nanobots aboard the ship, providing significant resistance for their devestating abilities. A well made nanobot defence has a good chance of completely striking back a rather large infestation, but should it be
overwhelmed, the pilot may have to resort to an electromagnetic pulse.
Emp generators are a last line of defence against nanobots. They charge rather quickly, but if not properly initialized, activating one will inflict severe damage to the ship. Like most other onboard devices, they appear as a block in the ship core gui. When selected and activated, a hud pops up, asking you to confirm the activation by holding down some key for one and a half second. When you have done that, the ship will automatically begin shutting down and securing systems, beginning with non-essentials such as weapons and propulsion and keeping shields active until the last moment. The progress of this shutdown, which should take about five or six seconds, is detailed in the hud, and the pilot can detonate the emp at any moment. Should they however do it before the shutdown is complete, any system still active will be damaged partially beyond repair. All active nanobots will be fried, and most of the systems will be back online in another few seconds.
Sytems being shut down is graphically represented in the ship as the blocks they consist of switching to a static, glowless greyish version of their texture and
an inablity to emit light should they normally do that.
Nanobot vents are blocks needed to launch the bots into space. In order for them to function, there must be an unblocked path from the vent side of the block to the space surrounding it. Only one is required, any more that that will make no difference whatsoever.
Shield remodulation computers are the primary countermeasure against nanobots trying to lock on to the ship's shield frequency. The speed at which a nanobot swarm can do that increases by the amount of bots and decreases by the amount of said computers, but is also influenced by a constantly changing and entirely random factor.
Multiblock missile arrays consist of a minimum of four blocks; a charge syntethiser, a delivery module fabricator a launch tube and missile fabrication Cpu. The Cpu controlles all aspects of the missile production, but a regular missile cpu is required for launching them. I'll get to that later.
The charge syntethiser consumes stem mass and power and produces some amount of kilograms of explosive power per unit of time, which can be split over a maximum of five production lines per module. A production line consists of four values: active or not, consumption, size and name. Active is rather self explainatory, consumption decides how many kilograms of power the line should accumulate per second and size decides at what point the accumulated power should be outputted as a charge. For example, if your ship has two syntethisers that produce 150x kilograms per second each, you can have ten production lines. Let's then say you set one production line to a consumption of 100x kg/sec and a size of 2500x kg, another to 125x kg/sec and a size of 250x kg, and another to 75xkg/s and 25x kg, and leave the others unused, you will be able to spit out a 2,5x tonne missile every twenty-five seconds, a 250x kg one every other and three 25x kg ones per second. The name value is only used when the game needs to adress you about choices regarding what class-specific production line continuation to put a larger missile in,
I'll get to that too. All of this is configured in the fabrication cpu, which centralizes your charge production and available production lines to a single gui.
The delivery module fabricator is an equally essential component. Those multi-tonne explosive charges aren't much use to anyone if you can't launch them without them blowing up in the tubes, are they?
There are three kinds of module faricators, one for each missile class. They all turn a certain amount of charges into proper missiles per unit of time and at a cost of stem mass, both of which are decided by the type of missile and the size of the charge. While the type is just a factor by which the cost and speed is
multiplied, the relation to the size of the charge is somewhat more complex. Straightly put, the requirements equal B+Mt/(? 3 cbrt(4C/3?)^2)+2(? 0,5 cbrt(4C/3?)^2), where Mt is the missile type and C is the charge size. Basically the time is decided not by the size of the charge, but by the total surface area of it should it
be a cylinder with a 3:1 ratio between the diameter and height, plus a balancing constant of some sort, B. (I hope "cbrt()" means cube root.) The type value should be configured so that SD-BB modules are significantly more expensive and slower to produce than D1000 and SD-KB missiles, for balancing. The missiles are split over different class-specific production line continuations at this point. In the pCpu, every explosive charge production line can be split over four continuations, representing the three missile types plus one undefined, or optional. The latter one means the system will ask the pilot what do with the missile, a function intended for heavier and slowly produced missiles which one might want to use for different purposes. How to distribute the missiles is defined in percents of the original production line.
The final stage is obviously the launch tubes. They are the only component controlled by regular missile cpus and not fabrication ones. They have two classes, the "Smart Missile Tube" and the "Ballistic Missile Tube". The smart tube is indended for SD-_B missiles, and can launch every four seconds, provided they are supplied with missiles. SD-KB missiles can however be launched two at a time, essentially doubling their firing speed. They are also capable of launching D1000-class projectiles, but at no higher rate than SD-KB. The Ballistic tube is for D1000 missiles, and can launch up to twice a second. They boost the speed of whatever they fire by several times, and if aimed forwards they can aim to the same extent as antimatter cannons. They can launch other missiles as well, but those will loose all tracking capabilities. Each tube can only launch one kind of missile, however, decided by what missile Cpu they are linked to.
Which brings me to advanced missile Cpu configuration. When linked to launch tubes, those computers should be able to do more than fire or not fire. This is configured as launch patterns.
Launch patterns consist of a name and any number of numericaly indexed chanells, or sub-patterns, which in turn consist of a production line continuation, a tube and a firing speed. When a pattern is initialized in the ship core gui, the involved launch tubes will begin opening fire accordingly. Several patterns can be initilazed at once regardless of the amount of cpus as long as there is matching production capacity.
Another optional but highly recomended feature are missile batteries, temporary storage devices for missile surpluses. They can store whatever and as many kinds of missiles as you like, but the total volume is restricted. The volume of a missile is calculated as 5cbrt(4C/3?)^3, in english the box size of the 1:3 cylinder of the charge times 1.33333. Stored missiles retain their classification as production lines and continuation sub-lines, not impairing the missile selection of launch tube firing patterns.
A stationary shield disperser is a multi-block contraption with a much higher effiecy than normal shield disperser. Constructed of a pedistal-based frame and a core, consisting of several different blocks each, they have a most traditional look resembling many larger sci-fi shield generators and take up about a 5*5*8
area. They are controlled by an advanced shielding cpu, used for disabling and geometrically reconfiguring the shield. The energy screen that is projected is bubble-shaped, and does not protect the station directly like normal shield dispersers, but only let's through fire from entities set as friendly in the Cpu. They draw their screening particles (or whatever the shield is made of) from normal shiled dispersers, which must be linked tp the Cpu the same way antimatter canons are linked to weapon computers. Such linked dispersers will cease their normal operation and pump their entire capacity into the stationary disperser whenever it's active. The bubble-based shield is many times stronger than a regular one sustained by the same amount of dispers. It's primary drawback is that it consumes a lot of extra power, and should the entity that carries it move, the shield would follow first five seconds later, even longer if it's larger than
usual, making it practically useless on ships and other non-stationary units.
And that's about it. Sorry for taking your time.
For a variety of reasons, it's all written in present tense. Sorry about that.
Why not begin with the concept of Stem mass, which is a basic component for on-board specialized fabrication, including nanobots and advanced missiles.
The Stem materializer is the unit responsible for stem mass generation. It functions rather simply, it requires a certain amount of power and generates a certain amount of stem mass per unit of time.
The Nanobot dispenser unit manufactures basic nanobots from stem mass and power. These can then be used for basic ship repairs, but also as highly intelligent offensive weapons and defence against them. All functions do however require a specialized nanobot coordinator.
There are two main classes of nanobot coordinators, external and internal. These do in turn have subclasses like repair, tactical infestation, anti-infestation and direct offensive. These are controlled by some form of gui-ish feature in the ship core. Using this, you assign different precentages/amounts of your total nanobot stack to the different coordination units, a proccess which is not instantaneous due to each nanobot needing to be reconfigured for a split millisecond or so when transferred between coordinators. They can only coordinate a certain amount of bots at a time, depending on how advanced they are, forcing you to have several of each class on larger ships.
The coordinators will then preform different tasks with their assigned nanobots. Basic repair coordinators will make them restore damaged blocks at the cost of some stem mass. They will prioritize blocks according to some smart and possibly upgradeable pattern, preferrably along the lines of beginning with the outer and most damgaged hull blocks, and working their way inwards. More advanced coordinators should be able to replace fully destroyed blocks as well, though only through a significantly more costly and time-consuming proccess.
External coordinators are all tactical and require the ship to be equipped with a nanobot vent exposed to space in order to function. Anti-projectile coordinators will have the bots intercept incoming missiles, detonating them at a distance as soon as enought bots have reached them. Bots that have reached it when it detonates are destroyed, and quite a lot of them are required to set it off.
Bots coordinated for direct offensive will seek out enemy ships and detonate on impact, in many ways like tiny SD-KB missiles would. They can however tell(or at least be told) friend from foe, and aim for vulnerable hull spots.
Infestation bots are the by far most advanced and destructive kind, and as such the most expensive to maintain. When launched, they will seek out or be directed to a target, to which's hull they will then attatch themselves, and attempt to lock on to the ship's shield frequency. This may take a while, especially if the target has active countermeasures. Once done, however, they will be able to pass through them unimpaired, and begin consuming the ship. If there are no open ways to the inside of the ship, as many as possible will try to get in through microfractures in the ship's hull, while the rest will remain outside and eat their way in. While the radiation will keep them away from the ship core, they will heavily damage the rest of the ship, decimating it's tactical capabilities beyond extreme vulnerability.
Fortunately, there are also anti-infestation coordinators. Bots controlled by these will attack enemy nanobots aboard the ship, providing significant resistance for their devestating abilities. A well made nanobot defence has a good chance of completely striking back a rather large infestation, but should it be
overwhelmed, the pilot may have to resort to an electromagnetic pulse.
Emp generators are a last line of defence against nanobots. They charge rather quickly, but if not properly initialized, activating one will inflict severe damage to the ship. Like most other onboard devices, they appear as a block in the ship core gui. When selected and activated, a hud pops up, asking you to confirm the activation by holding down some key for one and a half second. When you have done that, the ship will automatically begin shutting down and securing systems, beginning with non-essentials such as weapons and propulsion and keeping shields active until the last moment. The progress of this shutdown, which should take about five or six seconds, is detailed in the hud, and the pilot can detonate the emp at any moment. Should they however do it before the shutdown is complete, any system still active will be damaged partially beyond repair. All active nanobots will be fried, and most of the systems will be back online in another few seconds.
Sytems being shut down is graphically represented in the ship as the blocks they consist of switching to a static, glowless greyish version of their texture and
an inablity to emit light should they normally do that.
Nanobot vents are blocks needed to launch the bots into space. In order for them to function, there must be an unblocked path from the vent side of the block to the space surrounding it. Only one is required, any more that that will make no difference whatsoever.
Shield remodulation computers are the primary countermeasure against nanobots trying to lock on to the ship's shield frequency. The speed at which a nanobot swarm can do that increases by the amount of bots and decreases by the amount of said computers, but is also influenced by a constantly changing and entirely random factor.
Multiblock missile arrays consist of a minimum of four blocks; a charge syntethiser, a delivery module fabricator a launch tube and missile fabrication Cpu. The Cpu controlles all aspects of the missile production, but a regular missile cpu is required for launching them. I'll get to that later.
The charge syntethiser consumes stem mass and power and produces some amount of kilograms of explosive power per unit of time, which can be split over a maximum of five production lines per module. A production line consists of four values: active or not, consumption, size and name. Active is rather self explainatory, consumption decides how many kilograms of power the line should accumulate per second and size decides at what point the accumulated power should be outputted as a charge. For example, if your ship has two syntethisers that produce 150x kilograms per second each, you can have ten production lines. Let's then say you set one production line to a consumption of 100x kg/sec and a size of 2500x kg, another to 125x kg/sec and a size of 250x kg, and another to 75xkg/s and 25x kg, and leave the others unused, you will be able to spit out a 2,5x tonne missile every twenty-five seconds, a 250x kg one every other and three 25x kg ones per second. The name value is only used when the game needs to adress you about choices regarding what class-specific production line continuation to put a larger missile in,
I'll get to that too. All of this is configured in the fabrication cpu, which centralizes your charge production and available production lines to a single gui.
The delivery module fabricator is an equally essential component. Those multi-tonne explosive charges aren't much use to anyone if you can't launch them without them blowing up in the tubes, are they?
There are three kinds of module faricators, one for each missile class. They all turn a certain amount of charges into proper missiles per unit of time and at a cost of stem mass, both of which are decided by the type of missile and the size of the charge. While the type is just a factor by which the cost and speed is
multiplied, the relation to the size of the charge is somewhat more complex. Straightly put, the requirements equal B+Mt/(? 3 cbrt(4C/3?)^2)+2(? 0,5 cbrt(4C/3?)^2), where Mt is the missile type and C is the charge size. Basically the time is decided not by the size of the charge, but by the total surface area of it should it
be a cylinder with a 3:1 ratio between the diameter and height, plus a balancing constant of some sort, B. (I hope "cbrt()" means cube root.) The type value should be configured so that SD-BB modules are significantly more expensive and slower to produce than D1000 and SD-KB missiles, for balancing. The missiles are split over different class-specific production line continuations at this point. In the pCpu, every explosive charge production line can be split over four continuations, representing the three missile types plus one undefined, or optional. The latter one means the system will ask the pilot what do with the missile, a function intended for heavier and slowly produced missiles which one might want to use for different purposes. How to distribute the missiles is defined in percents of the original production line.
The final stage is obviously the launch tubes. They are the only component controlled by regular missile cpus and not fabrication ones. They have two classes, the "Smart Missile Tube" and the "Ballistic Missile Tube". The smart tube is indended for SD-_B missiles, and can launch every four seconds, provided they are supplied with missiles. SD-KB missiles can however be launched two at a time, essentially doubling their firing speed. They are also capable of launching D1000-class projectiles, but at no higher rate than SD-KB. The Ballistic tube is for D1000 missiles, and can launch up to twice a second. They boost the speed of whatever they fire by several times, and if aimed forwards they can aim to the same extent as antimatter cannons. They can launch other missiles as well, but those will loose all tracking capabilities. Each tube can only launch one kind of missile, however, decided by what missile Cpu they are linked to.
Which brings me to advanced missile Cpu configuration. When linked to launch tubes, those computers should be able to do more than fire or not fire. This is configured as launch patterns.
Launch patterns consist of a name and any number of numericaly indexed chanells, or sub-patterns, which in turn consist of a production line continuation, a tube and a firing speed. When a pattern is initialized in the ship core gui, the involved launch tubes will begin opening fire accordingly. Several patterns can be initilazed at once regardless of the amount of cpus as long as there is matching production capacity.
Another optional but highly recomended feature are missile batteries, temporary storage devices for missile surpluses. They can store whatever and as many kinds of missiles as you like, but the total volume is restricted. The volume of a missile is calculated as 5cbrt(4C/3?)^3, in english the box size of the 1:3 cylinder of the charge times 1.33333. Stored missiles retain their classification as production lines and continuation sub-lines, not impairing the missile selection of launch tube firing patterns.
A stationary shield disperser is a multi-block contraption with a much higher effiecy than normal shield disperser. Constructed of a pedistal-based frame and a core, consisting of several different blocks each, they have a most traditional look resembling many larger sci-fi shield generators and take up about a 5*5*8
area. They are controlled by an advanced shielding cpu, used for disabling and geometrically reconfiguring the shield. The energy screen that is projected is bubble-shaped, and does not protect the station directly like normal shield dispersers, but only let's through fire from entities set as friendly in the Cpu. They draw their screening particles (or whatever the shield is made of) from normal shiled dispersers, which must be linked tp the Cpu the same way antimatter canons are linked to weapon computers. Such linked dispersers will cease their normal operation and pump their entire capacity into the stationary disperser whenever it's active. The bubble-based shield is many times stronger than a regular one sustained by the same amount of dispers. It's primary drawback is that it consumes a lot of extra power, and should the entity that carries it move, the shield would follow first five seconds later, even longer if it's larger than
usual, making it practically useless on ships and other non-stationary units.
And that's about it. Sorry for taking your time.
