# Phoenix Sector
###### tags: Phoenix Sector, Ideas Guy
## Design Notes
### Contracting System
- A system that creates, orchestrates, and rewards players for completing discrete sets of tasks (i.e. Contracts) outside of the Hub.
- Tiered into 5 major categories
- Temp Work: Short, Self contained contract where supplies, transport, and security are provided. Lowest time/risk, lowest payout.
- Day Laborer: 2-3 Contracts in a chain with a related theme/scope, where most supplies are provided, and transport is provided. Usually no risk, low/moderate time investment, average payout.
- Hired Position: A more long form set of jobs, usually completed in cooperation with other players who have built reputation with the job issuer via the previous two tiers. Players are expected to maintain their own equipment, but not organize transport. Long-form compared to other contracts, success is based on the group's performance, and has high potential payout.
- Independent Contractor: One or more high intensity jobs, requiring multiple players, with their own equipment and transport. Solid rewards, moderate/heavy risk, and a significant barrier of entry.
- Factional Missions: Contract work to perform jobs specific to the needs of a given faction, lucrative, dangerous, and necessitating prepwork.
- Dispatched out a hub, starting with the core NT hub only for the MVP
- Give players finite, tracked, achievable objectives inside the contract's area of the game.
- Have some amount of competition in full planet/space environments in larger contracts, where one or more separate contracts might have similar objectives.
### Character Progression
- Three key parts
- A storage medium guaranteed by the server with finite capacity
- A wallet/bank that safely stores the currency the player collects from the game world.
- A ledger of reputation/history with various factions, and what assets/equipment/tech/etc those factions make available to the player for lease/purchase.
- Core progression loop: Do Jobs -> Earn Credits/Reputation -> Unlock more gear/assets -> Get access to bigger and more risky jobs.
- Races should start with just Humans initially to focus on getting working core mechanics dones before moving onto implementing meaningful mechanical gameplay changes to races/balancing races with existing content/etc.
- Strong delineations between what constitutes the various tiers of equipment and how effective those are for jobs.
- Ubiquitous Gear: Things you're likely able to just pick up at the hub for cheap right as you start the game. Cosmetic, or general purpose items that can help you do just about any job.
- Standard Job Gear: Things that you've got to go out of your way to purchase, and keep handy to do your job. This is a toolbelt for engineers, RPD for Atmos techs, surgical tools for medical staff, etc. None of this should be rare, but expensive enough where you'll notice if you forget a piece. Unlimited run blueprints for these items can be purchased with enough faction standings.
- Specialized Equipment: Nominal upgrades to tech or equipment you might use on the job. You'll likely never be provided these by your employer, but they make your life easier when doing contracts where they're useful. Jobs that require them will list them on the contract, and may not let you sign up unless you can prove you have them. Losing one of these is mildly/moderately annoying depending on how much money you have in your bank account. With a Faction's support, you can acquire limited run blueprints for these items.
- High-Tech Equipment: Can't buy this in a department store! These items are things you work for, or get very lucky to find. Usually have a unique feature, or unlock new styles of gameplay via their use. Usually found as part of an Independent Contractor's arsenal, or as requirements for Factional Missions. Blueprints for these items can be found during some high-end contracts, or as rewards from IC/Faction contracts.
- Experimental Equipment: End-Game gear, only possible to acquire through the hardest Factional Missions, requiring large groups of players to successfully complete. Equivalent to "Raid drops", and cannot be manufactured. This gear should have a limited useful lifespan, before degrading into the equivalent High-Tech variant, but trivialize the applicable part of the game while pristine.
### Medical System
- Built around resilience, severity, and effects
- Resilience represents the amount of status effects that can be resisted over a certain threshold of severity before disabling the organ/limb.
- Temporary and Permanent effects are treated the same for the purpose of calculating whether or not to disable an organ/limb.
- Severity represents how serious a given effect is for the purpose of mitigation and effect application.
- Effects are functions that transform the player's status.
- Functional programming paradigm to minimize debugging + simplify test writing
- FIFO Queue of applied effects for healing/reversing effects
- Damage is applied using the following process:
- A tool/weapon/projectile hits a limb
- On impact, the highest/total resistance of items on that limb is calculated
- If the resistance is greater than the severity of the weapon, the attack is ignored
- If the resistance is less, the attack's effects are applied
- Effects include:
- A `penetrating` effect will repeat the above process for organs/implants contained within the impacted limb
- A `cutting` effect has a chance to dismember over a specified severity threshold, or remove a contained organ/limb if enough `cutting` effects are applied.
- A `bludgeoning` effect has a chance to stun the affected target, trip them, or cause them to drop a held item.
- A `cavitating` effect has a chance to shock affected organs/limbs, disabling them for a short period of time.
- A `crushing` effect has a chance to permanently disable the affected limb/organ, if the effect would surpass the organ/limb's resilience threshold.
- Repairing a limb/organ requires medicine/tools/procedures that reverse specific effects
- ex: reversing a Severe Cut requires an item that repairs a Cut at Severe or greater. This may be a
- Items may _mitigate_ effects for a short period of time, but not _remove_ effects, meaning the functional effect is reversed, but they are still listed on the limb/organ as a wound. This can be used to design temporary stims/medicines that mitigate certain status effects at high severity (see: adrenaline mitigating shock, etc).
- Severity levels are specific tiers, represented as flags, not numeric values.
- Order is: Trivial, Light, Nominal, Significant, Serious, Grievous, Catastrophic
- For the purpose of effect mitigation, each damage severity is mitigated in one of the following cases:
- The natural/equipped resilience is higher than the inflicted effect
- The natural/equipped resilience has five or more individual resilience one level below the inflicted effect's severity
- In this context, the effect is mitigated based on the result of a coin toss.
- ex: An arm with 3 equipment granting Nominal resistance, an implant giving the arm 1 Nominal Resistance, and a natural resistance of Nominal will have a 50% chance of mitigating Significant effects.
---
## Roadmap
### Phase One _(47pts)_
* Finish Culling codebase of unnecessary code & features. 5pts)
* Includes Removing...
* Most Gear (except most simple item per category)
* Weapons (reimplemented as part of Medical System rework)
* Races
* Cosmetic Items
* Maps
* Shuttles
* NPC mobs
* Antags
* Most Department-specific Modules, including...
* Science
* Medical
* Cargo (Specifically: remove from shuttle system)
* Engineering/Atmos
* Specifically content that is not a "core system", like power generators/storage, basic atmospheric machines such as pumps/coolers/pipes, construction, etc.
* Player customization UI on-connect.
* Get basic Runtime Station working (5pts)
* **AC**
* Compiles without errors
* Starts in server mode in TGS without errors
* Starts Runtime Station and allows players to join without error.
* Get basic persistence layer setup via... (13pts.)
* REST API for character persistence/s2s information sharing
* MariaDB SQL/NodeJS
* s2s information as blob JSON data
* s2s information indexed via...
* table with sender/recipient columns and "hint" column, with application specific identifier
* e.g. `handoff` or `result` b/t hubworld + contract servers.
* Store character data, including...
* "Safe Storage" (Bank/Lockbox/etc)
* On-Person equipment during SAFE log-off.
* BYOND interface for both layers
* Basic Server Deployment Tools (8pts.)
* Cluster Startup/Shutdown scripts
* Kubernetes?
* Update tools for Major/Minor releases
* CI/CD Updates (8pts.)
* Cull unnecessary automated tests
* ~~Automated Server Deployment triggers via REST API~~ **Deferred**
* ~~Should only trigger on patch versions~~
* ~~Major/Minor updates should require full maint-deployment downtime~~
* * Design initial pass of PS Medical System (5pts).
* See Notes section above for details
* Basic weapons/medicines for dealing/healing effects
* Re-implementation of [`ImmerJS`](https://immerjs.github.io/immer/) in BYOND
* Early Playtest of Medical System in PVPVE Arena (3pts).
### Phase Two _(29pts)_
* Map skeleton of new Central Hub (5pts.)
* First pass of Contract System (13pts.)
* Implement basic cross-server hand-off systems for contracts
* Cross server hand-off using REST API
* Queue of work for each server
* Servers accept work as-available in a "bid" system with requests indicating their availability
* Best bid = lowest player usage + best TPS average reported
* REST API accepts server bid after epoch
* Players teleport to server after epoch, get handed off to new server
* Servers awaiting updates should NOT bid on new work
* Contract Pass/Fail + Timer Checkers
* "Turn In" vs "Completion Watcher"
* Rewards Mechanism
* Possible vectors for item rewards include...
* Deliver straight to safe storage
* Deliver to player inventory on return to hub
* No reputation in first pass implementation
* Basic Contract Maps (3pts.)
* Two Planetary, two Orbital
* Contract Unit Tests (5pts.)
* Contracting Play-test (3pts.)
### Phase Three _(Xpts)_
* Double # of contracts for first two tiers (5pts.)
* Flesh out Hubworld w/Vendors + social areas (3pts.)
* First Pass of Reputation System/Factions (13pts.)
* Add NT-alike Faction, Three Government Factions (SolGov, RUSFOR, Independent Alliance), and Pirate Faction
* Implement low rep yield contracts for initial release
* Add basic items for each faction as unlock-able rewards
* Determine which mode of unlocks, options include...
* Per-Item Unlocks, where each item is assigned a rep required to purchase
* Tiered Unlocks, where items are grouped by reputation tier
* All-Unlock, where faction store is available at a given reputation threshold, contract rewards scale to reputation instead
* Determine which reputation style, options include...
* Unsigned integer reputation, (see FATE's Fame system) where points accrue and unlock rewards per-tier
* Signed integer reputation, (see Rimworld Faction Relations system) where, starting at 0, jobs affect your reputation, enabling +/- Rep with factions you do jobs for/against.
* Signed Floating Point reputation, (see EVE Online Faction reputations) where tiers are based on whole point numbers, up/down to a fixed limit.
*