From 8e387c43a8c9452eb8e7584424b716b1a4f3ea01 Mon Sep 17 00:00:00 2001 From: ArtisticRoomba <145879011+ArtisticRoomba@users.noreply.github.com> Date: Thu, 31 Jul 2025 12:06:52 -0700 Subject: [PATCH 1/6] Add workgroup policy page to SUMMARY.md --- src/SUMMARY.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index abc0e6b34..9cb531dc8 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -339,6 +339,7 @@ Staff - [Adding New Maintainers](en/wizden-staff/maintainer/adding-new-maintainers.md) - [Useful Maintainer Tools](en/wizden-staff/maintainer/maintainer-tools.md) - [Maintainer Policy](en/wizden-staff/maintainer/maintainer-policy.md) + - [Workgroup Policy](en/wizden-staff/maintainer/maintainer-workgroup-policy.md) - [Reviewing Procedure](en/wizden-staff/maintainer/review-procedure.md) - [Review Whitelist](en/wizden-staff/maintainer/review-whitelist.md) - [Hotfix Procedure](en/wizden-staff/maintainer/hotfix-procedure.md) From 8810d859b8a28c9d99482640d682a0046a41794b Mon Sep 17 00:00:00 2001 From: ArtisticRoomba <145879011+ArtisticRoomba@users.noreply.github.com> Date: Thu, 31 Jul 2025 12:11:06 -0700 Subject: [PATCH 2/6] Fix links on maintainer-workgroup-policy.md --- src/en/wizden-staff/maintainer/maintainer-workgroup-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/maintainer/maintainer-workgroup-policy.md b/src/en/wizden-staff/maintainer/maintainer-workgroup-policy.md index ce62e7a5d..59775a235 100644 --- a/src/en/wizden-staff/maintainer/maintainer-workgroup-policy.md +++ b/src/en/wizden-staff/maintainer/maintainer-workgroup-policy.md @@ -106,7 +106,7 @@ Conflicts on pull requests that are internal to the workgroup are subjected to t ### Design Documents Workgroups are encouraged to make design documents for their game area. -View the [Game Area Design Document Template](/src/en/general-development/game-area-design-doc.md) and the [Department Design Document Template](/src/en/templates-docs/department-design-template.md) for a good document basis. +View the [Game Area Design Document Template](en/general-development/game-area-design-doc.md) and the [Department Design Document Template](en/templates-docs/department-design-template.md) for a good document basis. When a workgroup creates a design document, it is said to be owned by that workgroup. From 5e09a32f62991ede8ad557973778a7ec2a312ddb Mon Sep 17 00:00:00 2001 From: ArtisticRoomba <145879011+ArtisticRoomba@users.noreply.github.com> Date: Tue, 23 Sep 2025 21:38:53 -0700 Subject: [PATCH 3/6] blank baseline good lord --- .../departments/engineering.md | 44 ++----------------- 1 file changed, 4 insertions(+), 40 deletions(-) diff --git a/src/en/space-station-14/departments/engineering.md b/src/en/space-station-14/departments/engineering.md index 44ee9036a..a7d7c36d2 100644 --- a/src/en/space-station-14/departments/engineering.md +++ b/src/en/space-station-14/departments/engineering.md @@ -1,47 +1,11 @@ -```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 +The powerhouse of the ~~cell~~ station. ## 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. - -[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. +Engineering is the department responsible for constructing, powering, and maintaining the station and its equipment, keeping it functional and usable by the crew. In addition, engineering may also process or synthesize materials -## 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. - -> 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. - -### Pillar_1: - > Breif Pillar Description - - ### Pillar_2: - > Breif Pillar Description - -## 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? - -## 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? - -## 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? - -## 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. -### 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. +### Proactive and Reactive Gameplay \ No newline at end of file From 23d2df696e2b2da6f600beb6c1bf576c79430593 Mon Sep 17 00:00:00 2001 From: ArtisticRoomba <145879011+ArtisticRoomba@users.noreply.github.com> Date: Wed, 24 Sep 2025 17:02:26 -0700 Subject: [PATCH 4/6] Additions --- .../departments/engineering.md | 84 ++++++++++++++++++- 1 file changed, 80 insertions(+), 4 deletions(-) diff --git a/src/en/space-station-14/departments/engineering.md b/src/en/space-station-14/departments/engineering.md index a7d7c36d2..a57188c56 100644 --- a/src/en/space-station-14/departments/engineering.md +++ b/src/en/space-station-14/departments/engineering.md @@ -1,11 +1,87 @@ # Engineering -The powerhouse of the ~~cell~~ station. +Assembling, maintaining, and powering a station soon to undergo rapid unscheduled disassembly. ## Concept -Engineering is the department responsible for constructing, powering, and maintaining the station and its equipment, keeping it functional and usable by the crew. In addition, engineering may also process or synthesize materials +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 process or synthesize materials, using these materials to create new items or structures researched by Science or requested by other departments. -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. +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 -### Proactive and Reactive Gameplay \ No newline at end of file +### 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. + +### Difficulty Population Scaling +The difficulty of tasks should scale with the population of the Engineering department, or the amount 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 accomplish 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 is supposed to be happening, but not at the beginning in the round, or as a first introduction to a system. + +For example: +- Setting up the AME is a task can be accomplished in a reasonable timeframe by one person. +- Setting up the Singularity or Tesla engine can be accomplished 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. + +### Toolset and Accelerated Work +The items in Engineering's restricted-level toolset should accelerate their work, enabling productivity and response time higher than if a person would want to accomplish 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 stats, but they are still encouraged to call on Engineering if available for large tasks. + +### Proactive, Reactive, and Maintenance 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 + needs to be performed] --> + a2{User performs + the action?} + + yes[Nothing happens, + round continues as normal + with no effects] + no[Round is significantly impacted] + + a2 -- No --> no + a2 -- Yes --> yes +``` + +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, and these upsets should do damage to the station proportional to the time or amount of resources it takes to perform the upset. + +### Station Infrastructure and Sabotage +Large and critical station infrastructure should be designed in a way that makes sabotage very hard to perform unless significant resources and/or time is dedicated to performing it. \ No newline at end of file From 5293fb8e293d33074c457aac85111c92b449dad7 Mon Sep 17 00:00:00 2001 From: ArtisticRoomba <145879011+ArtisticRoomba@users.noreply.github.com> Date: Wed, 24 Sep 2025 18:40:50 -0700 Subject: [PATCH 5/6] rider + grazia spellcheck goated at the sauce --- .../departments/engineering.md | 37 ++++++++++--------- 1 file changed, 19 insertions(+), 18 deletions(-) diff --git a/src/en/space-station-14/departments/engineering.md b/src/en/space-station-14/departments/engineering.md index a57188c56..99952610c 100644 --- a/src/en/space-station-14/departments/engineering.md +++ b/src/en/space-station-14/departments/engineering.md @@ -13,47 +13,47 @@ As such, Engineering and its mechanics should promote collaboration, cathartic s ### 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. +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. + - 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. + - 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. ### Difficulty Population Scaling -The difficulty of tasks should scale with the population of the Engineering department, or the amount of people that is expected to be doing that task. +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 accomplish tasks necessary for the station's beginning-of-round survival. +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 is supposed to be happening, but not at the beginning in the round, or as a first introduction to a system. +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 can be accomplished in a reasonable timeframe by one person. -- Setting up the Singularity or Tesla engine can be accomplished 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 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. ### Toolset and Accelerated Work -The items in Engineering's restricted-level toolset should accelerate their work, enabling productivity and response time higher than if a person would want to accomplish a maintenance task on their own accord. +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 stats, but they are still encouraged to call on Engineering if available for large tasks. +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 Maintenance Tasks -Tasks given to Engineering should not be extremely menial, or feel like a filler task meant to keep engineering barely idle. +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. @@ -66,14 +66,15 @@ This substation fuse replacement can be boiled down to the following tree: ```mermaid flowchart TD; a1[Periodic simple action - needs to be performed] --> + 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] + no[Round is significantly impacted + in a negative manner] a2 -- No --> no a2 -- Yes --> yes @@ -81,7 +82,7 @@ flowchart TD; 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, and these upsets should do damage to the station proportional to the time or amount of resources it takes to perform the upset. +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. ### Station Infrastructure and Sabotage -Large and critical station infrastructure should be designed in a way that makes sabotage very hard to perform unless significant resources and/or time is dedicated to performing it. \ No newline at end of file +Large and critical station infrastructure should be designed in a way that makes sabotage very hard to perform unless significant resources and/or time are dedicated to performing it. \ No newline at end of file From 1be50d97fcf3ec1148652f8676c4a6685fb94f40 Mon Sep 17 00:00:00 2001 From: ArtisticRoomba <145879011+ArtisticRoomba@users.noreply.github.com> Date: Wed, 24 Sep 2025 20:54:58 -0700 Subject: [PATCH 6/6] finish writing draft --- .../departments/engineering.md | 103 +++++++++++++++--- 1 file changed, 86 insertions(+), 17 deletions(-) diff --git a/src/en/space-station-14/departments/engineering.md b/src/en/space-station-14/departments/engineering.md index 99952610c..8bf3e4908 100644 --- a/src/en/space-station-14/departments/engineering.md +++ b/src/en/space-station-14/departments/engineering.md @@ -2,8 +2,8 @@ Assembling, maintaining, and powering a station soon to undergo rapid unscheduled disassembly. ## Concept -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 process or synthesize materials, using these materials to create new items or structures researched by Science or requested by other departments. +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. 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. @@ -33,26 +33,31 @@ As such, mechanics should be designed in a way that fulfills the following requi - 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. -### 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. - ### 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 Maintenance 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. + +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. + +#### 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. @@ -84,5 +89,69 @@ 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 critical station infrastructure should be designed in a way that makes sabotage very hard to perform unless significant resources and/or time are dedicated to performing it. \ No newline at end of file +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 +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 +### 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. + +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 + +### 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. + +### 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.