# Shitmed Design / Product Requirements Document

Just a week away...

# Core Idea

Shitmed is a clear-cut **STOP GAP** full of shitcode, until we have proper medical systems that are intrically tied into multiple facets of the game. It should NOT evolve into a fully fledged medical system.

As such the focus is going to be components that can be easily removed, and minimal modification on the existing systems/YML prototypes when the time comes to inevitably roll it back. In summary, here's what shitmed will do.

- Introduces an actual element of consequence to damages.
- Moves away the medical meta from chemical juggistry bullshit.
- Allows doctors to have an additional avenue besides chemicals (or topicals if corpse) to treat injuries.
- Adds fun to medical [weed cat]

As the system is conceptually also a stopgap, its paramount that its as easy to remove as possible, so a funky namespace and reliance on events/singleton patterns might be ideal here, at the cost of readability.

# Why make a "stop gap" system?

Because every single upstream that is more competent than us seems to love shooting themselves on the foot at every turn, or focusing on abysmal dogshit changes. And frankly this fucking "surgery just a week away" meme needs to die once and for all.

# Overall System Breakdown

An urist, or therefore, player entity is made out of `Body Parts` which may be attached to one another, these body parts serve functions, and can also work as containers for things, such as `Organs`. And when players take damage, their organs and body parts may also suffer damage.

This leads to various consequences, such as `Wounds`, parts malfunctioning or outright just gibbing/popping out of their bodies. Which is where `Surgery` allows you to fix them.

Essentially there are 4 main parts to this recipe in that case:

- Organ Systems
- Body Part Systems
- Wounds & Surrounding Systems
- Surgery Systems

It would be insanity to try and document every single one of those of those before even touching the IDE, so I'll mostly document the ideas around the main ones, auxiliary ones will be added when they are coded.

# Organs

So first things off. Organs, organs serve functions in the body of our beloved urists, each of them doing a specific activity, which are listed out below:

| Part | Function | What happens on removal? |
| -------- | -------- | -------- |
| Lungs | Intake Air | Asphyxiation |
| Liver | Process Chems | Can't process chems |
| Kidney | Process Drinks | Can't drink |
| Stomach | Process Food | Can't eat |
| Eyes | Vision | Shader w/ extremely limited POV |
| Heart | Pump blood, process chems | Delayed death, can't process chems |
| Brain | Houses the mind | Instant death |

# Organ Component

An organ should be able to know a few things about itself, namely:

Leaving a note to add removal procedures somewhere.

| Property | DataType | Brief Desc |
| -------- | -------- | -------- |
| Body | EntityUID | What body does this belong to? |
| OriginalBody | EntityUID | What body was this created on? |
| ParentSlot | Custom (OrganSlot) | What slot does this belong to, and with what properties? |
| OrganType | Enum | What type of organ is this? |
| Internal | Bool | Can this organ be accessed directly? |
| Species | String | What species does this organ belong to? |
| \*RejectionRounds | Integer | How many times should cellular damage occur on part rejection |
| \*RejectionCount | Integer | How many times has it been rejected? |
| Integrity | Float | Is the organ still in good shape? |
| MaxIntegrity | Float | Whats the max HP of this organ? |
| \*HealingTime | Float | How often does the organ run a check for a self heal? |
| \*SelfHealingAmount | Float | How much does the organ self heal for? |

`* This element might be part of an axed or postponed feature for the sake of scope.`

---

### Organ Slots

Organs also logically need to fit in a "slot" within the entity, which represents the area where the organ goes, and other things could potentially be inserted.

These organ slots would be attached as part of the `BodyPartComponent` which will represent each body part of the entity. Each OrganSlot has the following data:

| Property | DataType | Brief Desc |
| -------- | -------- | -------- |
| Child | EntityUID | What organ is associated with this slot? |
| Parent | EntityUID | What body part or entity is this slot attached to? |
| Attachment | EntityUID | Is there something (tool or entity) attached on this slot? |
| \*HasItems | Bool | Are there any items embedded in this slot? |

