Engineering Design Document

src/en/space-station-14/departments/engineering.md

@@ -1,47 +1,157 @@
-```admonish warning "Attention: Placeholder!"
-This section is a placeholder, pending a design-doc being created by the related work-group
-```
-
 # Engineering
-The powerhouse of the ~~cell~~ station
+Assembling, maintaining, and powering a station soon to undergo rapid unscheduled disassembly.
 
 ## Concept
-Engineering is responsible for building, running, maintaining, and repairing life-critical station hardware. No matter what the situation is, engineering keeps the power on and the atmosphere breathable.
-- **Primary Goal**: Keep the station habitable and respond to life-support emergencies
-- **Secondary Goal**: *Perform* upgrades[1] the station and process raw resources into usable items/equipment.
+Engineering is the department responsible for assembling, maintaining, and powering the station and its equipment, keeping it functional and usable by the crew.
+In addition, Engineering may embark on large construction projects, either transforming an area or deploying a new system.
 
-[1] The difference between engineering and science when it comes to upgrades is that Engineering focuses on the implementation/installation while Science researches/creates the upgrades or their components.
-
-## Player Story
-> A short (1-2 paragraph) story from the perspective of someone playing a role in this department. This is effectively a story of the ideal experience of a player interacting with these mechanics/systems. 
+It is extremely fun and rewarding for players to solve a mechanical issue or build something new for other players.
+As such, Engineering and its mechanics should promote collaboration, cathartic solutions, and above all, the feeling that the player's actions are making a difference.
 
 ## Design Pillars
-> A group of simple high-level ideas that embody this department. These are usually expressed with singluar words or short phrases, but may also include a *short* one sentence explaination. Game pillars are what makes the *identity* of the department. 
 
-> Pillars are there to act as guides when creating new mechanics or interactions, they serve as the measuring posts to make sure that what you are trying to do will fit in the department gameplay. 
+### Cogs in a Machine
+Engineering mechanics should promote teamwork, where dividing multiple people up into performing individual tasks results in a speedy resolution to a large problem.
+
+This gives the player the feeling of contributing towards a wider goal, or "keeping a machine alive."
+This feels fantastic and provides engaging roleplay and interaction.
+Players can divide themselves up among tasks, coordinate responses, allocate more people to matters more urgent, and so on.
+
+As such, mechanics should be designed in a way that fulfills the following requirements:
+1. **Large tasks can be parallelized.**
+   - Multiple people should be able to work on a large task without one person conflicting with another person's work.
+     - A good example: Setting up solars does not require people to wait on other people for tasks to be done—the work can be completed asynchronously and by any number of people.
+     - A mixed, mostly good example: Engine construction. While the work is parallelizable, multiple people may have different ideas as to what engine design should be used. In addition, many engineers prefer to wait until the engine generator is in place and containment online before the PA is fully assembled.
+       - While these concerns may not be able to be 100% alleviated, communication issues like engine design can be helped by giving the CE tools to help lead their team. For example, an engine projector that projects holograms of engine parts to be moved.
+   - If a task requires that a certain phase of work being completed, that subtask should be parallelizable.
+     - A good example: Hull breach repair. Atmospherics cannot restore air pressure without the hull being airtight, so that is a blocker. But multiple people can work on patching the hull, working from multiple directions inwards.
+2. **Mechanics and tasks should be intuitive and easy to see how they fit into a larger picture.**
+   - Players should be able to identify subsystems in a larger system and be able to understand what that system does and how it contributes to a larger system. Using an analogy, players should be able to identify a cog in a machine and see how that cog turning keeps the entire system moving.
+     - A good example: SMESes in the context of the station power distribution network. They may be given a fancy name (Superconducting Magnetic Energy Storage); however, in the grand scheme of things, players can understand that it is just a big battery that supplies backup power to the station.
+     - A bad example: SMESes and generators in the context of power ramping. Power is not delivered instantaneously in some devices, rather the output of the device slowly ramps up to match demand. As a result, power may not be supplied as quickly as consumers demand it, resulting in a deficit and brownout until the suppliers ramp up enough to satisfy demand. This is currently not communicated intuitively.
+   - Mechanics or systems should intuitively communicate their role in a greater system, whether that be through their outer appearance, connection to real life, or through their UI or interactions.
+     - Ex. It is **visually intuitive** that an air vent releases air into an atmosphere, or that an SMES stores power.
+     - Ex. It is **interactively intuitive** through UI that a generator has greater fuel efficiency at power outputs lower than their maximum output.
+
+### Toolset and Accelerated Work
+The items in Engineering's restricted-level toolset should speed up their work, enabling productivity and response time higher than if a person wants to achieve a maintenance task on their own accord.
+
+In a sense, everyone should be able to do work involving Engineering in a pinch, but performing work in a timely manner involves calling Engineering to help out.
+This allows players to still perform their duties if Engineering is in a skeleton-crew state, but they are still encouraged to call on Engineering if available for large tasks.
+
+### Proactive, Reactive, and Menial Tasks
+#### Proactive Tasks
+Proactive tasks are tasks that Engineering does on their own accord, whether that be fulfilling requests from departments or by constructing something in their pass-time.
 
