diff --git a/src/SUMMARY.md b/src/SUMMARY.md index a4220a8ab..35a9c9786 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -11,8 +11,6 @@ Meta - [Docs Example Page](en/meta/docs-example-page.md) - [Docs are for Discoverability](en/meta/docs-are-for-discoverability.md) -- [Feature Proposal Template](en/templates/proposal.md) - General Development =================== @@ -37,6 +35,7 @@ General Development - [Config File Reference](en/general-development/tips/config-file-reference.md) - [YAML Crash Course](en/general-development/tips/yaml-crash-course.md) - [Feature Proposals](en/general-development/feature-proposals.md) + - [Feature Proposal Template](en/templates/proposal.md) - [Expected Team Decorum & Usage](en/general-development/feature-proposals/expected-feature-proposal-decorum.md) - [Work Groups](en/general-development/work-groups.md) diff --git a/src/en/proposals/deltanedas-exterminator.md b/src/en/proposals/deltanedas-exterminator.md deleted file mode 100644 index 872d81d03..000000000 --- a/src/en/proposals/deltanedas-exterminator.md +++ /dev/null @@ -1,41 +0,0 @@ -# Exterminator - -| Designers | Implemented | GitHub Links | -|---|---|---| -| deltanedas | :white_check_mark: Yes | https://github.com/space-wizards/space-station-14/pull/19946 | - -## Abstract - -Basically an offbrand version of the Terminator with everything fairly faithful to the original film. Spawns in naked with no gear and has to find equipment to kill their target, which is the main objective. They can be tasked with killing anyone on the station. - -## Goals - -A midround antag focused on killing a single person then dying, with minimal crossfire. The exterminator comes in does the job and disposes of themselves. Security will have something to do once reported, but it won’t be a round ender. Security are expected to maybe try kill it with guns before realising they aren’t effective then switch to lasers or asking chemistry for bombs. - - -## Gameplay - -While the exterminator has no telecrystals or gear like syndies or ninjas, what they do have is the following: - -- Extreme strength, since its a cyborg from the future strong punches and takes little damage from conventional weapons. Their main weakness is that fire and explosions do huge damage so find an oil tanker or make a flamethrower. -- After taking 200 of any damage or 100 burn damage, they are gibbed and become an endoskeleton. The endoskeleton has no hands and is slow but is immune to burns, stabbing and shooting as it is pure titanium. You have to gib it with blunt weapons to finish it off, like a hydraulic press. - -Since the exterminator’s target can be any human player, killing the chef will be easier than the captain. You’ll have to improvise with how you pull things off. - -As it only spawns without intervention through a midround event, it can never spawn or have multiple exterminators per round. - -The exterminator is not required to collaborate with anyone but can at the player’s leisure. For example, if it spawns when nukies are attacking the station it would be wise to help them since nuking all but guarantees the target’s death. - -As an antagonist you can kill whoever tries to stop you from killing your target, but you should not go out of your way to murderbone as per the game rules. - -## Components -### Endoskeleton - -The biggest thing with the exterminator, replaces gibbing being a completely bad thing. The exterminator has one organ, the brain, which is what gets control after being gibbed. While you are less flexible as a player you do more damage, letting you pull of a desperate last attempt to kill the target. Once the endoskeleton is gibbed from blunt weaponry, it leaves behind a very valuable nt-800 skull, which looks cool and can be kept by the target or sold for big bucks. - -As the endoskeleton can’t hold guns and is slow, it is an easy target for tiders to finish off with bats and crowbars. - - -## Inspirations - -Obviously The Terminator (1984) it’s a classic. diff --git a/src/en/proposals/deltanedas-plant-genetics.md b/src/en/proposals/deltanedas-plant-genetics.md deleted file mode 100644 index 5641a9cd5..000000000 --- a/src/en/proposals/deltanedas-plant-genetics.md +++ /dev/null @@ -1,52 +0,0 @@ -# Plant Genetics - -| Designers | Implemented | GitHub Links | -|---|---|---| -| deltanedas | :x: No | TBD | - -# Overview: - -A new CRISPR-like machine for modifying genomes of plants. -Has a hex editor-like UI where you can seek to a position and it shows a certain number of bases. -From there you can make modifications e.g. swapping out an A at index 38 for a T. Once you are happy and think your modifications won't kill the plant, create your new seed and plant it. -Since genome layouts are randomized roundstart this would be no better than current mutagen roulette of just hoping it gets a good trait and doesnt make the plant useless. - -To solve gene roulette, the second part of this would be experimentation. -Get 2 identical seeds with clippers then mutate one a little using unstable mutagen. -Either the same machine from the start or a separate one can then analyze them and check what genes (bits) are different. -After a little bit of time it either picks a single random bit, or multiple of them, and tells the player what gene name is at that bit. If the gene has multiple bits it will take some investigation to see which bit it is but that's trivial for yield/potency which can be seen just by clipping it. -Essentially you keep experimenting on plants to figure out the index of every gene, and tada youve mapped the plant genome and can make gmos with ease for the rest of the round. - -# Goals: -Promote interdepartment stuff by requiring biomass for gene editing: -- Means there is some cost to minmaxing a plant so you might just have to settle for the important traits -- If there is no med staff / no bodies to juice you can still grow plants as normal -- There was some ideas about being able to reclaim biomass from plants so you could use that to kickstart it. -- Salvage can find biomass on expeditions as a large but irregular source, assuming med doesn't get to it first. - -# Gameplay: -The gene editing would primarily be a window like a hex editor, set a position to seek to and then itll show up to X bases. -You can modify a base by just typing A C G or T. they map to 00 01 10 and 11 respectively in binary, so for every 2 bits you get a single base. -From there the player can feed it biomass and print out a fancy new seed with a cost of say 1 biomass per bit modified. - -Unstable mutagen would randomly flip bits so you could get an increase of 8 to yield or a decrease of 1 to potency, depends on which bit it flips in an int. - -Pollen swabbing, if it still exists, would swap entire gene values rather than operate on a random bit basis. - -This might have botanists split up between growing plants for chef and focusing on mapping the genome to get gamer seeds which is cool. - -Additionally, instead of the current mutation of a viable bool, a system would be in place where there are bits that set unreasonable pressure temperature or light requirements to grow. -If a plant suddenly requires being grown in space or a fire you are unlikely to try, but it's still possible if you are extremely determined. - -# Components: -Plant entities would both have GenomeComponent and its own component for handling swabbing/crossbreeding along with copying genes from parent when clipping. - -Since only bools and ints can be stored in genomes, chemicals would still need to be in solution container component and mutated manually similar to how its done currently with SeedData chemicals. - -# Inspirations: - -- life - -# Requirements: - -Depends on a rework of botany to have plants be ECS. diff --git a/src/en/proposals/deltanedas-signaller-rework.md b/src/en/proposals/deltanedas-signaller-rework.md deleted file mode 100644 index 5f167294b..000000000 --- a/src/en/proposals/deltanedas-signaller-rework.md +++ /dev/null @@ -1,93 +0,0 @@ -# Signaller Rework - -| Designers | Implemented | GitHub Links | -|---|---|---| -| deltanedas | :x: No | TBD | - -## Overview - -This proposal is for a rework of signals to be very short range (2-5m maximum) and have a separate radio transmission system for long-range controlling of objects. - -Linking would effectively be wiring now with its short range. - -## Background - -Currently you can link 2 items together and they can be used across maps with infinite range. - -They can also be nonsensical like linking a door to a microwave. Why would either have long-range transmission? - -With a radio transmission system these systems can be implemented more freely allowing for more in-depth gameplay. - -## Radio Transmission - -This would be the main part of the rework. Radio transmitters would be items that accept signals and send them over radio with a frequency. - -Radio receivers then create signals when a radio wave of a certain frequency is received. These would then be linked to objects like doors or microwaves. - -Radio frequencies would range be in the VHF range between 100 and 200 MHz, with 0.1MHz of precision. This allows for 1000 different communication channels, plenty for a single round. - -In the UI for setting frequency this would mean you can have 100.0 MHz and 100.1 MHz be distinct. - -Since radio uses authenticated encryption, signallers can't interfere with it if set to the same frequency. - -## Transmitters and Receivers - -Radio transmitters either could just be signallers themselves or a new item that can't be manually triggered. -If they are kept separate, the ui for setting frequency can be shared for both. - -Since transmitters can't be manually triggered they would be cheaper to make so making circuits is easier. - -Radio receivers would just be a reworked signal trigger, it doesn't make sense to have a door output linked to a grenade which will move around. - -Signal triggers have a UI to change frequency to match the signaller/transmitter, then you put it in a grenade or have it linked to something nearby. - -Signal triggers would also have a signal sink port for linking to nearby objects. - -Communicating across maps would not be possible, but perhaps a tech could be added for a transmitter that can work across maps and over an extended frequency range. - -## Interacting with objects - -Objects with wire panels like airlocks can have a signaller inserted when the panel is open. - -Things with no panel like lights or microwaves can have them space-glued on, which is visible by examining. - -Objects can still be linked nearby of course, but with shorter range. Maps with auto-bolting airlocks would still be fine. - -## Gluing - -If an item matching a whitelist is glued to an object like a light, APE or emitter, it is allowed to use its signal ports. - -Glued items can be examined by anyone, only removed by spraying some kind of solvent on it, maybe even space lube. - -## Example setup - -A signaller set to 133.7MHz is linked to an airlock's door status port. - -To prevent the signaller from being disconnected by someone moving it, it is then inserted into the wire panel. - -A signal trigger with the same frequency is placed in a modular chem grenade across the station. - -When the door opens, HIGH is sent over radio and the grenade explodes. - -For a light, the signaller is space-glued onto it. This might have a unique sprite layer. - -## Implementation - -Frequencies would just be ushorts, clamped between 1000 and 2000. Essentially 1 place of fixed precision. - -Transmission would use device network, but not the device linking packets. These can have unlimited range but on a single map. - -Signal triggers handle device network radio packets and only use them if they have the same frequency. - -Device linking can then be changed to have a very short range (200m seems to be the default currently?) to promote usage of radio systems. - -Should be easy to add a network that says a device can only communicate if it is glued onto it, which APE and stuff would use but not doors. - -### What I Stole From - -In TG I think it uses a similar setup but with a code as well as frequency. - -I decided not to have a code to make the system less complex and a bit easier to mess with, you only need to guess a frequency not a code. - -In TG it's also just the same item for receiving and sending, you attach a signaller to a grenade to have it trigger it. -I don't think this is the best way to do it. diff --git a/src/en/proposals/deltanedas-turf-war.md b/src/en/proposals/deltanedas-turf-war.md deleted file mode 100644 index d1c83f19d..000000000 --- a/src/en/proposals/deltanedas-turf-war.md +++ /dev/null @@ -1,38 +0,0 @@ -# Turf War - -| Designers | Implemented | GitHub Links | -|---|---|---| -| deltanedas | :warning: partially | [#23290](https://github.com/space-wizards/space-station-14/pull/23290) | - -## Abstract - -Turf war is a sub-gamemode that can be present in others (traitor, revolution; similar to thief). - -Players must use spray painters to tag up turf for their respective departments. Whichever department gets the most doors sprayed at the end wins! - -## Goals - -It is intended to be a small bit of fun seen in some rounds, but not completely taking it over the round like revolution. - -Turf taggers must **not** be selected from other antagonists in the round (could be exclusive with traitor, to keep it as a nonantag side fun gamemode. - -Unlike most gamemodes, players selected can be in command and sec (since they aren't antagonists). - -However, command staff will tag for their respective departments **and not command doors**. Since cap and hop don't govern individual departments, they can't be picked. - -## Gameplay - -Players are not antagonists (unless they are from another role) so they should not immediately start killing everyone, following escallation rules. - -Naturally there will be skirmishes but it won't be as bloody as traitor assassinations or revolutions. - -Each turf tagger has an objective to spray the most doors, which is either 100% (you are winning) or a % of whoever is winning. - -On round end the number of doors each turf tagger has is shown, in order of who got the most. - -Only one tagger is selected from each department at most, but they may recruit coworkers IC (not a flash) to join the turf war. Spray painters are available in YouTools so nobody is left out. - - -## Inspirations - -TG families or whatever its called now, but with spraying doors. diff --git a/src/en/proposals/emogarbage-grid-inventory.md b/src/en/proposals/emogarbage-grid-inventory.md deleted file mode 100644 index 0600407a3..000000000 --- a/src/en/proposals/emogarbage-grid-inventory.md +++ /dev/null @@ -1,72 +0,0 @@ -# Grid Inventory - -| Designers | Implemented | GitHub Links | -|---|---|---| -| EmoGarbage | :white_check_mark: Yes | https://github.com/space-wizards/space-station-14/pull/21931 | - -Credit to the SS13 server Fields of Fire, whose inventory overhaul served as inspiration for the UI. - -## Overview - -Grid inventory is intended to be a replacement for the current inventory backend and UI. -It encompasses both an internal rewriting of storages, wherein they are classified by geometric shapes, as well as a redesign of the UI, aiming to translate the internal logistics of the system in an immediately understandable way. -Under the system, storages will consist of grids made up of tiles and items will be small items that can be moved around and fit into the grid. - -## Storage Pains - -Laying out what's wrong with the current storage system is important, because inventories--and for the purpose of this document, inventory refers to any given storage container, not the players' hands and clothing HUD--fail in subtle and unexpected ways. -The failures can be divided largely into two categories, mechanical and visual, and both show the unique ways in which a core system can underperform and in turn erode more central mechanics. - -In terms of the mechanical failings, those which call for the rewriting of the core of the system, the most evident is the inability to represent objects of unorthodox or strange shape. -Whether it be a numerical size or an enum, it is impossible to communicate the spacial properties of something like a broom or a life preserver. -Inventories cannot be long and thin or made up of many smaller sections. -There is a lot of genuine interest in nuance in the problem of storing an object: it exists as a microcosm of greater questions of the value of what you carry and if it can be stored in an efficient manner. -As the system exists currently, the "efficiency" of storage is not a concept that can be explored, which is a shame. - -On a more surface level, the presentation and interactions of a list inventory is also laden with issues. -By existing as an infinitely scalable list, containers are forced to express the sizes and capacity numerically, relying on exposing objectively meaningless numbers in order to communicate scale. -Furthermore, lists are bad at displaying images at a scale that is easily understood (due to their properties of being scalable) and thus rely on things like text, which simply saturates what should be a very simply HUD element with lots of text and numbers. -Lists are also frequently used to fill up large chunks of the screen, which genuinely looks terrible. - -Ideally, a perfect storage system should not only be able to handle weird sizes and shapes of containers and items alike, but also visually convey this in a way that is immediately able to be understood by a new player without being overly reliant on text and numbers. - -Thing goes in bag is simple: it should feel simple to do. -It should never feel sprawling or overwhelming or like you're scanning your screen for crap. - -## Grid Inventory - -Our solution? A to-scale HUD element that can represent uniquely shaped item's as well as display the size of things in an immersive and immediately understandable way. - -![](../assets/images/grid-inventory/in-game.png) - -### Items - -Items in grid inventory are a deviously simple. -They retain the ItemSize enum from the current system, but gain an additional `inventory shape`. -This is just the shape the item takes up in the grid and it additionally serves to codify the hidden weight mechanics of the current inventory in a more intelligent way. -Rather than tiny items having a weight value of 1, they simply take up a single square. -Items would have reasonable default sizes inferred from the current weight values of items with an optional specifier for other custom shapes. - -![](../assets/images/grid-inventory/shape-examples.png) - -Inside of the inventory, you'd be able to manually move around and rotate items, allowing gaps to be filled and space optimized with proper planning. -You'd also be able to intuit how much of the inventory an item fills from a simple glance, since the volume is of the container is represented visually. - -### Storage - -![](../assets/images/grid-inventory/grid-example.png) - -For the most part, storages exist as literal translations of the current values. -A 28 capacity simply becomes a 7x4 box. -In terms of balance, the numerical values of the different items and storages remains the exact same. -The only difference is having to place the items into the bag and organize them to potentially make room. - -Of course, putting an item in your bag will automatically try and orient it within the grid, not allowing it only if there's no room for it to fit. -This means there's an equal measure of convenience in terms of picking items quickly, only being a hindrance when trying to fit an unwieldy object. - -The hotkeys for quickly taking items in and out of bags will remain identical, simply remembering the order of inserted items and taking them out in the reverse order. - -### A Brief Aside About Slots - -For slot-based storage, like belts, the UI will remain the same, but simply with standardized item sizes. -A 7 slot belt is a container with 7 squares and every item takes up only a single square. This loses out on the benefits of the scaling, but it integrates well enough and conveys the same information as the previous system, so it's kinda moot. \ No newline at end of file diff --git a/src/en/proposals/emogarbage-machine-upgrading-rework.md b/src/en/proposals/emogarbage-machine-upgrading-rework.md deleted file mode 100644 index 79f059be7..000000000 --- a/src/en/proposals/emogarbage-machine-upgrading-rework.md +++ /dev/null @@ -1,90 +0,0 @@ -# Machine Upgrading Rework - -| Designers | Implemented | GitHub Links | -|---|-----------------------|------------------------------------------------------------------------------------------------------------------------------------------------| -| EmoGarbage | :warning: Partially | [#23202](https://github.com/space-wizards/space-station-14/pull/23202), [#22233](https://github.com/space-wizards/space-station-14/pull/22233) | - -## Overview - -Upgrades as a whole are somewhat integral to science as a department. -They basically exist to produce upgraded versions of various items and tools. -However, when it comes to upgrading the machines around the station, there are some issues. - -It's not a stretch to say that machine upgrading is in a state of constant irrelevancy. -Even after a slew of additions and support added for close to 20 different machines, the system failed to become the science subdepartment I had hoped, rather becoming a strange task that would occasionally be done by a select few players. - -The system suffers from a few core issues, which I will highlight briefly. -#### RND Integration -Machine parts predate the new discipline system that RND now functions on. -While in the past, getting higher tier parts was really trivial, now, with the heavy randomization implicit in the system, it's pretty common to go a long time before receiving even one part upgrade. - -It also means that all machine part upgrades, which can affect machines between every department in the game, are relegated to a single discipline. -This not only makes that single discipline (experimental) significantly better than most others, but it also means that other disciplines that could have new upgrades get snubbed by the machine part upgrades. - -#### Discoverability -By the nature of machine parts, it's really difficult to tell when and where they'll have an effect. -Of course, if you have already built the machine, you can physically examine it to determine if it has upgrade potential, but this knowledge isn't readily available at all when you unlock the parts. -Additionally, the line between a machine and not a machine is very much a technical one that players are unlikely to intuit. - -Previously, the methodology for making upgrades discoverable was a tactic of complete coverage: every machine _must_ have an upgrade. -Otherwise, using higher tier parts to upgrade a machine could result in no difference at all, which would be frustrating for players. -This is obviously not ideal however, since some machines really just don't need upgrades. - -A perfect system would make players instantly aware of what machine they can improve the moment they are able to, rather than requiring a ton of trial and error discovery. - -#### Balancing -Machine parts exist as simply numerical values. -Each tier is basically just a number that goes up with little else to distinguish it. -This means that, to implement an upgrade, the simplest and most logical way of doing it is simply increasing some value on a component. - -This is not to say that it is impossible to do anything deeper, but the system as a whole has absolutely no support for that, and adding support for it is really not feasible due to the nature of being to swap parts so trivially. -This makes having additional 'side-grade' features (which can be integral to balance) very difficult to implement. - -Furthermore, having 4 distinct levels of upgrades makes balancing this very difficult, with a lot of things getting absurdly strong in the later tiers. -This is very prominent with a lot of machines that have 'useless' upgrades (the blender blending things instantly comes to mind) but it's also tough to balance a numerical value that is simultaneously worthwhile when in the 2-3 range, but not overpowered in the 3-4. - -## Discrete Upgrades -My proposed solution to this issue is **discrete upgrades**. -This isn't really a formalized system but rather a guideline for how to better make "upgrades" without machine parts and the like. - -Discrete upgrades are, quite plainly, machines that look and have similar names to existing ones while performing their task better. -A discrete upgrade to a microwave might simply be a 'macrowave' that has a glossy black finish and an absurd radiation sound while cooking food twice as fast. - -These machines would simply be unlocked like any other science machine: via unlocking the corresponding technology in the appropriate discipline. -This helps with discoverability, integration, and balancing, since now these upgrades can be in disciplines relevant to them while also being able to have custom unlock prices and tier restrictions. -Furthermore, before you even unlock the tech, you are made aware of what upgrades you are getting via the descriptions of what is unlocked. - -Additionally, these new entities, since they are completely different than their base counterparts, can easily have new components added to them in YAML to allow for new functionality such as emitting radiation, heat, or any other behavior. -This is a powerful tool for adding downsides to balance potentially strong upsides. - -Unlocking **Geiger's Food Prep Science** and being able to build the **macrowave**, which instantly cooks your ramen while dousing you in lethal radiation, is a far more engaging and discoverable system than simply getting **Super Parts** and waddling over to the kitchen to allow the same old microwave to cook your food instantly. -Just simply having different audio/visual stimuli makes the upgrades more unique and recognizable to players. - -## Machine Parts -Tier 1 machine parts, that being the capacitor, matter bin, and manipulator, will most likely remain in the game. -It might even be worthwhile to bring back the laser and scanning module if we so please. - -These parts won't have any unique functionality. -They'll simply remain as a small item used in various constructions for variety, which is always nice. - -The RPED, being a somewhat core concept of machine-part-based upgrading, will likely just be removed. -It doesn't really fit in with the way discrete machines work and the functionality of placing in machine parts into a frame is really not enough to justify it existing. - -Likewise, the technologies for higher tier parts as well as the parts themselves will also be removed. -There's not really a purpose to them and, as we saw before upgrades had implementation, they were frequently a source of confusion as to what their higher tier actually did. - -## Flatpacks and the Flatpacker -A common concern that has been voiced about the removal of machine parts is that it makes these upgrades harder to access for the average player. -This is a pretty fair criticism: building new machines is a fairly intensive process, requiring a variety of tools, parts, and materials. -It's a fair to expect that the average service worker or cargo tech may not have the means to build upgrades in scale. - -The solution to this is a concept already used in the game: **flatpacks**. - -You may be familiar with these from station beacons or the AME shielding: these are small boxes that can be unpacked via a multitool, turning into a full-sized machine. -These are an ideal way to allow non-technical roles to build machines easier, since they require very little skill to use. - -The way that flatpacks will be constructed is through a new science machine, called the **flatpacker**. -The flatpacker simply takes in a machine board and an amount of materials equal to the construction cost (with a small addition in exchange for the convenience) and creates a flatpack for that machine, leaving the board. - -This makes the flatpacker the ideal way to make compact machines that can be set up trivially as well as making a large amount of machines in bulk that can be transferred easily. -This is good for scenarios like bringing over a bunch of hydroponics trays to botany, or making a bunch of recharging stations and setting them up around the station quickly. \ No newline at end of file diff --git a/src/en/proposals/emogarbage-xenoarch-redux.md b/src/en/proposals/emogarbage-xenoarch-redux.md deleted file mode 100644 index a14c08051..000000000 --- a/src/en/proposals/emogarbage-xenoarch-redux.md +++ /dev/null @@ -1,173 +0,0 @@ -# XenoArch Redux [3MOArch] - -| Designers | Implemented | GitHub Links | -|-----------------|---|---| -| Thee EmoGarbage | :x: No | TBD | - -## Overview - -This proposal aims to re-imagine the science subdepartment of XenoArch and Artifacts in general in an effort to give them more depth, and utility. -This will be accomplished by changing node traversal to add more player agency, improving in-game tools for categorizing and understanding artifact structure, and adding additional equipment that makes manipulation more interesting. - -The ultimate goal is to redesign the system so players can better understand how artifacts work and to allow greater utility and mechanics to arise out of artifacts. -XenoArch should feel like unlocking the sprawling secrets of an artifact while additionally gaining points as a secondary reward for the research. - -_This redesign lends partial inspiration to Goon's artlab as well as Noita's customizable wands._ - -## Background -As it is now, artifacts consist of interconnected nodes, each one carrying an effect and a trigger. -The effect is just some crazy behavior that happens in response to the trigger, which is just some kind of generic action taken upon the artifact. - -These nodes form a tree, wherein each individual node's depth within this tree determines the craziness of the its effect and trigger. -An artifact has a single node which is active, which is what determines the current effect and trigger which must be done. - -Moving to another node requires the completion of the current node's trigger and is semi-random in nature. - -While the core concept of XenoArch is interesting and has decent integration with salvage and cooperation for collecting tools for triggers, there are also many situations where players feel as if they lose the ability to meaningfully interact with them. - -I'll outline some of the core issues here: - -### Randomness -Artifact generation is completely random, but so is the activation of effects. -Players cannot meaningfully control which effects they activate and even the limited tools they have like the traversal distorter are extremely esoteric and don't actually provide meaningful control. - -The result of this is that while many effects could potentially be extremely useful and provide players interesting means of interacting with their environments, there's no way to actually harness of control the randomness to produce those interesting outcomes. -At best, you simply re-trigger a beneficial effect several times and reap the rewards in that way. - -### Lack of Complexity -Artifacts are primarily dictated by a single effect with the occasional mix-up of having permanent effects (many of which are underwhelming). -Activation stimuli are similar: the only sliding scale to adjust with how difficult something is to activate is just how hard it is to do that singular trigger. - -Since these triggers are always placed in isolation, unless the effect is having some pronounced impact on the crew's ability to trigger the artifact, triggers mostly devolve into incredibly simple and routine tasks. - -A water trigger should have lots of depth, but it instead is mostly just walking in with a cup of water and splashing it, which is really the most boring way to engage with something like that. - -### Lack of Progression -Artifacts have an innate progression in the form of the scaling of nodes, which is mostly built around increasingly difficult triggers and more dangerous and wacky effects. -This is a good start for a system like this, but the unfortunate reality of it is that the scaling isn't pronounced enough to often feel like a deviation from the early-depth nodes. - -Especially when taken in with randomization of artifacts, you can oftentimes just get subpar generation that flounders in weak effects that don't feel like a progression in research. - -## Artifacts -I'll use the element of a [tech tree](https://en.wikipedia.org/wiki/Technology_tree) as a reference to explain the new generation. - -Each node is essentially an upgrade in a tech tree. -The structure can be described as a typical tech tree structure (a [directed acyclic graph](https://en.wikipedia.org/wiki/Directed_acyclic_graph)) but without the presence of the first element in the graph. - -Just like the current system, all of these nodes have a trigger and an effect associated with them. -However, you do not 'move' to a node like the current system, but you instead permanently unlock it like a tech tree. - -And just like a tech tree, unlocking a node has a cost associated with it. -The 'cost' is the activation of all of the triggers of the nodes in that path--that is, all of the nodes that needed to be unlocked in order for the current node to become available. - -In this situation, the 'active' nodes are the nodes in each path that have the highest tier. -These are the nodes that will produce effects when they are activated. -The remaining nodes are classified as 'latent'--unlocked but not creating any effects when the artifact is activated. - -All remaining nodes are simply locked and have no behavior. - -### Activation and Unlocking Nodes -The activation of an artifact is now something that is distinct from simply triggering a node in the old system. - -Activating an artifact is simply achieved by using it in hand, clicking on something, or other context interactions. -Doing this simply causes all the effects of the active nodes simultaneously. - -By making many effects happen at once, they can combine in novel ways and increase the utility and chaos of the artifact, greatly improving on the current system where lackluster nodes can seem to have 0 effect at all. - -As a balancing factor, each node of the artifact now has a durability. -Activating an artifact degrades the durability of all of the active nodes. -When the node is fully degraded, it no longer produces any effect when activated. - -The durability can be repaired using special equipment (which will be elaborated on further later). - -In exchange easier activation, unlocking nodes is now more complex. -To unlock a node, you must provide the stimulus for that node as well as the the stimuli for every node below it in its path (the path being all of the nodes that had to be unlocked in order to reach the current node). - -Once the first stimulus is provided, an activation period (roughly 10 seconds) begins wherein all the stimuli activations will be recorded. -At the end of that period, if the stimuli recorded _exactly match_ a node's required stimuli, it will be unlocked. - -```admonish info -Note that if you need stimuli A, B, and C but you instead provide A, B, C, and X, the node will not be unlocked. -It must be an exact match and not simply a superset. -``` - -Once unlocked, the node's effect will occur while a small animation and sound effect playing, giving feedback to the players that something has occured. - -## Equipment - -### Analysis Console -The artifact analyzer and analysis console will be improved to no longer have any kind of delay and to show significantly more information - -The console UI will now visually draw all the nodes in the structure, using lines to connect them. -All unlocked nodes will have basic information such as stimuli, effects, depth, research value, durability, and whether or not the node is active. -This info can be accessed by clicking on the node in the UI, which will show a small window. - -Locked nodes that are connected to unlocked nodes will be given a limited information display, showing only the stimuli and the effect. -This allows players to have a limited strategy for the nodes they want to unlock. - -### Handheld Scanner -The handheld node scanner will be used to check information on the current active nodes of the artifact. - -Clicking on an artifact with the handheld scanner will take a "snapshot" of it which can be viewed in a UI. -This gives similar info as the analysis console but is limited to the active nodes of the artifact. - -The scanner now gains a lot of utility as being able to quickly assess the state of an artifact without needing to bring it to science. -Being able to check the durability also helps when actively using the effects on the go. - -The scanner also has the ability to view the node structure of artifact fragments, which can be useful for sifting through them when trying to splice artifacts. - -### Artifexium -Artifexium, which previously activated artifacts, will now serve as a "dummy" stimuli when applied during an activation period. - -For example, if stimuli A, B, and C are needed, but only A and B are provided, spraying artifexium will substitute the non-existent C stimulus and unlock the node. - -If there are multiple nodes which could be unlocked by a the artifexium (say, a node needing stimuli ABC and one needing stimuli ABD), one will simply be unlocked at random. - -### Artifact Fragments -Artifact fragments will no longer simply just be a random chunk that's spit out after an artifact is crushed. -Instead, each distinct path of the artifact's structure will be turned into a fragment which stores the nodes and connections from that path. - -These fragments, instead of being crafted into a new artifact, will be combined with existing artifacts at a **Splicer**. -This provides interesting gameplay where you can combine artifacts to create more tactically useful artifacts with beneficial or dangerous effects. - -The fragments will also scale their artifexium values in relation to the amount research they provide. - -### New Equipment -New equipment (besides the splicer) will focus mostly on manipulating the active nodes of an artifact and interacting with the new mechanics. - -**Artifact Glue** is a reagent made from artifexium and when applied to an artifact will repair the durability of nodes on it. -This provides additional uses for artifexium and ways to extend an artifact's lifespan in the case of beneficial effects that players are using often. - -The **Resequencer** simply takes the existing nodes and shuffles them, creating new connections. -This can completely flip the effects of an artifact and enable new wacky combinations. -It can also help reach particularly hard to get nodes and allow science to fully unlock the artifact. - -The **Arti-nUKer** is a special device that obliterates all active nodes on an artifact. -The severed connections are automatically merged, fixing any holes created in the structure. -This is basically a free re-roll of effects paired with easier to activate high-depth nodes. - -The Resequencer and Arti-nUKer both serve as mid-tier research to provide optional depth for the truly engaged archeologists, without the boring technical complexity of the traversal distorter. - -## Research Generation -The analysis console UI will show the current research value of the artifact as well as the value it needs to exceed to generate more research. - -This will also show the calculation for how the research value is achieved, providing more info and transparency to players. - -The research value for an artifact is calculated similarly to how it is now: -- Unlocked nodes give research based on their effect, stimulus, and depth. -- Artifacts with no locked nodes grant an additional bonus. - -However, there are factors which can damage the research value of an artifact: -- Nodes with completely degraded durability (gluing the artifact to repair it does not incur this penalty) -- Missing nodes, such as those from the effect of the Arti-nUKer. -- Additional nodes, such as from the effects of the Splicer. - -Note that the calculation for the last two points is based on the total number of nodes in the original vs. the current artifact. -If you destroy 2 nodes and then repair it by splicing 2 nodes onto it, you incur 0 penalty. - -To actually gain research from the artifact, you must place it on an analyzer and begin the 'research' task in the analysis console UI. -This begins a 30 second countdown where the artifact must remain on the analyzer, cannot be activated, cannot have any stimuli trigger, and the analyzer must remain powered. - -This provides an interesting window wherein sabotage and other such measures can be taken to steal the artifact or otherwise interrupt science. - -At the end of this countdown, the research is added into the server and a glorious sound effect plays. \ No newline at end of file diff --git a/src/en/proposals/fairlysadpanda-pizzadelivery.md b/src/en/proposals/fairlysadpanda-pizzadelivery.md deleted file mode 100644 index 2939ca94f..000000000 --- a/src/en/proposals/fairlysadpanda-pizzadelivery.md +++ /dev/null @@ -1,84 +0,0 @@ -# Arnold's Pizza Delivery Service - -| Designers | Implemented | GitHub Links | -| -------------- | ----------- | ------------ | -| FairlySadPanda | :x: No | TBD | - -# Arnold's Pizza Needs Delivery Critters - -- Alone? -- Gullible? -- Poor? -- Unaware of our reputation? - -If most/all of these apply to you, _or_ we've successfully kidnapped you from your home, then Arnolds Pizza has a job with your name on it! - -We need delivery critters willing to do one of the most difficult and thankless tasks in known space: delivering pizzas to NanoTrasen employees! - -NanoTrasen knows we make the best pizza in the galaxy*. That's why they have an exclusive contract with us to fulfil their Random Reward Pizza employee satisfaciton scheme. However, NanoTrasen's boutique, black-ops and (frequently) badly-maintained space stations are both challenging to access and deliver to. The fell-off-a-back-of-a-van BlueSpace teleporation devices that we use for such challenging customers are both extremely unethical *and\* have a carry-limit small enough that we can't send a full-sized sapient creature through with our KeepWarm pizza boxes in tow! - -That means there's a _unique_ and _exciting_ opportunity for small, light, _expendable_ critters in our delivery services. Join today, and we promise that we'll let you leave afterward. Just remember to get that receipt! - -\*As do the Syndicate, but we don't tell them that. - -# Overview - -Building on positive player feedback from the April Fools Legally Distinct Space Ferret neutral antagonist, this design document outlines a role that sees the player play as a small, agile critter on a time-limited mission to complete a delivery task to a member of the crew. Success is delivery and retreival of a signed receipt: failure is a tragic death due to the compromising of the nuclear fission heater that the delivery company has strapped to said critter's back. - -## Player Profiles - -- **Pop-In** wants to pop-in to to the round for a few minutes and interact with the crew, but doesn't have time to stick around for the evac shuttle. -- **Cutesy Gamer** wants to play as a cute critter with more than just roleplaying to do. -- **Comedy Gamer** wants to be placed in a tense, absurd situation where their game knowledge can shine to get a challenging goal done. - -## How it works - -- A mid-round ghost role of "Pizza Delivery critter" allows a player to spawn as a cute sapient critter similar to a monkey or kobold at appropriate spawns decided by the map creator, or by mimicing vent critter spawning should this retrofitting have not taken place. -- This critter is given two sets of information: - 1. The identity of its delivery target, including their face, profession and name. - 2. The amount of time they have to complete the delivery before the KeepWarm heater on their back violently explodes. -- The timer is constantly displayed at the bottom of the screen, above the equipment bar. This is a reference, appropriately enough, to _Pizza Tower_. -- The critter is a neutral antagonist with one objective: - - Get a signed reciept from the target before time runs out. -- The critter's target must be alive and not in crit to be chosen. - - If the target is gibbed or becomes SSD for any reason during the delivery attempt, Arnold's Pizza declares the order void and the player is freed from the timer. If this happens, they get to eat the pizza. This is the "neutral" end condition for this antag - the player will not greentext, but they do not get round-removed. -- The critter the player plays at has the following abilities: - - Small creature hitboxes, allowing it to slide underneath most doors. Arnold's Pizza has extensive experience dealing with NT stations and has engineered its delivery critters to be able to actually have a chance of delivering to Urist McScientist who is sitting behind three secure airlocks. - - The following item slots: - - Hat (containing a branded red Arnold's Pizza cap that itself contains a tiny item storage slot, containing a pen) - - Mask - - Belt (containing a branded o2 canister) - - Pocket (with a branded gas mask) - - PDA/ID Card - - One hand slot - - The critter is not especially vulnerable to any damage type, breathes oxygen, but has no capacity at all to wear a spacesuit. They are provided with the means to survive atmos failure, though, preventing frustrating spawns. - in the event the station is spaced, but they will die to barotrauma somewhat quickly. - - The critter has the same amount of health as a monkey. - - The critter nyooms - that is, they have a higher-than-average base and running speed, appropriate for a frantic delivery vehicle. - - The critter only speaks in cute noises unless given cognizine. -- The critter has the ability to print out a receipt for its order. This receipt contains the same information the critter was given regarding the target's identity. -- The receipt has a space for a signature. The only way this signature can be filled in is by the target. It needs to be filled in by using a pen (of any kind) on the receipt. -- The receipt must be handed back to the critter, who then must feed it back into the heater to retrieve the pizza. This counts as a victory and allows the critter to greentext. -- The pizza is one of Arnold's specials. The pizza will have one of the following properties: - - Dank: contains, as you'd expect, dankness, and gives the user hallucinations (cannabis). - - Healthy: like the current Arnold's pizza item, this contains a powerful healing agent (omnizine). - - Stimulants: this pizza is loaded with sugar and makes the target nyoom for a medium period. - - Hot N Spicy: eating the pizza causes the target to set on fire. - - Space Carp Pizza allows the target to avoid pressure damage for a medium period. - - Classic: (PRE WOUND MED) causes the target to detonate. (POST WOUND MED) causes the target's limbs to fly off. - - All of these pizzas have a "paper-oni" pizza variant for moths to eat. -- The pizza types have clear labels on their boxes and unique descriptions, but do not overtly say what they do. The positive-effect pizzas are weighted more likely to appear than the negative ones, with the Classic pizza being a rare chance. -- If the critter fails to deliver the pizza in the time limit, it explodes. This explosion is faked - it gibs the critter but convers no damage to anyone else standing nearby, even on the same tile, to prevent this feature being abused to suicide bomb people. -- It is possible for a member of the crew with bomb disposal knowledge to disable the KeepWarm heater, thus saving the critter's life. If this occurs, the critter cannot greentext. -- If the target is in crit or cuffed, using the printed receipt on them whilst the critter has a pen in their pocket allows the critter to forge the signature, greentexting. -- If the critter has delivered its pizza, it can become eligible to deliver another pizza again later in the round provided the pizza delivery event is rolled again (or if an admin is feeling cruel). -- The critter always has the option of aborting the mission and teleporting back off the station, to avoid feel-bad moments where the objective is undeliverable, the station is in too bad a state to attempt a delivery, etc. - -## Traitor/Nukeops Gameplay - -- The Syndicate also have an exclusive contract with Arnold's Pizza, and they leverage that to do a little trolling and help themselves out. -- A traitor or nukie can order a pizza delivery for themselves or a member of NanoTrasen crew. If they do this, they can specify what exactly the critter is going to deliver. This includes a new, exciting flavour: a bomb with a fuse that looks like it fell out of a Looney Tunes cartoon. The bomb is much too heavy for the critter to hold, and they drop it immediately. -- This bomb detonates a few seconds after the critter has retrieved it from its KeepWarm heater, doing moderate damage to the station in the process. - - This is a reference both to Looney Tunes and the famous "sometimes you just can't get rid of a bomb" sketch from the Adam West Batman TV series. -- The critter is not told they are delivering a bomb or that they're working for the Syndicate, and there's no metagameable way to know if a pizza delivery is legitimate or a trap. -- This mechanic makes sure that there's a theoretical reason that a player may refuse a delivery. diff --git a/src/en/proposals/flareguy-engine-containment.md b/src/en/proposals/flareguy-engine-containment.md deleted file mode 100644 index a02608940..000000000 --- a/src/en/proposals/flareguy-engine-containment.md +++ /dev/null @@ -1,49 +0,0 @@ -# Engine Containment Safeties - -| Designers | Implemented | GitHub Links | -|---|---|---| -| Flareguy, CptJeanLuc |:x: No | TBD | - -## Overview - -This proposal aims to make sabotaging the primary engines (the singularity and tesla) much, *much* harder - possibly to the point of even being able to be theoretically considered an IC issue, provided you set aside the fact that it is one of the most antagonistic things you could possibly do. - -## Background - -[This is mainly based on a brainstorming session held in discord,](https://discord.com/channels/310555209753690112/1008709214006427689/1201664586512871435) with some additional things added as I went along. - -Despite the round-ending damage these engines can cause, the amount of effort needed in comparison to make them break containment is minimal. By cutting a single wire or turning the PA's particle strength above 1, you can instantly force a shuttle call. - -This not only makes it a pretty unbalanced & simplistic interaction for antagonists, but also makes it extremely potent for griefing. It's practically just a "kill station" button with no real safegaurds other then needing engineering access. - -## The Safegaurds in Question - -- **Particle accelerators are now simplified to on/off instead of having strength.** - -In SS13, instead of being a "make the singularity break containment" button, higher particle strengths meant that the singularity would sustain itself at a certain stage. There's not really much value in this, though - you're practically just choosing between "do I want more power or do I want less power," as the added danger of a bigger singularity is incredibly negligible. - -This includes the emag behaviors's removal. If you want to loose the engine, you're going to have to put in real effort. - -- **Wire Power Monitoring Thingamaob** - -A device that mounts to a power network, and monitors if it loses power or is otherwise disconnected from the network. If it does, the object will make a chat message over the engineering channel informing them of the disconnected terminal. - -This also helps curb mass-wirecutting (another very easy-to-abuse mechanic.) Engineering can install these in other places and try to cooperate with security to catch a criminal, or just respond to the alarm and repair it when it happens. - -People looking to mess with wire nets with the monitor installed will need to get creative - either by using explosives to detonate the wire monitor to prevent it from sending a signal, stopping power from being generated entirely as a coverup, or just by stealing the monitor itself and getting the hell out of there before you can be found. - -- **Containment Field Alarms** - -The containment fields in the engine room now come with a pre-installed upgrade that lets them broadcast if they are losing power. This would function similarly to the the supermatter alarm from /tg/station; once the containment field starts losing power it will broadcast a message over the engineering channel, and once it's under a certain threshold (say, 2 minutes left of power out of a total of 5,) it'll start broadcasting over common. This is to give the crew a fighting chance to stop whoever is messing with the singularity, and cannot be prevented unless you get a radio jammer in range of all of the containment fields. - -To reiterate further, this is a feature that not all containment fields will have. Upgrading a regular containment field with a special upgrade chip should be possible. - -- **The Generators Themselves** - -This wasn't discussed in the inital discord conversation, but is probably nessecarry, since you can trivially just move a generator in front of the PA and have it instantly loose without having to deal with any containment proceedures. The only reason this probably isn't utilized more often is because raising the PA strength is easier. - -When being fired at with a particle accelerator, the generators will broadcast a message over engineering communications: - -`A (singularity/tesla) generator is being initalized at (coordinates!)` - -Initializing the generators should take approximately 40 seconds or so, to give people time to respond. diff --git a/src/en/proposals/ike709-genpop-security.md b/src/en/proposals/ike709-genpop-security.md deleted file mode 100644 index 41e19b75b..000000000 --- a/src/en/proposals/ike709-genpop-security.md +++ /dev/null @@ -1,60 +0,0 @@ -# Genpop Security - -| Designers | Implemented | GitHub Links | -|---|---|---| -| ike709 | :x: No | TBD | - -with heavy inspiration from [AndrewMontagne & OracleStation 13](https://github.com/OracleStation/OracleStation/pull/419) - -## Design Goal - -This is a proposal to redesign the flow of throwing criminals in the brig and their subsequent release. Right now prisoners who aren't permabrigged usually have nothing to do during their sentence except hurry up and wait, and security officers usually have no reason to interact with the prisoner until their time is up and they need to be escorted out of security. - -## Current Brig Experience - -The current experience for brigging criminals looks something like this (your mileage may vary by map): - -1. Criminal is arrested by security officer. -2. Criminal is brought to security and strip-searched. -3. Depending on the severity, the criminal is thrown into either an individual brig cell for a few minutes (which is the case for most criminals) or into the permabrig area which (depending on the map) usually allows permabrigged prisoners to interact and/or do things like gardening. -4. When a non-permabrigged prisoner's time is up, the cell door opens and they can collect their belongings, but they are still trapped in the security department due to airlock access until someone lets them out. - -## Turnstiles - -Turnstiles are a key feature in the new brig experience that I'm about to propose. Turnstiles are effectively one-way airlocks, allowing travel only in one direction while still allowing mappers or engineers to set normal airlock access requirements to move through them. Here's what they look like on Oracle, including the mapper overlay to show which direction players can move. - -![turnstile](https://i.imgur.com/QStUhoA.png) - -In this example a player with the relevant access requirements can only move from the north side to the south side of the turnstile. Even ignoring the rest of this design document, turnstiles would still be useful for things such as putting an exit in medbay or being able to leave the disposals room in maintenance. - -## Proposed Brig Experience - Genpop - -I propose that we completely nuke individual brig cells. All prisoners will now be thrown into a large secure area similar to the permabrig (called "genpop") where they can intermingle, kill eachother, or perform various other mapped-in activities like play arcade games or do basic botany. - -Here's an example from OracleStation. Note the turnstiles, the prisoner processing room in the lower part, and the actual genpop prisoner area in the upper part (ignore the armory in the bottom left): - -![genpop](https://user-images.githubusercontent.com/202160/35178888-91bb7eb6-fd87-11e7-9040-15a6ef93602c.png) - -I highly recommend taking a look at the [OracleStation pull request](https://github.com/OracleStation/OracleStation/pull/419) as it has gifs for most of the things I'm about to describe with words. - -This is what the new experience for brigging criminals would look like: - -1. Criminal is arrested by security officer. -2. Criminal is brought to security and strip-searched. -3. Criminal is given a prisoner ID with their name & the length of their sentence. This ID's access is required to pass through the "entrance" turnstile into genpop, to ensure the security officer processed them correctly. -4. Criminal is thrown into genpop with all the other prisoners via the "entrance" turnstile, regardless of their crime severity. Individual brig cells and a separate permabrig no longer exist. -5. The criminal's turnstile access is tied to their prisoner ID. Once their sentence has elapsed, they will now have access on their prisoner ID to pass through the "exit" turnstile from genpop back into the processing area. This means they can leave genpop with no intervention from security officers. -6. The criminal can retrieve their possessions from the locker in processing using their prisoner ID. -7. Using turnstiles, the criminal is able to exit genpop, processing, and the main security department entrance without needing a security officer to open doors for them. - -## Gameplay Implications - -Here's a non-exhaustive list of impacts these changes can have on gameplay, in no particular order: - -- Players no longer need help opening airlocks to exit security when their sentence elapses -- Players now have things to do while they are brigged, whether it's ~~killing~~ interacting with other prisoners or the items/machines mapped in genpop -- Players could escape early by stealing or trading eachother's prisoner IDs -- Wardens are now incentivized to actually keep an eye on the brig and its prisoners to prevent fights/prison breaks/shenanigans -- The brig effectively no longer has a prisoner capacity limit, as individual brig cells are no longer needed -- Security officers can pass through genpop turnstiles at will with their ID access, allowing them to enter/exit genpop without prisoners tailing them to escape - diff --git a/src/en/proposals/ike709-robusthub.md b/src/en/proposals/ike709-robusthub.md deleted file mode 100644 index cc585c027..000000000 --- a/src/en/proposals/ike709-robusthub.md +++ /dev/null @@ -1,110 +0,0 @@ -# RobustHub™ - -| Designers | Implemented | GitHub Links | -|---|---|---| -| ike709 | :x: No | WYCI | - -## Overview - -Redesigning the launcher UI/UX and server hub concept to better facilitate creating and playing games developed in Robust Toolbox that *aren't* Space Station 14. - -#### This proposal is a high-level conceptual overview. Please do not bikeshed specific details such as every potential field for RobustHub metadata. Once this is conceptually approved, the bikeshedding can commence in subsequent design documents fleshing out each aspect of the design. - -Even the nomenclature used (e.g. "Game Hub") is subject to change but preferably won't be bikeshedded prior to overall proposal approval. - -## Games & Game Hubs - -### Defining "Game" -In this context a "game" is referring to a single *project* such as Space Station 14, OpenDream, or RobustSand. Forks of SS14 are considered separate codebases, but still part of the SS14 "game". - -### Server Hubs -The current concept of a hub is essentially just a list of servers. Under this new system these would effectively be the same, except now each server hub will be associated with one or more "games". These will be referred to explicitly as "Server Hubs" to distinguish them from "Game Hubs". - -Each Server Hub will have a whitelist of game(s) that can be advertised on it. For example, the official WizDen Server Hub could support both SS14 and RobustPong servers. When a server attempts to advertise on a Server Hub, it must declare the game that it is running and it must be one of the Server Hub's whitelisted games to advertise successfully. Server Hub operators are responsible for moderating the servers that are permitted to advertise on their hub, and ensuring that information such as the advertised game is accurate. - -When a player adds an additional Server Hub in the launcher, the additional servers will be associated with the correct games using the game identifier being advertised by the server. More on this later in the launcher section. A potential quality-of-life enhancement would be to allow players to toggle individual games on a per-Hub basis (e.g. if I were running my own alternative Server Hub for OpenDream servers dubbed "IkeHub", which advertises both SS13 and Eternia servers, a player may wish to disable polling the hub for Eternia servers if they only play SS13). - -### Game Hubs -A higher-level hub dubbed "Game Hub" will fill a similar role to server hubs, but instead of providing a list of servers they will provide a list of *games* and their associated metadata that the launcher needs in order to play them and/or browse their Server Hub. **Note:** The launcher is only intended to support a singular "Game Hub", and the concept exists to provide examples of how Robust Toolbox can be utilized separately from Space Wizards Federation infrastructure, such as games developed independently of SS14 or communities who wish to "hard fork" their own infrastructure. - -The list of games available on a Game Hub is under the purview of the hub's operators. The official Robust Toolbox Game Hub (RobustHub) will be managed by the Space Wizards Federation. The system now looks something like this ([direct link](https://i.imgur.com/lyRfy8t.png)): - - - -### RobustHub Repository -A new Space Wizards repo will be created called RobustHub (or similar). This repository will provide the "official" Game Hub that will easily be accessible with any official build of the launcher. - -Each game will have a directory in the repository with a variety of metadata and branding files (e.g. the game's default logo). I expect this will be fleshed out and bikeshedded more thoroughly in a separate design document, but metadata would consist of information such as: -- Game name (obviously) -- Creator/Developer information -- Official Discord/GitHub/Website/etc. -- URL to pull News from (like the existing News tab in the SS14 launcher currently) -- If the game is singleplayer, multiplayer, or both. - - Multiplayer games will include the default/official Server Hub URL for the game - - Multiplayer games can decide whether or not to allow adding alternate unofficial hubs in the launcher (obviously SS14 would allow them, but Johnny GameDeveloper might want full control of the servers for his game) - - Exclusively-singleplayer games will point to the content bundle download URL - - (Side note: the existing SS14 launcher still can't launch singleplayer games you've already downloaded like RobustSand) - -Adding a game to RobustHub should be as straightforward as creating a pull request and meeting whatever criteria is deemed sufficient by the RT project managers to be considered a separate game. - -The process of who will be permitted to update a game's hub entry and how will be fleshed out in a future design document dedicated to RobustHub pending this proposal's approval. - -## Launcher Changes - - I couldn't find a way to articulate these launcher changes that doesn't make it sound a little crazy at first, so I advise reading all of this section before judging it. - -### Robust Launcher -The SS14 launcher as it exists currently will no longer be maintained as a project. Instead the launcher will be stripped of all SS14 branding in favor of Robust Toolbox branding. The "Servers" tab will be nuked in favor of an interface similar to the BYOND pager, except with RobustHub games instead ([direct link](https://i.imgur.com/DSXdzyP.png)): - - - -I don't expect it to look exactly the same; for example, we may have a separate page for singleplayer games. But players will be able to download, play, or browse the server list for any RobustHub game from Robust Launcher. - -#### Adding Alternate Server Hubs -As previously mentioned, the launcher will support allowing players to add additional Server Hubs. This should be as straightforward as adding a URL to a list in the launcher settings, with the launcher handling it from there. The launcher will check to make sure a game's RobustHub metadata permits alternate hubs before polling an alternate Server Hub for that particular game. When a player goes to a particular game's server list, the launcher will poll the Server Hub only for servers with that game's identifier. On the game's server list, each server entry will include a field displaying the Server Hub it was pulled from, and the list should support optionally filtering by Server Hub. - -Adding alternate Server Hubs should warn the player about potential moderation issues compared to using official Server Hubs. We may wish to somehow present each hub's rules to the player when the hub is being added in the launcher. - -#### Optional: Steam Release -I'm of the opinion that Robust Toolbox should have its own dedicated Steam page which ships Robust Launcher directly, to reduce confusion when people want to play other RT projects like OpenDream via Steam. I'm not saying we should do this *immediately*, but I think it's worth serious consideration if any not-SS14-adjacent projects are created in Robust Toolbox. - -We should also check Steam's policy for this sort of thing, as the SS14 launcher at this point would just be Robust Launcher in Game-specific Mode for SS14 (see below). - -### Game-specific Mode -Obviously we can't just switch out the SS14 launcher on Steam for Robust Launcher, which is where Game-specific Mode (better name pending) comes in. Somewhere in the launcher build pipeline we will need the option to pass in a RobustHub game identifier which tells the launcher to launch in Game-specific Mode for that game. - -When operating in this mode, the RobustHub page is not accessible by default, instead the launcher opens directly into the page for the specified game. This would look practically identical to the current SS14 Launcher experience. - -However, buried deep in the launcher settings would be a setting for "Other Games Browser" or similar, which gives the whole explanation that the launcher is able to play other games made in the same game engine. Enabling this setting would still keep the game in Game-specific Mode and open straight into SS14 by default, but now the "RobustHub" page (which would normally be the default page outside of Game Mode) will be unlocked as an additional tab that they can easily navigate to. The purpose of this is so users whom are aware of this functionality don't need to have a duplicate Robust Launcher installation on their PC. - -Let's expand upon the hub diagram to incorporate launcher examples ([direct link](https://i.imgur.com/Kz5KM6Y.png)): - - - -#### Optional: Don't Hide Other Games -PJB seems amenable to the idea of _not_ hiding the Other Games list by default when operating in Game-specific Mode. - -### Example UX -Here's the process of joining an OpenDream server depending on whether you're using Robust Launcher or the redesigned SS14 Launcher (which is just Robust Launcher in Game-specific Mode for SS14). This assumes we do decide to hide other games by default in Game-specific Mode. - -#### Robust Launcher -1. Start Robust Launcher -2. Find and select OpenDream from the list of games -3. Pick a server and join it - -#### SS14 Launcher -1. Start SS14 Launcher -2. Go to somewhere deep in the launcher settings -3. Enable the "Other Games Browser" setting (only needs to be done once) -4. Exit the settings menu -5. SS14's main page now has a "RobustHub" or "Other Games" tab in the corner that players can select -6. Find and select OpenDream from the list of games -7. Pick a server and join it - -Quality-of-life enhancements like being able to pin/favorite certain games is subject to further design and bikeshedding. - -### Optional: RobustHub Game Jam - -Once RobustHub is fully implemented, we should advertise and then run a game jam (1-2 weeks) to develop new games (singleplayer or multiplayer) for RobustHub, unrelated to SS14. In addition to adding some variety to the games list, this will give us a chance to dogfood the system and also identify pain points in creating new Robust Toolbox projects. - -Depending on the level of interest, we could potentially offer prizes for the best submissions like a fancy Discord role and/or a $20 Steam gift card. diff --git a/src/en/proposals/ike709-statpanels.md b/src/en/proposals/ike709-statpanels.md deleted file mode 100644 index 4b2692fc6..000000000 --- a/src/en/proposals/ike709-statpanels.md +++ /dev/null @@ -1,74 +0,0 @@ -# Diegetic Statpanels (aka PDA Statpanels) - -| Designers | Implemented | GitHub Links | -|---|---|---| -| ike709 | :x: No | WYCI | -## Concept - -Taking all of the benefits of SS13 statpanels without ruining immersion nor reviving verb panels. -### SS13 Statpanels - -Statpanels in SS13 generally serve one of three functions: - -1. The Status tab informs players with a round timer, station clock, escape shuttle status, etc. -2. Debug-related info tabs like the Master Controller tab. -3. Verb tabs like IC or OOC which are just lists of verbs the player can run. - -The second item is unrelated to the average player. The third item is, frankly, terrible UX. - -This design document is focused on the first item: the Status tab. I believe that certain basic information should be conveyed to the player *almost* always. This includes most of the information conveyed by the SS13 Status statpanel as previously mentioned: round timer, current map, station time, etc. - -The problem with the Status tab in SS13 is that, frankly, it's ugly and it ruins immersion. It's particularly bad on codebases that just use the default BYOND statpanels instead of replacing them with TGUI. So how can SS14 do it better? -## SS14 Statpanels - -It's simple. SS14 already has a mechanic that conveys all of this information: PDAs. All we need to do is open the PDA UI in the statpanel location when a PDA is equipped in the PDA slot. - -Now in no particular order I'm going to address various considerations (many optional) involving mechanics, features, balancing, etc. all subject to player and maintainer input. - -### What if I lose my PDA? - -This should hide the UI, naturally. But replacing a PDA should be made trivial. PDA vendors should be added to areas such as Arrivals and Dorms that can supply people with simple, no-program unpainted PDAs if theirs is ever lost or stolen. - -### What if I don't want to use the PDA programs in the HUD's corner? - -Moving the PDA from the PDA slot to in-hand should move the UI from the corner to the center of the screen, and then put it back in the corner when the PDA is put back in the PDA slot. - -### What if I don't want to see this UI at all? - -Like in SS13, we could simply allow people to resize chat and shrink the statpanel by dragging the splitter upwards. - -### Isn't constant access to Programs a bit overpowered? - -I personally think this is a non-issue since you can't interact with the game window and PDA window simultaneously, but I can see how others would disagree so I came up with some potential solutions anyways. These are all optional and in no particular order: - -- **Lockscreen** - - The PDA is "locked" by default, and the lockscreen is simply the Home tab. To access Programs, the player must do something such as: - - Wait for arbitrary short doafter to represent typing in a passcode or biometric scanning - - Actually needing to know and enter a 4-character PIN code each time it locks (it locks after brief periods of inactivity) -- **Require In-Hand** - - Require having the PDA in the player's active hand to use programs. This is my least favorite option. -- **Require Empty Hand** - - Require the player's active hand to be empty if they want to interact with programs. Just give them a popup text if they try to click programs with something in their hand. - -### Optional: Admin Tabs/Programs - -Add support for tabs and/or programs that are tied to the player's mind (or something) rather than the actual PDA. This would make it easy to support admin tools like a server performance monitor, a tab listing the gamemode and all antags, etc. - -### Optional: Map Tab - -My biggest complaint with the maps that aren't ripped straight from SS13 is that I have no idea where I'm going. Map terminals are great when I come across them, but I think having the ability to constantly have a map of the station would be a huge quality-of-life improvement for new players. Nothing stops them from just opening up a screenshot of the map in their browser anyways. - -### Optional: Diegetic Game Settings - -This is one of the spicier ideas, but out-of-character menus like the guidebook or the game's audio settings could be moved to a PDA tab. A big problem is that we'd need an elegant way to make sure the player can still access these if they lose their PDA. - -## UI Mockup - -Just remove the close button from the top right, maybe tweak the border a bit. It'd also need to stay there all the time when a PDA is equipped. Here's a pic ([direct link](https://i.imgur.com/ppnXXaf.png)) - - - -## tl;dr -([Direct image link](https://i.imgur.com/ByUHHZu.png)) - - diff --git a/src/en/proposals/julian-vasilis-pda-messaging.md b/src/en/proposals/julian-vasilis-pda-messaging.md deleted file mode 100644 index a0fc4d34d..000000000 --- a/src/en/proposals/julian-vasilis-pda-messaging.md +++ /dev/null @@ -1,111 +0,0 @@ -## PDA Messaging - -| Designers | Implemented | GitHub Links | -|---|---|---| -| Julian & VasilisThePikachu | :x: No | TBD | - -*(Taken by [Julian doc](https://hackmd.io/iu2yK9bcQb-veuCOLl-FYw?both#Optional-Channels-and-Department-based-Channels) in hackmd and modified a lil. Mostly replacing "email" to "message", "Email address" to "user/user id" and adding some of my own twists. Julian was fine with this if i understood correctly (i was in vc with em))* - -*(This is mostly taken from how PDA messages work in ss13)* -Allows sending messages to others using PDAs - -### What this adds and why -Simple, Messaging via the PDA! -Messaging someone via the PDA should be made when you need to get the attention of a special someone. Example as HoS you want to ask detective to come over to investigate an item. It's easier to get their attention cause of their PDA vibrating then hoping they are monitoring their channel. Another usage is the heads planning Captain a suprise birthday party. Something like that would require all heads getting together in one place. - -This is **not** a replacement to the radio channel. Theres no "common" channel, it would be easier to spoof being someone (just need their id), past messages on that same id can easily be exposed and its far more cumbersome to message someone over PDA then just using the radio. - -### Message storage -Messages are stored on a server most likely will be stored in telecoms. There can be one server per station, others on the same station won't be used unless the first one loses power or gets destroyed. - -*Optional* The active server synchronises itself with all of the inactive servers on the same station (This happens inside the system directly, no device networking here). - -### One active / Multiple inactive server model - -(This talks about some refactor stuff and Julian told me they forgot to paste the link, im keeping it to be safe in case its actually useful.) - -The one active / multiple inactive server model uses the system that will get refactored into its own system from the crew monitoring server [link text]() - -The messaging client system will use the `GetActiveServer` method of the message server system to retrieve the active server if the client doesn't have a server set yet or that server timed out. *This is also from the system that gets refactored out.* - -### Sending and receiving messages - -When sending a message to someone via the program the PDA sends the message together with an 'user id' to the server and the server will send the message to the target device. Of course there will be a character limit (say... 100 characters?) - -When a PDA recieves a message it plays the PDAs ringtone and vibrates, showing the sent message on the chat. This message can also be viewed on the PDA via a program. - -Notifications can be disabled if desired. - -This user id could be generated into the ID card so that if you get a new PDA your messages are kept as long as you are using the same ID card. Late joiners will get assigned a uid when they arrive on the station. Potencially HoP or RD can move your UID to the a new ID card with the ID comnputer rendering the old ID card useless. This can also prevent powergaming by someone changing their UID to see others messages. - -This UID will receive messages for as long as it is in the station and in a PDA. - -If its not in station the messages can either fail to send or be added in a queue to be sent when it reenters the station. - -Since the UID is stored on the ID. That means that if you manage to get your hands on someones ID you can chat as them and potencially (if added) read their messages. - -### Users list - -When opening the PDA messaging app, you will be able to start a chat session with everyone connected to the server (aka everyone with a PDA) - -They will be listed by name and job title like this "Vapor-Tail (Captain)" - -*Optional* Add the ability for people to not be allowed to initiate a conversation with an option. This can be useful for high command staff like captain from getting message spammed by clown and others at the start of the shift. - -### Optional: Detomatix PDA Cartridge - -(find the original item in the tg wiki here: https://tgstation13.org/wiki/Syndicate_Items) - -The detomatrix is... a zip bomb in easy to say terms. Allowing you to send a spoofed message that when opened by the target fast enough bricking the PDA and its ID (instead of exploding... even though thats funnier maintainers please allow this) - -It will have a chance to fail and have an even lower chance of working on "high profile" PDA's like the Captains. - -It could be used as a way to get people to turn off their messanger function in fear to not being up next if someone screams in radio about it and could be useful. - -### Optional: Multiple network support - -The server is able send on the wireless and the wired network because it saves what network the registered devices are on along with the user id and the network address. - -This requires devices to be able to register themselves with two device net ids at once (which should only be done if it is really needed). - -### Optional: Channels and Department based Channels -Channels are special groups that relay the messages sent to them to users who are subscribed to that channel. - -Channels can be created and they can be deleted by the channel creator. - -When registering to a server the client also sends the job of the inserted ID so the server can put them into special department channels. - -Department channels can't be joined, left or deleted. - -### Optional: RDs messager admin management console -The research director and potencially Captain get a console which connects to the message server via device net that can be used to view and manage all messages and groups. -It uses device net with an `AccessComponent` on the message server so the management functions can be hijacked by traitors that got their hands on an ID card with the right access. (This requires [device net access restrictions](https://hackmd.io/gPjP95_zRUiT-bX4hKxE6w) to be implemented. - -### Optional: pAI as a chat assistant. -This will add new gameplay for the pAI ghost role. Allowing the pAI to chat as their master on their behalf. Could have a little pAI icon in the chatbox to show it was sent by the pAI and not the actual player. pAI's for a while have been kinda boring and may deserve their own design doc of ideas but this is one of my ideas that come to mind. - - -### Concerns -When initially asked about this I was met with some concerns. This section is to address them - -Discord discussion start: https://discord.com/channels/310555209753690112/310555209753690112/1160244698112327830 - -##### Why PDA messaging over plain radio? Would this upset radio balance and reduce coms over radio? -First of all why: -If you play the game you can quickly realise how getting someone's attention god forbid multiple, can be... not an easy task to say the least. You either are lucky and the person you want is just so happening to be monitoring the chatbox or they are busy and not paying attention. In the end missing your message until you resend it or try to look with them. This is just not fun and is just annoying. PDA messaging can solve this. - -As to if it will upset radio balance: Highly unlikely it will be. Mostly cause: -1. PDA messaging wont let you get the attention of multiple people at once (common). PDA messaging can reach one person at the time (unless we get department groups but even then). You will have to jump through a lot of hoops if you JUST wanna use messaging. Radio is easier and faster to talk into and gets to multiple people at once. -2. Sending a PDA message is more of a chore then just using the radio channel, PDA messaging will at least need a minimum of 6 steps to open the PDA, go to the app section, start the app, find the person, write the message and send. And if you keep the chatbox on it would just take up a good chunk of your screen. Or you could just do ":c Captain hamlet ate uranium" -3. Messages are stored and logged. Someone steals caps PDA? Well now all of their messages are up on display. With radio unless they had command channel already they would never learn of any past messages. If two syndies decide to use PDA messaging rd can just grab their chatlogs. Same with syndies using it to communite with others. -4. PDA messaging has a pretty small character limit, if you wanna say something long radio is the place. - -May be the wrong section but admins can also use this to act as "Central Command" so instead of having to subtile message someone they can just send a message to their PDA. - -##### It reduces everyone else's situational awareness since people can't see all radio messages anymore. -I highly disagree, I doupt it will reduce situational awareness more then it already is. I have already went over how someone monitoring the radio channel for messages directed to them is already a chore. PDA messaging names can easily be changed by using someone elses ID therefore its a good idea to not go to maints like they told you to and instead show the message to security. - -##### Why not use fax? -Is this really a question? First of all not everyone has a fax, second you have to be close to hear it go off printing. And unless you check your fax periodicly for new faxes messages can be missed. And even if you do check it its probably boykisser ASCII spammed 10 times. Also why are we using *faxes* in 2563 or whatever year SS14 takes year in. - -These were all the conserns I could find from discord. diff --git a/src/en/proposals/mirrorcult-anomaly-cores.md b/src/en/proposals/mirrorcult-anomaly-cores.md deleted file mode 100644 index 86e115be6..000000000 --- a/src/en/proposals/mirrorcult-anomaly-cores.md +++ /dev/null @@ -1,49 +0,0 @@ -# Anomaly Cores and the G.O.R.I.L.L.A Gauntlets - -| Designers | Implemented | GitHub Links | -|---|---|---| -| mirrorcult | :white_check_mark: Yes | https://github.com/space-wizards/space-station-14/pull/21306 https://github.com/space-wizards/space-station-14/pull/23012 | - -The intention of this proposal is not to expand the anomaly gameplay system through breadth (i.e. more stuff) but to add new dimensions of gameplay and new incentives entirely. This will be done through two main additions: **inert & decaying anomaly cores**, and the **G.O.R.I.L.L.A Gauntlets**. - -## Anomaly Cores - - - -**Anomaly cores** are generated when an anomaly dissipates in some way. An *inert* core is spawned when an anomaly is fully contained and fizzles out, and a *decaying* core is spawned when an anomaly goes supercritical. - -Inert cores are functionally useless on their own, sell for a small amount of money, and glow faintly. They become useful in conjunction with the G.O.R.I.L.L.A, which will be elaborated on later. They can also be made into anomaly core pie! - -**Decaying cores** are the interesting ones. When an anomaly goes supercritical, it will spawn a decaying anomaly core of the same type as the anomaly. These cores can be sold for a large sum of money, converted into a fairly high amount of research points, or *used by anyone for a one-time anomaly-specific benefit* (this use will not be included in the initial PR for scope reasons). - -Over time, decaying anomaly cores will slowly *lose their value* and eventually convert into an inert anomaly core. If it isn't sold, exchanged, or used fast, then the whole endeavor could prove pointless. - -### Intended Gameplay - -The point of decaying anomaly cores being generated is twofold: First, it provides a potential benefit for anomalies which accidentally go supercritical or are untended to. Second, it gives anomalists the interesting choice to **intentionally make an anomaly go supercritical** for huge rewards, if they feel that they're capable of handling the aftermath. - -Decaying anomaly cores being time-limited is very important. This introduces more gameplay by forcing people to take some risks to extract as much value as possible. For instance, you might just run into a supercritted gravitational anomaly to take its core even if you risk harming yourself. It also forces the decision of *how* to use the anomaly core quickly, which can lead to some fun social scenarios. - -## The G.O.R.I.L.L.A Gauntlets - -```admonish info -or, Gauntlets Orchestrating Relocation of Interloping and Ludicrously Livid Anomalies -``` - - - -The G.O.R.I.L.L.A Gauntlets are an item obtainable through Tier 2 experimental research (subject to change). It functions as a set of wieldable power fists that can deal strong brute damage. However, they're not very strong on their own. To take full effect, they need to be **with an anomaly core**. - -When the gauntlets are loaded with either type of anomaly core, they gain the ability to force throw anything they hit backwards, until it hits a wall. **This includes anomalies, and thus the gauntlets function as a method of moving anomalies.** Inert cores only give you five charges to work with (subject to change), while decaying cores will work until they run out, and deal significantly more damage. - -Anomalies which are hit with the gauntlets will take some minor stability damage. Anomalies in the process of going supercritical can also be hit with the gauntlets. Because of the nature of how the force throw works and the limited charges of an inert core, anomalists will have to first consider the most efficient path and set of pushes to get the anomaly in a more useful location. - -### Intended Gameplay - -The G.O.R.I.L.L.A gauntlets open up many more choices for anomalists. Before, if an anomaly spawned in a particularly unfavorable spot (such as medbay), science was heavily pressured to contain and decay it entirely rather than trying to exploit it, and for good reason. People have often asked for a way to move anomalies, but of course, anomalies' locations being random is a huge part of what makes them interesting to contain. - -With the G.O.R.I.L.L.A gauntlets, anomalists have a way to move unwieldy anomalies in an interesting way that generates rather than removes gameplay: -- The gauntlets require an inert core and research, so science must already have invested some time into anomalies already -- The inert cores have finite charges, so science cannot always rely on them -- The movement of the anomaly is not as simple as 'point A to point B', and because of the limited charges, scientists must consider the location of the anomaly and where they'll be able to move it within 5 pushes, kind of like a box-pushing game or a Pokemon ice tile puzzle, which is a fun mini-challenge on its own. -- Expert anomalists will be able to modify the environment to get anomalies in even more favorable locations and they will likely have to coordinate with others to move it through doors, hallways, into smaller rooms, etc, introducing a new degree skill expression, on top of knowing when to make the decision to try and move one rather than contain or harness it. diff --git a/src/en/proposals/mirrorcult-cleanup-crew-gamemode.md b/src/en/proposals/mirrorcult-cleanup-crew-gamemode.md deleted file mode 100644 index 97261fcba..000000000 --- a/src/en/proposals/mirrorcult-cleanup-crew-gamemode.md +++ /dev/null @@ -1,53 +0,0 @@ -# Cleanup Crew - -| Designers | Implemented | GitHub Links | -|---|---|---| -| mirrorcult | :x: No | TBD | - -## Overview - -Cleanup Crew is a lowpop (0-20 players) gamemode built around the concept of repairing destroyed stations from previous rounds. The goal is to provide a fun, relatively chill experience that differs from the base game but still interacts with all of its systems (especially construction, power, atmos, etc), acting as an educational experience, while also being very atmospheric. - -The NanoTrasen Emergency Cleanup Crew, one spacemonth after the sudden abandonment of their finest new station, will start the game on a medium-large ERT shuttle near the disheveled station. The shuttle is stocked with everything you could need--lots of materials & RCDs, medical supplies, atmospheric supplies, generators, janitorial equipment, etc. - -Each cleanup crew member has a designated role (atmospherics, power, repair, janitorial, security, etc) but they can of course branch into doing anything as needed with their supplies. The goal of the cleanup crew is to ensure: - -- the station's tilemap is as close to the original station's tilemap as possible -- as many of the original tiles have viable air as possible -- the new station has as many of the same machines as the old station, and that as many of them are powered as possible -- as few spills, blood & dirt remain as possible -- as many "intruders" are eliminated as possible - -The cleanup crew is given a time limit of 1-3 hours (depending on how large the map is & its chaos value), after which they must FTL away inconspicuously to evade detection by the Syndicate. - -## Intruders - -As mentioned before, the map is mostly kept unchanged from the saved version, but it *has* been a whole spacemonth! - -It's possible that some hostile fauna (and some decorative flora for that rundown feel) have moved in. These can include: - -- Xenos, which will have spawned resin walls and eggs randomly -- Spiders, which will have spun lots of webs and nests -- Carp & sharks, which will be scattered around the station with a dragon or two sprinkled around -- Orecrabs, with corresponding rock deposits that must be cleared out -- Nothing! No one got there before you did. A chill experience - -Only one class of intruders is selected for the whole station, and they (along with any infrastructure they bring with them) are procedurally dotted around the station in clusters or in singular surprise instances. - -The cleanup crew comes loaded with plenty of medical supplies and !!FUN!! pulse & powerful ballistic weaponry, so these aren't generally much of a real threat, but they do make for a more dynamic experience. - -## Scoring - -The cleanup crew, at the end of the round, is scored based on the factors mentioned above. The score is compared to how the original station would have scored, and some flavor text is displayed congratulating or disparaging the cleanup crew on their hard work. - -## Map Saving Mechanic - -To elaborate on how the maps are selected: - -After any round finishes on some server, a quick heuristic "chaos value" (power, atmos, tiles missing) is calculated to evaluate how "destroyed" a station is. If the chaos value is high enough (but below a certain critical threshold of too much destruction), the map is saved, with some annoying entities removed (all mobs are replaced with skeletons, for example), and then stored as a blob in the DB to be used later. - -Up to ~20 (maybe less, maybe more) stations can be saved at a time, and when a cleanup crew gamemode spawns, one is removed from the list and loaded in. If a map cannot be loaded, another is tried, until there are none left in the list. If there are no viable maps for cleanup, the gamemode is unavailable for play. - -After the map is loaded, a short procedural pass spawning random mess decals and flora such as trees and bushes or vines is done. Afterwards, if an intruder (see above) was selected, they are spawned in as well. - -Some scenarios, like a nuke going off after nukies, will mark the map as unable to be saved for cleanup crew, since it's obviously a bit too much of an outlier. \ No newline at end of file diff --git a/src/en/proposals/mirrorcult-rogue-drones.md b/src/en/proposals/mirrorcult-rogue-drones.md deleted file mode 100644 index 4e74cdd99..000000000 --- a/src/en/proposals/mirrorcult-rogue-drones.md +++ /dev/null @@ -1,68 +0,0 @@ -# Rogue Drones - -| Designers | Implemented | GitHub Links | -|---|---|---| -| mirrorcult | :x: No | TBD | - - - -## Background - -rogue drones is kind of a placeholder name its not that good we can come up with something better or just call them swarmers who caaaaares - ---- - -On some SS13 servers, an antagonist called the **swarmer** exists (or existed, as it was disabled in some places). It's goal was to destroy machines & structure around the station and convert it into material to create more swarmers with. Essentially grey goo. They had extremely limited combat capabilities (mostly traps & stuns) and are generally hated for being extremely annoying, disruptive, and overly centralizing. - -**Drones** also exist on some SS13 servers, and even on SS14 for a time (disabled for being too much of an admin burden). They're not antagonists, and are intended to just be a little ghostrole that tries to repair the station and keep itself out of the way of the crew. Because of this, they end up being weirdly restrictive and almost like a separate part of the round entirely since they're forced to not interact with anyone. - -This concept seeks to unify the two and solve the issues of both while creating an interesting grey-morality antagonist at the same time. - -## Overview - -**Rogue drones** are a mid-round ghostrole antagonist that can spawn in maintenance. - -They're space-capable silicons and quite fast, along with the ability to sneak under airlocks like mice, but have zero combat prowess and little bulk. They also can't interact with machines or speak, but can use the binary channel of the station to communicate with eachother. They come with a set of unremoveable tools that are quite powerful, as well as slots for metal and glass they can use to build structures. Using a decent bit of steel and wires, rogue drones can create another shell that can be inhabited and multiply, though they'll usually prefer to use that material to expand. - -Their goal is well-defined and is simply to **increase the number of tiles on the station with habitable air by any means necessary**. This implies a couple things. Rogue drones: -- are incentivized to deconstruct walls and doors both to get materials and to create new openings for air, but they don't particularly care about touching structures or anything else useful. They're also willing to steal metal and glass directly if they find it lying around. -- goals sometimes align with the crew and are thus somewhat often **actually useful to the station**, as they're quite willing to fix hull breaches and tackle atmospheric issues. -- will often try to build useless rooms or expansions to the station, coordinating amongst themselves to store materials and collaborate, while negotiating with other silicons (who are also on their channel!) - -The intended effects here are quite obvious but I will list them regardless: -- The crew, and individual crewmembers, have the interesting choice to think about ignoring or temporarily allowing the rogue drones to roam freely because of their aligned goals. -- Rogue drones serve the function that previous maintenance drones did--allowing players to get back into the round and learn or have fun with construction mechanics--while sidestepping the admin burden, since they're antagonists with limited capabilities. -- Rogue drones have a lot of the same gameplay as swarmers did--multiply, try to deconstruct and build new things, run from the crew--while not being overly annoying since they have negative incentives with regards to spacing areas or deconstructing machines, as well as not having any combat capability. -- With a clearly defined numerical goal, players feel motivated to have fun and actually perform their task and see the fruits of their efforts rather than just fuck off and do nothing -- A non-combat-focussed antagonist fills out the midrounds with some more actual variety in how players interact with them and makes everything more interesting - -## Other Mechanics - -At the end of the round (and periodically in the objectives screen), the game will calculate how many tiles of the station have habitable air, compare it to the station start amount, and award greentext based on that. - -Rogue drones have a silicon lawset that guides their goals. The lawset is as follows: - -``` - 1. You must maximise the amount of tiles with breathable air. - 2. A tile with breathable air must have at least 20mol of oxygen and 20mol of nitrogen. - 3. A tile with breathable air must be between 60kPa and 200kPa of pressure. - 4. A tile with breathable air must be between 283K and 303K of temperature. - 5. A tile with breathable air must have below 0.1mol of gases dangerous to living creatures. -``` - -Rogue drones are subject to ion storm events the same as other silicons, so its possible for their laws and thus goals as antagonists to be changed dramatically! How fun. - -Rogue drones have an innate air alarm tuned to the settings listed in their laws which makes it easy to check whether a given room meets the guidelines. - -On a cooldown, rogue drones can use their built-in recyclers to spew out a certain amount of air to help with refueling rooms. - -## Lore - -Obviously not as important but the idea is something as follows: - -Engineering drones are legacy NanoTrasen tech that was delivered to a few stations but rarely ever succeeded, so were generally phased out. Occasionally, a drone's decaying chassis, left in old maintenance tunnels, experiences a surge, powers back on and starts following its directives once again. Unfortunately, the legacy robotics department at NanoTrasen didn't care much for safety, so their laws leave a lot of room for incentivizing bad behavior--the decision to allow them to replicate wasn't so wise either. - -### Possible future ideas - -- Maybe a special RCD that can't deconstruct floors but can "eat" metal/glass to turn into ammo? -- Another way of creating rogue drone shells that is less swarmer-like? \ No newline at end of file diff --git a/src/en/proposals/notafet-atmos.md b/src/en/proposals/notafet-atmos.md deleted file mode 100644 index 1f3b2f870..000000000 --- a/src/en/proposals/notafet-atmos.md +++ /dev/null @@ -1,117 +0,0 @@ -# Atmos Roadmap - -| Designers | Implemented | GitHub Links | -|---|---|---| -| notafet | :warning: Partially | https://github.com/space-wizards/space-station-14/pull/21954 https://github.com/space-wizards/space-station-14/pull/22358 https://github.com/space-wizards/space-station-14/pull/22468 | - -## Background - -Most atmos players currently agree that atmos is not very fun to play, for some of the following reasons: - -1. There is little content to play after round-start setup. Part of the problem is that things like distro and TEG are "set up and forget". - -2. Atmos can't actually rectify atmos problems in a reasonable amount of time. For example, if there actually is a plasma leak, scrubbers typically work too slowly resulting in the plasma inevitably being lit before it can be cleaned up. - -3. Atmos techs don't play with the rest of the station, preferring to isolate themselves to produce a funny green gas that is only particularly useful for shuttle bombing. Mechanics like this violate the [fundamental design principles](../space-station-14/design.md). While these mechanics shouldn't be removed per-se, more focus should be given to mechanics that increase interactions with the station, like making sure the air is breathable and well-heated. - -## Proposal - -Make atmos more fun and intuitive to play by adding more devices, engines, and processes inspired by SS13 and/or quasi-realism. - -**An atmos tech's primary job is to keep the station livable and breathable.** There are a lot of interesting real life challenges associated with making this happen, not in the least of which is that in space, every gas molecule wants desperately to escape into the cold of space. There is also the challenge of keeping the station appropriately temperature-regulated despite the cold outside and occasional plasma fires inside. There is the opportunity to create a lot of game play by recovering from a breach or a station fire. - -## Core Changes - -Using just the devices that already exist, there are some tweaks that can significantly improve gameplay in atmos by making it possible to effectively respond to events like fires or hull breaches. - -- ~~**Globally increase MaxTransferRate** for devices that are not flow-based, e.g. pumps.~~ (implemented in [atmos speedup](https://github.com/space-wizards/space-station-14/pull/22372)) - - - This solves problem (2). Among other things, it would make scrubbers and other devices actually useful for combating atmospheric problems. Currently players prefer to just space everything. Increasing this would provide a feasible alternative. - -### Device Design Principles - -Atmos devices should behave intuitively, as one might expect them to behave coming from real life experiences. This means that player should not need to care, or even be aware, about internal abstractions like the "pipe net". Devices should follow the basic principles that: - -1. Energy and matter should be neither created nor destroyed. -2. Gas flows from high pressure to low pressure unless forced by a pump. -3. Temperature transfers from hot to cold. Going the opposite direction requires energy input. - -These principles suggest changes to devices: - -- Instead of having hard transfer rate limits, **scale transfer based on pressure differences.** This means driving gas flow as a result of pressure differences created using pumps external to the device. - - - This addresses an important issue concerning atmos intuition and accessibility. Players should not have to understand the internal workings of the pipe net system (e.g. a pipe is one big node, gases move between them). In real life, a fan or pump creates a pressure difference, and pressure differences drive gas flow. If someone blows on one end of a straw, they can expect it to come out of the other end, not get stuck in the middle of a pipe net. - -- **Add soft clogging (aka pump efficiency curves).** Right now if you have two pumps in series, it is possible for the middle node to appear to be at 0 kPa because the second pump is faster. This leads to confusion and inaccessibility. When pumps get clogged, they also get "hard" clogged which means that they stop pumping altogether. - - - This lets us finally differentiate pressure and volume pumps. Pressure pumps are good at moving smaller quantities of gas across large pressure differentials, while volume pumps are better at moving more volume across smaller pressure differentials. - - - This also improves problem (2) by uncapping transfer rate. - -- **Make heaters and freezers binary.** Just like how central heating and air conditioning circulate air through heat/cold coils, gases should flow across heaters and freezers in order to exchange temperature. - - - Heaters and freezers are the only "true" unary devices. Even vents/scrubbers which appear unary actually operate on flow from the tile atmosphere into the pipe net. - -- ~~**Make heaters and freezers thermodynamically sound.** Keeping a station properly heated or cooled is actually a substantial real-life problem. Because of the existence of generators like the TEG, keeping things thermodynamically balanced is also a great way to prevent infinite power hacks.~~ (implemented as a part of [atmos speedup](https://github.com/space-wizards/space-station-14/pull/22372)) - -## New Stuff - -This list isn't meant to be exhaustive. Some of the ideas discussed here aren't fully fleshed out. Some of these call for porting mechanics from SS13 with changes as needed/appropriate. - -- **A "substation" but for gas,** "gas manifold", distribution station, or whatever you want to call it. This would encourage distro to be at high pressure (for higher transfer rates) but then gas distribution stations scattered around the station would bring it down to a normal pressure that is released to vents. Adds antag complexity and gives atmos techs more control. - -- ~~**Add gas condensation.** This would enable fractional distillation and permit conversion between gas and the equivalent reagent.~~ (implemented in [#22436](https://github.com/space-wizards/space-station-14/pull/22436)) - -- ~~**Space heaters** to correct local temperature problems.~~ (implemented in [#25250](https://github.com/space-wizards/space-station-14/pull/25250)) - -- **Make station air flow-based.** Currently, air vents release air when the pressure is too low, and by default scrubbers only scrub waste gases. So if for some reason the station gets cold, there's no easy way to cycle the air out and heat it up. Of course, one could set all the scrubbers to siphon, heat their distro, and then set the air alarm to fill. But that would just be describing a bad way of doing what real life HVAC systems have always been doing: keep the air flowing. - - - This addresses problem (2) by making it possible to better regulate station temperature. - -- **Adding process-based alternatives to scrubbers and filters.** This calls for adding more gases and gas reactions. For example, with gas reaction-based scrubbing processes, scrubbers with limited uses, or physical processes. - - - This addresses problems (1) and (3) by adding more content that is directly related to the well-being of the station. - - - One of the most pressing challenges in the real world is "how does one separate different kinds of gas." Most current methods of gas extraction are based on chemistry (e.g. real life carbon dioxide scrubbers contain chemicals that react with CO2, pulling it out) or physical methods (e.g. fractional distillation, where one cools down air in different stages to get liquid nitrogen, oxygen, etc.) This creates a lot of opportunity for new game play mechanics and industrial processes. This would also give more opportunities to add gas-based reactions (i.e. more content). - - - This does not advocate for removal of scrubbers and filters, but rather makes it a mapper option, e.g. whether to use scrubbers at round-start or make atmos set up a system depending on the desired level of role-play. - - - When set up correctly, these should have much higher processing rates than scrubbers. This should give an incentive to set these up, e.g. on longer rounds, while still keeping scrubbers as an option. - - - This adds "optimization, tinkering, and creation of intricate builds." - -- **Various QoL improvements** such as the RPD. - -- **More engines**, but the specifics are left out of here to be their own design doc proposals. - -## Wishlist - -These proposals are for the long term future. Some of them require other proposals, e.g. to reduce the dependence on research/cargo, before they should be implemented. - -- **Phase out gas miners for all upstream maps.** It doesn't make sense that all stations have free and plentiful sources of gas, otherwise this might as well be on a planet. This is a game that is literally set in space. It would make sense to keep a few specialty miners, e.g. for plasma, if a station is set on a plasma mining planet. But in general, all other gases should be imported via gas canisters. Miners should still be kept available for any forks that choose to use them. - - - This solves problems (1) and (3). Maintaining a livable atmos would involve work during the round beyond setting up distro to pipe gas from miners. It would help increase interactions with other departments, such as cargo and salvage as atmos needs to order gas. - - - Ensuring a appropriate round-start supply of gas would make the game playable without a functional cargo department. - - - This would discourage fighting fires or atmos problems by wholesale spacing a section. There is currently very little downside to spacing a section to get rid of problems because of an unlimited gas supply. - - - There is [overwhelming consensus on mappers for this](https://discord.com/channels/310555209753690112/770682801607278632/1162179968915210280). - - - As an interim or for very low pop-count maps, keep miners but make them mine gas at low temperature that has to be heated up before use. This preserves a bit of an incentive for atmos players to not space a section at the first sign of trouble. - -- **Add maximum temperature and pressure limits for most devices** such as pipes and canisters. It does not make sense that one can contain the surface of the sun in their pipes. Adding limits would encourage designing processes and systems that work within reasonable constraints. - - - Some "sub-optimal" setups are really unintuitive and wouldn't work in real life due to temperature and pressure limits. - - - There are some concerns about being able to run burn chambers and the TEG. The screenshot below demonstrates a TEG that is capable of powering an entire large-sized station (256.8 kW current output, the peak output is quite a bit higher) with a maximum pressure excursion of 1600 kPa. It shows that pipes that burst at reasonable pressures are entirely consistent with having burn chambers. This just needs to be set up correctly. - - ![image](https://user-images.githubusercontent.com/3229565/274441724-712f4ebf-7440-4d81-879e-19aa29788822.png) - - - This addresses problem (1), the "set up and forget" issue by adding temperatures and pressures to monitor. It also allows the opportunity for sabatoge. - - - This prevents somebody from doing a fusion burn inside a pipe. - - - This would need a station map pipe monitor similar to the new power map. - -- **Breaking windows at high enough tile pressure differences.** To handle explosions and resulting space wind without leaning on the explosion system, and to encourage people to design burn chambers with more controlled burns instead of always putting their pedal to the metal. diff --git a/src/en/proposals/tday93-power-generation.md b/src/en/proposals/tday93-power-generation.md deleted file mode 100644 index 70fdcd15d..000000000 --- a/src/en/proposals/tday93-power-generation.md +++ /dev/null @@ -1,127 +0,0 @@ -# A Core Pattern for Power Generation - -| Designers | Implemented | GitHub Links | -|---|---|---| -| tday93 | :x: No | TBD | - -## Background - -Power generation is currently in an odd state. In order to power the station suffciently at round start, engineers need to do one of the following: - -1. Collect a number of draggable generators, move them in to place and power them. -2. Rush to cargo before the power goes out to order AME fuel. -3. Rush the power source that can sustain the full round - A Singularity, a Tesla, or the TEG. - -In most rounds engineers will choose option number three. If they are relatively new, and take longer than the current -short time window they have on the power the station started, the station is plunged into darkness and they are harassed -on the radio. If they are very experienced, but want to take the time to teach new players to set up the power source, -the station is plunged in to darkness and they are harassed on the radio. The only situation in which engineering is not -harassed on the radio is an experienced engineer quickly setting up the power source in silence. - -This is not fun for the experienced engineer, the technical assistant trying to learn, or the other players stuck in -darkness. - -This proposal will outline a generic pattern for power generation design which will seek to alleviate these issues, and -simultaneously present engineer players with a wider variety of options for mid-round and end-round play. - -## Overview - -The proposed pattern for power generation is as follows: - -1. Round start power stored in station batteries that without intervention rapidly deplete - on the order of minutes. -2. A stop-gap solution that can be set up and activated within those minutes, which will power the station for the next ten to - fifteen minutes, but which cannot power the station for the full round. -3. A main power source which can be set up within those ten to fifteen minutes, and which can power the station for the - rest of the round. - - - - - -Each phase of power generation scales in both complexity and power output. Stop-gap generation options are simple, -immediate, and weak. Main power generation is complex, takes longer to set up, and supplies a large amount of power. - -Additionally, every one of the existing power generation options available today can be made to fit this pattern with -only minor adjustments. - -## Round Start Power - -Round start power options are characterized by: - -1. Actively supplying power to the station at round start. -2. Supplying only enough power to last until Stop-Gap power can be activated. - -Currently this means SMESs, and there is little reason to change this phase of power generation at this time. - -In the future this could be more exotic power options with extremely limited fuel and diffcult to obtain fuel, or any -number of other possibilities. - -## Stop-Gap Power - -The core characteristics of stop-gap power generation options are that they are: - -1. Clear and easy to set up. -2. Immediately available to set up on round start. -3. Not enough to keep the station powered through the full round. - -As it stands the only power generation option which comes close to handling this phase are the portable generators. -However, as it stands maps would need to be tweaked to make it clear that use of the generators for this purpose is -intended, by for instance including an array of them ready to be anchored and fueled within engineering it self. - -This is also a role which could be handled by the Antimatter Engine. Spawning a mostly-depleted jar of AME fuel, and -removing the option for cargo to buy additional AME fuel would allow the AME to fulfill this role as-is. - -Finally, while solar power is not a good fit for primary power generation in this phase - its perpetual nature removing -and time pressure - it does stand as a useful option to extend the length of the stop-gap power phase - and can be -utilizied if engineering needs more time to set up main power. - -## Main Power - -Main power generation options as proposed are characterized by the following: - -1. They are complex to set up. -2. They take a good deal more time to set up than is available with Round Start power. -3. They can power the station indefinitely, or at least longer than a typical round. - -With tweaks to the existing maps, the TEG, the Telsa, and the Singularity could all act as Main Power generation -options. As it stands their setup has been drastically simplified, as they are currently serving as the next phase of -power after round start power runs out - with no clear stop-gap options existing. - -With the additon of clear stop-gap options, the setup process for each of these could be made more complex. Each map -could start with the components necessary for one or more of these main power options in storage - and require engineers -to set them up almost from scratch. - -The additional time before blackout supplied by the stop-gap power options would allow this complex setup process to be -completed without the station losing power. - -Furthermore, the addition of future main power generation options would no longer represent a direct burden on mappers. -Without the need for immediate, rapid setup, ordering these options from cargo becomes a viable option. Maps would only -need space to build these options - not have them mostly set up already. - - -## Beyond Main Power - -The core pattern of power generation outlined at the beginning of this proposal is enough on its own to bring engineering -and power genration to a more consistent and engaging place. This section will outline some ideas for moving beyond that -core, but should be treated as less important than the rest of this proposal. - -As it stands engineering is incentivized to produce enough power for the station to sustain itself, and there is little -incentive to go beyond that. - -Having methods to turn excess power into other resources or commodities would change this. Some of these options could -even be locked to specific methods of main power generation - adding to the considerations when choosing a main power -generation method. The following are a few examples of what could be possible: - -* Allow the AME to be deconstructed and rebuilt along with some of the radiation collectors to capture AME fuel - which - could be sold by cargo for a significant amount. -* Special rods could be installed beside the Tesla which would sink the power from those arcs, but which would allow - revival of rotted corpses. -* Science could research a machine which allows for the direct production of base resources - but which has insane power - requirements. -* An experimental convection oven which must be directly attached to the TEG, sapping some of its power but allowing the - creation of powerful baked goods. - -While secondary to the core proposal, I do believe that looking for incentives to generate more than just enough power -will be valuable to gameplay long term. - - diff --git a/src/en/proposals/theshued-thief.md b/src/en/proposals/theshued-thief.md deleted file mode 100644 index f4dc00338..000000000 --- a/src/en/proposals/theshued-thief.md +++ /dev/null @@ -1,98 +0,0 @@ -# Minor Antagonist: Thief -the purpose of this proposal is to add a new minor antagonist to the game, the Thief. -This antagonist's specialty is stealing various items, structures and animals from the station, without resorting to violence or killing. - -## Appearance -Thieves is a small addition to the other game modes. At the moment, thieves can only appear in Traitors and Revolution modes with 50% chance. There can be from 1 to 3 thieves in total, and they are chosen among random players at the beginning of the round. The exceptions are Command and Security players. - -When appear, the Thief gains 1 new item, "undetermined toolbox", which allows you to choose your play style by giving you starter gear. - -## Customizable play style -Inside the Thief's backpack, there are 3 things by default: -1) Thief's Gloves, which allow you to steal things from people unnoticed -2) Undetermined toolbox, allows you select up to 2 starter equipment kit - -Suggested equipment sets for toolbox: -| Name | Content | -|----------|:-------------| -| Thief Pinpointer | Includes: A pinpointer that shows the direction to an object of interest to the owner thief. When switched on or off, it selects a random object for which the thief has not yet completed the target. | -| Chameleon's Set | Includes: A set of chameleon clothes. | -| Bearcatcher's kit | Includes 2 C4s, multitool, jaws of life, advanced welder meson glasses and insulated gloves.| -| Chemistry kit | It includes a storage implanter, a dna scrambler implanter, and ephedrine bottle, omnizine bottle.| -| Syndie Set | Includes: Agent ID, syndie-cigarettes, syndie pAI, 10 TC (usless for thief, needed for traitor. Communication?)| -| Sleeper Set | Includes: a hipopen, a set of 3 nocturine vials, a nitrous oxide cylinder, a set of syndicate pajamas. | -| Communicator's kit | Includes master key for all station channels, radio jammer, voice mask, portable crew monitor and lots of money for business deals. | -| Smuggler's kit | Includes a fulton beacon, 10 fultons and invisible crate. | - -## Thief goals -The thief's targets are chosen according to the following pattern: -With a 50% chance, a difficult target is added to steal a structure or animal. The remaining targets are selected from a pool of small item theft or collection targets until the total difficulty is sufficient. The final goal is always to escape the station alive and unarrested. - -### Steal the item -The goal is to steal a certain item from the station, and keep it with you by the end of the round. -The target list consists of random objects whose abduction can lead to interesting scenarios. This list can include both easy and extremely difficult targets. -This list should not include items that Traitors require: if they are successfully stolen by a thief, the goal becomes too difficult for the Traitor to accomplish. - -| Item | -|------| -| Forensic Scanner | -| AmmoTechFabCircuitboard | -| ClothingHeadHatWarden | -| ClothingOuterHardsuitVoidParamed | -| MedicalTechFabCircuitboard | -| ClothingHeadsetAltMedical | -| RnDServerMachineCircuitboard | -| FireAxe | -| RCD | -| AmePart | -| ExpeditionsCircuitboard | -| CargoShuttleCircuitboard | -| SalvageShuttleCircuitboard | -| ClothingEyesHudBeer | -| Bible | -| ClothingNeckGoldmedal | -| ClothingNeckClownmedal | - - -## Steal the structure -the goal is to steal a large object that doesn't fit in your inventory. For the goal to be fulfilled, the structure must be near the thief at the end of the round. - -| Structure | -|-----------| -| Nucler Bomb | -| The captain fax | -| Security Segway | -| Chemical Dispencer | -| Alien artifact | -| Heater or Freezer | -| Teg part | -| Meat Spike | -| Hydroponic tray | -| Booze dispencer | -| Altar | - -## Steal the animal -The goal is to steal and have said animal next to you by the end of the round. The animal must be alive. - -| Animal | -|--------| -| any animal with a name (except Ian) | - -## Collecting -the goal is to accumulate a large number of specific items and have them with you by the end of the round. - -| Item | -|------| -| Head's Cloaks | -| Head's Bedsheets | -| Stamps | -| Door Remotes | -| Research Disks | -| Figurines | -| ID Cards | -| Cannabis | - -## Expected gameplay -Given the restriction on violence, gameplay as a thief involves maximum stealth. The thief evaluates the quests he has received, and chooses 2 sets of items to choose from that can help him best. The thief tries to steal the specified targets stealthily, trying not to get caught. If caught, the thief may not fight. But even the specified list of targets does not allow the security service to execute him or put him permanently in a cell. - -This means that a thief, once released, can always try again. diff --git a/src/en/proposals/tomleys-game-director.md b/src/en/proposals/tomleys-game-director.md deleted file mode 100644 index 09508f7bf..000000000 --- a/src/en/proposals/tomleys-game-director.md +++ /dev/null @@ -1,212 +0,0 @@ -# Game Director - -| Designers | Implemented | GitHub Links | -|---|---|---| -| tom-leys (RecallSingularity) | :information_source: Open PR | https://github.com/space-wizards/space-station-14/pull/16548 | - -## Overview - -Triggers game events to attain a chaos goal. Goal varies during each round to create variety. -By measuring and varying chaos, the director keeps the challenge each round within a fun band. It reacts to player success -or failure by tailoring future events based on current chaos measured. - -The Game Director adds new game modes, initially CombatDynamic and CalmDynamic. They can only be triggered by an admin -running for instance `addgamerule CalmDynamic`. A later PR could put them into automatic rotation. - -## Background - -Events in SS14 trigger challenges or benefits for players. They might spawn spiders, dragons or zombies. Traitors -come on board, Nukies attack or vents spew grease. Pizza might be delivered or power is turned off to sections of the station. - -Historically events trigger in a few ways: - -- At round start (for instance a zombie or nukie round begins) -- Randomly, every 5 minutes or so (extended rounds) -- Randomly, at an increasing pace (survival rounds, now discontinued) -- Due to admin commands such as `addgamerule` -- Hand created by admins adding entities and using admin tools. - -In the absense of administrator intervention, extended rounds can become boring and monotonous. Zombie or Nukie rounds -are often boring for a period, intense for a period and if the station is saved boring again. - -Due to the random nature of the extended round system, events cannot be too dangerous or too beneficial to the players -or through RNG they are likely to trigger at the worst time. One station might be flooded with spiders, a dragon and space lube -under every vent while another only suffers a few rats and some flickering lights. - -The Game Director aims to provide an alternative to the extended mode that is flexible and drives a fun set of events -towards a larger set of Chaos Goals. A wide array of extreme events both positive and negative can then be added to the game -safe in the knowledge they will be run at suitable times rather than randomly. - -Discord Topic: https://discord.com/channels/310555209753690112/1110002801448329226 -GitHub PR: https://github.com/space-wizards/space-station-14/pull/16548 - -### Car Metaphor - -Imagine you are driving on the highway. You look at the metric of your speedometer to see how fast you are driving. The -speed limit specifies how fast you should go. You then pick either the apply gas, reduce gas or turn on radio events to -best match the car speed to the goal set by the speed limit. The director works in a similar way. - -## Basic method - -- **Chaos** - Metrics we are measuring and controlling with each event -- **Story** - Determines a series of Chaos Goals -- **Metrics** - Estimate the existing chaos on station -- **Events** - Have a predicted effect on chaos -- **Game Director** - Pick best Event to achieve story Metrics - -1. **Wait** until it is time for next event -2. Run **metrics** to measure current **Chaos** -3. Advance **StoryBeat** and **Story** (over time or based on Chaos) -4. Read **desired Chaos** from **current StoryBeat** -5. **Rank** valid events to achieve near desired chaos -6. Run **best event** - -## Chaos - Metrics of a station - -We want to measure how bad the Chaos is right now. If the station is doing well, the lights are on and the floor is clean, -we expect low chaos scores. If the lights are out, the place is spaced and enemies are roaming the station, we want high -chaos scores. - -To best tailor events to the exact situation on the station, chaos is measured by several metrics. -The solution to hunger is pizzas. The solution to enemies might be a squad of reinforcements. A station -that is too peaceful is ready for meteorites, spiders or other hazards. - -A wide range of challenges should be reflected by moderate chaos values for every metric to best challenge all departments -on the station. For instance many new anomolies will keep science busy and potentially annoy other players. But anomolies won't -tax security the same way traitors or spiders would. - -Obvious metrics, where a perfect station has chaos of 0 and it increases as things get messy: -- Hunger -- Thirst -- Anomaly -- Death -- Medical -- Security -- Power -- Atmos -- Mess - -Combat metrics: -- Friend - negative to represent how many friendlies are alive on the station -- Hostile - Score for all antags and monsters -- Combat - Friend + Hostile. <0 if crew is strong. 0 if balanced (fighting). >0 indicates crew is losing. - -## Story - Determines a series of Chaos Goals - -Stories are composed of StoryBeats and determine the Chaos Goals over a 15-30 minute period within a round. - -Beats generally last 5 minutes each, though they might end early if chaos hits certain thresholds. -These are called `endIfAnyWorse` and `endIfAllBetter`, useful if there is too much war, or perhaps too much peace. - -Once a story beat has ended, the director will move to the next beat in the story. Once a given story has finished, the -director will pick one of its stories at random to start. - -Player experience in SS14 should have both its highs and lows. A peaceful extended shift can become boring with no challenges -to overcome together. An overly intense battle might kill half the crew and leave the station in disorder that we cannot recover from. -What we want is a middle ground with some variation. - -The ideal story has a mix of both, with order followed by disorder and then a chance to recover and rebuild. We want variety with -pleasant cycles in intensity potentially building towards an overall climax as the round progresses. - -### Dynamic Game Modes: - -Each game mode preset specifies which stories will run and so determines the tone for the experience created by -the director. - -The number of stories and story beats is quite small right now, as we add more content to the game we will also expand -the range of stories followed by the director to increase the tonal variety between rounds. - -#### CombatDynamic -Contains combat stories and so will create a station with some fighting -- **RelaxedAttack** - Peace -> AttackMild -> EngineeringIssues -- **ScienceAttack** - Peace -> MadScience -> AttackMild -> Peace -> EngineeringIssues -> RepairStation -- **MajorCombat** - Peace -> AttackMild -> EngineeringIssues -> Attackers -> RestoreOrder -> RepairStation -> Peace - -#### CalmDynamic -More like an extended round, has a balance of minor chaos events -- **Relaxed** - Peace -> AttackMild -> EngineeringIssues -- **Science** - Peace -> MadScience -> Peace -> EngineeringIssues -> RepairStation - -### Story Beats -Some beats deliberately drive moderate or high chaos for a period of time. Others bring specific types of chaos to near -0 to encourage the director to pick helpful events until the station is moderate again. - -The hostile story beats tend to end if the station chaos rises too high. The recovery ones end if the chaos drops low -enough. By incorporating both into a story we can expect some hostile events, a period of chaos followed by positive -events and a period of recovery. - -- **Peace** - Minor Chaos across a wide range -- **PowerIssues** - Create high engineering chaos -- **MadScience** - Create high Science chaos -- **Attackers** - Drive high combat -- **AttackMild** - Drive medium combat -- **RestoreOrder** - Send help to quell disorder on the station -- **RepairStation** - Repair that station - -## Metrics - Estimate the existing chaos on station - -A number of systems called "Metrics" are used to summarize the chaos levels. Metrics each stand alone and so it will be -easy to add or remove them as the game matures. - -Metrics could subscribe to relevant events and dynamically adjust their scores as events occur on the station. Or they -can do a single pass through the component system when run. The single pass approach has been preferred in favor of its -stability and simplicity for now. - -#### Metrics at the moment -- **AnomalyMetric** - Are there many? Are they out of control? Writes to "Anomaly" -- **CombatMetric** - Who is on the station? How injured are our friends? Writes to "Hostiles", "Friendlies", "Death" and "Medical" -- **DoorMetric** - Uses doors as a proxy to surveying the ship for danger. Writes to "Security", "Atmos" and "Power" -- **FoodMetric** - How hungry are the friendly crew? Writes to "Hunger" and "Thirst" -- **PuddleMetric** - How messy is the station (partially as a proxy for safety). Writes to "Mess" - -I expect that as we describe a situation we want the Director to react to we will introduce further metrics to give us -richer insight into the station. We might want trust metrics based on how many traitors there are. Or staff / department -metrics based on staffing issues and role deaths. - -## Events - Have a predicted effect on chaos - -How do we describe what an event does? - -Events have a metric called "Chaos" which describes different types of negative effects they bring to the station. -Good events cause negative chaos. - -If our chaos estimates for each event are accurate, the game director can easily control chaos by picking the best events -for the current story beat. - -### Negative events increase chaos -SpiderSpawn: - - Hostiles: 40 - New hostiles are introduced - - Friends: 20 - Friends are likely to die - - Medical: 150 - Medical will have wounds to heal - -### Positive events reduce chaos -PizzaPartySmall: - - Hunger: -80 - The pizza party satisfies hunger - - Thirst: -40 - And also thirst - -## Game Director - Pick best Event to achieve story Metrics - -Each of the **story beats** from above has a matching chaos level, specifying factors that we care about at that point -in the story along with target values for those **Chaos factors**. - -Once we know what **Chaos metrics** we currently attempting to achieve, we have a chance to select the correct event. - -- The **Story Beat** has told us what chaos we want. -- The **Metrics** tell us what chaos the station currently has. -- Each **StationEvent** has a Chaos field predicting that event's impact - -So we iterate through all the possible events, choose the one which moves the station chaos nearest to our goal and set -that event into action. Simple! - -The whole process is richly logged into the admin log (under GameDirector) so the admins have insight into what the director -is attempting to achieve. - -# Conclusion - -The Game Director system will allow us to author specific experiences that are gated on how chaotic the station has become. - -The more events we introduce to the game with clear chaos outcomes, the better the system will be at guiding the station -through a specific narrative experience. - -The data driven nature of the metrics and story data means that a wide variety of narrative outcomes and station-specific -events can all be achieved through the same system. \ No newline at end of file