`* This element might be part of an axed or postponed feature for the sake of scope.`

---

### "Sub"-organ Components

The majority of the organ components don't actually need any unique properties on their own for these first iterations.

Theres some discussion to be had around unique organ properties, such as the heart having potentially health, strain and other values to simulate heart failure, or the liver/kidneys processing toxins. But for the sake of speed let's go simple and limit the components to just act like glorified tags.

# Organ Systems

So for these sections, we'll break down all of the relevant systems that would be used.

###### PS: Some of this stuff is already implemented in existing versions of the code. But it will be written down for the sake of completeness

### Eye System

This one would be fairly simple, when the body loses its eyes, we send an event that applies a blind overlay on the individual. If they get working eyes again, we remove this overlay.

In latter iterations, damage would be stored in the eye itself, so if you get eyes from a person thats been flashed nonstop, you'll still get bad eyesight.

---

### Stomach System

Stomachs do a couple of functions, namely intaking foods/nutrients (these are in form of a solution), vomiting those solutions if needed, and digesting them.

The removal of a stomach would mean that you cannot process any foods or liquids, which will starve you to death. So we need to check for its presence in `VomitSystem`, `FoodSystem` and `DrinkSystem`.

In latter iterations, if a person eats food or drinks something that contains toxins and the like, these should inflict some amount of damage to the organ. The more damaged the stomach is, the less efficient it is at eating meals and with a reduced capacity.

---

### Kidney System

Kidneys serve as a filter for the liquids and waste product that is generated by our body. Which means they help to get rid faster of toxins and other poisons.

Probably for a first iteration it would be best to keep them as simple metabolizers (`MetabolizerSystem`), whose removal would very slowly start causing poison damage for the user, as they cannot filter out waste in their blood/liquids.

Afterwards we would likely want to take it into more of a toxin filtering direction, akin to how MiningStation does it, complete with an expanded `BloodstreamSystem`. How this will work is still TBD.

---

### Liver System

Livers are in a similar spot to Kidneys, they would directly be in charge of processing chemicals in the body, along with processing some toxins.

The removal of a liver would probably also poison you slowly (needs to check for its presence), but additionally remove your ability to process and reap benefits from ANY positive chemicals (`MetabolizerSystem`). Toxins would still affect you.

Ditto as the Kidney system, in the future this needs to be expanded via `BloodstreamSystem`, but for a first iteration simple checks and poison ticks should do.

---

### Lung System

Lungs take care of allowing the entity to breathe and exhale air, the lack of lungs simply means you will choke to death (asphyxiation). So its presence needs to be checked for in `RespiratorSystem`.

Lungs also allow you to smoke, and reap any benefits from chemically laced cigarettes. If you have no lungs, you will be unable to smoke (`SmokeSystem`).

---

### Brain System

Brains are probably the most important element in terms of organs, they hold the `MindComponent`, which lets the player control whatever entity its on.

The removal of a brain means you "die". How we handle this entity's death after brain removal is another ordeal entirely (would they just straight up die? would they go in stasis? or do they just live until removed from a stasis bed?) but thats the idea.

For a first iteration it would likely be completely fine if we keep it as is, as theres already checks for removal and addition, in the future however we will definitely want brain damage to have lasting annoying effects (reverting controls, random actions, dropping to the ground, body part failure, etc).

---

### Heart System

Lastly the heart. Extremely vital organ, pumps blood all over your body, and in turn allows chemicals to flow through. No heart would mean your blood is not gonna move, so you will rapidly asphyxiate (`RespiratorSystem`), and also wouldn't be able to metabolize chemicals (`MetabolizerSystem`).

# Body Parts

Body parts are in a similar boat to organs, they are kind of the "outer layer" of them for entities, as such, they are prone to damage, and also hold the entity's organs.

