-
Couldn't load subscription status.
- Fork 250
Medical design doc(s) #510
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
sowelipililimute
merged 32 commits into
space-wizards:master
from
Princess-Cheeseballs:medical-design-document
Oct 20, 2025
Merged
Changes from 10 commits
Commits
Show all changes
32 commits
Select commit
Hold shift + click to select a range
c48b395
Update medical.md
Princess-Cheeseballs 83f9d2b
Create medical-workgroup.md
Princess-Cheeseballs 47cb422
Update medical.md
Princess-Cheeseballs d58ae51
Add offbrand to the design doc
Princess-Cheeseballs 959c84a
Merge branch 'space-wizards:master' into medical-design-document
Princess-Cheeseballs 9feb90e
PR guidelines
Princess-Cheeseballs 841c584
Update SUMMARY.md
Princess-Cheeseballs 26e2ea1
Fix links and typos
Princess-Cheeseballs b03fabd
Lets try this
Princess-Cheeseballs f448181
Update src/SUMMARY.md
Princess-Cheeseballs a89d0e3
Update medical.md
Princess-Cheeseballs c204c53
Update medical-workgroup.md
Princess-Cheeseballs 43c4e91
move file
Princess-Cheeseballs b1c1a74
fix link
Princess-Cheeseballs 055b685
Update guidelines.md
Princess-Cheeseballs a117dac
Update SUMMARY.md
Princess-Cheeseballs 7c8fc25
move it again
Princess-Cheeseballs 17d8d64
Update guidelines.md
Princess-Cheeseballs 27dc62a
Update medical.md
Princess-Cheeseballs 6f366ea
Update guidelines.md
Princess-Cheeseballs c2f044e
Update src/en/space-station-14/departments/medical.md
Princess-Cheeseballs d06f4b6
Update src/en/space-station-14/departments/medical.md
Princess-Cheeseballs 14001bd
Update medical-workgroup.md
Princess-Cheeseballs 81228f0
Update medical.md
Princess-Cheeseballs b564f97
Update guidelines.md
Princess-Cheeseballs a457dc2
Update medical-workgroup.md
Princess-Cheeseballs b27a7d7
Added a 5th design pillar
Princess-Cheeseballs aed2358
disco-med rename
Princess-Cheeseballs 746dda6
disco med rename
Princess-Cheeseballs 01cb83b
Merge branch 'space-wizards:master' into medical-design-document
Princess-Cheeseballs 0f9d5dd
review
Princess-Cheeseballs d827c48
removed periods from titles :)
Princess-Cheeseballs File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Some comments aren't visible on the classic Files Changed page.
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,43 +1,56 @@ | ||
| ```admonish warning "Attention: Placeholder!" | ||
| This section is a placeholder, pending a design-doc being created by the related work-group | ||
| ``` | ||
|
|
||
| # Medical | ||
| Responsible for causing patient's skeletons to disappear | ||
|
|
||
| ## Concept | ||
| > A high-level conceptual overview of what this department does. This is generally 1-2 paragraphs and should reflect a high level view of what this department brings to the player and the game. | ||
|
|
||
| ## 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. | ||
| ## Concept | ||
| Medical as a department is primarily tasked with keeping the crew alive and healthy. | ||
| The challenge of that very simple task is that the crew lives in a tin can that is prone to very bloody and violent accidents and disasters. | ||
| It's medicals job to be able to respond to a variety of different injuries and deaths, from a variety of different sources and to diagnose and cure so that the crew can get back to work or at least limp their way to the evacuation shuttle. | ||
| The tools medical uses should be scarce, but never scarce enough to halt the department, should be time consuming such that death is dangerous, but never time consuming enough that there's a lot of waiting involved in healing, and should keep medical constantly moving, but not so constant that it becomes overwhelming or unreasonably swamped. | ||
| Given the right tools medical should be able to deal with most bodies coming in, but there should always be a clear line of when a body is unrecoverable. Some wounds are too grievous, too rotten, too deliberate to recover from. That's what the morgue is for. | ||
Princess-Cheeseballs marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| ## 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. | ||
| Medical as a department needs to have consistency to work. But things should never be so consistent that they become mundane. | ||
| In order to maintain this balance, there are a number of design pillars that must be upheld. | ||
|
|
||
| > 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. | ||
| ### Pillar 1: Injuries should match the danger of the source. | ||
Princess-Cheeseballs marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| The difference between a common workplace accident and getting shot to pieces shouldn't be one number being higher. | ||
|
|
||
| > 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. | ||
| > Common injuries should be easier to treat, almost trivially so. Something you come into medical for, get a band aid and a pill and then be on your way as to not slow down the department. | ||
|
|
||
| ### Pillar_1: | ||
| > Breif Pillar Description | ||
| > Rarer job hazards should require some care and maybe more intensive treatments depending on the degree of the mistake. Got bitten a few times by a carp and lost your hand? A prosthetic limb can fix that. Decided to hang around the singularity for a bit too long? You'll probably need a coupe new organs alongside those radiation burns. | ||
|
|
||
| ### Pillar_2: | ||
| > Breif Pillar Description | ||
| > And most important, if someone really wants you dead then medical shouldn't be able to reverse that easily. | ||
Princess-Cheeseballs marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| ## 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? | ||
| ### Pillar 2: Treatment should be reactive. | ||
| Nobody likes doing the same thing over and over again. That's boring! As much as possible injuries should be dynamic and interesting. | ||
|
|
||
| > There should be no cure all medicine that is always the correct option to use. Any that could exist should be limited by drawbacks of side effects, scarcity or exclusiveness. | ||
Princess-Cheeseballs marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| > Real injuries shouldn't be static, gunshot wounds should worsen over time if left untreated, a patient in crit should get worse and become harder to heal, a dead body should rot and that rot should make getting them back up harder and harder the more time passes. A dying crewmember should need to be monitored because no medicine should be a cure all. You should have to put effort into treating bad injuries, it shouldn't just be about waiting for a number to go up after clicking 1-3 times with the correct healing item. | ||
Princess-Cheeseballs marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| ### Pillar 3: Medicine should be interesting | ||
| Players should want to know how to be a doctor, not only for the purpose it serves but for the depth and complexity involved. | ||
|
|
||
| > Everything from treatment, to chemistry, to surgery should have mechanical depth where knowledge and creativity is rewarded and experimentation is encouraged. | ||
|
|
||
| ## 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? | ||
| > Getting the best numbers should be mechanically discouraged by having a wide variety of options available. The same injury might call for different treatments depending on context, some poisons might suit some situations better than others. Any "best of their class" meta items or tactics should be discouraged through complexity and should never so heavily outweigh the simpler options that it becomes a burden to not understand them. Not knowing the meta shouldn't put you at a major disadvantage. | ||
|
|
||
| ### Pillar 4: Information is a resource | ||
| The information that is communicated to a doctor should be something doctors have to actively try and get. Medical scanners shouldn't be an end all be all. As with Pillar 2, no treatment should be a cure all, and therefore no source of information should trumph another. | ||
Princess-Cheeseballs marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| > Getting information from a patient should be the fastest and easiest way to diagnose, but not the only option for obvious reasons. | ||
|
|
||
| > Handheld items should only give some of the story, with the rest having to be intuited through knowledge or context. | ||
|
|
||
| > No information should be completely obscured. There should be fallbacks in case other methods of information gathering fail so that a medical player never feels stuck. These fallback methods should be always available but should be inconvenient so players don't rely on them and instead learn to master their medical skills. | ||
|
|
||
| ## Objectives | ||
| Medical is arguably the most important department for the crew round flow wise. If a player can trust that the medical department will be there to catch them when they fall, they're more likely to go out and make mistakes, and mistakes are fun. A traitor trying to assassinate their target should be having to make sure that medical wont be able to save them in addition to security not being able to catch them. A nuclear operative should be thinking about and accounting for the fact that medical is going to be turning dead bodies into walking obstacles. | ||
Princess-Cheeseballs marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| ## 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? | ||
| From a doctor's perspective, they should be a neutral but station leaning party. It's their job to keep these crewmembers alive in spite of everything and they should at least have a vague idea of how to handle that. | ||
|
|
||
| ## Mechanics | ||
| > What major mechanics does this department use and how are they connected to this department. | ||
| An experienced doctor should never feel overwhelmed but their work also shouldn't feel mundane. Each injury should be a puzzle to solve, some more simple than others but none feeling impossible or discouraging to solve. Intuiting and gathering information should be their most important skill, such that they always have to put some effort in to do their job well. | ||
Princess-Cheeseballs marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| ### 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. | ||
| At the same time, medical shouldn't have such a high learning curve or barrier to entry that it becomes obtuse. Tools should be intuitive, information should be immediately understood upon being recieved and the potential solutions obvious. While problems may worsen over time, the stress shouldn't be about "I have no clue what to do" but instead "I'm not sure which option is the best one right now". | ||
Princess-Cheeseballs marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| ### 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. | ||
| Medical should try to stay within the medical department. Their best tools should be static such that a traitor can't run around with better healing than what the security officer they just shot is going to be getting on their medical bed that they're strapped to. Nobody should be able to become a perfect one crewmember walking medical department. At the same time, a doctor should be able to reasonably handle treating a single patient or a group of patients on their own. Given the nature of the game, there's a very high chance their will be more bodies in the department than there are doctors. | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,5 +1,28 @@ | ||
| # PR Guildlines | ||
| # PR Guidelines | ||
|
|
||
| ```admonish warning "Attention: Placeholder!" | ||
| This section is a placeholder, pending a design-doc being created by the related work-group | ||
| ``` | ||
| ## Important | ||
|
|
||
| All PRs must adhere to the [Medical Design Document](../medical.md) and/or the [Medical Workgroup Document](../../medical-workgroup.md) for questions about the differences between these documents please consult the medical workgroup through the SS14 discord server. | ||
Princess-Cheeseballs marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
Princess-Cheeseballs marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| ## How to label Medical PRs | ||
Princess-Cheeseballs marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| Medical related PRs should, in their description or title, state whether this change is meant to be for the current upstream medical system or for debodying/psycho-med. A PR without these labels is not subject to closure unless the author is unable or unwilling to have their PR adhere to the design goals of either system. | ||
Princess-Cheeseballs marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| ### PRs for Current Medical | ||
| A PR for current medical should typically be for fixing up or rebalancing a current behavior and justify why it should be fixed up or rebalanced. Because the current medical system is flawed and simplistic, justification is a very important part of the PR description, why do we need to make changes now instead of just brushing it off until medical is refactored as a whole. Common justifications would be bugs, exploitative behavior, unbalanced behavior, or small additions which do not greatly alter key systems. | ||
|
|
||
| In addition these PRs cannot and should never reverse debodying or hardcode body system behavior into another system. If a PR is unable to be changed to meet these criteria it must either be refactored to be made for psycho-med or be closed. | ||
|
|
||
| ### PRs for Psycho-Med/Debodying | ||
| A PR for debodying/psycho-med must be cleary stated as such and must adhere to the [Medical Design Document](../medical.md). These are subject to much heavier scrutiny since psycho-med and debodying related changes are expected to be final. These PRs should clearly explain how this advances the medical system or advances the destruction/reconstruction of body system within the PR itself without compromises. If compromises have to be made, which is common and expected, it should be explained what the compromises are, what is needed to remove them, with a plan of removal, and why the compromises can't be addressed first. | ||
|
|
||
| PRs which have to be split into multiple parts may require a design document, this is particularly true if any of the following criteria are met: | ||
| - PR is not covered by a previous design document | ||
| - PR was not pre-approved by a medical workgroup member | ||
| - PR strays from the Medical Design Document or Medical Workgroup Document | ||
| - PR is of such large scope that it may need to be divided amongst multiple contributors | ||
|
|
||
| For more questions on Debodying and Psycho-Med please see: [Medical Workgroup Document](../../medical-workgroup.md) | ||
|
|
||
| ### PRs for Offmed | ||
| PRs for offmed shouldn't be merged into master as offmed is a testing branch. These should instead be merged directly into the offmed branch themselves. Since offmed is a feature testing branch and completely under the control of the medical workgroup, any PR intended for offmed may be closed for any reason. | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,60 @@ | ||
| # Medical Work Group Document | ||
|
|
||
| ## Overview | ||
| Given the split, unbalanced, and blatantly unfinished nature of this game's medical system it's necessary that the medical workgroup's responsibilities and limitations are in a public space such that they can be easily understood and read. | ||
|
|
||
| The medical workgroup is responsible for the medical system of Space Station 14 which includes but is not limited to: Damage, BodySystem, Reagents, Metabolism, BodySystem, the Medical Department, and Chemistry. The goal of the medical workgroup is to nearly completely overhaul all of these systems to match the mechanical depth of Space Station 13's various medical systems. | ||
Princess-Cheeseballs marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| To accomplish this impossible task I have set aside three basic responsibilites of the workgroup. | ||
|
|
||
| ### Responsibiltiy 1: Maintaining Current Medical Balance | ||
|
|
||
| This comprises of two things, keeping medical balance static as microbalancing is bad and takes away from work we could put towards making it better, but also doing active maintenance on it. Fixing bugs, adding small features, code improvements, cleanup ect. | ||
|
|
||
| Upstream medical balance should be in a "acceptable enough" state, and big changes should only be made if something has gone horribly wrong or needs fixing. New features should be scrutinized and only accepted if they are small and easily reversible or portable to a new medical system. Larger medical changes that may interfere with development should either be redirected to the development of a new medical system if possible, or closed and or frozen if not. | ||
Princess-Cheeseballs marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| Any new PRs for current med should be compliant with the great debodying no matter what or be closed at the discretion of the medical workgroup. | ||
|
|
||
| ### Responsibility 2: The Great Debodying Cleanup | ||
|
|
||
| The bigger responsibility is "The great debodying." This must be enforced if we are to have a body system and complex medical systems. | ||
|
|
||
| All debodying should be compatible with the goals of the new medical system. Debodying is the most important step of the process because it makes building a new medical system a lot easier and gives us a lot more options to make changes without compromise. | ||
|
|
||
| Debodying comprises of two things: | ||
|
|
||
| #### 1. Removing the depdencency of all systems reliant on bodysystem or organ code in favor of more generic methods that anything can hook into. | ||
| Previous attempts to overhaul medical came with the assumption that bodysystem would be on every living entity, such that it was often used as a check for if an entity was a mob that was alive. This resulted in extremely rigid code that assumed that many entities would not only have a body, but that there would be specific organs that did specific things and if you wanted something even slightly different, you'd have to make a brand new system for it. | ||
|
|
||
| Needless to say, this coding approach does not flex the benefits of ECS and is not up to modern wizden coding standards. As a result, all of this code needs to be completely refactored or thrown out. | ||
|
|
||
| As a general rule of thumb: Anywhere that checks for a body component, we should be raising handleable events that body system hooks into. And we should make as little assumptions as reasonably possible about what these events are doing. The less rigid the code, the more creatively contributors can use the system and the more flexible we can be with a new medical system. | ||
Princess-Cheeseballs marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| #### 2. Refactoring and cleaning up reagent code and attached reactive systems. | ||
| Reagent code is messy, broken, and comes with a lot of assumptions and workarounds that aren't nice. | ||
|
|
||
| As a goal, reagent code should be easy to understand, have a usable API, and its features should justify themselves. A lot of reagent code is made with the assumption it would be used for something someday, but that day never came to fruition. | ||
|
|
||
| ### Responsibility 3: Psycho-Med/Offmed | ||
|
|
||
| Psycho med is the name we've given to the planned medical system for upstream, and as a result the third responsibility is developing that system. | ||
|
|
||
| Offmed is an extension of Psychomed, it is a body-system agnostic medical system that simulates a lot of the behavior we want out of psycho-med without having to deal with the baggage of dealing with current body systems. | ||
|
|
||
| It is the duty of the medical work-group to maintain and manage both for different and distinct reasons. | ||
|
|
||
| #### Psycho-Med | ||
|
|
||
| Because of the massive changes required to make a new medical system happen, psycho-med development will need to be done in parallel to current upstream and reviewed and tested off of upstream. From there the system can be merged upstream in large feature complete chunks that would normally be unreviewable due to size and complexity. | ||
|
|
||
| This gives us the leverage to make big sweeping changes while still being able to adequately test them and without the worry of breaking things or having to do big rollbacks that result in setbacks, delays, and loss of morale. | ||
|
|
||
| As of writing, Psycho-Med has no current singular document for a number of reasons, mostly coming down to organizational reasons. Medical is an exceptionally large system with many aspects requiring a number of targeted documents and discussion for specific systems (solutions, metabolism, organd and body, damage ect.) In addition with refactoring still going on it would be jumping the gun to try and finalize any ideas which are not going to be in the immediate future. Lastly, we have a general medical design document over the desired gameplay and a full psycho-med doc would be a lot "crunchier" falling more into a series technical design document for how we want specific systems to interface. | ||
Princess-Cheeseballs marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| #### Offmed | ||
|
|
||
| Offmed, aka "Offbrand-Medical" is a official unofficial upstream medical system. Like other unofficial medical systems integrating into it comes with the baggage of potential upstream breaking changes and loss of support. Everything in Offmed is subject to change on a structural level as it is a testing bed for the features we want to see, not the finalized version of them in any capacity. | ||
Princess-Cheeseballs marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| That being said, Offmed is meant to take advantage of the currently merged refactors and changes to bodysystem meaning it will evolve as psycho-med evolves. Consider it a look into the future of medical since a lot of the simulationist aspects are using smoke and mirrors tactics to avoid touching systems that still need refactoring or building. Features from offmed will be ported to psycho-med as needed and when we are able to. | ||
|
|
||
| As such, offmed is not planned to be officially released in any permanent capacity. Releases and tests are handled by the medical work-group and are for testing purposes without obligation for long term support or a regular release schedule. | ||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.