Heya! I wrote up this feature proposal design doc following the SS14 dev guide “The Robust Book” but ran into a snag with figuring out how Pull Requests work & I’m not versed in C#, so a friend recommended I give these forums a go instead!
Rework Robotics
| Designers | Implemented | GitHub Links |
|---|---|---|
| CharlotteBones128/collectionofbones128 |  No |
TBD |
I, Bones, am the author of this document. The ideas found in this document are primarily mine, with collaboration from the following members of the Harmony fork discord: ashteroza, dearestandromeda
Overview
Rework Robotics to give Roboticists something to do, encourage maintaining borg ion laws, increase Robotics’s relevance with other departments, and add Robotics to the core Science loop.
Background
Robotics as a Subdepartment of Science and as its own discipline do not adequately work.
It features key problems that result in mats spent by Robotics to be wasteful, and specialising in Robotics to not be rewarding. Robotics also does not have any cooperation or interaction with other departments.
The key points of this issue are:
- No core gameplay loop
- It does not generate research points
- No incentive to keep ion law borgs
- Ion laws are fun to roleplay, but if they are even slightly obstructive there is no reason not to eject the borg brain other than consideration for the borg’s player.
- No reason to do Robotics as your primary discipline
- On Low-pop servers Robotics isn’t done. On High-pop servers, Robotics is done by people who joined Science but aren’t able to do artifacts or anomalies.
- No incentive to interact with other departments
Robotics is only done when Scientists or RDs are bored, or if a Borg Player is actively asking for upgrades. On Low-pop servers, this results in issues for Borg Players as they can be left unattended by Science.
There are also other “Robotics” fantasies that SS14 does not currently cater to that could be added alongside insuring Robotics is a mechanically functional Subdepartment.
Goals
The rework proposes strategies to address the identified issues while bringing the flavour of Robotics more in line with the “Research” and “Experiment” focus of the Science Department, as well as incentivising Players to create characters that are Roboticists first and foremost by making that role fun, interesting, and viable.
The ways to achieve these goals is broken up into three categories based on how much they change about the subdepartment, how much effort is estimated to go into them, or if they require features or reworks outside the scope of this one.
Short-Term Concepts
These are concepts that could be implemented quicker, without too much alteration to stations, and without radically changing Robotics.
These are most likely bandaids, but also feature things that Robotics should probably just be able to do as the game is now.
Ion Storm Borg Laws Generate Research points
As it stands, Robotics does not generate points, and there are no IC reasons to keep Ion Law Borgs around.
Science as a whole department is focused on researching and understanding phenomena even if this impedes other departments for the overall good of the crew.
By introducing a machine or machines that could induce and research Ion Laws, this incentivises keeping the fun roleplay opportunities of Ion Laws while also allowing a degree of control, such as anomalies has with their plasma-based Anomaly Generator.
The Machine or Machines would spawn at roundstart in Robotics. A Borg enters it like a charging machine, and the Roboticist can see any laws that are generating points or could generate points. This should Not reveal EMAGing. This should not reveal all the Borgs laws, such as if a law was removed by ion storms.
The Machine should likely show any natural made ion laws not induced by science as either [???] or [ERROR], but still show how many points it makes. This keeps the fun a Borg Player might have from having their laws be secret.
This by itself would not fix Robotics, but would be a good bandaid. It still has flaws, as it is reliant on a Borg being controlled, and it does not by itself form a Core Gameplay Loop.
Experimental Borg Modules
These would be modules creatable by Robotics in line with Science’s “Experiment” theme.
These modules would be stronger or more interesting than their basic counterpart, but come with an unexpected randomized drawback.
The Borg the module is installed in would be incentivised to get checkups at Robotics to maintain using the module, and the module should be able to upgrade into a stabilized version with use and checkups.
The Experimental Modules generate points for Science based on either Borg Usage, Danger or impedence of the drawback, or a burst of points on stabilizing.
While this is closer to a Core Gameplay Loop, it is still insufficient for fixing Robotics. It still relies on a Borg Player existing, failing to meet the “Player Agency” tenant. It can still work as a bandaid or stopgap, and forks could implement this while waiting for a truer rework, like concepts mentioned later in this proposal.
Robotics Makes Implants
Currently, Security asks Cargo for implants, such as tracking implants.
Security does not have any incentive to interact with Science directly overall, other than maybe HoS faxing or command channelling RD for research, as Security have their own techfabs.
Having Robotics (Or even R&D) make implants for Security would give the two departments incentive to interact, facilitating roleplay and station inter-connectedness
This could also open up the design space for low-stakes low-impact “Crew Implants”, such as a one-time programmable MIDI implant, or giving the clown a “Laugh track” implant.
(More) Mechanized Hardsuits/Exosuits
Mechanized Hardsuits as a term is used for the loose category of Science Fiction device that improves the users strength or capabilities while being two legged.
It encapsulates everything from “Exoframes” (Powered Exoskeletons) to “Power Armor” to Near-human sized mechs, such as the Prawn Suit from Subnautica, or the Ripley APLU.
The current Robotics fabricator is called the “Exosuit Fabricator”, despite not having many options to fabricate these.
Robotics should be able to make more of these types of items and gear.
Robotics should be able to build more items like the Ripley, and they should be more useful than being able to build a Ripley.
Currently, while Robotics can built a Ripley, a HONK Mech, and the HAMTR Mech, this is never done. Cargo spawns with a Ripley, and the other two are silly items.
Robotics should be able to make a Mining counterpart to the Ripley capable of short-length space flight for Salvage, and a Mechanized Hardsuit for the Engineering department specializing in external repairs and construction - it should be capable of assisting in Solar Array repair, as well as have the tools suited for laying out the foundations for new Solar Arrays and new sections of the Station.
This would promote more inter-department activity, as well as give Robotics something to do.
It would also incentivise players to interact with SS14’s dynamic environment.
The Mechs should not be combat oriented. Any EMAG Syndicate Mechanized Hardsuits should be a “Loud” option, if they exist at all. Mechs likely should not be able to wield normal weapons, if they get any weapons at all. They should be comparable to using a Ripley APLU for combat.
Long-Term Concepts
These are concepts that will likely take more effort to implement, radically change the department, or otherwise require overhauling the Robotics chambers on maps in major ways.
This is for fixing the lack of Core Gameplay Loop for Robotics.
They likely require refinement, and may need trimming or further reimagining.
Experimental Mech research
Playing off the fantasy of Mechs, such as Jaegers or Gundams, a major core loop of Robotics could be working to create new Mech Components for NanoTrasen/CentComm.
The new core loop could manifest in many different ways, but should focus around the thematic concept of “Experimental Robotics”.
This is not intended to be Science constructs a full Mech, but instead Robotics works to create and optimize a new experimental Mech Engine, or Weapon, or Cockpit, or arm.
The aim would be allowing experienced players to create interesting and optimized components, allow new players to engage with the core loop, and not encourage each component to be built in a single optimal way.
I have drafted up 2 primary design concepts for how this core loop could work. At the end of each option will be a summary of how the concept addresses the relevant issues identified in Background, how the concept interacts with the Core Design of SS14, and a list of potential pros and cons.
These proposals would require a major upgrade to Robotics chambers, giving them space to store, design, build, and test their components.
Salvage should be able to bring Robotics exclusive materials for component fabrication.
The component should be consumed to create a blueprint when the design is finished.
The design of this space should draw from Mech Hangars in Sci-Fi, and vehicle factories in real life.
The Component Design could look like this:
Each component must have their “shell” or “housing” built first, which can be as small as 2 tiles (1x2) or as large as 6/9/15 tiles (2x3/3x3/3x5). Each component will have a preset arrangement of these tiles. The tiles must be contiguous.
The Roboticists will then input materials and/or parts, which they will then arrange in a UI, probably similar to the inventory screen. They will then connect all the parts, and the way they do this impacts the things measured for part success. Salvage can bring rare unfabricateable materials and/or parts for this process. Once the component is complete, it is turned into a draggable tile which is then tested. If the test is satisfactory, it is then submitted or converted into a blueprint. If it unsatisfactory, it is turned back into the tiles/shell/housing, and the team continues to work on it.
Component housing and materials/parts is either using real materials, or is a holographic simulation. This will depend on how this impacts station material costs, which will depend on how many Components can be reasonably expected to be made per hour.
Examples of Parts and/or Materials include:
Organic Hull Plating, Organic Servo, Repair Nanobot Housing, Gaseous Plasma Pneumatic Servo, Bluespace Ammunition Storage, Antigravity Structural Matrix, Reinforced Structural Matrix, Artifexium Structural Matrix, Laser Hull Plating, Superconductive Wiring, Organic Wiring, Experimental Anomalous Wiring, Experimental Plasma Wiring, Reinforced Wiring, Bananium Plating, Experimental Bananium Wiring
Option A: NT Requests Specific Parameters
At the start of the shift, the Robotics Team will pick from a short list of randomized tasks, flavoured as a request from NT/CentComm.
The request will follow a pattern of “Make a <COMPONENT> out of <MATERIAL>, it must take up <SPACE> and not exceed <WEIGHT>/<SPESOS>.”
The Roboticists will then work to fulfil the request, getting research points either upon completion or throughout the process. They will complete the request by inserting a Blueprint into the place they got the request from, and then be allowed to pick a new request.
Summary
While this does make Robotics a department with a core loop, it does not promote department interaction. While point generation is guaranteed, it is one big burst and may be difficult to balance the time and effort to the outcome - everything might already be researched when Robotics finishes their first component.
Pros:
- Fully random requests prevents Robotics from being a Solved Department, keeping it dynamic.
- A set goal is more approachable to new Players
- NT requesting stuff directly helps tie it into a Reason for the subdepartment that is obvious.
Cons:
- Might be too similar to cargo bounties
- Might be too limiting to playe freedom, or lower the skill ceiling too much.
- Might become frustrating or stale too quickly.
Option B: Random Materials
The Robotics Team has free reign to design whatever components they want, however they are limited by the materials they have available to them.
Each component either has a permanent set of required attributes (Such as size, weight, cost, damage, defence, etc), or at roundstart these attributes are randomized within a range.
Robotics can either order new crates of random material from Cargo, or NT/CentComm delivers the team a new set of materials when they finish a component.
Points are generated on each component test based on the efficiency of the component. If the same component is tested, only the increase in efficiency should reward points. This prevents the Roboticists powergaming by making small changes and getting full points.
Summary
This promotes some greater department interaction. It may be possible to promote more department interaction other than just Supply/Salvage/Cargo, such as allowing Robotics to take contraband from Security and turn it into interesting experimental parts.
Pros:
- Full freedom, maximum player agency
- Players can get going with the system right away, no need to interact with a terminal
Cons:
- Needs active balancing to prevent Meta builds
Future-Term Concepts
With the fabled “limb update”, Robotics should be able to create interesting prosthetics. These should draw from Sci-Fi’s rich history of Cybernetics.
These prosthetics should be realistic in how their materials react and thus not be a true subsitute for a limb, instead coming with their own drawbacks and benefits.
For example, metallic prosthetics should be more reactive to shifts in temperature, and their weight should be noticeable. Their installation, upkeep, and repair will probably require collaboration between Science and Medical.