Continuing the similarities to organs, they serve functions, and when removed the entity suffers either a debuff, or the removal of an ability. Below you can see a quick reference table for this.

| Body Part | Function | What happens on removal? | Organs |
| -------- | -------- | -------- | -------- |
| Head | Vision, Speech, Hearing, Eating, Mind. | Death. | Eyes and Brain. |
| Chest | Connects all parts. | Death. | Heart, Lungs, Liver, Kidney and Stomach. |
| Arms | Connects the body to hands | Loss of hands, thus loss of hand usage. | |
| Hands | Allows the entity to grab and use things. | Can't grab or use things. | |
| Legs | Connects the body to feet, allows movement. | Loss of feet, thus slowdown, and eventually loss of movement. | |
| Feet | Allows movement. | Slowdown, and eventually loss of movement. | |

# Body Part Component

Body Parts should also know a few things about themselves, such as:

| Property | DataType | Brief Desc |
| -------- | -------- | -------- |
| Body | EntityUID | What body does this belong to? |
| OriginalBody | EntityUID | What body was this originally from? |
| ParentSlot | Custom (BodyPartSlot) | What slot does this belong to, and with what properties? |
| Children | Dictionary<string, BodyPartSlot> | What body parts is this a parent of? |
| Organs | Dictionary<string, OrganSlot> | What organs are inside this body part? |
| Wounds | Dictionary<string, Wound> | What wounds does this body part have? |
| PartType | Enum | What type of part is this? |
| Species | String | What species is this body part compatible with? |
| \*RejectionRounds | Integer | How many times should cellular damage occur on part rejection |
| \*RejectionCount | Integer | How many times has it been rejected? |
| IsVital | bool | Would removing this body part kill the entity? |
| Symmetry | BodyPartSymmetry (enum) | What is the symmetry of this part? (used for limbs) |
| Attachment | EntityUID | Is there something attached? If so, what? |
| \*Container | bool | Can this body part contain things? (storage) |
| Incisable | bool | Can this body part be cut? |
| EndoSkeleton | bool | Does this entity have a skeleton? |
| ExoSkeleton | bool | Does this entity have an outer shell? |
| EndoSkeleton | bool | What species is this body part compatible with? |
| Integrity | integer | What's the health % of this body part? |
| MaxIntegrity | integer | What's the max health of this body part? |
| \*HealingTime | float | How much time does this body part self heal for? |
| \*SelfHealingAmount | float | How much does this body part self heal for? |
| \*HealingTimer | float | How much time has this body part self healed for? |
| Working | bool | Is this body part still functional? |

`* This element might be part of an axed or postponed feature for the sake of scope.`

---

### Slots

Body Parts due to their position can contain either Organs (OrganSlots) or be connected to other Body Parts. The former has been somewhat explained in the previous section, only leaving us with Body Part Slots.

Every Body Part's slot should be able to know what body parts are connected to it (children) and what body part it comes from (parent), which when traced all the way back, leads to the root (BodyComponent). An easy way to imagine this would be by representing the human body as a tree diagram, which starts out from the "center", and everything connects to it.

###### Somewhat shitty example but it conveys the idea

With that said, a BodyPartSlot would know the following things about itself:

| Property | DataType | Brief Desc |
| -------- | -------- | -------- |
| Child | EntityUID | What body parts are in this slot? |
| Parent | EntityUID | What body or part does this slot belong to? |
| Attachment | EntityUID | Is there something attached to the slot? If so, what? |
| IsRoot | Bool | Is the body part the root slot? i.e. Should it be removable? |

---

### Body Part Appearance Component

This kinda exists right now, and helps systems manage the states/appearances in body parts. But needs some small additions, particularly:

| Property | DataType | Brief Desc |
| -------- | -------- | -------- |
| Color | Color | What color is this body part? Usually matches the entity's skin, but might change if its an implant or smth. |
| OriginalBody | EntityUID | What body does this originally belong to? |

---

### Body Component

