Ship Contracts

[deathride58]

As per Citadel Sector XIV's design document, contracts should be implemented as part of the MVP, as they're a vital part of the planned game loop.

Ship contracts should be implemented as entities to ensure the system remains flexible and robust at the abstract level. Additionally, this system should tie into #6, with all purchased ships being inseparable from contracts, and ships requiring a contract defined in order to be purchased. The way contracts work should also be fairly modular, with individual mechanics like scrip, progression caps, the presence of a captain, and more, being implemented as components that contracts don't necessarily require in order to function as expected. Gigs (#13) should also be implemented as entities. Ideally, contracts as a system should be abstract enough such that they're fully capable of doubling as a system that can power hidden role teams (revs, for instance!) and other fun stuff. If implemented well enough, the contract system could very well be used as a backbone for SS14's way of handling antags.

The core functionality of contracts should be keeping track of a collection of (preferably player-controlled) entities with shared values and properties. This could, for instance, allow contracts to function as a way to handle teams in a TDM-focused environment, while still allowing contracts to be used to track a singular individual antag.

This should also tie into #5. Whenever major events happen in a contract (such as gig objectives receiving status updates. What counts and what doesn't should be definable per-contract) containing a payout component, every single character (including the captain) tied to a contract should be added to a payout array, with an associated float value that increments (at a value of 1/(crewcount)) every time that character is added to the array. When a contract is ended by any means, the payout array should be used as a set of weights to determine the cut that the given character receives, with scrip being converted into thalers at a server-cvar-defined conversion rate. Additionally, it should be entirely plausible for any abstract entity to be part of the payout array, such that handling payments for logged-out characters remains straight-forward, and so that NPCs can potentially take a cut of a crew's profit. It should also be plausible to define multipliers for how much weight a given entity can take from the payout array on major events, though for the sake of economy balance, this should only be used for NPCs.

When a ship is purchased, the player who purchased it should be placed as the captain of the ship, and by extension, captain of the contract. The only perks this should grant are the ability to set permissions (such as allowing individual crew members to spend the contract's scrip pool, or determining the access of individual crew members for ships that have more than one access type available), the ability to list the contract on the contract browser (#45), the ability to pass captainship to anyone who's eligible to purchase the ship by normal means, and the ability to remove players from the contract, all from the comfort of their own PDA.

Ships contracts should generally come standard with a pool of scrip. The starting scrip for a given contract should be more than enough to stock up on extra fuel and ammo for a given ship, or potentially make some basic modifications before the ship even leaves the dock. The amount of scrip spent should be kept track of, with scrip spent on Nanotrasen, and scrip spent elsewhere, being tracked separately.

Additionally, players should be allowed to be in an indefinite number of contracts. Not only does this ensure the system's flexibility at an abstract level, but it also directly allows for interesting multi-crew shenanigans that can be properly rewarded, such as the captain of a support ship joining the contract of a larger ship to benefit from their contracts. However, the contract browser (#45) should not allow browsing open contracts when a player's in at least one contract involving a ship component, with the player instead having to be explicitly invited (or buy a ship contract while already in a contract) in order to join more than one contract.

If a ship contract ends while the ship it's tied to is in dock at the Citadel Station, the ship should simply be despawned. If a ship contract ends while the ship isn't in dock, then a swarm of drones should spawn and travel to the ship for the purpose of dismantling it (with no regard for anything that might be inside, and further drones spawning if they somehow get destroyed, until not a single tile of the ship remains). Additionally, when despawning at the Citadel, the ship's value should be appraised, and that appraised value should be used to influence the contract's payout (with upgraded ships increasing the value, stripped ships decreasing the value, and a missing/dismantled/abandoned ship deducting the whole cost of the ship from the payout).

Payouts should also have their pool capped on a per-contract basis, as per the design doc. This cap should be able to be individually adjusted for the final scrip balance, all scrip spent at the Citadel, and the ship's appraised value difference from the initial appraised value. Gigs should become unavailable once the first two caps are met (with the detection for this overflowing scrip from the first cap into the second, such that a contract cannot be made indefinite by simply not spending anything). This should ensure that contracts have a definitive end point at which a new contract must be purchased.

For in-game flavortext regarding ship contracts, inspiration from real-world MLM schemes could probably be used, as they've served as an indirect inspiration for the mechanics outlined in the design doc, and the general flavoring would be fairly on-brand for Nanotrasen.