-> To acheive this you want pillars that are concrete enough to get your concept across but broad enough that there is some room of interpretation and discussion.
+The bulk of proactive tasks are projects.
+These projects can be anything, from deploying and maintaining a station point defense grid, to renovating or installing a new section of a department.
+These tasks should be able to be completed in a standard shift and benefit the station across the board, not just Engineering.
 
-### Pillar_1:
- > Breif Pillar Description
+#### Reactive Tasks
+Reactive tasks are tasks that occur in response to some station event.
+For example, science exploded their artifact chamber, meteors spaced an area of maints, or a hardbomb blew up medical.
+
+These are the most important tasks that affect the round, as not completing them exacerbates the feeling of station damage.
+If damage can be caused too easily, and the damage is not fixed fast enough, Engineering will feel underwater fairly early in the round, which is not a fun experience for players.
+
+Since this gameplay is the most important, it should be the most engaging and fun to fix.
+Reactive tasks should not be seen as a distraction from proactive tasks, as this can lead to Engineering ignoring issues that the crew cannot solve on their own accord, leading to a feeling of helplessness and evacuation.
+
+#### Menial Tasks
+Tasks given to Engineering should not be extremely menial or feel like a filler task meant to keep engineering barely idle.
+These tasks are boring and do not contribute to fun gameplay.
+
+For example, presume that we make a task where engineering has to replace fuses on a substation frequently.
+If these fuses aren't replaced, the substation will be disabled. This has the following effects:
+- If this task is not completed for some reason, a large portion of the population's round is now negatively impacted, and this impaction is outside their control, which reduces agency.
+- This menial work distracts away from potentially interesting work that Engineering could be doing, such as construction, renovation, or other interesting mechanics. In addition, this menial work could be so boring that Engineers may frequently forget to perform the work in exchange for doing work that actually interests them.
+
+This substation fuse replacement can be boiled down to the following tree:
+
+```mermaid
+flowchart TD;
+    a1[Periodic simple action
+    that needs to be performed] -->
+    a2{User performs
+    the action?}
+    
+    yes[Nothing happens,
+    round continues as normal
+    with no effects]
+    no[Round is significantly impacted
+    in a negative manner]
+    
+    a2 -- No --> no
+    a2 -- Yes --> yes
+```
 
- ### Pillar_2:
- > Breif Pillar Description
+Generally speaking, very few tasks should have this dynamic, if at all.
+Instead, your mechanic should be designed around upsets driven by in-round events that can happen either by chance or by antagonistic activity.
+Players should be able to tell when these upsets occur if their effects on the round are large. These upsets should do damage to the station proportional to the time or amount of resources it takes to perform the upset.
+
+### Difficulty Population Scaling
+The difficulty of tasks should scale with the population of the Engineering department, or the number of people that is expected to be doing that task.
+
+The intention of this design pillar is to prevent situations where a skeleton crew (likely) cannot achieve the tasks necessary for the station's beginning-of-round survival.
+For example, stations designed to host a skeleton crew (or stations that may see a skeleton crew engineering department) should have engines that can be operated by a skeleton crew.
+
+It's important to note that it's okay to have tasks out-scale the player in the end-stages of a round where chaos and disrepair are supposed to be happening. However, this should not be happening at the beginning of the round, or as a first introduction to a system.
+
+For example:
+- Setting up the AME is a task that can be achieved in a reasonable timeframe by one person.
+- Setting up the Singularity or Tesla engine can be achieved solo, but this takes a bit of time as setup is a complex series of steps, compared to other engines. Multiple people should be able to set up the engine in a reasonable timeframe. This makes the Singularity/Tesla less attractive for lower-population stations, and an alternative generator should be afforded, or the setup of these generators be partially or fully completed.
+- Setting up the TEG can sometimes be a difficult task for one or multiple people, especially people being introduced to many mechanics like Atmospherics and its limiting factors like window shattering. Mechanics like these should be communicated visually or intuitively as mentioned before.
+
+### Station Infrastructure and Sabotage
+Large and/or critical station infrastructure mechanics should be designed in a way that makes sabotage difficult to perform unless significant resources and/or time are dedicated to performing it.
+For other station infrastructure, the level of disruption should match the time, effort, or resources put into the sabotage. For example:
+- Disrupting the power in a single room shouldn't be too hard—anyone can cut the wire or disrupt the APC if they have access to it.
+- Disrupting the power in an area serviced by a substation should be harder. The substation can be access locked, be in a space where you can be caught, and disconnecting the substation could set off a series of low power alarms.
+- Disrupting the power on a station-wide level should be challenging unless done at the source or the circuit is open.
+
+Very frequently, the actions of one singular person doom the entire round, whether by intentional malice or simple accident.
+This is unfun for all players, as people may lose out on their antagonist or job roll, and nobody wants to sit through the ~25 minutes that it takes to restart the round.
+This is a large pain point that can be solved through mechanical design.
 
 ## Objectives