Lastly the body component itself, this holds the "root" that every single body part is attached to, and is the last stop if you were to follow every part's parent. It already exists but logically needs a few extra fields to handle part information, such as:

| Property | DataType | Brief Desc |
| -------- | -------- | -------- |
| Root | BodyPartSlot | What slot is the root of this body? |
| RequiredLegs | Bool | Does this entity need legs to walk? |
| \*Species | String | What species is this body? Used for matching parts. |

`* This element might be part of an axed or postponed feature for the sake of scope.`

# Body Systems

Now we get to the meat of this section, the Body System can be roughly divided in a few sections when it comes to logic and functionality, these being:

- Handling the body itself.
- Managing the parts.
- Managing the organs.
- Handling the appearance of the body and its parts.
- Keeping tabs on the integrity of the parts.

I'll break down some of the main functions that would be needed for each section, and flesh them out more as they are coded in.

---

### Body Management

Besides the obvious functions that would let us initialize a body, along with gib, and attach/remove parts from it, we would need to make a lot of use of IEnumerable iterators, since we may want to know for a given body:

- What are all of its parts?
- What are all of its organs?
- What are all of a part's organs?
- What are all of the children of a part?

Which is easily handled via recursive calls to functions that iterate on themselves via yielded returns. Though a bit harder to parse for my inexperienced ass :)

---

### Body Part Management

Body Parts are in a similar boat, they need obvious functions such as:

- Attaching and removing body parts
- Managing their slots, along with tracking which parts:
- Are their parents
- Are adjacent
- Are their children
- Checking for their children organslots, and potentially components they contain.
- Getters/Setters for states such as incised, exoskeleton open, etc.

---

### Organ Management

Again for organs, they need functions like:

- Attaching and removing organs from a given body part.
- Managing their slots, along with tracking which body parts "own" them.
- Getters/Setters for states relating to the BodySlot.

---

### Appearance Management

This one is probably the simplest, it needs to check if the body has any special visual layers (such as markings or custom limbs) that need to be applied on top of the particular body part.

Along with watching when a part is removed/added from an entity to make it visually match the action.

---

### Integrity Management

Lastly integrity management, this one is essentially how we apply damage to the body parts, no clue how blended it will be with the Damage Systems and DamageableComponent, but there's gonna be a non insignificant amount of overlap.

This should handle damaging a part, healing a part (be it by medication or self healing), removing it when integrity hits 0, and disabling or enabling it depending on damage thresholds.

# Woundmed

###### * From this point onwards the document gets a bit hazier due to not having many references to steal from, but mostly conceptual!

So, logically, taking damage damages your body parts or organs, the gameplay that comes out of dealing with these consequences is commonly referred to as Woundmed.

Let's get the elephant out of the room. **Yes, implementing proper woundmed requires a body doll, and targeted damage.**

We already have basic infrastructure planned around body part damage, so it just comes down to creating a "working" body doll, to then target all instances of damage to that part, or default to the root slot's part on a given entity. (Or the entire entity if they dont have body parts, such as animals)

The current concept for a body doll is simply a fake one, which is a series of PNGs representing the user's body, and can be toggled via a radial menu, at least until I get someone competent enough with XAML to make the real deal :)


###### Imagine this but its the different parts of a body, represented with the sprites of an urist's body parts.

# Woundmed Components

### Wound Component

Wounds should be a component that can be attached to either an entity, one of its body parts, or even later down the line, organs themselves. For the sake of simplicity lets consider it to only entity (Whole body) or a single Body Part.

This wound component would have:

