Engineering Design Document #519
Conversation
# Conflicts: # src/en/wizden-staff/maintainer/maintainer-workgroup-policy.md
ArtisticRoomba
added
the
Design
There was a problem hiding this comment.
Pretty much spot on with my personal observations as an engineer player
Two things to note:
- We need a way to simplify construction ghosts so you can build-on-the-spot like how the RCD does, as well as a way for players to 'share' or project construction ghosts to do big plans.
- We might need to look at the amount of destruction a single player (or antag) can do and scale it somehow with the number of engineer players.
That is more a feature request than something that should be in a design doc. |
| 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. |
There was a problem hiding this comment.
I feel like this should be expanded on even just a bit to specify some tools that an engineer should be faster at. Fixing hull breaches? Dispos pipes? Atmos Pipes? Wiring? Building machines? Deconstructing Machines? All of the above? Should they be able to have all their tools on them at once? Should these tools be split between multiple departments?
| 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. |
There was a problem hiding this comment.
Could use an extra sentence to describe how these are typically the least important and more used to give engineers something to do when the shift is slow, and maybe one about how one would ensure engi doesn't get too focused on doing them (i.e limiting the amount of tasks they can do and how quickly they can complete them? limiting the scope of the tasks such that engineering can hop off of one and straight to reactive tasks quickly?)
| - 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. |
There was a problem hiding this comment.
May also be good to state that stations should be designed such that one person can complete the engine without worrying about power issues for the rest of the station. This is an issue on a lot of maps (I believe Fland starts seeing multiple department wide power outages less than 10 minutes into the round if Singulo or TEG are not set up by then)
| 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. |
There was a problem hiding this comment.
I know you've mentioned the idea of "sabotage being dangerous" before in regards to opening a pressurized pipe launches you and cracks your head open so that should be mentioned here as well where trying to disrupt larger scale devices comes with immediate risks to the person doing the sabotage that they will be forced to mitigate using resources.
| ## 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. |
There was a problem hiding this comment.
Can probably just nuke this section. It says nothing that the Design Pillars section doesn't already say.
| ## 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. |
There was a problem hiding this comment.
This sentence feels like two sentences smushed together, and it also starts off weird. I'd just rephrase it.
| 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. |
There was a problem hiding this comment.
"Tools that work" is vague, should be a bit more descriptive.
| ### 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. |
There was a problem hiding this comment.
This whole section could probably be 1984d. The design pillars already pretty extensively cover desired mechanics and how they interface with the round more thoroughly than this.
|
Something the proactive task section reminded me of is that engineering is responsible for constructing shuttles, but salvage usually breaks into engineering to make the shuttle instead. It could be a good case on what makes a good or bad proactive activity. |
| 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. |
There was a problem hiding this comment.
Would welding the Tesla not fall under this category? It is something that if not done negatively impacts a round, but also has little to no interesting gameplay (click on five rods with a lit welder).
If so would the idea be to switch this with a round upset as suggested below where an event causes the need for the primary engine to need maintenance instead of it being something that requires the CE to set a timer on their phone.
There was a problem hiding this comment.
Correct, yes. The Tesla (and other engines) are a bad example of what an engine should be and this document doesn't attempt to justify current gameplay - because it isn't good.
| 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. |
There was a problem hiding this comment.
IMO it should also be easily tracked as often damage can happen and then not be reported for long periods of time. If you ask me including a ticketing system (possibly integrated into nanotask) that allows department heads to submit issues and for engineers to mark issues as resolved would go a long way in making it more clear what issues must be dealt with.
There was a problem hiding this comment.
This document doesn't go into the specifics as to how repair gameplay engaging, rather that it should be engaging and interesting. But those are some good points as to what repair gameplay should offer.
6 participants
This PR fleshes out the Engineering design document, setting the groundwork for future Engineering gameplay and the various systems, gameloops, and interactions that are to come. This design document will be used to write other design documents delving into the various systems like Construction and Power, and how they should work and contribute to the roundflow.
Merging this document will grant powers to the Engineering side of the Engineering/Atmospherics Maintainer Workgroup.
This document is put up in a draft state to collect feedback from the other members of the workgroup before starting a vote.