-> What is this department's objective when it comes to the round? Do they have a unique failure condition? If so, what is it? How does this department's objectives interact with the rest of the station?
+Engineering's job is to deploy, maintain, and power the station and its equipment, with their tasks ranging from reactive repair to proactive construction.
+
+As previously mentioned, it is important that tasks involving reactive repair are the most fun and engaging elements of Engineering's gameplay and are not distractors from proactive gameplay. Otherwise, engineers will be encouraged to ignore reactive repair work and focus on proactive work instead.
 
 ## Progression
-> How does the *gameplay* of this department change over the course of a round? Are there unlocks? Are players collecting/spending resources? Is this progression tied/related to other departments? If so how?
+### Roundstart
+Engineering starts the station off in a state of calm before the storm—their first task is to suit up and prep all the systems available to them and ensure they are operational.
+The only major station system available to all engineering personnel is power.
 
-## Flow
-> How does the *experience* of the player change over the course of a round? Are players constantly running around putting out fires or are there breaks in the action? Do players need to wait on other departments as pre-requisites for their own gameplay, or is this department fairly self-sufficent?
+Power is the most important system to set up, as a station without power effectively pauses gameplay for the entire station. In time-sensitive events like nuclear operatives declaring war, this can easily result in a loss outside the crew's control.
+A lack of power also exacerbates issues like atmospheric upsets, as many devices that stop spacing and maintain an atmosphere stop functioning during a power outage.
+
+Considering that Power is the most important system to set up, it should be the most intuitive system to set up.
+The time that Engineering gets to set up power should allow someone to mentor and teach people how to set up power.
+
+Further guidelines as to what power (and other systems should be like roundstart) should be explained in their respective design documents.
+
+### Mid-Round
+As the round progresses, Engineering can engage in various tasks that are either created on their own accord or pop up due to random events (proactive or reactive tasks).
+Maybe a small group of engineers dedicates themselves to working on a point-defense array, and maybe another group responds to a spacing incident triggered by a passenger.
+
+In any case, this is where Engineering starts to pick up the pace, responding to issues more pressing than the simple emagged door.
+
+### Late-Round
+As the round progresses, Engineering may find that their workload is starting to overwhelm them, with chaos ramping up and destruction widespread. Maybe syndicate traitors have knocked out important substations, or the engine is being forced into an unstable position. 
+
+At this rate, players will start to notice that Engineering simply cannot keep up, and evacuation will be called.
+Just like what is outlined in the Atmospherics design document, it is important that this feeling of being underwater or overwhelmed with work does not come too early.
+Otherwise, players may feel like their efforts are not making a difference.
 
 ## Mechanics
-> What major mechanics does this department use and how are they connected to this department.
 
-### Mechanic_Placeholder1
-> Each mechanic should have its own subheading and should contain a *short high-level* overview of the mechanic and how it is used by this department. Each mechanic should also link their associated design document as the subheading.
+### Construction
+At the heart of Engineering is its construction system, which gives players the agency to shape their environment and construct new machinery and areas for the crew.
+
+As outlined in _Toolset and Accelerated Work_, it is important that Engineering's interaction with construction is intuitive and fun, as it is the bulk of their work, especially their repair work.
+Tools that work and give Engineering the feeling of progress further encourage Engineering to restore areas to their former glory.
 
-### Mechanic_Placeholder2 (Not Implemented Yet)
-> Mechanics that are unimplemented should be marked with (Not Implmented Yet) and should link the associated design proposal if it exists.
+### Power
+Power is the lifeblood of the station, with the crew living or dying (or becoming really, really bored) because of its presence or absence.
+As such, it is important that Power and its sabotage and roundflow align with the predefined design pillars and contribute to a fun experience.