| Property | DataType | Brief Desc |
| -------- | -------- | -------- |
| Parent | EntityUid | What entity is this wound attached to? |
| BodyPart | BodyPartSlot | What body part is this wound attached to? |
| Severity | Integer | How severe is the wound? (Obtained based on damage taken) |
| WoundType | Enum | What type of damage caused the wound? (Can be used for effects, should be serialized at some point)
| HealthRemaining | Float | How much health should the entity restore to get rid of the wound?
| MaxHealthRemaining | Float | How much maximum damage should this wound at the given severity have?
| DamagePerTick | Float | How much damage per tick should the entity take with this wound?
| ShouldDamage | Bool | Should the wound apply its DamagePerTick value?
| TimePerTick | Float | How much time should pass between each tick?
| RunningTime | Float | How much time has passed since the entity got this wound and took damage?
| MaxRunTime | Float | How much time can the wound inflict damage for? (Intended for lower severities)
| IsPaused | Bool | Are the wound's negative effects paused? (Commonly by stasis or sleeping)
| HealingMultiplier | Float | How much of the entity's healing counts towards removing the wound?

> Note: Later down the line we want to turn these wounds from status effects scaled on the damage types... into serialized unique wounds that are tied to the severity, akin to how [Wizden's Newmed draft](https://github.com/space-wizards/space-station-14/pull/19383/files#diff-5a1b2593264793d38d128d93c6394d13268fe821be9e2d995bb51683f5786527) does it.
>
> In practice this means that you could potentially have minor cold burns that simply lower your mood, all the way into major frostbite damage that slows you down, adds a moodlet penalty, and adds other components.

---

### Target Component

This is mostly a rough idea, don't have much detail or thought behind it yet since there's no public examples of targetting code.

| Property | DataType | Brief Desc |
| -------- | -------- | -------- |
| TargetPart | BodyPart | What body part does this entity want to target? | Parent | EntityUid | What entity is doing the targetting?

###### Only two properties, sad :(

This component would be used mostly to hold the state of the entity, and what it should target with damaging and (later down the line) other actions. The rest of the logic should be done via raising events, or hijacking damage/healing attempt events.

---

### Wounding Component

Tentative idea. This component allows any given weapon to indicate what types of wounds it inflicts, and what chance it has of inflicting one upon impact.

And yes, each weapon might have its own damage object declaring what types of damage it does, and I could check that on every instance of damage... But that might not be very efficient. And it cannot accomodate for special cases. The properties would be as follows:

| Property | DataType | Brief Desc |
| -------- | -------- | -------- |
| MainType | Enum | What damage type does this entity do?
| WoundChance | Float | Modifier to every hit's chance of inflicting a wound, could be positive or negative. |
| \*SpecialVerb | List | Vague idea, serves as a list of special verbs weapons might be able to do (axes should be able to behead!)

`* This element might be part of an axed or postponed feature for the sake of scope.`

# Woundmed Systems

Again, since theres not a lot of implemented examples of this system + targeting, details on what systems there are might be a little vague. But I would roughly group them up as follows:

### Target Handling

This system would be rather simple, it would have a main client part, which handles the "Command Binds" or clicks on the body doll, along with managing the creation of a Radial Menu which corresponds to the parts the entity can target. In the process sending an event once its done.

This event would be then picked up by the server to set what limb an entity wants to target now (Should it be this way? Not sure if it could lead to cheating by hijacking what limbs an entity is targetting). And saves this data to its respective `TargetComponent`

---

### Damage Handling

This part might be a little dicey, it can be done at multiple points, be it by listening to the damage events, or by writing directly into their systems, but essentially we'd listen for each damage instance, and from there:

- Decide what part the damage is going to be applied to
- If the target entity doesnt have the desired part, then its an animal and should be applied to the body or chest by default.
- Roll for a wound, and apply any respective multipliers from the weapon and such. (Might need to raise an event).
- If the entity already has wounds on the target, and isn't on stasis, we refresh and potentially modify their severity.
- Reduce the targetted part's integrity, and raise any necessary events.

---

### Wound Handling

As for wound handling, most of the work is done however we decide to modify the Damage Systems (if we rely on events, a lot of that is going to be moved to this system). But some additional functionalities would be:

- Keeping track of the time via `Update()` to know if a wound should apply damage, stop doing so, and whatnot.
- Adding, removing and modifying wounds.
- Managing a wound's special effects based on the type (shitcodey, hopefully I won't need to do this before I serialize wounds).
- Managing a wound's health, based on the healing events raised on the entity, and remove if needed.

