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. |
Princess-Cheeseballs
left a comment
Princess-Cheeseballs
left a comment
There was a problem hiding this comment.
Peer review incoming!
| 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?
| - 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)
There was a problem hiding this comment.
This is moreso already mentioned in the beginning of the pillar where we state that tasks meant to introduce the engineering department shouldn't be outscaling the player in terms of difficulty.
| 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.
|
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. |
ilovehans10
left a comment
ilovehans10
left a comment
There was a problem hiding this comment.
These are just some thoughts I had while reading the document.
| 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.
|
Me and Partmedia had a little bit of discussion on this document and gave it some amount of thumbs-up, however the following was raised:
I'll get to it when I have some time. |
github-actions
bot
removed
the
Design
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.