# Development Roadmap

<style>
.ui-infobar, #doc.markdown-body { max-width: 66%; }
</style>

## Summary

- Track state of ongoing / planned projects as well as ideas / plans for various things.
- Anyone wishing to contribute should coordinate with maintainers for edits.
- Something not being in here doesn't mean we're not doing it, it means it isn't planned yet. Please, propose additions to departments. Anything helps, whether it's a single item or a full backend system.
- Nothing is set in stone unless stated or already in active development. Regardless, anything in here is authoritative and reviewed by *a* maintainer.
- Please check [HackMD](https://hackmd.io/@citadelstation13rp) for more information.
- This is not strictly code related. Lore / Admin issues can/may be on here too, it's just out of the hands of the maintainer team to deal with.
- Anything with a (name) after it is being staged by that person.
- If you have interest in helping with a project, contact that person.
- Anything finished will be **removed from the document** to prevent too much clutter.
- If we determine we **won't** do something, we **may** make a note of it in the document for future referencing.
- Otherwise, assume that any feature that doesn't *directly* spit in the face of these is probably alright. We want to be as flexible as we can.
- **Backend / refactor projects are not on here.** Those are usually a silicons/zandario thing to deal with. They don't mean a lot to the average player.
- Some of them, like atom damage, regardless have a pretty massive impact / add major features.

## Goal

Citadel RP's general goal, development wise, is to:

- Make interesting, sustainable mechanics for our format (5 hour rounds, with canonicity) that are decently easy to learn, but still open ended so that there's no one best way to do them.
- Have our mechanics and game world be sensical enough to roleplay around and support the atmosphere we're going for.
- Keep the server 'habitable' for slow / more relaxed character development / roleplay as opposed to just littering in high action all the time.

### Game

The general gameloop will be this:

1. Station / Ship is primary map. Most players are here.
2. Every other faction is considered offmaps.
3. Everyone is able to explore the world. The station / ship always has objectives to do so, as that is why it is here (unless we make a map with a different niche, this is under the assumption it's a NSV/NEV-class map.)
4. Things are procedurally generated for the above point.
5. Conflict arise organically between players, whether of the same or different factions. Everything should be organic; admins step in for OOC rulebreaks as outlined in rules, not for hurt feelings *alone*.
- Assuming players are cooperative and are in good faith, punishments should be IC.
6. Events can always break this gameloop.

### Exploration

The codebase, and game as a whole, is focused towards exploration - whether literal, or through interactions of the main player map (held by the main corporation, which is currently Nanotrasen) with 'offmaps' / other factions.

- On a planet map, the primary content is the planet, as a whole. Players should be able to form away teams and go outside to explore and interact.
- On a ship map, the primary content is the overmaps system and generated planets / ruins / offmaps. Players are able to form away teams and fly out on shuttlecraft, with the main ship acting as an anchor that most of the crew operates and works for - the main ship should accompany said shuttlecraft and the IC niche / reason the main ship is around is going to have something to do with the concept of exploration / discovery.

### Atmosphere

Ship / Station are interchangeable here.

Without getting too wordy because this is hilariously abstract, I'm going to just say the following:

- Space is dangerous. It shouldn't feel safe or trivial to go around it, even if it is in game. Overmaps will be adjusted to match.
- The main ship / station / planet (and, to an extent, factional ones) should feel like a beacon of light in the darkness, but still one that struggles.
- The main map should be well supplied, but not enough so that it doesn't have to worry about provisions at all. This means they aren't **required** to cooperate with any *one given* offmap / faction / do any *one specific* thing to survive / accomplish their goal outside of the goal itself.
- Offmaps should be slightly less well supplied, and lack something (non-critical, obviously, unless we're doing something special; 'just remove their medbay' isn't usually a valid way to balance a role.). This makes it so they should cooperate with each other, or the station, if they need something. The key word is **or**. They should not be beholden to the station.
- If this all sounds complicated and arbitrary, that's because it is.
- It should be decently comfortable on the ship rather than grimdark. The ship **should** be decently lit, decently spacious, have recreational facilities, etc.
- This, by extension, means that the ship should feel safe. This is the case. The ship does not need to be *actually* safe, and there are things we can do in code/map design to enforce this.
- We intentionally partially segment the ship between civilian areas that are more centralized and shielded by map area and work areas that are shielded from the void of space by a thick hull. This gives a sense of security that's in reality, easily breached, especially if we manufacture 'defects' / flaws into the map.
- There's some pushes to do occult stuff. We're not going to talk about it in this document because that's frankly out of my hands and not my problem.

tl;dr: Space is not friendly, but not *everything* is out to kill us.

### Conflict

Citadel RP has historically been pretty, bluntly, boring, and more or less served as a slice of life hangout.

While this is honestly pretty nice and unique, it stops being that when it's run to the ground. A certain amount of gameplay and conflict must exist. It's hard to roleplay in a vacuum, and without this and lore / worldbuilding efforts, it certainly feels like one.

- Starting off: 'antagonists' and 'objectives' are silly. Conflict should arise between characters and their factions. Calling something an antagonist implies they are against the protagonist. **The station are not the protagonists**, they are simply the point of view of the main faction of the server.
- **Offmaps**: We will be doing *copious* amounts of offmap development later on. They will be be bracketed into 1. allied, 2. friendly, 3. neutral, 4. hostile. Allied and hostile are realistically very rare outside of events, as the former makes the game too easy (they're just a free explo team), and the latter are Chaos.
- Antagonist backend: We aren't tossing it out. They're insanely useful. We'll be refactoring and improving them over time.
- Things like changelings / borers are amazing concepts. We'll be keeping them and other things, obviously.
- Things like traitor backend are useful for projects where we need to give people equipment uplinks. They should not be used verbatim outside of specific events, as again, we are **not** going for `antagonists`, we are going for **organic conflict**.
- Going onwards with the 'segmenting' of the map: The reason offmaps are extremely opportune for this is that engagement, especially hostile engagement, is controlled. There is a de-escalation 'timer' / criteria.
- When someone gets chased by security, security will not give up the chase until they are captured, or all of security is dead. This simple problem results in infinite escalation. Offmaps prevent this - you either escape, or you don't and try to get another way to escape or fail to do so.
- This makes ship maps advantageous over planet maps for our purposes when it comes to offmap conflict. We can simulate the same with planets and shuttles, but with ships, it's pretty much just built in for us.
- Stuff like conversion antags will never happen outside of non-canon events.

### The Critical List Of Development Projects

tl;dr this is what we need for shipmaps to be fun and permanently sustainable

this is basically all silicons projects due to their extreme scope and just is here to serve as tracking.

0. **Finishing + playtesting NSV Euthenia**
1. ~~maploader - critical backend for all other projects~~
2. shuttle dynamic / manual landing - critical backend for gameplay
3. derelict (dynamic space ruin) generation system / hardspace shipbreakers - sustainable long term content
4. world sectors / world structs - better planet / zlevel glue backend, sector generation - sustainable long term content
5. overmaps / spaceflight overhauls - critical backend for gameplay
6. station / ship objectives system, and the system that eventually spawns offmaps + seeds the overmaps. - critical backend for gameplay / atmosphere
7. atom damage - critical backend for gameplay. the world should be destructible.

## Core Systems

### Species

Species should be unique and have their own advantages/disadvantages and most importantly, niche. We don't balance around better/worse than humans, we balance around the place of a species in the game and in the game's canonical world.

#### [Species Backend / Mechanics](/dyJDc78jSh6PBq_mKBJJUA)

#### [Species List / Specifics](/w1DEQqNIRUyDHl4P5ORrlA)

#### Projects

- [Holospheres](/jTMzyfwnQQ-nzXTeaVQfIw) - add "hardlight" servitor synthetics as whitelisted role
- Snow vision for Teshari: Darksight (still obeying the darksight vision cone) for all snow tiles regardless of actual darksight range.

### Combat

Combat should be:

- No instant kills. Medical system updates will make it harder to 'full kill' someone without trying, and it shouldn't happen in a few hits unless *completely* outmatched and facing against extremely powerful weapons.
- Costly for both sides in context of 1v1s. Unless one side entirely outclasses the other, you shouldn't walk away from something scot-free if you were trading bullets. This **includes** for simplemobs, which will have their defenses against things like ranged weapons dropped.

All of this combined will put emphasis on doing things slow and thoughtfully rather than sprint shotgun/smg'ing everything in the game.

#### Melee

I really don't know what to do for this section, so skip this for now.

When atom damage comes out and is in full swing, we'll look at what to do. Melee should always be a highly available source, but **not** outclassing ranged as to not encourage brute force charges against things / people with guns.

#### Ranged

Ranged weapons should be:

- Non-abundant: Aka not scarce, but not literally everywhere.
- Ammo-restrictive: Their power is limited by how much ammo you carry. This will go into effect as we tweak and redo storage.
- Effective: A laser shouldn't take 10-20 shots to take down a simple spider. *If* a weapon matches the armor tier / has enough armor penetration to deal with a certain class of defense, it should do the job sufficiently in a few shots, especially against simplemobs.
- Non-hitscan where possible. Projectile speeds, however, will be sped up.

#### Stuns

Stuns should be:

- Not effective in all cases. Someone in full armor / hardsuit shouldn't just go down in a taser shot or two. This drives the cost of engagement up, rather than everyone being able to be taken down by a stun so you can always play nice in the face of belligerence.
- Gradual, as opposed to instant / one hit. Tasers will eventually shoot DoT + stagger probes, and batons will cause more effects than flat out pain (though frankly batons will still be really good since they're pretty high risk weapons).
- Eventually make sense: Synthetics cannot be painstunned, but will receive severe systems disruption from electrical stuns, which does more or less the same effect. RIGs will be somewhat of the same after updates.

### [Cyborgs](/Hk-PVGMoSRK5GkQnnReecw)

### AI

- Nothing planned yet but something that's important enough I'll leave it on here. I believe Mazian has an idea or two, but I might be wrong on that. ~silicons

### [pAIs](/SltEX8KzSkyY1HjSM4dNVg)

- Rework plans in there, would be nice to give them some love.

### [Overmaps (outdated)](https://hackmd.io/6yv10eAsRKGU6is-5hmNMg?view)

We'll (I'll) be following the above, outdated draft still, since I highly doubt anyone else wants to take over any of this. ~silicons

### [Skill System](/EQXpS4TBTDOGtdp03E6CpQ)

This is already in the codebase, and written out. This is all just awaiting implementation - it'll be enabled when we have enough **good** mechanics to hook it into.

### Persistence

**Don't blindly yell about balancing. Trust me, it's already considered and the numbers will be taken care of.**

Absolutely a `silicons` thing. Current planned list of mechanics:

- Persistent materials store for mining: mining should be very difficult but very rewarding, and you shouldn't have to rush mining every roundstart for a whole hour. Short-medium term.
- Persistent techwebs: see science. Extremely long term.
- Persistent debris: Making janitors relevant + fun feature.
- Persistent character system: Augments, organs, prosthetics, limbs, and potentially, afflictions.
- There will be a 'hard reset' button to reset certain threshold of state (how much is determined by the code, not the user) - this is your "Oh no, this is unfun to play because I fucked up too badly" panic button.
- Persistent loadout / bringing items home (?)
- Pilot program: photo albums
- Persistent newscasters / journalism system. See Service department notes.
- Two more are in the Experimental section.

### Misc Combat Things

- rebalance explosions and make them dampened / blockable by walls (silicons)
- rebalance EMPs and make them dampened / blockable by walls, less burst-damaging, but more numerous maybe (silicons)

### Misc Misc Things

- Standardized forms printer
- Memory optimized, templated, a la Aurora.
- Saves players the headache of copypasting from wiki paperwork guide.
- The world should be constructible and destructible.
- If it exists, and it's not an immediate balancing issue to make it buildable/deconstructable, we should aim to make it as such. We **should not** have things that are just not able to be made without admin intervention.
- **Adminspawn only materials/boards, are, however, valid.** Not *everything* has to abide by the above. That would be silly - you wouldn't want people being able to make super broken gear. The above only applies to reasonable things otherwise expected to be usable in gameplay.

## Departments

### Command

- Overmaps update will give them what they need on shipmaps specifically.
- Improve the bioscan system - make it able to track people based on how long they're standing still, similar to telecomms triangulation, only name-and-identifier anonymous; render it on a tgui map of probability clouds.

### Security

- No specifics yet.
- Monara is currently working to overhaul the department.
- Please contact silicons for major codebase proposals.
- Please contact Monara for SoP proposals.

### Science

- Robotics: [Persistent Augmentations](/D7chkh5cSx23KcLE_tdepQ)
- Robotics: Mechs - Design-incomplete. Anyone is free to propose ideas or attempt an overhaul.
- Quick note from silicons regarding mech combat balancing:
- Absolutely no magical ammo synthesis for kinetic/missile weapons. We should make reload packs a la /tg/ mechs.
- Mechs should use high armor tier decent damage weapons with potentially a bit of soft penetration as opposed to extreme damage weapons. This avoids overly buffing their TTK (time to kill) while making them extremely dangerous to face.
- Nanites: Incomplete. Please talk to `silicons` if you want to help. We're looking for programmable swarms without the spreadsheet gameplay of old /tg/ nanites.
- [Telescience / Teleportation](/Ao-b5yOdS9CLqg3M0yg7jA) [(PR)](https://github.com/Citadel-Station-13/Citadel-Station-13-RP/pull/5282) - PR up, WIP by `silicons`
- Toxins: Will be converted to a combined "Materials Research" subdepartment, staffed by both Science and Engineering, and also given a R-UST research reactor. This will happen when either Dynamic Gases, or R-UST overhaul is done, though both are ultimately planned to be the department.
- [Xenobotany](/_u_cNwDgRCKugrBx8O6zmg) - Design-incomplete, help out if you want to take over.
- These two come together
- [Science / Techwebs 2.0](/MSIwwTV6S9KUeshWBpvfZQ)
- [Science System](/TOw18lhATIqBSvs13C6ljA)
- R&D / Fabrication - talk to `silicons`, this is basically a tool for the science system and there'll be a lot of changes down the line.
- [Xenoarcheology](/bn_ewuXlSwyBONLBaqetwA) - Not even started yet, feel free to muck about.

### Engineering

- [Powernets & Engines](/X3JRUCuYRlWvC6UFLSReiw) - **Core department refactor / rework**
- Powernets / APCs / plasma conduits / load balancing is WIP by silicons
- Engine / etc are WIP / being decided.

I am claiming atmospherics even if I'm not actively working on it due to how complicated / involved updating that area of code is. ~silicons

- Speed up & overhaul atmospherics machinery / pipenets, add proper pipe layers and better interfaces (silicons)
- [Dynamic Gases / Gas Research](https://github.com/Citadel-Station-13/Citadel-Station-13-RP/pull/4604) - requires chemical effect refactor (silicons)
- Gas reactions (silicons)

### Supply

- [Supply Systems](https://github.com/Citadel-Station-13/Citadel-Station-13-RP/pull/5469) - total overhaul of economy, supply systems, shipping, exports, etc. Major WIP. (silicons)
- [Mining](/EwMSNc77RjybHiuWn4RzrA) [(Stale PR)](https://github.com/Citadel-Station-13/Citadel-Station-13-RP/pull/4412) - total overhaul of mining mechanics. Major WIP. (silicons)
- Nebula-Style trade pads that require overmaps proximity with trade beacons?
- Mining: Core Defense Drill - idea by Colfer

### Medical

Oh boy we have a number of semi-updated-semi-outdated drafts.

[Medical](/wrAMdjiYTJC5SPjJ9anA-A) - silicons
[Medical Equipment Rework and Additions.](/GGwa9oVTQguJJkfhP6cDMQ) - rezbit

This is pure chaos. If anyone wants to touch medical, talk to us / maintainers / anyone listed above as a whole.

If you're looking for the **general idea** of what we're going towards, check out the first draft by `silicons`.

We'd also love someone taking over and doing something with Virology.

Chemistry, rough notes (silicons):
- CM-like chemical effects system: accumulate than tick, helps prevent stacking from getting out of hand.
- Application methods: touch, inject, ingest
- Better chemical tagging system
- Add temperature
- Add goofchem precursor reagents to dispenser
- Add goofchem chemicals using those
- Add dynamic chemistry / chemical research
- Obtain generated chemicals from gas research or unknown sample vats when out exploring
- Since this isn't CM, we do want to make this faster - make a machine that vaguely says what something does so figuring it out is faster.
- Add an automated system to detect collisions for unit testing and for chemical research generation

### Service

- [Botany](/_u_cNwDgRCKugrBx8O6zmg) - Design-incomplete / not even started, help out if you want to take over.
- Cooking: Talk to Marionette on Discord. They have something being drafted.
- Food should give small buffs and have qualities / etc. Skills system integration for boosts.
- Journalism (silicons):
- Persistent news network with photo / commentary support
- Command can censor/D-notice things, and admins can too (with a stronger override)
- Chaos :)
- Library:
- It would be nice to use the persistent photography backend to allow pictures in books, and better books. We'll see, though.
- We'll migrate books someday to a better format.

### Exploration

- See Discord `exploration 'removal'` thread in #development-rp for details. This is a **major** project that ties directly into the shipmap.

## Mapping

- Maps should have engineered weaknesses and strengths and more or less not be invulnerable.
- **Map control** is how we balance things, not hard access locks. Map control is going to be **core** to access control schemes, including for overmaps (where control columns will be hard-mapped and indestructible, and hard-wiring to it gives you control over a ship's overmap peripherals).
- **Maintainer directives: Do not use adminwalls under any circumstances outside of critical usages in ruins.** They are immersion breaking and jarring.
- Unsimulated walls are allowed for usage to equalize atmos, and at the edge of levels, and no more other than that.

## Fun

- add /tg/station droppods. They won't really be used for cargo but they can be a fun thing for admins/event managers, and potential future planet maps where it makes sense to send pods.

## *Experimental*

Here are the extreme ideas that may or may not be worked on / considered over time.

### Persistent Records

- Persist security, medical, employment records to an *extent* - IC actions can now be seen in later rounds.
- Obvious issues include fraud, griefing, trolling, metagrudging, and all that fun stuff.

### ~~Persistent Identification (silicons)~~ (Cancelled)

~~tl;dr without going too into specifics...~~

- ~~Everyone gets a voice, and a face identifier.~~
- ~~This is just a hash.~~
- ~~This can be changed by voluntary and involuntary methods like surgery / etc~~
- ~~Because we're all snowflakes you can always reset this to your 'canonical' identity so you can't permanently be defaced unless you consent to it.~~
- ~~Everyone gets a lookup table of associations between voice and name, and between face and name.~~
- ~~You see people as `Unknown (e51a)` (example) when they say stuff or when you examine them (and just `Unknown` on mouseover) if you don't know them.~~
- ~~You can manually associate people's faces or voices to a name, or automatically do it by clicking a button you can see if they're wearing an ID that you can view.~~
- ~~This can be **wrong** - it's perfectly possible to associate someone 'wrongly' and have to be corrected later, potentially in another round.~~
- ~~Everyone **always** knows the face + voice of the station's command staff, and face of their co-department-workers.~~
- ~~This is automatically forced onto your memory datums at roundstart, meaning if there's incorrect data, it'll be overwritten (and you'll be notified accordingly)~~
- ~~Security records have the real (roundstart) face identifier of every crewmember. You can view it and compare manually.~~
- ~~The AI / Cyborgs start off with a full database of the crew's identifiers, because they're the AI / cyborgs. This can drift / become out of date.~~

#### But, why?

~~Everyone yells about wanting or not wanting antagonists, but the simple fact of the matter is that antagonist rounds are antagonist rounds either because they have action, or because they have intrigue, or in many cases, both.~~

~~While we can't really jam pack the server with action (nor do we really want to, at least to the level often experienced on 'antag servers'), intrigue is what we do want. An oppressive atmosphere where you can only trust your other crewmembers is great!~~

~~However: As it stands, everyone knows who everyone else is.
It's impossible to stow away on the ship because you can simply check the crew manifest to see if someone's 'real'.~~

~~No, 'remove the crew manifest' is not a solution, nor is 'just break in and add yourself to it'.~~

~~Instead, we can, with a lot of difficulty and adjusting period (and heavens know how many QoL/balancing patches), permanently solve this problem by pretty much making it so you have a certain uncertainty when meeting someone new.~~

~~It will impact how people act around each other, but I don't think it's enough of a big deal that this system is entirely undoable.~~

#### But, why persistent?

~~Because we do canon rounds and persistence and man, while it's already painful to have to 'identify' the same person on every character, it'll be quite a bit worse if you had to do that every. Single. Round. Ad. Nauseum.~~

~~Plus, this adds to the hilarity if you get someone wrong and only get corrected later.~~

## Refactors

Stuff that'll make a big impact and isn't currently being done by silicons, basically.

Please help out.

### `inv_hide_flags`

Current inventory hide system is slow, and bad.

- toss the current inventory hide flags away, most of it should use body parts cover. add INV_HIDE_SEETHROUGH for no-obscure, and INV_HIDE_NEVER to override hide system
- add `body_obscure_flags` that override body_cover_flags when specified, otherwise it uses body cover flags
- define relative layering on inventory slot datums
- only recompute visible items on /datum/inventory level, only when asked to; it's just a cached list of items that gets nulled whenever inventory changes in a tangible way (i might have to add an item flag for 'this item is registered in /datum/inventory in a meaningful way, please invalidate caches when removing')

recompute:
1. start with all body cover flags visible and go from highest to lowest item by slot layer
2. if the item has no flags in visible, check if item has never hide, continue if not, add and continue if so
3. if no obscure, add item to visible and continue
4. remove item's body obscure \|\| cover flags from visible flags and add to visible, continue

to handle stuff like idcards which logically cover nothing, inventory slots get default cover flags that determine what they use for this check when something in it has no cover flags.
this doesn't make it cover, this only is used to check cover so no-cover items aren't always visible

accessories are computed separately, inheriting layer of parent item. if they're visible but parent item isn't, the viewer gets a "`half-cape attached to something you can't see!`"-like message

### `/datum/inventory` `items_by_body_zone()` & `items_in_body_cover()` caching

Auto-invalidated caches on /datum/inventory lazy-generated on request, used for stuff like zone armor checks and whatnot.

Useful for armor checks and otherwise.