# Surgery

Surgery would be the complete process to open up, repair, add or detach body parts. And is also the natural culmination of all of the systems that I just defined! Theres a couple of existing systems, and IMO the better implementation to steal ideas from is currently RMC's.

The main idea would be (another set of) radial menus that guide you via popups on what steps to do for surgery, still keeping it somewhat linear, but with minimal implementation efforts, which would later allow us to introduce a dynamic amount of surgery options per each step (branching) as the user is undertaking a surgery.

# Surgery Components

Going off RMC's implementation, most of the work is actually defining components, for surgery we would need:

- SurgeryComponent itself.
- Components for each of the tools (scalpel, hemostat, retractor, etc)
- Components for surgery steps
- Components for surgeries
- Components for conditionals or body states (are they buckled, are they asleep, etc)

The reason we have so many components is because a lot of things are dynamic in surgery, your tools might not be actual tools, but maybe an esword or glass shard that you found on maints, so being able to define in YML prototypes what effects and values these should have is key.

Same with surgeries, by serializing them, we can make the system incredibly flexible when it comes to adding different types of surgeries that may not differ that much from the base (i.e. We have surgery for adding/removing items to an entity, and we make a surgery to add/remove implants based off it.) This also would apply to the steps themselves!

As for the conditionals or body state components, these will make it a lot easier if we ever have special components (such as the xeno larva) affecting the entity.

###### PD: These will be expanded as I get to implement them for realsies.

---

### Surgery Component

| Property | DataType | Brief Desc |
| -------- | -------- | -------- |
| Requirements | EntProtoId | What entity prototype (step/surgery) does this require? |
| Steps | List<EntProtoId> | What are the steps of this surgery? Represents prototype IDs of steps. |
| BlockingSlots | List<string> | What slots block this surgery from taking place?

---

### Surgery Tool Component

| Property | DataType | Brief Desc |
| -------- | -------- | -------- |
| MalpracticeDamage | DamageSpecifier | How much damage should this tool do when something goes wrong?
| FailRate | Float | How much chance does this tool have of failing?
| StartSound | SoundSpecifier | What sound does the tool make when starting the surgery?
| EndSound | SoundSpecifier | What sound does the tool make when ending the surgery?

---

### Surgery Step Component

| Property | DataType | Brief Desc |
| -------- | -------- | -------- |
| Tool | ComponentRegistry | What tool component does this step need? |
| Add | ComponentRegistry | What components should be added when the surgery is done? |
| Remove | ComponentRegistry | What components should be added when the surgery is done? |
| \*AffectsBody | bool | Should the surgery affect the body or just a part? |

`* This element might be part of an axed or postponed feature for the sake of scope.`

---

### Conditional Components

This is more of a broad umbrella, but for each conditional we would define components, for instance, the checks for whether or not a surgery would work on all parts or just one would be serialized within the surgeries or steps themselves.

# Surgery Systems

As for the systems surrounding surgery, its fairly simple by itself, since the structure of this surgery system relies heavily on serialization and a lot of components to do the work. What we need to do in summary boils down to:

- Populating the radial menu containing the surgery "branches" or options.
- Showing the user next steps along with helpful tooltips or prompts to keep them informed of what they need to do after.
- Check along each step for necessary components, and see if the surgery's conditions (tools, buckling, state) have been filled before proceeding.
- Check if components need to be added or removed as each step is done.
- If surgery is interrupted for whatever reason, deal shock damage to the entity. This might be hardcoded in the now.

# Action Items

So here's an evergrowing list of shit we need to do in order to make real all of my yapping above!

Ideally I'll get these into some form of ticketing system with story points and all that fancy jazz once we're a couple of weeks in. For now we'll explore how much shit we can get done.

---

- [ ] Modify the existing Organ Components to accomodate for new properties - **Difficulty: Low**
- [ ] Add any missing functionality to the existing Organ Systems to account for when they are removed or added. - **Difficulty: Medium~High**
- [ ] Eye System
- [X] Brain System
- [ ] Heart System
- [ ] Lungs System
- [ ] Kidney System
- [ ] Liver System
- [ ] Stomach System
- [ ] Adjust/create OrganSlots to prepare them for the upcoming work with surgery and body parts - **Difficulty: Low~Medium**
- [X] Create if needed BodyPartComponent, and add the necessary properties to the base prototypes - **Difficulty: Low**
- [X] Adjust the existing BodyPartComponent and BodyPartSlotComponent to include new necessary properties - **Difficulty: Medium~High**
- [ ] Clean up serialization for species, ensure that components are being added accordingly to organs, body parts and their respective slots. **Difficulty: Medium**
- [X] Add surrounding systems to the existing body parts if needed which affect the entity when they are removed. - **Difficulty: Medium~High**
- [X] Head
- [X] Chest
- [X] Arms
- [X] Hands
- [X] Legs
- [X] Feet
- [ ] Add the additional functions from MS14 to iterate through things - **Difficulty: Medium~High**
- [X] Fetching through all body parts from the root.
- [X] Fetching through all children body parts from a given part.
- [X] Fetching all of a body part's organs.
- [ ] Fetching an organ's parent body part.
- [X] Fetching adjacent body parts from a given part.
- [X] Fetching all of the organs in the body.
- [ ] Add the functions needed to add or remove organs from an entity. - **Difficulty: Medium~High**
- [ ] Add the functions needed to add body parts from an entity. - **Difficulty: High**
- [X] Add the functions needed to remove body parts from an entity. - **Difficulty: Medium**
- [X] Add functions to damage organs or body parts when needed, be sure to drop or disable parts when they are too damaged. - **Difficulty: Low**
- [X] Create a body target doll and status indicator doll - **Difficulty: Medium**
- [X] Hijack damage events so they target a given entity's body parts, if they lack this body part then target the root: - **Difficulty: Medium**
- [ ] Add the WoundComponent and its necessary properties - **Difficulty: Low**
- [ ] Add WoundingToolComponent to weapons that might inflict injuries: - **Difficulty: Low**
- [ ] Modify damage functions or hijack their events so they can roll a chance to inflict wounds, and apply the respective WoundComponent. - **Difficulty: Medium~High**
- [ ] Add updates and trackers for wounds to disable themselves after a certain period of time, reactivate if hit, and also inflict damage over time based on severity. - **Difficulty: Medium~High**
- [X] Add the RMC Surgery Component, and add it to entities that can be operated on. - **Difficulty: Low**
- [X] Add the RMC Surgery Components to Tools: - **Difficulty: Low**
- [X] Add the RMC Surgery Components for Conditionals: - **Difficulty: Low**
- [X] Add the RMC Surgery Components for Steps and Surgeries: - **Difficulty: Medium**
- [X] Port the logic for steps and surgeries from RMC. - **Difficulty: High**
- [ ] Add wounds and penalties for malpractice - **Difficulty: High**

# How bad of an idea is this?

Well, in my software development experience, it turns out, products that:

- Release quickly, and iteratively
- Are intuitive
- Garner user feedback ASAP
- Provide value quickly with not much effort
- Take into account feedback (easy to do here as its limited into scope)

Usually turn out beating the others. Especially if there is a clear gap in the market (just a week away...), so lets say that shitmed with its reduced scope is completed here in... 3 months maybe? And by then Whitemed or Jezmed is still dead on the water.

By then, people will want more features, things to better enable RP, and our idea of an easily removable system thats not rooted deeply into the game is now a liability. This is *not necessarily* a bad thing, it's a gamble we're taking. **But one that we'll pay for dearly if the community gets used to our system and wants more of it into the experience.**


gaming