Welcome

Welcome to the Funky Station Developer Wiki.

This goes over things like getting started, our design principles, and other miscellenious topics that might be developer related.

For other questions specific to RobustToolbox, you'd want to visit the Space Station 14 Developer Wiki

How do I get my feature proposed?

You want to add a new feature, amazing! You can go ahead and fork this repository, add your feature via a document in the appropriate folder, then go ahead and PR it to here. There are templates provided that you need to use in order for a maintainer to look at it with the attention it deserves. Be descriptive, as it will give you an edge in getting your feature added!

Fork this!

What is This?

This is meant to be both a guide of how to get started contributing for SS14 and an introduction to development as a whole. The end goal is that you not only have successfully made a pull request (PR), but that you also have a decent understanding of what, why, and how you do so.

People with any sort of development experience may find sections of this guide redundant; please keep in mind that it is written with new developers in mind.

What's in This Guide?

This primarily focuses on introducing the tools you will be using to create a PR, rather than the nitty gritty of developing as a whole. Please consider looking at WizDen's developer docs if you want to learn more about the finer details.

Getting Started

This guide assumes you have Git, a GitHub account and the .NET 9.0 SDK. If you don't, it's fine, just go ahead and follow the links, select your platform, and watch the installers whirr. For GitHub, make an account if you don't have one already.

Navigate to the Funky Station GitHub repository, click on Fork on the right side of your screen. Name your fork whatever you want. Once it completes, you should see a new repository on your account. Click on the green Code button, select Local, HTTPS, and copy the URL in the box. Congratulations, you now have your very own development build of Funky Station.

Let's get it on your machine. Open a new explorer window (or whatever file manager you have), and create a new folder called funkystation.

Go into the folder, and create a terminal window. If you've installed Git for Windows, then you can Right Click and then select Open Git Bash Here, and it will create a terminal window for you.

In this terminal window, ensure the path ends in /funkystation. If it does, amazing, keep going. If not, double check you've created the folder, and have navigated to the folder in your terminal window.

In your terminal window, type git clone <your repo url here> . (without the <>, and paste in the URL we just copied earlier) (AND REMEMBER THE PERIOD AT THE END). Let that work.

Let that work, if it errors, reread the guide and make sure you followed all the steps.

Congratulations, it's completed. To open a development build of Funky Station, you can now go to the Scripts folder. If you are on Windows, use the bat files, and if you are on Linux, use the sh files. Run buildAll... first, then runQuickAll to get a build working. Use buildAllDebug if you need to quickly load into a developer environment to test specific features, buildAllTools if you are mapping, and buildAllRelease if you need to test something in a simulated round.

Why not use Github's Web Editor?

I know it's tempting. Especially if you know that the change you want to make doesn't deal with actual C# code; maybe you want to fix a typo or rewrite one of the guidebook pages. Something small.

PLEASE DON'T!!!!!!!!!!!

Part of this is for future proofing--learning how to use these tools on a small change helps prepare you to do larger changes later. Just because your changes are small now doesn't mean they will be later.

The web editor, and Github in general, can not handle large changes. Plus, changes you might think are small might be larger than you think. As an example, try to open the 'Files Changed' tab of a PR that changes maps. Usually it crashes.

Github also likes to fuck up files if you try to upload them through Github, rather than setting up a local host and doing all of this. Things like images getting lossy, audio getting bit crushed, et cetera. It sucks.

Creating a Local Host

Please see Getting Started for information on how to get a local host on your computer. If you have an issues with this guide, you are always free to ask us in the Discord!

Similarly, if you want a more detailed version of the same guide, consider reading WizDen's Setting up a Development Environment

Most commonly, these two files open your local host in Debug. There are other .bat files to open your local host in different configurations (modes), however, there are other ways to do this that are generally a little better.

The most common way is to use your IDE (integrated developer environment, the program you use to code) of choice. Use your IDE to open SpaceStation14.sln and then navigate to the build button. In Jetbrains Rider, it's in the top right.

If you don't have an IDE, you can also use command line to run and configure a local host. Git Bash works for this, just make sure you are in the correct directory. Then run:

• dotnet build
• dotnet run --project Content.Server
• dotnet run --project Content.Server

If you want to run your local host in a different configuration, add --configuration Release/Debug/Tools at the end of the two run commands.

Updating a Local Host

Assuming you followed the guide in Getting Started, you can just press the "Sync Fork" button on Github's website. Then it updates your fork! Yay!

If you prefer to update things manually, then you can also add a remote to fetch and merge into your local version. Make sure you are on your master branch while doing this.

A remote is a way for Git to know to go to that specific repository (a codebase) and grab changes and code from there. In this case, you'll need to add a remote for Funkystation's Github. You can do this in Git Bash by running:

• git remote add funkystation https://github.com/funky-station/funky-station.git

You can change funkystation to anything you want. This is just the name of the remote, so pick something you can remember easily!

If you need to add a remote for a different repository (such as Wizden or Goobstation), you can run the same command with the name and link changed. The link you want can be acquired by going to the repository's Github page, clicking the green "Code" button and then copying the link there.

After this, you need to fetch the remote. Fetching something means you are telling Git to go get everything on the remote and hold onto it:

• git fetch funkystation

Git Bash will spit out a lot of lines at you, assuming it's been a little while since you last updated your local host. This is good! If you get nothing, then that's also fine. It means whatever Git Bash is holding onto is up to date with Funkystation's repository. If you get an error, usually the error message is pretty obvious with what's wrong. If it's something like "Remote not found!" then make sure you typed in the name correctly.

Then, you need to merge the remote into your local code:

• git merge funkystation/master

Notice the addition of /master! This just means that you are telling Git to merge specifically the master branch (the main code) of Funkystation into your code. There are other branches in Funkystation's repository, which we generally don't want. Git Bash will tell you it's updating, and then it's done!

What Next?

So you've got a nice and updated local host, then obviously you want to jump in and figure out coding and your changes. However... you're not quite there yet!

If you make changes now, you'll be doing so on your master branch. Your PR will automatically be closed if it comes from your master branch, so first, you need to figure out how to use Git and make a new branch.

If you want a more in depth explanation of Git, please see Wizden's Git for the SS14 Developer. This also has some information on how to use TortoiseGit and SmartGit, if you prefer those over Git Bash.

A branch another copy of your codebase, which you make your changes onto. You are "branching" off of the main tree in order to develop and test your changes. When these changes are done, we can then merge them into the main branch--also known as a pull request.

We do this in order to help organize development. If you end up doing multiple projects at once, or even something like a minor bug fix while you are working on something else, branches help keep everything neat and separate. If you prefer to see things visually, there are many resources online explaining branches with visual guides.

Working with Git

Now, you have to actually make a branch. To get started, open Git Bash in your directory (the /funkystation/ folder created prior). Unless you've worked with Git Bash before, this will open it on your master branch. You can tell what branch Git Bash is currently on by the cyan text in parenthesis, it should say "(master)."

The first command you need to know is git checkout. This is how you move between branches, you are checking out from one to the other. To make a new branch, you can simply do:

• git checkout -b branch-name

The -b tag means you want to make a new branch. You can replace branch-name with anything you want, just make sure it's unique.

After that... You're on a new branch! You can actually start coding now. After you finish your work, or need to save your work, you'll need to do two commands to commit your changes:

• git add -A

This "stages" the files to be committed. Basically you're telling Git that these are the files you edited and want to commit. The -A tag means all files, but you can remove it and individually add files for staging if you prefer.

• git commit -m "commit message here"

A commit basically an entry in your log of changes. The -m tag is so Git knows that you're attaching a message to the commit. If you don't add the tag, Git will probably open VIM (or whatever command line text editor you have installed. If you don't know what that is, it's probably VIM).

The message is so you know what was edited at a glance, but Git helpfully saves detailed information about what was edited in a commit.

After you've finished all of your changes and committed them, the last step is to push them to your origin, GitHub:

• git push origin branch-name

Origin refers to Github, and branch-name would be the name of your current branch. After you do this, go to Github's website find your forked repository (you can click your PFP and then "My Repositories").

Usually a nice little popup that says that the branch you were just working on had new changes. You can click "make a pull request" from there, or navigate to your branches and do the same thing. Then, you can make a pull request!

Pull Requests

A pull request is a way for you to showcase your changes and ask for them to be merged into the main codebase. You are requesting that your changes be pulled. A little bit of a confusing term if you don't know the prerequisite jargon.

The last section of Branching tells you how to navigate Github and start your actual pull request. From here, you can select which branch you are PRing to. By default it is Funkystation's master branch, and you usually want to keep that the same. You can also see the diff (the difference in files between your changes and the original codebase) here. Please make sure to review this, as you don't want any other changes sneaking into your PR.

Similarly, you'll want to fill out the description of your actual PR. Each section has an explanation in its comments, which are the sections enclosed with <!-- -->. PRs are more likely to be reviewed and merged if these sections are properly filled.

Changelog Formatting

Enclosed in comments is a sample changelog for your usage. Please make sure your changelog is formatted completely correctly, otherwise it won't appear in game.

The format is as follows:

🆑Username
- add: 
- remove: 
- tweak: 
- fix: 

For the username section, please make sure there are no special characters at all. Hyphens and exclamation points will break the changelog. You can also leave it blank if you prefer it to autofill your Github username.

Reviews

Once we receive a properly made PR, the maintainers will review your PR! We first look at things like test fails (CRLF check, YML linter, Content.Integration tests). Any related test fails will have to be corrected prior to being merged.

If the tests pass, great! We then review the code, discuss how it would impact the server, and then we either request changes, merge the PR, or close the PR. If you would like to know more about why or why not a PR was merged, please see our Design Principles.

Design Principles

Riffing off of what the Space Wizards have done with the game, these design principles go over what we should consider when designing new features for Funky Station.

Questions about game design should be discussed in Discord and requesting the presence of a maintainer or Tay.

For cool and fun features that you would to add (that aren't exactly a simple pull request), we suggest creating a design document using this template.

Caveats

• Just like WizDen says, these are living documents and will change over time.
• These documents are Funky Station's interpretation of what SS14 should be, and only reflects Funky Station's direction.
• Ideas should be discussed with the mindset of the games roleplay features being held above anything else.

What is MRP?

MRP, Medium Roleplay, is a version of the game where players are encouraged to take things straight and as they are.

The statement that a clown has ran into the supermatter should both be tragic and hilarious. A chemist blowing off all their limbs in an accident to make space meth should also be just as tragic and hilarious. Medium Roleplay is a stage where one player controls one character, and the players behind those screens are the audience. In-character actions have consequences, and sometimes the consequences are funnier than whatever gimmick the player might have thought up that round.

What is Funky Station?

Funky Station is a fork of Goob Station designed around being explicitly MRP.

Core Principles

Creating new features for Funky Station should not violate these core principles.

Seriously Silly

Funky Station is a play, with each round being a scene. The entire play revolves around a chartered corporation who's only interest is to keep their shareholders rich. Each character in that play, either directly or in-directly, is exposed to danger by other characters.

Increasing the chances of interactions like these playing out is essential when creating new features. Sometimes, something can be hilarious just for the sake of it (see the smoking on a bed may set you on fire PR.) Constantly players are having to poke death every 10 minutes or so, whether knowingly and unknowingly, which is the beauty of Funky Station.

Crazy situations happen, and must be embraced. When designing new features, think of possible outcomes and other systems your feature might interact with. And also consider how such a feature might be interacted with in a roleplay scenario. If the answer is very funny, it's probably a winner.

Maximize these silly situations whenever you possibly can.

There is no Winning or Losing

Space Station 14 is a game that can be ruined for someone very easily if they approach it with the wrong mindset. If you approach Space Station 14 in the same way you would approach Among Us or other social deduction games, you WILL become bored VERY quickly. Rather, ask yourself, what would my Felinid-Lizard-Moth abomination be thinking in this exact moment? Would they be thinking about winning? Or rather, thinking about when their next smokebreak is?

When designing a feature, ask yourself that question. Will this encourage players to engage with my feature with this win or lose mindset? Or does it help maintain the story telling and flow of a round?

This is especially true when designing new antagonist objectives. Sometimes, an objective is MEANT to be difficult to do, and is MEANT to be accomplishable by a manner that would be considered violent. Funky is a Space Opera, and a win or lose mentality only serves to compromise the fun. There is great fun to be had in failure, just like there is with success.

Maintaining Authenticity

Interactions should feel authentic, there is a reason why it is around 7 steps to light a cigarette in this game.

Making a feature feel authentic to real life does not always mean realism. Realism is a different goal that some other forks have in mind, but Realism =/= Authenticity.

Take for example reloading in games, there are more steps to reloading a gun in real life than there is on a game. You can get as granular as you want, even going as far as identifying individual muscle fibers to flex or whatever to achieve a reload. But most games, of course, don't do that. Sure, it'd be realistic, but would it be authentic? No. It would be annoying and tedious.

Just because something happens in real life, doesn't mean it should happen in game, if it takes away that feeling of authenticity.

Again, a cigarette taking 7 steps to light is authentic. The Supermatter being crazy as hell to maintain is also authentic. People getting up instantly after being exploded twice isn't.

Take Things Slow

Funky Station is built around 2 - 2:30 hour rounds. Many other servers balance their content and gameplay around an hour of gameplay. Thus, when designing new features, consider how much effort a player will have to put into interacting with your system. Things are meant to be complicated and difficult to understand, but first grasping the concepts shouldn't. The expectation players have when joining is that the round will go on for this long, so use this to your advantage.

Atmospherics is an example of this. An atmosians job is to make sure the station has a consistent (roughly) 80/20 mix of nitrogen and oxygen, at around 101KPA. This simple concept is easy for players new to atmospherics to understand, but the additions to atmospherics Funky Station has done has made the barrier to entry rather low, but full of mechanical depth and skill. The same goes with Chemistry, and other departments on Funky Station. See also the section on Maximizing Roleplay Potential, as these two things are very intertwined when considering regular department gameplay.

If you are adding a new gamemode or a weapon, consider TTK and think about how your feature can interact with added or in-progress medical systems. Not everything has to be survivable, but not everything has to be an instakill either. Consider using TTK for weapons or potential RR as deterrents for certain features, as this is one way to communicate to the player OOC that the thing you're working on is dangerous, and should be taken seriously.

Delimbing, targetting specific body parts or organs, or other things related should be considered with antagonists or weapon balance. People don't die in real life because they took 200 brute damage, people die in real life for specific causes, even if unknown. Consider the time investment a player has put into a round when considering antagonist or weapon balance. If death must occur, make sure it is a spectacle in its own right. In this regard, the aesthetics of dying matter.

When designing other features, consider the story you want to tell, and ask yourself if it is a worthwhile story a player wants to engage with for more than 15 minutes. Try justifying why it's worth it for an engineer to take 15 minutes to setup a single power engine, or why a chemist should spend 15 minutes creating a chemical. This is a co-operative game, so when designing things around regular department gameplay, leverage the social aspect of it all, and have people depend and rely on each other where ever it makes sense.

Being respectful of peoples time when they join Funky Station is important when designing a new system.

Maximizing Roleplay Potential (Avoid QOL slop)

When developing a new feature that is set to "optimize" a certain aspect of gameplay, think about the feature as a vector for roleplay. Does the previous feature introduce more ways for people to interact with each other? Or does this feature take away a vector for people to interact? If it does take away, is it a positive change in the long run?

These questions can be applied like so:

Say for instance you are changing the ChemMaster to have a way to produce bottles en masse, filled with a reagent of a chemists choosing. This, in our eyes, is a positive change that encourages healthier RP, as the previous method for chemists to distribute chemicals en masse to doctors and other crew members, is via jugs, which only serve as an intermediary tool and are rarely thought of. Bottles adds to the immersion that this is an actual item that someone made, and not just a bunch of reagents in a container. In this instance, aesthetics matter.

An instance where a feature would take away a vector for roleplay is the Stationwide Material Silo. Apply the questions like so:

"Does the previous feature introduce more ways for people to interact?" - The previous feature was cargo delivering materials to departments as ordered. While sloppy, it did encourage a lot of small talk and smaller interactions with characters, which is a positive.

"Does this new feature take away a vector for people to interact?" - Yes, cargo players can just deliver materials to a central point in the station, while not communicating with anyone at all.

"If it does take away, is it a positive change in the long run?" - No, hyperoptimizing a crucial part of the gameplay for a cargo tech, talking to random people on the station, is not healthy for the game. Having players be more entrenched in their departments is generally not good for the culture, and stationwide material silos, from the questions we just asked, encourage that very thing.

Dynamic Environment

Anything should be possible. Just like Wizard's Den, we feel that building an entire, functional station should be possible to do, if there is a considerable effort put into this undertaking.

What is a Proposal?

A proposal is a way to put your feature out there to the world. A chance for you to speak uninterrupted and for maintainers at Funky Station to give your feature the proper attention it deserves.

A proposal, given enough care and thought, will be reviewed by the Head Maintainer and other Maintainers. The community may also have a chance to speak up about things they like and do not like about your feature.

What can a Proposal be about?

A proposal can be about anything you want to add to the game. There are two categories for now, although this might be subject to change.

A Map Proposal

A map proposal is about adding a map into rotation for Funky Station. This helps maintainers ensure a level of quality when approving new maps, although typically mapping proposals need to go through multiple layers of approval before they are accepted.

The reason for why a mapping proposal may be denied include:

• Significant overhead already added ontop of maintaining several maps
• The mapping proposal is missing key features that is needed for a map to be viable
• The map does not fit into the vision the maintainers have for Funky Station
• The map may not recieve the proper care and support it needs after it is merged
• The map is unfriendly towards crucial features specific to Funky Station

There are a lot of hurdles, and consider these when designing a new map and request that it be added. Maintainers do not want to see a new map get added then forced out of rotation because of little support from the community.

A Gameplay Proposal

A gameplay proposal is about adding a new feature for players to interact with. This helps maintainers understand the thought put into a feature before it is merged, as well as gives admins the means to understand what your feature is doing and help provide support to players who may ask about it.

The reason for why a gameplay proposal may be denied include:

• Significant changes to code that may be modified by Upstream
• The gameplay proposal does not fit into the vision the maintainers have for Funky Station
• The gameplay proposal goes against one of the core design principles
• The gameplay proposal is not well thought out enough for certain scenarios
• The gameplay proposal that comes with a PR may have code that is not up to maintainer standard

A Lore Proposal

A lore proposal is a submission of an article or content piece for canon status in the Funky environment. Articles may be developed and discussed in the Lore-Article-Review channel of discord, but must undergo a proper review via submission to the lore-proposals folder. The submission template is located in the design folder of src

The reasons for why a lore proposal may be denied include:

• The proposal does contradicts the core vision and goal of the Funkystation project
• The proposal has goes against one our core design principles
• The proposal requires further changes or review to meet standards, whether in grammar or content
• The proposal does not properly explore the ramifications of the change on the setting and game

What are the chances my proposal gets accepted?

To be truthful, we won't know until you propose it. We can give you some expectations though.

A mapping proposal will have a much harder time getting through because of the significance a map has to the game. Players remember good maps, and players especially remember maps that they do not enjoy.

A gameplay proposal might have an easier time getting through, especially if a demo PR is already made and tested, although this isn't to say cool things won't get merged because they need work done for them to work.

Short, Properly Capitalized Title

Your title should convey the basic jist of your proposed changes. It should be short because the text will be linked in the sidebar.

Designers should be the names that you use on GitHub and/or Discord. This is optional but strongly recommended, since:

• This acknowledges credit where it is due
• People who are confused about the written intent can use this information to contact the authors

Implemented is the status of the feature.

Github links can include multiple PRs, if relevant.

Overview

A very short, maybe three sentence summary of what this proposal is about. A high level "overview" or "what this adds".

Background

Summarize any information that is needed to contextualize the proposed changes, e.g. the current state of the game.

Also link any relevant discussions on Discord, GitHub, or HackMD that are relevant to the proposal.

Features to be added

Give a description of what game mechanics you would like to add or change. This should be a general overview, with enough details on critical design points that someone can directly implement the feature from this design document. Exact numbers for game balance however are not necessary, as these can be adjusted later either during development or after it has been implemented, but mention what will have to be balanced and what needs to be considered when doing so.

Game Design Rationale

Consider addressing:

• How does the feature align with our Core Design Principles and game philosphy?

Roundflow & Player interaction

Consider addressing:

• At what point in the round does the feature come into play? Does it happen every round? How does it affect the round pace?
• How do you wish for players to interact with your feature and how should they not interact with it? How is this mechanically enforced?

Administrative & Server Rule Impact (if applicable)

• Does this feature introduce any new rule enforcement challenges or additional workload for admins?
• Could this feature increase the likelihood of griefing, rule-breaking, or player disputes?
• How are the rules enforced mechanically by way the feature will be implemented?

Technical Considerations

• Are there any anticipated performance impacts?
• Does the feature require new systems, UI elements, or refactors of existing ones?
• For required UI elements, give a short description or a mockup of how they should look like (for example a radial menu, actions & alerts, navmaps, or other window types)

Name of your Map

Designers should be the names that you use on GitHub and/or Discord. This is optional but strongly recommended, since:

• This acknowledges credit where it is due
• People who are confused about the written intent can use this information to contact the authors

Implemented is the status of the feature.

Github links can include multiple PRs, if relevant.

Overview

A very short, maybe three sentence summary of what this map is themed around.

Population Expectation

The general population your map is expected to accomodate for. A sentence is perfectly fine.

Design Rationale

A place to talk about your design choices with this map, how it fits the theme of what your map is designed around, as well as any miscellaneous info that is relavent to the map.

Render / Screenshots

Place renders of your maps here, upload all files to the assets folder. Also place whatever else you used to help you design this map.

Bartender Overhaul

Overview

The general goals of the revamp is to make the bartending experience feel more manual and true to life, increase the number of roleplaying opportunities, and encourage more player expression within the role. This is done through removing the primacy of the metamorphic glass, by removing the drinks dispensers, and by defining a standard that all drinks should conform to.

Background

The service department is meant to be the roleplay department. I think that while it is fine for them to have less mechanical depth in comparison to the other departments, the sparcity of it gives little aid to players to help them roleplay or even just play their role accurately. Bartenders face this problem quite heavily. Bartenders and services workers have a tendency to attract players who see the bar as a place for easily accessible loot, getting kitted out with flash protection, armor, and a gun. Customers who come to the bar have a tendency to order the same drink each time without any motivation to change their order. Some bartenders have the habit of just flooding the counter with drinks. None of the above can be considered as conducive of roleplay.

When you look at the features associated with the bartender, it feels more like the attempt at a stereotypical saloon owner with bandaid systems that have been grandfathered in as the foundation of the role. The gun and armor, somehow, take center stage of the role rather than mixing drinks. The dispensers and metamorphic glasses feel like easy shorthands to get the base mechanics of the bar without the extra overhead of making it feel like one.

Features to be added

Jiggers

Implementation

Jiggers should be able to be flipped. Instead of a 20u capacity, one side should have a 10u capacity and the other 5u.

Motivation

Currently, jiggers are useless and don't match their real life use case, which was as a measuring tool. Most of the time, a bartender pours in 5u or 10u incremements. A shorthand to let them pour accurately without having to change the pour rate is to set it to a higher pour rate then the maximum, and pour it into the jigger. Theoretically, this would give the bartender access to 3 different pour amounts without ever having to adjust the bottle's pour rate.

This is something I do already with the dispensers to quickly make certain drinks. I would set the dispenser to dispense 20u of liquids. Dispensing tea and then ice will give you 20u tea and 10u ice, making 30u iced tea.

Addition of mixing glass

Implementation

Mixing glass will be a resprited large beaker, 100u capacity.

Motivation

This is useful so that players are able to mix non 30u increments of drinks and do so in a way that's easily visible. There have been many times where a shaker is used for this purpose only for the other bartender to mistakenly use it as it is opaque.

Bartender glasses changes

Implementation

Let beer goggles function similarly to chemical analysis glasses and replace sunglasses with cheap sunglasses.

Motivation

Choosing bartender or service worker tends to attract powergamers due to bartenders having access to armor, a gun, and flash protection. By removing the sunglasses. The addition of chemical analysis to beer goggles is to give bartenders the ability to see the contents of any vessel without having to put them into a dispenser.

Removal of liquid dispensers from the bar

Implementation

Changes in all maps to remove the dispensers and replace it with alternative storage for both alcohol (such as through the alcohol cabinet) and for glasses and other paraphenalia. This may include respriting the jug to be transparent as well.

Motivation

The changes listed above to make it more convenient to hand pour and otherwise work the bar without the dispenser are all there to make up for dispensers being removed. This is done to accurately mimic the bartending experience and help make it more distinct from just being "chemist-lite". Sure, it may seem like this introduces an extra layer of inconvenience in the drink making process, but the kitchen operates in a similar manner, mixing regents by hand into a vessel to create various types of dough and having multiple steps to create a single food item. If anything, this will bring it more in line to the labour required with botany and the kitchen.

Standardisation and expansion of tasting notes

Implementation

Rewriting of the flavours of cocktails so that they are, where possible, evocative imagery rather than the actual taste of the drink itself. The actual flavour of a drink, meanwhile, should be used primarily for base liquids.

Motivation

I am of the opinion that more metaphorical descriptions are more compelling to both read as well as utilise when mixing multiple cocktails together. A prime example, I think, is a cuba libre. The drink, historically, is in reference to revolution and rebellion and would be made more intersting if it had a taste alluding to that rather than just tasting "like a spiked cola".

To illustrate the two different paradigms of naming flavours:

• Blue curacao + the martinez: tastes like orange flowers and like violets and citrus vodka (based on the actual flavours of the drink)
• The manhattan + gildlager + tequila: Tastes like looking out the window of a 5 star hotel, like the tsar’s gold, and like fermented death (based on imagery)

I believe the latter is more compelling to work with.

In addition to this, a variety of drinks have no "reward" for their creation. A posca "tastes bitter" while its description talks about it being a drink of ancient warriors. Non-alcoholic drinks, in general, do not have unique flavour profiles that help them stand out.

Giving drinks themes in the guidebook

Implementation

In the guidebook description of each drinks, other than the lore, add in things like "classy", "strong", "bitter", etc to further categorise and describe the drinks like in VA-11 Hall-A.

Motivation

People who visit the bar tend to only order the same drink over and over again rather than varying their choices like people would do in real life. I think that part of this is due to the amount of analysis paralysis that a person has trying to read and navigate through the sheer number of different types of drinks in the handbook. By giving this way of simplification, they are more able to scan throguh the handbook and find drinks based on their mood as a character rather than what the player behind them finds easy to order. Conversely, the bartender may offer certain categories of drinks to a person to match their mood, giving them aid in roleplay in this aspect if they do not have a strong knowledge of all the types of drinks, their flavours, and the like.

Completion of the non-metamorphic glass set

Implementation

Addition of, at minimum, a highball and a lowball glass.

Motivation

There already is a precedent set by the existence of the shot glass and the coupe glass. The thing is, I find that those two forms aren't always the best way to present the custom cocktails I want. Most bars, in real life, would have the aforementioned glasses for their drinks along with a variety of other stemmed glassware. With the changes to how metamorphic glasses work, more types of glasses are also need to match the different types of drinks that can be made.

Sprite layers for non-metamorphic glasses

Implementation

Refactor code for non-metamorphic glasses to include sprite layers and the creation of items that utilise these layers. Similar to how, say, a janitor's cart works.

Motivation

To further increase the uniqueness of a drink beyond just choice of glass and the colour produced, additions such as staws, umbrellas, ice, etc. are all things that can make the drinks stand out. The initial impression of a custom cocktail will be the look, not the words that appear when it is drank, of course. I believe this would, with the above changes, allow for more personal expression in each individual barkeep beyond making the set drinks and increases roleplay opportunities as both the customer and the bartender can use the drink as a catalyst for conversation. It may also potentially draw more players to visit the bar due to it having more novelty and uniqueness on a round by round basis in comparison to the current system, where players are liable to order a regular drink and expect the same result, regardless of the bartender.

Reworking the metamorphic glass meta

Implementation

Glasses will now have a whitelist for the kinds of drinks that will transform their appearance. This will not change the way the shape of the glass looks, instead changing the fill and possibly adding garnish or other elements to the glass. Additionally, it should also turn back to a regular glass with its normal fill method when there is more than one type of reagent within the solution.

It should be mentioned that I have already prototyped and created a working version of the glass whitelist portion of the rework. This can be ported first should the latter half of the functionality take too long to make.

Motivation

To me, this is one of the biggest parts of the bartender fantasy that is missing from the current system. Now, bartenders are motivated to be picky with their choice in glassware to fully create a given drink. At the same time, it also gives more room for people to actually start experimenting and making more custom drinks as they are forced to engage with systems that facilitate them rather than use the metamorphic glass for every drink. The general customisability from this system, the variety of glasses, the different tasting notes, and the sprite layers, will all help give the bartender the tools they need to make cocktails outside of what the handbook offers, leading to more chances of roleplayy and personal expression.

General respriting efforts

Implementation

Based on the rework above, all metamorphic glass sprites should be reworked to match the new vessels.

Motivation

General updates to match funky's general art style and provide more consistency and parity with other sprites and the new system for drink transformations.

Bartender SOP updates

Implementation

Bartender SOP should have infromation actually detailing their work rather than just gun ownership. This should be styled after Japanese bartenders, emphasising proper ways of mixing drinks and a general demeanour of grace and elegance. It should also state that people getting drunk on shift would be the fault of the bartender.

Motivation

The current bartender SOP feels more like a bandaid to curb LRP players as it only mentions the usage of the shotgun and the type of ammo that it is allowed to contain. Having a proper SOP will not only give bartenders guidance for how to act and encourage roleplay, it also gives IAAs more opportunity to interact with the bar within their capacity.

The above guidelines were inspired by Japanese bartending, which known to be wholly focussed upon having a beautiful procedure in the creation of the cocktail. Due to that, they are both famously slow and discourage such behaviours such as getting drunk. It also matches the general context of funky as bartenders in Japan will serve a small amount of people at a time, with a bartender catering for around 5 people at most at a given point in time. I think that following or choosing to ignore the SOP in this case will lead to more interesting roleplay interactions.

Game Design Rationale

Seriously Silly

I believe that adding a SOP that, while possible to do, is unreasonable to maintain will lead to more interesting and fun interactions as bartenders now have to contend more with IAA as they are expected to follow a certain mode of conduct. With the ability to get alcohol in maints, drunk crewmembers may not necessarily be the bartender's fault but they will still be blamed for it.

Maintaining Authenticity

By removing the dispensers and the metamorphic glass, it will make the bar more true to life as people are forced to pour out of bottles and choose the right glasses to properly make a drink rather than doing the equivalent of using a soda dispenser and a magic glass to make a gin and tonic.

Take Things Slow

The changes above will make the amount of time and effort it takes to make a single drink increase. This will mean that people who visit the bar will have to linger a bit longer rather than just taking a drink and leaving straight away. It also prevents the bartender from easily mass producing drinks and filling the table with them.

Maximizing Roleplay Potential (Avoid QOL slop)

For the same reasons above, taking more time to make a drink will mean that people are more likely to roleplay with one another as they wait. The process of drink making being more transparent means not only can the customer view and comment upon the process, the bartender can actually see the bar and see conversation instead of the game being obscured as they are in the dispernser UI. The added customisability to drinks encourages bartenders and customers to be more dynamic with their interactions and changes to flavours and drink categorsiations provide easier avenues to roleplay as well.

Roundflow & Player interaction

A full implementation of the system won't really change the way a bartender would currently operate, other than having to content with the lack of dispensers. Instead, they would be using mixing glasses or actually wearing the beer goggles instead of the sunglasses to determine whether or not they made the right drink for the customer. They would be using the alcohol cabinet instead to access the drinks that they need. If the bartender was particularly in tune with the current system, they would be using the jigger in tandem with a bottle so they have access to 5u, 10u, and 15u pouring increments without having to access the transfer rates UI. Rather than selecting the same glass over and over again, bartenders would have to choose the correct glass if they want the drink to look correct rather than having the generic fill sprite for the given glass.

Those bartenders who are more experimental can focus on creating custom drinks based on the liquids or tasting notes they observe and pour them into the glasses to achieve unique tastes, looks, and colours. They can add things like straws and umbrellas via sprite layers to further customise the look.

Customers are more encouraged to order from a "secret" menu as they know they can get custom drinks from the bartender. On top of that, they also have an easier time varying their drink selection as drinks are given categories for them to select for rather than needing to read the description of every single drink.

Administrative & Server Rule Impact (if applicable)

Should this be completely implemented, it will need a general oversight on all maps for the removal of dispensers and additional storage space for the bartender.

Technical Considerations

One of the bigger things to consider is that drinks that are pulled from upstream will need to be reconfigured to fit the aforementioned standard for flavour profiles to maintain cohesion and enhance the custom drink experience.

Refactoring of the codebase will be needed to introduce sprite layers to etamorphic glasses.

Refactoring the way metamorphic glasses work for the new system.

Hydroponics Changes

Overview

Expands the role of botany by opening the design space through the rebalancing of existing features, a new mutation system, and the addition of new plants, machinery and mutations.

Background

I initially set out to incentivize shadowlands exploration by adding plants as interesting loot, however, the more I tested certain features the more potential problems I found. I discussed some of these problems with Terkala/The Fern of Functionality and they agreed that the current state of botany wouldn't support some of the more powerful plants I planned to add. As a result, the scope of this proposal has grown far beyond my initial expectations.

Features to be added

Unique plant crossbreeding

Feature Description

Different seeds can be crossbred together into new species. This would be achieved through a new roundstart machine that would consume seeds and potentially a catalyst to output a new species of plant.

One path could relate to steel-caps, for example:

• Combine papercane and steel-caps to create plastic-caps
• Combine plastic-caps and golden apples to create aurum-caps which could produce small amounts of gold

This feature would allow botany to grow plants that would have been too strong or would invalidate other departments if they existed purely in the current system. The process of mutating three unique plants, combining them together, and finally trying for self-harvesting mutations should be long and difficult enough to make salvage the much preferred route to gold, however, it allows botany to fill gaps in the manifest and provides a longer term goal. It's also easy to balance. If we wanted gold to be locked behind salvage we could make a requirement be salvage loot.

Motivation

Currently players need to apply unstable mutagen and hope for the best to mutate plants. In isolation this system if fine, although it has a heavy reliance on chemistry, there's limited skill expression and - provided you've got access to exotic seeds - you can grow everything almost immediately from round start. If I added new varieties of mutations they'd all be easy to achieve purely by dumping buckets of mutagen and then dylo/multiver/vitamins onto certain plants. I've also seen a common trend in botany of cryoing earlier after growing certain plants. Usually these plants consist of everything the chef could need or some combination of omni, cognizine, deathnettle and gatfruits. This new feature should encourage greater variety in the number of plants grown, add to the progression throughout a round and allow botany to grow plants that are useful to a variety of departments.

Machines

Plant Sequencer

Swabbing is completely random and fairly obtuse for new botanists, so I propose adding a new machine to aid the learning process and partially remove the randomness. It would be available as a tier 3 civilian services research.

The plant sequencer would consume two seeds to displays what traits could be spliced between them. The player would then manually choose some mutations and traits, limited by a new mechanic called 'genetic stability', and then the remaining traits would be spliced randomly, identical similar to the current system. More powerful traits would cost more genetic stability and this would only be recovered as plants grow. This machine requires a competent botanist and civ t3 to make full use of so I'll probably tune it higher to start and if it's problematic we can tune it down late.

Plant Analyzer

I'd like to make adjustments to the plant analyzer to give it different tiers so it can be available from roundstart as well as more powerful versions through research. At T1 the plant analyzer would be available at round start but it would only display less useful info such as potency, yield and potentially growth rates and use more power. At T2 it'd be the current plant analyzer with - potentially slightly faster with less information? - which would add information such as chemicals, gas and mutations. At T3 it'd be available from the T3 civ services research. It would be fairly fast and show details such as potency divisor, weed growth and threshold, and mutations.

Seed Splicer

A new machine for crossbreeding plant species. This would take two unique seeds in varying quantities and combine them into a new species. Certain plants may require more then one packet of seeds or catalyst (vestine, exotium, artifact shards) as a balancing measure.

Botany rebalance

Motivation

As mentioned earlier, the best method to achieve anything in botany right now is to throw a cocktail of chemicals on a plant. Whilst most of these chemicals aren't a huge concern there are a couple that I believe are problematic, notably diethylamine.

Diethyl can be used to speed up a plant's growth by increasing it's age. This bypasses anything that could affect the plants health so it can be abused to instantly grow any plant regardless of its requirements. I've managed to grow 9 gatfruits in under three minutes from round start using a single seed and 35 gatfruits in about five minutes with a bucket of diethyl, despite the fact that it's bugged to be less effective then intended. Diethyl greatly limits the botany design space as any plant with longer growth times, complex requirements, or unique conditions can be instantly grown.

Another issue is that multiver/dylo/vitamins can restore plant health and phalanx can remove an invalid gene so a plant can always be kept alive at no cost.

I'm proposing that we link plant health to growth rate and instead have diethyl speed up growth rate. A healthy plant with this change could grow even faster than in stable but plants with worse conditions or botanists with thousands of units of diethyl would have a harder time. As part of this change I'd be modifying mutations to remove some conditions that I've never once seen satisfied (Requires zauker/trit/bz) and adding some new ones - including intended features that were never finished.

Changes

• PlantGrowth now increases the rate a plant grows instead of instantly increasing a plant's age
• A plant's growth rate and health is increased or decreased based upon a formula rather than the current all or nothing system.
• Implemented missing features or features marked as TODO (such as improper light doing nothing, potentially pests if the playtests go well)
• Modified gas mutations to be safer (I'll talk to Terkala/Fern for this one)
• Removed a number of the health modifying mutations that will never be satisfied. (I don't think an atmosian has ever been or should ever be asked to trit flood botany and it's not an interesting way to punish excessive mutation)
• Colored the third hydroponics light to differentiate between what's impacting a plant's health
• Robust harvest has a 5-10? unit threshold so it won't punish botanists for being one or two units over
• Modified the mutation weights to be more enjoyable

The following are a few potential tentative and controversial changes to botany, most won't be implemented.

These are potential balancing levers for if more variety and content leads to powercreep, to potentially reduce entity spam, and to reduce the gap between standard plants and perfect plants to help newer botanists. If given the choice I'd rather have power in the variety, experimentation and content of botany rather than a few very strong plants.

• Specific plant species have a max yield
• Plants have a maximum chemical storage based on potency
• Chemicals are decreased the more that exist in a plant
• The potency divisor of certain chemicals is increased
• High yield plants take longer to grow, chemicals in a plant are potentially increased to compensate (Might require kitchen changes)
• Plants take slightly longer to grow if they're multi-harvest, increased for self-harvesting or these traits reduce yield
• Plants will always be able to be clipped exactly two times. Maybe can limit to 1 or 0 for extremely powerful plants so you need a lot of effort to grow one.
• Clipping will reduce the stats of the parent plant, clippings might be unaffected. Could use genetic stability so plants recover over time

New plants

Shadowlands Loot

I'll work with an artist and maintainer on the naming and theming of these.

The majority of these plants will be poisonous and grow better in low light conditions. This gives the option for engineering to help build a space but these plants could also be grown in the botany locker room (on most maps), grown in maints, or spliced to remove this trait. I'll also add some standard plants too, I'm just listing the ones that should be in a design document.

Ebonberry

Peer into the shadows

A berry obtained by crossbreeding a shadowlands plant and blue pumpkins. It grants nightvision to aid in exploration but it can also be beneficial for hiding or exploring maints.

Duskpalm

Obscure the world

A rare plant found responsible for creating the shadows found near shadow portals. It can be mutated into dawnpalm which has an intense glow that banishes away any nearby shadows. If science is using a shadow anomaly as a portal an expedition team can retrieve this and a botanist can mutate it to help deal the anomaly and it may be useful for exploring the shadowlands. I'll need to look into performance impacts for this one.

Spectra

Fade into darkness

A crossbreed of a chilly, glasstle and a rare shadowlands plant. Anyone who consumes this plant will become temporarily invisible.

Uses the upstream regent Spectra-Fade pull request.

Wormhole

Warp yourself into genpop

A crossbreed between an extra-dimensional orange, spaceman's trumpet and a rare shadowlands plant. Any player who consumes this regent will be teleported a short distance randomly, suffer heavy toxin damage and empty their stomach from the transition. It's a great escape from antags or for antags with a heavy risk attached. It should be difficult to use as a poison since it's extremely obvious, you don't want your target to teleport to safety, and it's consumed after one teleport.

Salvage Loot

Radium and Phosphorus plants

For when you've pestered chemistry too much

Currently there's only one component of mutagen available in plants without random mutation, chlorine. A plant would be available from salvage that could be crossbred with a few standard seeds to produce radium and/or phosphorus so botany could better mutate without a chemist.

Gaia

The only plant anyone ever suggests

With the introduction of rare plants and crossbreeding we can finally add Gaia back without breaking the game. Gaia would be the pinnacle of difficulty to obtain and require advanced mutations, salvage and potentially even an expedition to the shadowlands. Once it's been achieved plants will no longer need weeding, water or compost.

Catmint

Have any ahelp instantly answered!

A plant that contains drugs that only affect felinids and cats. Can be crossbred with blueberries into a plant that contains a regent similar to wehjuice that makes players meow. This regent can be used for a chem that can temporary polymorphs players into a cat. When scurrets/slugcats get merged upstream (VERY IMPORTANT) it'll also be used for scurret polymorphs.

Features that might be designed later

This is already long enough but here's a list of plants I'm looking into and some other features I might include

• Expanding the cap series of trees to include most resources the station could need - provided the right seeds are found and the right plants are mutated
• An expansion to syndicate botany that requires growing, mutating and crossbreeding gatfruit among other plants and vestine. It rewards more powerful guns at much greater risk of sec discovery and a big investment in time and resources
• A low capacity battery that can be grown that slowly recharges over time
• A plant that grows improved fibres to make slightly larger backpacks.
• A more consistent way to obtain anomaly berries
• More mutations

Suggestions

• Stunbaton equiv of nettle, might be fine if it uses the same salvage plant containing licoxide to crossbreed with difficult enough requirements

Game Design Rationale

Botany was the first department I started with in SS13 (and SS14) and I believe that it's unique in its position as beginner friendly job that's never required for the station to run whilst simultaneously having a high skill ceiling and potentially patch almost any issue in a station. If medical is understaffed you can produce omnizine, if materials are an issue you can supply the station with steelcap and random chemicals help keep the department fresh. Despite all it's very common to see reworks suggested and I agree there are improvements that could be made. I've reviewed proposals and pull requests across different repositories and the common threads are the following:

• Botany lacks interdepartmental interactions outside of providing ingredients to the chef and requiring chemicals from the chemist
• There is limited progression throughout a round
• Traits are obtuse and mutation is random

I disagree that botany only interacts with one, maybe two, departments since I've had botany specific interactions with almost every role, however, there's plenty of room for improvement and the new plants should aid in this. Additionally, the addition of crossbreeding should add long term goals and the loot can open up exciting possibilities for a botanist late into a round. New machinery alongside our previous addition of and improvements to the plant analyzer ashould aid players in learning how to mutate and splice traits from plants together.

Seriously Silly

The new plants should open up some very silly possibilities. I love the idea of bluespacing only to end in the worst location, invisibility timing out at the worst time, new fun chems to mess around with and overall just an improvement to the amount of people I roleplay with in a botany round. Also the image of a syndicate agent gearing up with plants instead of a hardsuit and high tech weapons is hilarious to me.

Maintaining Authenticity

Crossbreeding plants and genetically modifying them is a common part of modern agriculture. Kale, cauliflower, broccoli, cabbage and Brussels sprouts all were developed from the same plant and there's thousands of chilli varieties. Improving this feature should feel authentic and add to the idea that this station was primarily setup for research and development. I concede that some of the sillier plants aren't realistic although I think it's fine to sacrifice some realism for entertainment.

Dynamic Environment + There is no Winning or Losing

For this proposal these principles are intricately linked so to avoid repeating the same thing: At the moment botany can feel somewhat solved; while random chems in plants are great at creating roleplaying experiences and dynamic rounds they aren't consistent. Your best bet right now is to grow omnizine, deathnettle, gatfruit or killer tomatoes. I'm hoping these changes open up new strategies, unique options and expand on what makes botany dynamic rather than player's focusing on a small set of meta plants.

Roundflow & Player interaction

Roundflow

Most of these plants will be difficult to come by and require a competent botanist, chemist and salvage team working together and some features require T3 service research. In longer rounds you could see botany become a force to be reckoned with, however, plenty of other jobs (salvage, atmos, science, cargo) also scale well so I'm not expecting anything major to change we could always rein it in if it does and apply some nergs. If Verna or Fern become DAGD agents then I'm sure they could abuse these changes but that would be peak SS14.

Player interaction

Players would have many new options open to them and it these changes encourage other departments - notably salvage - talking to botany so this should be great for player interaction. I could see veterans being annoyed after going from an extremely skilled botanist to a new player so that could be a problem but I'd like to hope our playerbase is above flaming newbies for not being Verna. Some botanists might ignore the chef at the risk of breaking SOP and getting fired?

Administrative & Server Rule Impact

Everything added would just expand existing features so the admin load should be similar. There's the potential it would make it easier to self-antag or powergame as botanist but given the current system allows for botany to produce lethal amounts of BZ or trit I'd expect it to reduce workload if anything. There is also the potential for OOC mald at new players (which already exists in other departments) in a role that's well suited for new players.

Technical Considerations

If do my job correctly I don't expect any performance impact, there could be issues with entity spam but I'm planning on profiling the code and improving the current performance. There's been plenty of arguments on improving the botany code and switching to more of an ECS design pattern but I'm planning on working on content first and foremost rather then getting bogged down in making a perfect system and the code is workable for the most part, I'll look into it further down the development pipeline.

I'll develop a mockup for this UI if the proposal is received well and I'd require help spriting for this project since I'm horrific at drawing.

Cargo Overhaul

Special thanks to ThatOneMoon, literallyablueberryguy, Sophia Impetus, Goobie, Moxie_Is_Moxie, and UristMcWiki. You helped flesh out this idea a ton <3

Overview

Overhauls how cargo works by replacing the ATS with Traders that visit the station over the shift.

Background

Cargo 2.0’s objective is to remove the “bluespacing” magic of things from normal rounds, making bluespace a more mysterious force that needs to be investigated, leaving it for the station’s purpose of researching it, while making cargo a more intresting role than just selling the station for parts on the ATS. The replacement for the game's magic instant teleportation comes in the form of Traders who visit the station, maintaining a more authentic representation of how things would work in real-life space logistics.

Initially inspired by https://static.slugcat.systems/salvage/

Features to be added

Traders

Trader ships will start visiting the station, FTLing to a nearby spot. Each ship will stay for a time before departing. While near the station, cargo can contact them to verify the ship's manifest and purchase itmes. Traders can be haggled with to get a better deal, or pay extra to gain better favor (Reduce annoyance). Traders who are going to the station to make deliveries may also carry mail for the station's workers. Traders may advertise different missions that the station can take.

• Traders may advertise increased prices for certain items they are looking for (bounties). While you can haggle for bounty prices, they run out of patience much sooner.
• Traders may advertise a Hold mission, where cargo needs to hold onto some crates for a bit while another ship comes to take them later. The "holding price" can be haggled too.
• Other mission types may be added later.

I am looking for names and backgrounds for trader companies. If you want to contribute your own funky idea please do so here

Deliveries

When things are bought through the station's cargo request terminal, a delivery will be generated. After enough time passes, a delivery ship will be sent to the station with both deliveries and mail. There are 2 options for deliveries:

• A NanoTrasen delivery ship that delivers the cargo and then leaves.
• A Trader that was going that way anyway, so they get paid to do the delivery.

Traders that are going to the station anyway (are not contacted by FTL-Comms) may also carry regular mail deliveries.

Once Scrip is added, players could also have access to a Scrip shop and get that delivered to the station. (NT would be acting as the intermediate party, letting their employees use Scrip to buy small, silly things) Traitors could also get their things delivered by traders, being smuggled onto the station this way, but after a discussion (https://discord.com/channels/1276640157511979008/1276653734767755294/1465387091998281769), the idea grew enough to become its own design doc for further down the line.

FTL Antenna

A large device which, when powered, can be used to scan signals from FTL ships.

• Could be required to see space

FTL Communications Computer

The FTL-C Computer is a new computer that allows cargo to scan FTL space in search of trader signals. If a signal is found, it would allow them to check a trader's manifest and communicate with the trader to call them over. Needs to be connected to an FTL Antenna via a networking tool

External Radio Communications Computer

The ERC Computer is a new computer that allows cargo to communicate with nearby trader ships, letting them check their manifest, place buy orders, and track any mission they have.

Haggling

Traders can be haggled with in order to get better prices for buying or selling. Each trader has a preset price change tolerance and a range of possible patience values. Traders will haggle you back, so the actual value of the offer after haggling will be somewhere in the middle of the original price and your offer. All traders have a "final offer" line that they will say when they are out of patience, but they may try to fake you out by using this line when they are still willing to haggle more.

Annoyance

Annoying a trader won't have much effect, but annoying many traders will spread the word that this station is not worth the trouble.

Ship Types

Flagships - THE Flagship. Has all the luxury for whoever owns it - Only for admemes (Think NT Super-VIP visit, probably has a death squad protecting them)

Traders

• Big - Ships with tons of cargo space, they exist for moving freight across the vast distances of space
• Intermediate - Most common type of trade ship. Designed to go station to station, trading for goods
• Independent/Small - Small ships offering limited things

Mail Carriers - Ships dedicated to moving large amounts of mail through a territory.

• In between Intermediate and Small, designed for "last light year" (last mile) delivery

• After consulting with the lore people, I was told it would not be common for the competition to sell stuff directly, so new companies will need to be created. Eg, CarpPro, a company that sells fishing products; MorningStar Dynamics, a company that resells mercenary gear

  • After even more consultation with the lore people, it has been determined that traders under Sol Gov could be a thing (as in registered under Sol Gov)

Item market value fluctuations

This is a system intended to add more variety by making prices slightly fluctuate throughout a round, while also preventing the station from only selling one thing. At the start of each round, item prices are randomly set higher or lower than usual. This randomness shifts the meta of what items are most profitable to sell each round. Include demand and supply dynamics

• Selling a lot of one thing would impact its market value, lowering it. This is intended to stop the selling of one item the whole round (SMES farm type nerf)
• Buying a lot of one thing would impact its market value, increasing it.
• A random event could trigger that makes an item to be demanded by the market (raises prices), or the inverse, which makes the item be oversupplied/not wanted by the market (lowers prices).

Game Design Rationale

The proposal aims to remove the magic teleportation of things/spawning out of thin air to make a more authentic game, while also making the world feel bigger and more alive with the inclusion and regular interaction with different trading companies.

This also introduces some round variation, as each trader will buy and sell different things. Maybe you can get a discounted artifact from some local archaeologist, or sell a used artifact to a research company just passing by!

Roundflow & Player interaction

The first random traders will start showing up soon after the round starts

Having to wait for all their batched orders to arrive will be a slowing factor for cargo, but it will also introduce variations into the rounds as each trader will be different than the last (With a big enough trader ship pool).

Cargo is expected to buy things needed by the station from the traders, plus things that they plan to sell to the highest bidder. As different companies have different needs, they need to recognize who will buy things over the market price (bounties) to generate the most profit possible.

As a way to de-incentivize certain behaviours, an "annoyance counter" will be added, representing how annoyed traders are at the station's cargo department.

The game director can call up random events mid-round that affect the item market, making things more or less expensive for the station. Many market events could have their own flavor text; this would give players a way to RP things happening outside the station (eg, news about a refinery fire) and make the world feel lived in outside the station itself.

Administrative & Server Rule Impact (if applicable)

Cargo SOP will need to be amended to take into account the time it takes for Traders to appear after things are bought on the cargo console.

Technical Considerations

Trader Ships

• Each trader ship will start with a random timer designating how long they will stay near the station.

  • A hard ship cap can be enforced by not having any more trade ships on the FTL-C, and not allowing cargo to buy things until the current delivery ship is cleared

• A trader will have a list of things they sell. That is their manifest.

  • A hidden manifest can be implemented for antags to use. They usually contain contraband items.
    • This feature is mostly for other people to build on (eg, Urist's Fence support antag on his thief rework proposal, or the Interdyne Chemist to get some "special" restocks).

• Each trader will come with a list of missions the station can partake in.

  • For now, they will be heavily weighted towards Bounties, until enough mission types can be added to make it more interesting.
  • Some missions will need to be completed before the trader leaves, while others will have different triggers for completion.

Delivery ships

• Unlike traders, delivery ships won't have anything to offer but what has been asked for.

• They will arrive, announce themselves, and leave as soon as the ship is clear of any people and deliveries.

  • They will get annoyed if they are left waiting for too long

Mapping Trader Ships

• Different styles for each corporation

  • A corporation could have a fleet of smaller and larger ships.

    • This depends on corporation size and lore (Megacorp (NT), Big (Cybersun/Gorlex), Medium (Animal rights consortium), Small (random independent traders))
    • Each corporation should have its own set of decals to make each ship theirs (eg, big NT logo, or red highlights for syndicate)

  • Ships could share shape (ship model), but with different paint jobs.

  • Smaller traders could have more cozy ships, or repurposed vessels? (eg, Big Ore Trader using a standard ship vs Local Salvaging Crew having a scrappy salvage vessel).

• Use a modified ATS spawning and sell zones in a hidden compartment to hide the spawning of crates and selling of bounties. Usage of conveyors and airtight flaps is encouraged.

  • Spawn zones modified to have a buy queue (Kills "not enough space" error message).
    • Spawns crates from the queue in an interval to simulate cargo being moved on the back of the ship.
  • Sell areas modified to instantly sell any crates placed on them.

FTL Antenna

• A large device that needs to be powered and connected to the FTL-C Computer with a networking tool
  • (Optional) When a connection is started, power usage increases
    • (Optional) The power usage could depend on how high the signal gain is

FTL-Commnications Computer

• Requires the FTL Antenna to be connected via a networking tool to function (Look at how artifact scanners work).

• Minigame that lets you tune the antenna's FTL comms to find traders that are "warping" (not spawned) near the station.

  • Adjust Azimuth and Elevation, read radio gain, and adjust again till you hit a trader with a high enough gain to connect.

• When tuned lets you see the cargo manifest of a ship and also allows you to call it to the station for trade.

  • Emmaging enables looking at the hidden manifest of ships that have it.

External Radio Communications Computer

2 Tabs:

• Ship Manifests Tab:

  • Allows you to see the manifests of nearby ships and place orders on them.

    • Emmaging enables looking at the hidden manifest of ships that have it.
    • You can haggle the price of the order. Bigger orders can get a bigger discount.
      • Being too unreasonable (haggling too far or too many attempts) will annoy the trader, who may refuse to complete the order and leave as soon as they can.

  • Will allow you to see the remaining time before they warp away.

  • Will allow you to dismiss the trader early, freeing up a spot for another trader to come (soft trader limit).

• Missions Tab:

  • Let's you track active bounties on the different ships.
  • Let's you track other missions (like hold orders).

Haggling

• Each trader has 2 values:

  • Price Change Tolerance: How much they are willing to go over or under the price for selling and buying, respectively.
  • Patience: How many attempts the player gets before getting annoyed and rejecting the haggle outright.

• Traders haggling back will take a value between the original price and your offer.

  • Exception: The offer is in their favor (you sell cheap or buy high).

Annoyance

• Annoyance is a counter that increases when players act in ways that are not good for the traders, and decreases when favorable deals are struck with the traders.

  • The starting annoyance value will be set on the mean annoyance of the traders that visited the station during the shift. This will be akin to the station "gaining a bad reputation".

• When the annoyance counter is high enough, traders will stop allowing haggling.

  • If the annoyance counter keeps increasing, they will stop visiting the station if they don't have a purpose. This includes refusing to come over when contacted, and stop allowing trade altogether.
    • It is a QM's job not allow this to happen.

• Each trader has their own annoyance threshold. This is done to make sure that the station is not suddenly cut off from trade.

• Annoyance triggers:

  • If a player is on a trading ship, the ship will not FTL away. If you leave traders waiting to leave for a long time, they will get annoyed.
  • Failed haggling attempts will annoy traders.
  • Failing missions (may also incur a fine).
  • Damage to trader ships will ANNOY traders a lot.
    • This includes hacking doors.
    • If damage is serious enough, they may hightail it. Any players remaining on board will be removed from the round as their body has left with the trader ship.
      • (To determine later) Display a message on the common channel about them leaving? Play some claxon to indicate the ship is emergency warping away soon?

Item market value fluctuations

• Add an item market console that would have a list of items that can be sold. When an item is clicked, relevant information is shown.

  • Take inspiration from Sec’s Wanted computer and add a category dropdown and search functionality.
  • Add a bar graph with historic prices when an item is clicked?

• Each item on the market should have a "mass" that makes it more or less easy to move its price from the station exporint/importing it

  • Events outside the station can still easily impact the market (say "a refinery-planet fire makes plastic costs soar by 15%", or "a shipping lane disaster makes ships coming from outside NT territory delayed, making certain product prices go up temporarily")
  • Basic resources should not be easy to move by the station selling them
  • Some items should not be able to be moved (eg, lottery crate)
    • Define mass = 0 to not allow items to be moved on the market

Removals

• Remove the ATS.
• Remove the Mail Teleporter.
• Remove the bounties computer.

Command SOP

1. Command members are to ensure the safety of the entire station, each primarily responsible for their own Department and respective duties;
2. Command members are to ensure the wellbeing and dignity of Nanotrasen and its related assets;
3. Command members may not slander or libel Nanotrasen;
4. Command members must ensure that Nanotrasen corporate secrets remain confidential, and may reprimand or punish fellow command members who threaten this confidentiality;
5. In the event of a confirmed threat to the station or Nanotrasen as a whole, command members may temporarily reveal related corporate secrets to crewmembers;
6. Command members must report such confidentiality breaks as soon as the event is resolved;
7. Command members must follow any Central Command officer's (such as the Nanotrasen Representative, Internal Affairs Agent, or the Magistrate) direction on corporate secrets;
8. Command members must accept any fine, punishment, demotion, or death when a Central Command officer informs them of a wrongful break of their confidentiality agreement.

"Corporate Secrets"

Overview

The metashield, as it currently is, is confusing and heavily relies on OOC enforcement of IC actions. This is a proposal in order to rewrite the metashield as "corporate secrets," focusing on giving players a better way to react to the game in character.

The basic summary of corporate secrets is:

• Pretty much everything is shielded now, with some minor exceptions. Normal crewmates are here to do their job, and as such, NT does not tell them about any of the potential on-station threats.
• However, command is trained to deal with these threats. The metashield does not exist for them. However, these threats are corporate secrets, and command has signed some sort of NDA about them. Telling the crew about said threats (unless in emergency situations) is strictly prohibited.
• Since IAA, NTR and the Magistrate are directly from NT corporate, they are tasked with ensuring that command does not fearmonger and spill the secrets. In the case that a command member reveals corporate secrets unnecessarily, these three would be the ones to punish them IC. Admins are still encouraged to enforce the metashield OOC.
• The metashield can only be lifted one of two ways: Central Command announcements (think war ops, unusual activity, or blob biohazard announcements) or by command telling the crew.

Features to be added

Multiple new in-game and wiki documents:

• Metashield
• Command SOP

Overview

Genetics is a new medical science wing that lets researchers scan, sequence, and modify DNA to unlock mutations ranging from harmless accents and traits to powerful abilities. Every round, all mutations receive unique 32-base DNA sequences that must be discovered through experimentation on test subjects. Correctly sequencing a block activates the mutation, but excessive non-natural mutations cause genetic instability leading to harmful effects; rare mutations generate research points. While most mutations will be discovered through research on monkeys, some only naturally manifest in certain species or mob types, leading to experimentation with a wider assortment of station life.

Background

Science currently lacks depth in research variance, with minimal interaction involving live subjects or DNA manipulation. This proposal draws inspiration from SS13's genetics system but adapts it for SS14's codebase, emphasizing discovery, experimentation, and integration with the proposed science overhaul's point types (e.g., biology points). Genetics will function as a wing of science, using monkeys, crew volunteers, or acquired specimens (e.g., from salvage, cargo, or scavenged pets) as test subjects.

Features to be added

Genetics revolves around four key pieces of equipment: the DNA Scanner, DNA Scanner Console, DNA Injectors, and Handheld Genetic Analyzer. Mutations are prototype-based, and include many unofficial categories such as speech accents, quirks/disabilities, beneficial, harmful, and instability punishments.

Core Mechanics

• Round-Unique DNA Sequences: At round start, each mutation prototype is assigned a unique block and 32-base sequence (A-T/G-C pairs). Sequences never repeat.
• Genetic Instability: Non-natural mutations add instability. Over 100: random severe negative mutation every 60–90s. Over 150: constant cellular damage. Instability is balanced to discourage spamming powerful mutations.
• Mutation Discovery: Sequencing a block reveals and activates the mutation station-wide. Common mutations generate minimal/no research points; rare mutations (unlocked via precursors) generate significant biology points, pacing higher rewards mid-to-late round.
• Mutation Removal: Mutadone removes most mutations. Select mutations can be flagged resistant to mutadone, sequencer, or "Scramble DNA" (30s cooldown, 25 cellular damage, resets non-resistant mutations).
• Departure from SS13: Monkeys cannot revert to humans (permanent visual punishment for instability; avoids conflicts with changeling/cargo systems involving corpses being a rare commodity).

Equipment

• DNA Scanner: Pod for one occupant. Links to console via device network for scanning.
• DNA Scanner Console: UI shows vitals, mutation list, sequencer grid (click bases to guess; each click: 0.2 cellular damage), saved mutations, injector printing. Starts with 60 empty injectors (refillable via lathe). Filled injectors transfer mutations between consoles. Hidden mutations unlock via precursors (e.g., thermal resistance after heat/cold).
• DNA Injector – Activator (blue): Single-use; activates existing mutation.
• DNA Injector – Mutator (red): Single-use; adds/activates new block (increases instability if non-base).
• Handheld Genetic Analyzer: Portable; displays all blocks/revealed sequences, prints paper reports. Uses small power cell.

Example Mutations

• Speech/Accents (0 instability): Cowboy, Pirate, Russian, Stuttering, etc.
• Quirks/Disabilities: Pacifism, Narcolepsy, Blindness, Mute, etc.
• Beneficial: Alcohol Immunity, Supermatter Hallucination Immunity, Anaerobic Metabolism, etc.
• Punishments: Monkey Transformation (human-only, permanent, non-printable, sequencer, mutadone and scramble resistant).

Mutations apply/remove components dynamically. Balance focuses on removable effects with non-permanent drawbacks (except instability punishments).

Game Design Rationale

• Seriously Silly: Experimenting on monkeys/kobolds/crew with mystery DNA sequences encourage absurd and serious roleplay, from forcing accents on unwilling subjects, chasing rare mutations in unique species or mob types, or dealing with upset monkeys who have gained sentience.
• There is no Winning or Losing: Instability risks balance powergaming mutations, and mutadone/scramble provide easy recovery before permanent consequences are suffered. Most mutations will be researched solely for the sake of contributing to scientific research points, not simply to hand out to crew.
• Maintaining Authenticity: NanoTrasen experimenting on DNA fits corporate evil. The simplified sequencing mimic genetic base pairs. Genetic instability mutations such as those that polymorph players into another creature follow the Carpenter/Cronenbergesque aesthetic of Space Station.
• Dynamic Environment: Rare mutations require diverse subjects/stimuli, pulling in medical/cargo/salv.
• Take Things Slow: Paced by sequencing damage, instability, and precursor unlocks; extends science gameplay without rushing.
• Maximizing Roleplay Potential: Injectors enable trading mutations, and sequences can be discovered by analyzing crew and printing out their genetic sequences. Both of these should foster inter-department roleplay and cooperation.

Roundflow & Player Interaction

• Early Round: Scan monkeys/crew with handheld for base sequences; discover low-point common mutations.
• Mid Round: Radiation/crew incidents provide new subjects; precursors unlock rarer mutations for research points.
• Late Round: High-point rare mutations discovered; injectors potentially distributed to crew for buffs/drama.
• Every Round: Core loop active throughout, slowing early science (plentiful undiscovered commons) and ramping late.
• Desired Interactions: Voluntary crew testing, injector trading, cross-dept subjects.

Administrative & Server Rule Impact (if applicable)

• Minimal new workload: Fits existing griefing rules (no forced perma-harm without consent). Instability self-regulates abuse.
• Low grief risk: Removable mutations prevent round-removal; instability mutations require many deliberate choices and failure to recieve mutadone for at least a full minute of warnings.
• Mechanical enforcement: Instability, resistant flags, and scramble cooldown prevent exploits.

Technical Considerations

• Performance Impacts: Should be negligible; prototype-based mutations use lightweight components.
• New Systems/UI/Refactors:
  • New genetics component (per-entity DNA blocks/instability).
  • DNA Scanner/Console entities with device linking.
  • Console UI: Tabs for vitals, sequencer grid (clickable 32-slot base pair matcher), mutation list/storage, injector printer.
  • Handheld UI: Simple list view with print button.
  • Injector entities.
  • Round-start prototype shuffling for sequences.
• No major refactors; integrates with science lathes/research points.

Lasers and Armory Overhaul

Overview

This design doc outlines the removal of current ballistic weapons in the armory in favor of safer, more retro, family-friendly weaponry designed to melt station-ending threats.

Background

Ballistic weaponry from an in-universe common-sense/immersion perspective is not ideal whatsoever when bullets can break windows and space (very dangerous!!!) sections of the station, potentially killing crew if no protections are in place.

This design doc is made from the perspective of both allowing melee weapons to be more viable and to unify NanoTrasen standard weaponry in a way that makes more sense.

They are additionally the primary killing tools of the Syndicate (bad guys!!), and this works to differentiate NanoTrasen brand killing tools (good) and Syndicate brand evil killing tools (bad), as well as allow unique balancing around factional weaponry. Found bullet casings in maintenance? You probably can't blame that on a trigger-happy cadet anymore.

Why this is Good for the Game

These changes all aim to serve a few purposes:

Aesthetics: Energy weapons are cool and retro sci-fi-y, and very distinguishable as opposed to having 5 generic Gun sprites.

Melee, especially unique antagonist melee such as the energy sword and armblade, should be more viable as a method of killing, as a high risk-reward profile. The overall increase of Time-To-Kill on ranged weaponry should aim to incentivize the use of more 'up close and personal' killings and encourage antagonists to take on Security more.

The splitting up of Sec lethals should also encourage Security to use their other tools, like truncheons, more for better damage profiles instead of using their gun as a metaphorical hammer for everything.

This also aims to bring Sec more 'back to Earth', so to speak. By lowering the amount of pure weaponry they have access to roundstart, we curb the constant Sec - Antag cat-and-mouse balancing game that leads to intense powercreep, and makes crew cooperation and interdepartmental play somewhat more useful in ending station-wide threats, such as the Blob. In short, this helps allow for antagonist abilities to be imposing without having to be overwhelmingly powerful or durable.

Ranged weapons, due to their inherent safety and power over using melee, should require a bit more tactical use and forethought than just pointing in a direction and killing whatever's there. Lasers allow for more of this planning through the use of, for example, constructing windows to prepare for a threat. The lowered amount of charges and damage-per-charge/magazine also requires more forethought when bringing them out. Why use a gun when I can relatively safely use melee here?

Additions

Map into Armory

Temperature Gun

See https://github.com/space-wizards/space-station-14/pull/35447 for implementation. Main difference: this will be an Armory weapon and not researchable.

Ion Rifle

A powerful three-shot rifle that deals 50 ion damage on a direct hit as well as a 3x3 tile weak EMP where it lands. Very powerful against cybernetic threats, such as borgs, IPCs, or mechs, but only tactically useful against other energy-weapon users.

Energy Gun

A battery-powered carbine (can fit in the backpack) which can fire either disabling or laser bolts, with less charge than the base Laser Rifle. It has 15 charges.

Miniature Energy Gun

The replacement for both the Officer's disabler and pistol, this is simply a smaller version of the Energy Gun. It can fit in your pocket and has 12 charges, which can be used to disable or laser.

Cadets will also start with this, but it will be locked on Disable until the childproof plastic lock is broken using a screwdriver.

Possible Additions (to be added to Research, primarily)

Blue Laser Rifle

Same as the stock laser rifle but it deals cold damage because it's blue.

Force-bolt Pitcher

An energy weapon that fires slow-moving but long-lasting spheres of energy. This deals blunt and some stamina damage.

Inducer

A portable recharger. It takes battery-cells and charges at a very slow rate. Possibly upgradable with Science.

Changes to current Features / Gamestate

Armory (Mapping)

The removal of all ballistic weaponry from the Armory, in favor of the new laser-based weaponry.

Kammerers should stay as they are explicitly very CQB weapons, as opposed to the longer-range, more reliable lasers.

The addition of a disabler safe to all armories for emergency Command-arming reasons.

The removal of the WT-550 from the Head of Security office.

The removal of disablers from Sec officer lockers.

The removal of ballistic ammo that no longer corresponds to armory/on-station weaponry. Keep rifle, revolver, and shotgun ammo printing for the Chaplain, Detective, and armory respectively.

Overall, Armory would now contain:

• 1 disabler safe (containing 5 disablers)
• 3 energy guns
• 3 laser rifles
• 3 Kammerers
• 1 ion rifle
• 1 temperature gun

Note: Although the weekly rollouts can simply migrate weapon safes in the armory through migrations.yml, it would be best to have them also mapped out by their respective map's maintainers where possible.

Cargo

• The removal of the WT-550 SMG crate from Cargo.
• Replacing the Enforcer crate with the Kammerer crate.
• Replacing the smg and pistols crates with the Energy Gun and Miniature Energy Guns crates.

Technical / Misc. Tweaks

• One unified Laser Projectile and one unified Disabler Projectile defined in Funkystation files.
• An overall increase in laser damage.
• The removal of self-recharging from the HoS' multiphase gun (why is it a better captain's laser?)
• The removal of self-recharging from the EG-4 energy revolver (Blueshield)
• Reduce the Warden's energy shotgun to 6 shots.
• The removal of the mk58 pistol and disabler from the Security Officer loadout for the miniature energy pistol.
• Changing all laser-based weaponry from hitscan to projectile, except for the retro laser blaster because it is funny.
• Remove ion damage from disabling bolts.
• Reduction of the total amount of disabler shots-per-charge.
• Reduce the reflective vest's deflect chance from 100% to 66%

Possible (Future) Tweaks and Concerns

New Arsenal research paths for better energy / ballistic weaponry, printable by Sec to make up for the reduction in overall roundstart firepower.

Certain antag's heat resistances, most probably Nukeops and Dragons, will likely need to be tweaked down a significant margin.

Blob health might need tweaking as a result of the now mainly-heat-based armory.

Game Design Rationale

Seriously Silly

Laser guns are as dangerous as they are silly-looking and sounding and a staple of retro sci-fi. In short: they're flavorful and iconic, much more so than generic ballistic assault rifles.

Maintaining Authenticity

In the future corporate hellscape that is Space Station 14, anachronistic current-day technology exists with futuristic-but-not-really tech. Fax machines exist in the same station as alien artifacts and extradimensional anomalies. Dinky laser guns just fit the environment of a space station much better than a gun that would fit in the hands of a Vietnam War-era soldier.

Roundflow & Player Interaction

This should ideally encourage players in combat to fight in more up-and-personal ways, using more game mechanics while in combat. Slips, stuns, shoves, and antagonist abilities will have a chance to thrive when not every fight is a shootout.

Technical Considerations

This is all possible to do with purely .yml and mapping changes. Coordination will be required from mapping maintainers for armory changes.

More input will be required from the maintainers, particularly concerning the specifics of numbers.

Health Analyzer Redesign

Overview

One of the Medical department's largest flaws is its insistence on being a very direct approach to health and wounds. There is a verifiable existence of a "health bar" for players and bodies as whole, and the department largely focuses on simply matching the right types of numbers to the correct chemicals. Despite the department being flavored to be based in semi-reality, there is no particular difference between, say, using a chemical to heal a wound versus drinking an HP potion.

Ultimately, this makes the gameplay loop of the department as a whole very boring: you match the right numbers to the right tool. This is particularly seen in the usage of the MedTek and medical scanners. Currently, players are able to see the exact type of damage and then use the according solution. Rather than continuing down this pathway, this proposes to adjust the way that medical doctors interact with the health system as a whole: doctors should use symptoms to diagnose wounds, then treat accordingly.

One of the first steps in order to accomplish this is to redesign the gameplay loop associated with diagnosing patients. MedTek scanners, health inspections, etc. are the primary object to be redesigned within this proposal.

Background

Baymed is the primary inspiration behind the actual implementation and gameplay loop with this proposal. This inspiration is really more abstract, though, so it likely won't end up actually looking very inspired to Baymed. The main idea is that there should be a more in-depth medical system, and looking at actual hospital practices is also fine for inspiration.

Proposed Gameplay Loop

The proposed gameplay loop is split into three sections:

1. An initial, surface-level inspection in order to triage the patients
2. A slightly more in-depth inspection to know the patient's injuries or ailments
3. If necessary, a specialty analysis to address more obscure ailments (for example, missing/injured organs, poison analysis, etc)

I. Initial Inspections

Currently, medical personnel know who to prioritize because of the medical HUD. Any damage is simplified into a health bar and icon denoting alive, crit, or dead above their head. The current usage of the HUD, allowing for quick triage, should be retained, but it should be reflavored to move away from the contextualization of health being a "bar" or "pool" of damage numbers.

Similarly, there should be some sort of way to encourage a step between initial triage and diagnosing a patient. Triage is primarily for high-intensity situations where doctors may not be able to do an in-depth examination, rather focusing on making sure as many patients as possible are back up on their feet. When the situation permits, we should encourage doctors to thoroughly inspect their patient and possibly roleplay with them (ex. "How are you feeling?" or "What happened?").

Option A). Simplifying the HUD health bar to reflect the same health states shown in the primary hud: Good, Okay, Poor, Bad, Bad! (about to crit), Crit, and Dead.

This gives a similar amount of information as health bars, it just isn't as exact as it currently is. While it solves the issue of reflavoring the design to better match the goals of this proposal, it does not entirely address the core problem. These states are still based off of pools of damage. This does not communicate any sort of "advanced" damage such as missing or broken limbs, which we possibly would want to communicate clearly and instantly. Additional sub icons for amputations or broken limbs should be considered (when the support for such is properly there).

Option B). Redesigning the medical inspect/shift-click menu to better communicate visible wounds.

Currently, the medical shift-click menu shows a list of color-coded sentences, displayed based on what kind of damage the entity has. This menu, hidden behind two sublayers (shift-click, then press the medical icon), is often ignored by players due to it being a very unintuitive menu that is objectively worse than other options (scanning with a health analyzer). The phrases become long and unwieldly quickly, but they also don't give very much information. There is no way to tell if someone is poisoned, irradiated, etc from this menu.

This menu should be redesigned to accomplish two tasks: immediately show any visible damage quickly and give hints to less visible information (such as poisoning). A visual aide, similar to the body dolls, can be used to accomplish communicating the visible damage. A base body doll would have certain states overlaid on top, communicating if a limb is healthy, broken, amputated, or if there are any wounds. Overlays for bleeding, bloodloss, and rot would also be necessary. The text should be repurposed to show symptoms of invisible wounds.

For example, "they are sweating profusely," "they are salivating," or "they are shaking" can all be ways to communicate that a patient is being poisoned (specifically by a poison targeting the nervous system, toxins should later get a pass to actually define how they poison people later). The symptoms can be made as general as necessary, such as "they seem disorientated" or "they seem feverish" to denote radiation poisoning.

This option, however, needs a lot more thought put into it before it can truly be redesigned. How do we ensure that this menu does not "powercreep" doctor-specific equipment, such as health analyzers? Should we tie this level of detail to having the medical HUD equipped, or should it be an inherent skill to doctors? How do we purposefully and clearly communicate the difference between types of visual damage, such as cold, burns, lacerations, blunt, pierce, without these visuals becoming too graphic?

II. In-depth Diagnosis

This step would actually use the health analyzer, along with any other possible tools we wish to give functionality to (the penlight or stethoscope). The health analyzer should be redesigned to give a good overall analysis of a patient, at the cost of being unable to fully identify special ailments. Overall, the analyzer should favor information that is easy to visually identify and treat, such as brute and burn damage, and only hint towards invisible injuries, such as poisoning or organ damage.

Information that points towards more complex treatments should be limited. For example, only medical chemicals should show in the bloodstream. Otherwise, "unknown reagent detected" should show up.

III. Specialty Symptoms

In the case that there is a need for more in-depth information, doctors should then swap from the basic handheld scanners to full body scanners. These scanners should be specialized based on the information hinted at in the handheld scanner. All of this damage should be not immediately life threatening, as splitting up this process forces medical to take more time to see the issue. These scans should also not take very long to do, as the act of splitting them up into different machines slows them down considerably.

For example:

• Full body x-ray scanners to diagnose damaged organs, bones, or internal bleeding
• Toxicology tests to see traces of poisons and currently ingested reagents
• Biopsy scans to see any genetic damage

Game Design Rationale

my rationale is i already wrote 1k+ words and im genius and should always be followed

Technical Considerations

• ui code
• medical system being good

The Metashield

Something that is "shielded" cannot be known by your character during a round until the "revealing condition" happens. This also means that your character cannot do things based on "shielded" information. Knowing or acting on something that is shielded before the revealing condition is met is referred to as metagaming.

Revealing conditions reveal the shielded information for the round, not for a specific instance. This means that once a revealing condition is met in a round, the shield no longer applies in any case for the remainder of the round.

Lifting the Shield

The metashield can be lifted one of two ways:

• Any announcement from Central Command, relating to the specific antagonist. Such as:

  • War declaration
  • Unusual activity recalls
  • Enemy communications
  • Biohazard announcements

• Command members (or any other player who is no longer under the metashield) telling others about specific antagonists

Lifting the metashield (spilling corporate secrets) is considered to be something only done with sufficient reason.

Corporate Secrets

The metashield is an out-of-character term used for admin actions; in character, this would be referred to as corporate secrets. You, as an average crewmember, are not trained to react to potential threats, nor do you remember the events between each round. Nanotrasen policy dictates that the average crewmate is here to do their job, not to worry about any potential threats. It is in Nanotrasen's best interest that the crew is unaware of any potential threat, as that would imply there is something to be afraid of.

As such, all information about specific antagonists is shielded. You do not know the objectives, tools, abilities, etc of any antagonist. Also included in metashielded knowledge is:

• Non-NT implanters
• Chameleon items and mysterious fibers
• Stealth items

However, all command members do not have a metashield. They are fully aware of any potential threats, and are specifically "trained" on how to deal with any threat. If the situation requires it, they are also allowed to tell crewmates what is happening and lift the shield. Security is still under metashield, however it is slightly modified and less strict. Please see the "Security Training Manual" for what they specifically know.

This comes at the expense of being against Nanotrasen policy. Wrongfully lifting the metashield, as a command member, has both IC and OOC consequences. Please see the general Command SOP for when it is considered wrong or right to lift the shield. The fact that Nanotrasen is hiding something from its crewmates is not shielded, but the actual secrets are shielded.

Examples

As a standard crew member, you do not know the objectives or abilities of any antagonist until the shield is revealed. However, you may know about rumors or concepts that relate to a specific antagonist, or that specific items or people are high-risk and require safekeeping. For example:

• Knowing that someone is a revolutionary is shielded; however, you may report them for unsolicited union activities.
• Knowing that someone is a heretic is shielded; however, you may report them for assault, kidnapping, etc.
• Knowing that someone is a traitor is shielded; however, you may report them for theft or murder.
• Knowing that someone is a changeling is shielded; however, genetic horrors beyond your imagination should probably not be on station. You can report them.

Essentially, do not take any action because you know that someone is antagonist, take action depending on what they have done. Avoid callouts that name the antagonist or game mode, at least until the shield has been lifted. If you find evidence that is inexcusably from an antagonist, bring it to a command member in order to "force" them to reveal the shield to you. Command is your boss, and you should consult them if you don't know what to do, IC or OOC.

This does not mean that the entire shift must play out without ever naming or dealing with the specific antagonists. As stated prior, the metashield is equal to corporate secrets, which do exist in character. This means that Nanotrasen is fully aware of any potential threats; they are just selective to who they give this information to.

Metafriending and Metagrudging

This section provides additional information on a concept that is prohibited by multiple metashield items that are never revealed IC. Giving a person or character preferential treatment based on something that your character should not know is considered metafriending. Treating a person or character negatively based on something that your character should not know is considered metagrudging.

Metafriending Examples

These are all examples of things that are prohibited by at least one metashield item that is never revealed IC.

• Giving a character additional access or a job because you are friends with the player who is playing that character.
• Trusting a character because you are friends with the player who is playing that character.
• Not fighting a character because you are friends with the player who is playing that character.
• Ignoring your objective to kill a character because your character and theirs became friends in a previous round.

Metagrudging Examples

These are all examples of things that are prohibited by at least one metashield item that is never revealed IC.

• Not giving a character additional access or a job because you are mad at or don't like the player who is playing that character.
• Not trusting a character because you are mad at or don't like the player who is playing that character.
• Starting a fight with a character because of something that they did last round.
• Starting a fight with a character because they killed you while you were playing a different character.
• Targeting or harassing a character based on anything which that character did outside the current round.
• Targeting or harassing a character based on anything which the character's player did while not playing the character.

Explicitly Not Shielded

The following is a list of things that are explicitly not shielded. If something is not on this list, it doesn't mean that it is shielded, but if something is on it then it definitely is not shielded.

• Non-NT aligned organizations exist, such as the Syndicate.
• The fact that the nuke disk must be protected and could be used by a bad actor to try to destroy the station.
• Certain items are high-risk and may be desired by outlaws or outside organizations (such as the Syndicate), and therefore are likely targets of theft.
• The idea that any Syndicate agent or other bad actor has goals or objectives that they are attempting to accomplish.
• The number of goals or objectives that a Syndicate agent or other bad actor has.
• The fact that the Syndicate are enemies of Nanotrasen.
• A character's typical appearance. Though you should keep in mind that multiple characters can share the same name.

Resource Overview Console

Overview

The removal of the global ore silo from the game was an inevitable change- While massively helpful to solve resource management issues regarding the existence of several lathes and fabricators, it created another massive issue: It completely trivialized and hyper-optimized the supply of materials accross the station.

Now that it is removed it is up to the cargo technicians to keep the station's localized ore silos well-stocked, which does come with a price; with every lathe and silo essentially being thrown to one of the four corners of the station, resource management proves itself very difficult, and it's not uncommon for cargo techs to eventually become weary of resource distribution, causing at times for them to become stingy towards any departments that are not science, leading to resource denial accross the board.

Background

I recently returned to Funkystation after suffering from a health issue, I needed a SS14 server to play that wasn't as fast-paced, and so this became my home. However I was a bit bummed to notice the techfab of the department I was playing at wasn't stocked at all 2 hours into the shift!

I've mentioned the issues this could create; Those being the lack of player authority over resource management and difficult resource management in general. While this doesn't solve player authority as an issue it does optimize resource management enough for that to likely not be an issue at all to begin with.

The new stuff

The Resource Overview Console

Think of it as the energy distribution console of the cargo man: it's a simple concept, it gives you an overview of the lathes and ore silos on the station, with the ore silos being your "SMES'es" and the lathes/fabs being your "APC's" or "Substations".

The idea behind this is to allow cargo technicians to peek at which departments are in more need of X or Y material and blare an alert if a department is currently not stocked with the three essential resources (Steel, Glass and Plastic). If it does include listings for the department techfabs it would be wise to also include a way to change the essential resources threshold, science has a lot of use for plasma, while glass is debatably not that useful for security as well.

A simple, but elegant solution to the daunting task that currently is resource management that does not completely trivialize roleplay.

What the console looks like is actually not that important. Its task is so simple that even a list specifying how supplied each department silo is could already do the trick. Ideally, however, it should probably look similar to some of the existing engineering consoles.

It should come pre-mapped into the cargo bay, so it can work in tandem with the department silos from the start.

Why is this good for the game

The console optimizes resource management without trivializing roleplay, as mentioned earlier. Having a numerical display of how well each department is doing in terms of materials is an attempt at game-ifying the process without throwing away the roleplay value of such interactions. Players on MRP servers may sometimes be more gameplay-oriented than roleplay-oriented; this system incentivizes both groups. Gameplay-focused players would have a metric to push maximum efficiency in distribution, while roleplay-focused players still get to interact with other departments. In short, there’s something in it for everyone.

Game Design Rationale

Maintaining authenticity

While an integral part of life on a space station, manual resource management—down to personally checking what each lathe has is not authentic. As the design principles point out, it’s downright infuriating at times. Cargo may deny materials erroneously, and some techfabs may remain unstocked for entire shifts.

If cargo can see which departments actually need materials from the start, they can not only preemptively deliver them but also exercise fair judgment over requests. For example, if a cargo tech can confirm that Medical truly lacks plastic, it makes much more sense to approve that request.

Maximizing Roleplay Potential (Avoid QOL slop)

Much like global silos, the resource management console is objectively an optimization of the cargo technician’s duties. What it is not, however, is a trivialization of them.

Cargo technicians would still need to interact with each department to stock them. The difference is that they would know which departments to prioritize, how much to allocate, and when to do it.

Technical considerations

I’m not coding this. I am a terrible programmer when it comes to C# and ECS—there’s a reason I gave up on Shitmed after designing it and just let Mocho take over. I’m a game designer; when it comes to coding, I’m mediocre at best.

Company Scrip

Overview

Scrip, a currency for regular crew to gamble with, purchase goods and services, and pressure heads of staff! Scrip is only valid on NanoTrasen stations.

Background

Spesos are fine and dandy as currency that is used with the TSF, but in-lore NanoTrasen is a chartered corporation that is given a complete monopoly on authority on its stations and any planets it may colonize. This concept is more accurately reflected when workers are paid in Company Scrip rather than Spesos. This falls in-line with the long term vision maintainers have for the lore of NanoTrasen. NanoTrasen now becomes a paternalistic entity that can be compared to the coal and timber companies of the United States during the 1900's. This also helps us form a more coherent narrative of NanoTrasen being more overtly evil.

Scrip now also adds a lot of dynamic interactions with crew, as there is now a viable currency that players can be bribed with.

Features to be added

For company scrip to be given the proper attention it deserves, it requires a large overhaul of these systems:

• Vending Machines
• New PDA Cartridge

Additional Systems should be added, for example:

• On-Demand Payment Square
• ATMs
• Station-wide Payout System
• Kiosks ran by Service Workers
• BankApp (CashApp rip off)
• Currency Exchanger

Scrip will also have an exchange rate of 3,000 to 1 speso. Yeah, it's worthless outside of NanoTrasen stations.

Vending Machines

Vending Machines need to automatically withdraw from a players spesos balance. This also means that Vending Machines should either have a flat price of all of the items they contain, or a method of specifying which items cost what. Vending Machines should also just not work when the ACC wire is snipped.

PDA Cartridge

PDA's should now come with a banking app that outlines how much Scrip they are getting next pay routine, their transactions, and their balance.

On-Demand Payment Square

An item that accepts payments when prompted by a user. These are handheld devices that can be used by Tidershops, Service Workers, etc. NanoTrasen issued payment squares have their funds sent to the Station Scrip Bank Account, which is then used as a means to pay out workers. Squares owned by individual people will have their funds deposited to their bank account, with a 5% tax.

Station-wide Payout System

The Station-wide Payout System is a system that, every 10 minutes, issues a set amount of scrip to the station. That money is then sorted through and given out to everyone. Salaries can be set by the HoP and bonuses can be given out by heads of staff if they observed their workers doing great work. It could also be used for anything else, for example, embezzeled by the Captain.

BankApp

The BankApp is another cartridge that players can aquire through Cargo or through the HoP. This Cartridge allows players to send funds to eachother, with the funds being recorded on the Station Records computer.

Players can use the BankApp to pay each other for favors, or whatever. A new entry to Space Law should be added, something along Circumventing Taxes. This law only applies if someone is considered to be running a business and using a non-NanoTrasen approved method to accept payment for goods or services, in order to avoid taxes.

Currency Exchanger

The currency exchanger bluespaces scrip out of the station and gives the player an appropriate amount of spesos; charged to their balance with a 2% conversion fee.

Game Design Rationale

Seriously Silly

Company Scrip sets the tone for what NanoTrasen is. Adding another tool that shows the player how evil NanoTrasen is and a tool that can be used as leverage against someone is perfect for this Seriously Silly sentiment.

Maintaining Authenticity

As said in Seriously Silly, Company Scrip sets the atmosphere. It reinforces the idea that you really are just a cog in a larger machine that's designed to make money. Exploited and easily replaced. This sentiment is what makes the atmosphere of Space Station 14 unique.

Dynamic Environment

Company Scrip can mean different things to different people. Some people don't care, others want to get rich quick. Adding another medium that can allow players to express themselves gives more weight to this dynamic environment as scrip could be used to brag, bribe, or not be used at all.

Roundflow & Player interaction

I don't forsee this having any major impact on round flow persay, an antagonist will still antagonize, but between players, this new feature opens up the door to many potential roleplay opportunities.

Bribes will have more of a weight to them, because scrip can be converted to spesos.

Administrative & Server Rule Impact (if applicable)

No additional stuff needed. Maybe more lenience for players who do choose to accept a bribe for a reasonable amount. No accepting bribes for 1 scrip or something.

Technical Considerations

Several new UI windows need to be made.

• BankApp
• ATM
• Balance App
• Vending Machines now need to display how much an item is worth in Scrip

A mass rebalancing of Cargo things need to take place as well, as there will be a way to generate spesos from Scrip.

More input will be required from the maintainers.

Security Training Manual

Welcome to your new job, officer!

We at Nanotrasen praise your dedication to safety and willingness to do anything for the wellbeing of the corporation. Below, you will find training material for your new position.

The following material is available for your reference, training, and use. The information is designed to assist Officers in their professional development. Please use the material to expand your understanding, enhance your professional knowledge, and to further your career.

Please also remember that all of this material is confidential, as per the NDA you signed on employment. Failure to comply with the terms of your employment will be met with swift legal action.

Section I. Corporate Secrets

As one of our field officers, you are primarily in charge of maintaining the wellbeing of the station's crew and ensuring that the crew properly performs their job. You are to ensure that the crew is kept in line and focused on this task, and you are also to ensure the crew's safety from any external forces. These forces may range from xenofauna, such as: snakes, spiders, or slimes, or other corporations, factions or individuals who may want to cause harm to Nanotrasen or its crew.

One of the primary organizations who may target the station is the Syndicate. The crew is aware that they exist, however, they are instructed that Nanotrasen will take care of any potential issues with it. You, as one of our officers, are the force that deals with any targetted attacks. The crew should not be involved in any capacity. Similarly, the crew is not to know that their immediate wellbeing is in danger, in the event of Syndicate espionage. In the event of a targetted attack, you should resolve it to the best of your ability without fearmongering within the crew.

The crew may be discontent with their current working conditions. You are, of course, to ensure that the cause of this disatisfaciton is not due to unsafe conditions. However, this dissatisfaction become unmanagable and cause the crew to consider a unionization, or even a revolt. In this event, the source of said discontent is likely caused by an outside force and can not be resolved through de-escalation. Refer to your command members for more instruction.

You may come across specific items or events that are unexplainable by natural means. These items may be magical in nature. Refer to your command members for more instruction.

Department Unions

Overview

The Stations Departments will each have a union, excluding Command. This includes security as well.

A player can opt in to be chosen as a head of a union for their department. Selection is random, and if no one is selected as a union leader, another player will be chosen to lead both unions, or multiple.

This will ultimately replace the Revolutionaries gamemode, and server rules will adjust as well. SOP will also be adjusted to be a LOT more sensical and immediately relavent to shift needs. This is to ensure that union heads and enforcers convince other members to follow their SOP, otherwise pay or other station benefits will be lost.

All station unions will have a mix of benefits already provided, such as improved healthcare plans, increased scrip pay, or other benefits, such as a free drink every 15 minutes. The Head of Personnel, NTR or Captain can increase or remove benefits.

This isn't a separate gamemode, this is just Space Station now.

Background

There is a huge gap in this game. How do players express discontent with command staff in a way that is tangible and round changing? Revolutionaries as a secret gamemode only present a window into an overarching story of corporate slavery and exploitation. As Funky Station wants to be a more immersive MRP environment, its best that we introduce dynamics that exist in real life.

Revolutionaries will be removed in favor of this.

Features to be added

Union Leader

A union leader is a randomly selected player (who opts in) to lead their department union. They are given special tools and items. They can roll changeling, traitor, thief, pretty much all round start antagonists. They are not mindshielded.

These special tools are,

• Whistle
• Megaphone
• Union Leader Hardhat (department themed!)
• 2 Steward Caps
• Clipboard Roster
• Brass Knuckles

These are used to rally and organize employees on the station. A union leaders job is to ensure that both your employees are following their contracts (SOP) and that Command is treating employees fairly.

The Security Union is given additional leeway, such as protection when an arrest goes wrong, funding for lawyers if a case ever makes it to trial, other union members serving to intimidate passengers or victims of crime (Other unions can do this as well!), and give out bribes to command, crew members, or other roleplay scenarios that would make something interesting.

Union Leaders can request funds be taken out of their departments budget, as a stand in until scrip is properly implemented. It is up to them how these funds are used.

Whistle

Standard whistle. Used to alert people to Get Moving or Stop Moving.

Megaphone

This is an item that allows a union leader to call a strike. After a strike is called, union members are expected to stop working. Union Members who see Non-Striking Union Members are encouraged to take extra measures to ensure that they do not work. The same goes for non-union members or passsengers/other various personnel that were not originally part of a department who begin working for a department. Making this an innate feature (such as Thieving on Thieves) is an idea I am open to, but a megaphone is undeniably cool.

The item will work like a toggle. When it is initially activated, a station announcement will play, announcing that the Union is on strike. Characters are free to react however they want to this, but they also understand that pay is supsended, things like department consoles that are used for work are closed, shuttles, such as the salvage shuttle, are to be returned to the station ASAP, whatever else that can be thought of.

When the item is used a second time, the strike is called off. There is a 15 minute delay between uses.

If a person who is NOT a union leader tries to use the item, they will be given a prompt asking them if they would like to become the union head. Ideally, this won't be abused. That's what the brass knuckles are for.

Union Leader Hardhat

It's to signify that this character is in-fact a union leader. They are to wear this if they want to be taken seriously, but there is no need.

Steward Cap

The Steward Cap is given to those who the Union Leader deems capable of enforcing SOP and also attending to the needs of workers. A worker may complain to either the Union Leader or Steward that they are being mistreated, that another department is slacking, report missing personnel, etcetera. The Union Leader must tap their ID to their clipboard, and register them as the Steward.

Clipboard Roster

A clipboard that can register new members to the union. Simply tap their ID, enter some additional information, and they now appear on the roster. They are now elgible to become a steward or the union leader. To remove someone from the union, you can click X. They get a NanoChat or some other notification alerting them that they have been removed. Roleplay can go from there (don't expect to be alive if you do this).

Brass Knuckles

Sometimes words aren't enough.

Win Condition

Since this is replacing revolutionaries, this is important to mention.

There is no win-condition.

People who are on strike or willingly break their contracts, or those who do NOT have contracts are not allowed on the evacuation shuttle. If a riot or strike gets so terrible, command is free to use lethal force to escape, and protect loyal crew and station property. A contract can be broken by the worker themselves or a command member. A Union Steward can recommend that someones contract be broken, for fighting, not following SOP, endangering others, or otherwise any issue that is deemed relavent.

There will be no evac restrictions apart from those imposed by other antagonists. A new Space Law provision can be added to prevent strikers from accessing CC, allowing security to forcefully remove or kill strikers and union heads. Encourage strikers to stay on the station with some fancy green text talking about how the station was overrun by strikers and revolutionaries.

Game Design Rationale

Setting is the most important thing in Space Station. Building up this setting to its maximum potential allows players to sink their teeth into a rich world where things Happen™️. This Happening™️ will encourage players to interact with one another in a way that makes sense for roleplay.

There is nothing magical here in terms of mechanics, but the primary goal is to continue building up our world to encourage corruption and violence, in a way that does not feel out of nowhere.

Roundflow & Player interaction

This is the biggest change to roundflow that has ever happened on Funky.

All rounds from now on will have this looming precense of tangible violence that can break out at any time if someone fucks up big enough. Players will be forced to consider what their actions will mean in the long run (in the context of a round), both in terms of what there is to gain and potential consequences. Laws will also have to be rewritten to make sure that they do side with NanoTrasen, but also leave there be enough meat for potential court cases and decisions to be made by higher ups in NanoTrasen. The Magistrate and all other roles will now have an extended responsibility to make sure that they protect all NanoTrasen property.

Union Stewards will also now make sure their departments have everything they need to keep running. This is the contract between the Union, employees, and NanoTrasen. That they will fulfill the stipulations of the contract to the best of their ability.

More and more people will be accountable to each-other, which for an immersive roleplaying game, is a good thing.

Administrative & Server Rule Impact (if applicable)

This will change a lot of things. The removal of the self-antag rule and an emphasis on keeping things in-character is now paramount. There needs to be a greater emphasis on each player that they will keep things that happens in a round confined to a round, and to accept that things will not always go their way, if ever.

Why this prelude? The game, after this is merged, more than ever is now dependent on things running smoothly between departments and between individuals. If a break down in communication happens, that is heard. If materials are now running out, that is heard. Conflicts that does not relate directly with antagonists will be more common now. This is ultimately our goal, to blur that distinction in-character as much as possible to allow people to tell interesting and immersive stories.

Technical Considerations

not much really other than revs being removed. we can keep all that logic the same.

Hydroponics Changes

Overview

Expands the role of botany by opening the design space through the rebalancing of existing features, a new mutation system, and the addition of new plants, machinery and mutations.

Background

I initially set out to incentivize shadowlands exploration by adding plants as interesting loot, however, the more I tested certain features the more potential problems I found. I discussed some of these problems with Terkala/The Fern of Functionality and they agreed that the current state of botany wouldn't support some of the more powerful plants I planned to add. As a result, the scope of this proposal has grown far beyond my initial expectations.

Features to be added

Unique plant crossbreeding

Feature Description

Different seeds can be crossbred together into new species. This would be achieved through a new roundstart machine that would consume seeds and potentially a catalyst to output a new species of plant.

One path could relate to steel-caps, for example:

• Combine papercane and steel-caps to create plastic-caps
• Combine plastic-caps and golden apples to create aurum-caps which could produce small amounts of gold

This feature would allow botany to grow plants that would have been too strong or would invalidate other departments if they existed purely in the current system. The process of mutating three unique plants, combining them together, and finally trying for self-harvesting mutations should be long and difficult enough to make salvage the much preferred route to gold, however, it allows botany to fill gaps in the manifest and provides a longer term goal. It's also easy to balance. If we wanted gold to be locked behind salvage we could make a requirement be salvage loot.

Motivation

Currently players need to apply unstable mutagen and hope for the best to mutate plants. In isolation this system if fine, although it has a heavy reliance on chemistry, there's limited skill expression and - provided you've got access to exotic seeds - you can grow everything almost immediately from round start. If I added new varieties of mutations they'd all be easy to achieve purely by dumping buckets of mutagen and then dylo/multiver/vitamins onto certain plants. I've also seen a common trend in botany of cryoing earlier after growing certain plants. Usually these plants consist of everything the chef could need or some combination of omni, cognizine, deathnettle and gatfruits. This new feature should encourage greater variety in the number of plants grown, add to the progression throughout a round and allow botany to grow plants that are useful to a variety of departments.

Machines

Plant Sequencer

Swabbing is completely random and fairly obtuse for new botanists, so I propose adding a new machine to aid the learning process and partially remove the randomness. It would be available as a tier 3 civilian services research.

The plant sequencer would consume two seeds to displays what traits could be spliced between them. The player would then manually choose some mutations and traits, limited by a new mechanic called 'genetic stability', and then the remaining traits would be spliced randomly, identical similar to the current system. More powerful traits would cost more genetic stability and this would only be recovered as plants grow. This machine requires a competent botanist and civ t3 to make full use of so I'll probably tune it higher to start and if it's problematic we can tune it down late.

Plant Analyzer

I'd like to make adjustments to the plant analyzer to give it different tiers so it can be available from roundstart as well as more powerful versions through research. At T1 the plant analyzer would be available at round start but it would only display less useful info such as potency, yield and potentially growth rates and use more power. At T2 it'd be the current plant analyzer with - potentially slightly faster with less information? - which would add information such as chemicals, gas and mutations. At T3 it'd be available from the T3 civ services research. It would be fairly fast and show details such as potency divisor, weed growth and threshold, and mutations.

Seed Splicer

A new machine for crossbreeding plant species. This would take two unique seeds in varying quantities and combine them into a new species. Certain plants may require more then one packet of seeds or catalyst (vestine, exotium, artifact shards) as a balancing measure.

Botany rebalance

Motivation

As mentioned earlier, the best method to achieve anything in botany right now is to throw a cocktail of chemicals on a plant. Whilst most of these chemicals aren't a huge concern there are a couple that I believe are problematic, notably diethylamine.

Diethyl can be used to speed up a plant's growth by increasing it's age. This bypasses anything that could affect the plants health so it can be abused to instantly grow any plant regardless of its requirements. I've managed to grow 9 gatfruits in under three minutes from round start using a single seed and 35 gatfruits in about five minutes with a bucket of diethyl, despite the fact that it's bugged to be less effective then intended. Diethyl greatly limits the botany design space as any plant with longer growth times, complex requirements, or unique conditions can be instantly grown.

Another issue is that multiver/dylo/vitamins can restore plant health and phalanx can remove an invalid gene so a plant can always be kept alive at no cost.

I'm proposing that we link plant health to growth rate and instead have diethyl speed up growth rate. A healthy plant with this change could grow even faster than in stable but plants with worse conditions or botanists with thousands of units of diethyl would have a harder time. As part of this change I'd be modifying mutations to remove some conditions that I've never once seen satisfied (Requires zauker/trit/bz) and adding some new ones - including intended features that were never finished.

Changes

• PlantGrowth now increases the rate a plant grows instead of instantly increasing a plant's age
• A plant's growth rate and health is increased or decreased based upon a formula rather than the current all or nothing system.
• Implemented missing features or features marked as TODO (such as improper light doing nothing, potentially pests if the playtests go well)
• Modified gas mutations to be safer (I'll talk to Terkala/Fern for this one)
• Removed a number of the health modifying mutations that will never be satisfied. (I don't think an atmosian has ever been or should ever be asked to trit flood botany and it's not an interesting way to punish excessive mutation)
• Colored the third hydroponics light to differentiate between what's impacting a plant's health
• Robust harvest has a 5-10? unit threshold so it won't punish botanists for being one or two units over
• Modified the mutation weights to be more enjoyable

The following are a few potential tentative and controversial changes to botany, most won't be implemented.

These are potential balancing levers for if more variety and content leads to powercreep, to potentially reduce entity spam, and to reduce the gap between standard plants and perfect plants to help newer botanists. If given the choice I'd rather have power in the variety, experimentation and content of botany rather than a few very strong plants.

• Specific plant species have a max yield
• Plants have a maximum chemical storage based on potency
• Chemicals are decreased the more that exist in a plant
• The potency divisor of certain chemicals is increased
• High yield plants take longer to grow, chemicals in a plant are potentially increased to compensate (Might require kitchen changes)
• Plants take slightly longer to grow if they're multi-harvest, increased for self-harvesting or these traits reduce yield
• Plants will always be able to be clipped exactly two times. Maybe can limit to 1 or 0 for extremely powerful plants so you need a lot of effort to grow one.
• Clipping will reduce the stats of the parent plant, clippings might be unaffected. Could use genetic stability so plants recover over time

New plants

Shadowlands Loot

I'll work with an artist and maintainer on the naming and theming of these.

The majority of these plants will be poisonous and grow better in low light conditions. This gives the option for engineering to help build a space but these plants could also be grown in the botany locker room (on most maps), grown in maints, or spliced to remove this trait. I'll also add some standard plants too, I'm just listing the ones that should be in a design document.

Ebonberry

Peer into the shadows

A berry obtained by crossbreeding a shadowlands plant and blue pumpkins. It grants nightvision to aid in exploration but it can also be beneficial for hiding or exploring maints.

Duskpalm

Obscure the world

A rare plant found responsible for creating the shadows found near shadow portals. It can be mutated into dawnpalm which has an intense glow that banishes away any nearby shadows. If science is using a shadow anomaly as a portal an expedition team can retrieve this and a botanist can mutate it to help deal the anomaly and it may be useful for exploring the shadowlands. I'll need to look into performance impacts for this one.

Spectra

Fade into darkness

A crossbreed of a chilly, glasstle and a rare shadowlands plant. Anyone who consumes this plant will become temporarily invisible.

Uses the upstream regent Spectra-Fade pull request.

Wormhole

Warp yourself into genpop

A crossbreed between an extra-dimensional orange, spaceman's trumpet and a rare shadowlands plant. Any player who consumes this regent will be teleported a short distance randomly, suffer heavy toxin damage and empty their stomach from the transition. It's a great escape from antags or for antags with a heavy risk attached. It should be difficult to use as a poison since it's extremely obvious, you don't want your target to teleport to safety, and it's consumed after one teleport.

Salvage Loot

Radium and Phosphorus plants

For when you've pestered chemistry too much

Currently there's only one component of mutagen available in plants without random mutation, chlorine. A plant would be available from salvage that could be crossbred with a few standard seeds to produce radium and/or phosphorus so botany could better mutate without a chemist.

Gaia

The only plant anyone ever suggests

With the introduction of rare plants and crossbreeding we can finally add Gaia back without breaking the game. Gaia would be the pinnacle of difficulty to obtain and require advanced mutations, salvage and potentially even an expedition to the shadowlands. Once it's been achieved plants will no longer need weeding, water or compost.

Catmint

Have any ahelp instantly answered!

A plant that contains drugs that only affect felinids and cats. Can be crossbred with blueberries into a plant that contains a regent similar to wehjuice that makes players meow. This regent can be used for a chem that can temporary polymorphs players into a cat. When scurrets/slugcats get merged upstream (VERY IMPORTANT) it'll also be used for scurret polymorphs.

Features that might be designed later

This is already long enough but here's a list of plants I'm looking into and some other features I might include

• Expanding the cap series of trees to include most resources the station could need - provided the right seeds are found and the right plants are mutated
• An expansion to syndicate botany that requires growing, mutating and crossbreeding gatfruit among other plants and vestine. It rewards more powerful guns at much greater risk of sec discovery and a big investment in time and resources
• A low capacity battery that can be grown that slowly recharges over time
• A plant that grows improved fibres to make slightly larger backpacks.
• A more consistent way to obtain anomaly berries
• More mutations

Suggestions

• Stunbaton equiv of nettle, might be fine if it uses the same salvage plant containing licoxide to crossbreed with difficult enough requirements

Game Design Rationale

Botany was the first department I started with in SS13 (and SS14) and I believe that it's unique in its position as beginner friendly job that's never required for the station to run whilst simultaneously having a high skill ceiling and potentially patch almost any issue in a station. If medical is understaffed you can produce omnizine, if materials are an issue you can supply the station with steelcap and random chemicals help keep the department fresh. Despite all it's very common to see reworks suggested and I agree there are improvements that could be made. I've reviewed proposals and pull requests across different repositories and the common threads are the following:

• Botany lacks interdepartmental interactions outside of providing ingredients to the chef and requiring chemicals from the chemist
• There is limited progression throughout a round
• Traits are obtuse and mutation is random

I disagree that botany only interacts with one, maybe two, departments since I've had botany specific interactions with almost every role, however, there's plenty of room for improvement and the new plants should aid in this. Additionally, the addition of crossbreeding should add long term goals and the loot can open up exciting possibilities for a botanist late into a round. New machinery alongside our previous addition of and improvements to the plant analyzer ashould aid players in learning how to mutate and splice traits from plants together.

Seriously Silly

The new plants should open up some very silly possibilities. I love the idea of bluespacing only to end in the worst location, invisibility timing out at the worst time, new fun chems to mess around with and overall just an improvement to the amount of people I roleplay with in a botany round. Also the image of a syndicate agent gearing up with plants instead of a hardsuit and high tech weapons is hilarious to me.

Maintaining Authenticity

Crossbreeding plants and genetically modifying them is a common part of modern agriculture. Kale, cauliflower, broccoli, cabbage and Brussels sprouts all were developed from the same plant and there's thousands of chilli varieties. Improving this feature should feel authentic and add to the idea that this station was primarily setup for research and development. I concede that some of the sillier plants aren't realistic although I think it's fine to sacrifice some realism for entertainment.

Dynamic Environment + There is no Winning or Losing

For this proposal these principles are intricately linked so to avoid repeating the same thing: At the moment botany can feel somewhat solved; while random chems in plants are great at creating roleplaying experiences and dynamic rounds they aren't consistent. Your best bet right now is to grow omnizine, deathnettle, gatfruit or killer tomatoes. I'm hoping these changes open up new strategies, unique options and expand on what makes botany dynamic rather than player's focusing on a small set of meta plants.

Roundflow & Player interaction

Roundflow

Most of these plants will be difficult to come by and require a competent botanist, chemist and salvage team working together and some features require T3 service research. In longer rounds you could see botany become a force to be reckoned with, however, plenty of other jobs (salvage, atmos, science, cargo) also scale well so I'm not expecting anything major to change we could always rein it in if it does and apply some nergs. If Verna or Fern become DAGD agents then I'm sure they could abuse these changes but that would be peak SS14.

Player interaction

Players would have many new options open to them and it these changes encourage other departments - notably salvage - talking to botany so this should be great for player interaction. I could see veterans being annoyed after going from an extremely skilled botanist to a new player so that could be a problem but I'd like to hope our playerbase is above flaming newbies for not being Verna. Some botanists might ignore the chef at the risk of breaking SOP and getting fired?

Administrative & Server Rule Impact

Everything added would just expand existing features so the admin load should be similar. There's the potential it would make it easier to self-antag or powergame as botanist but given the current system allows for botany to produce lethal amounts of BZ or trit I'd expect it to reduce workload if anything. There is also the potential for OOC mald at new players (which already exists in other departments) in a role that's well suited for new players.

Technical Considerations

If do my job correctly I don't expect any performance impact, there could be issues with entity spam but I'm planning on profiling the code and improving the current performance. There's been plenty of arguments on improving the botany code and switching to more of an ECS design pattern but I'm planning on working on content first and foremost rather then getting bogged down in making a perfect system and the code is workable for the most part, I'll look into it further down the development pipeline.

I'll develop a mockup for this UI if the proposal is received well and I'd require help spriting for this project since I'm horrific at drawing.

"Corporate Secrets"

Overview

The metashield, as it currently is, is confusing and heavily relies on OOC enforcement of IC actions. This is a proposal in order to rewrite the metashield as "corporate secrets," focusing on giving players a better way to react to the game in character.

The basic summary of corporate secrets is:

• Pretty much everything is shielded now, with some minor exceptions. Normal crewmates are here to do their job, and as such, NT does not tell them about any of the potential on-station threats.
• However, command is trained to deal with these threats. The metashield does not exist for them. However, these threats are corporate secrets, and command has signed some sort of NDA about them. Telling the crew about said threats (unless in emergency situations) is strictly prohibited.
• Since IAA, NTR and the Magistrate are directly from NT corporate, they are tasked with ensuring that command does not fearmonger and spill the secrets. In the case that a command member reveals corporate secrets unnecessarily, these three would be the ones to punish them IC. Admins are still encouraged to enforce the metashield OOC.
• The metashield can only be lifted one of two ways: Central Command announcements (think war ops, unusual activity, or blob biohazard announcements) or by command telling the crew.

Features to be added

Multiple new in-game and wiki documents:

• Metashield
• Command SOP

Lasers and Armory Overhaul

Overview

This design doc outlines the removal of current ballistic weapons in the armory in favor of safer, more retro, family-friendly weaponry designed to melt station-ending threats.

Background

Ballistic weaponry from an in-universe common-sense/immersion perspective is not ideal whatsoever when bullets can break windows and space (very dangerous!!!) sections of the station, potentially killing crew if no protections are in place.

This design doc is made from the perspective of both allowing melee weapons to be more viable and to unify NanoTrasen standard weaponry in a way that makes more sense.

They are additionally the primary killing tools of the Syndicate (bad guys!!), and this works to differentiate NanoTrasen brand killing tools (good) and Syndicate brand evil killing tools (bad), as well as allow unique balancing around factional weaponry. Found bullet casings in maintenance? You probably can't blame that on a trigger-happy cadet anymore.

Why this is Good for the Game

These changes all aim to serve a few purposes:

Aesthetics: Energy weapons are cool and retro sci-fi-y, and very distinguishable as opposed to having 5 generic Gun sprites.

Melee, especially unique antagonist melee such as the energy sword and armblade, should be more viable as a method of killing, as a high risk-reward profile. The overall increase of Time-To-Kill on ranged weaponry should aim to incentivize the use of more 'up close and personal' killings and encourage antagonists to take on Security more.

The splitting up of Sec lethals should also encourage Security to use their other tools, like truncheons, more for better damage profiles instead of using their gun as a metaphorical hammer for everything.

This also aims to bring Sec more 'back to Earth', so to speak. By lowering the amount of pure weaponry they have access to roundstart, we curb the constant Sec - Antag cat-and-mouse balancing game that leads to intense powercreep, and makes crew cooperation and interdepartmental play somewhat more useful in ending station-wide threats, such as the Blob. In short, this helps allow for antagonist abilities to be imposing without having to be overwhelmingly powerful or durable.

Ranged weapons, due to their inherent safety and power over using melee, should require a bit more tactical use and forethought than just pointing in a direction and killing whatever's there. Lasers allow for more of this planning through the use of, for example, constructing windows to prepare for a threat. The lowered amount of charges and damage-per-charge/magazine also requires more forethought when bringing them out. Why use a gun when I can relatively safely use melee here?

Additions

Map into Armory

Temperature Gun

See https://github.com/space-wizards/space-station-14/pull/35447 for implementation. Main difference: this will be an Armory weapon and not researchable.

Ion Rifle

A powerful three-shot rifle that deals 50 ion damage on a direct hit as well as a 3x3 tile weak EMP where it lands. Very powerful against cybernetic threats, such as borgs, IPCs, or mechs, but only tactically useful against other energy-weapon users.

Energy Gun

A battery-powered carbine (can fit in the backpack) which can fire either disabling or laser bolts, with less charge than the base Laser Rifle. It has 15 charges.

Miniature Energy Gun

The replacement for both the Officer's disabler and pistol, this is simply a smaller version of the Energy Gun. It can fit in your pocket and has 12 charges, which can be used to disable or laser.

Cadets will also start with this, but it will be locked on Disable until the childproof plastic lock is broken using a screwdriver.

Possible Additions (to be added to Research, primarily)

Blue Laser Rifle

Same as the stock laser rifle but it deals cold damage because it's blue.

Force-bolt Pitcher

An energy weapon that fires slow-moving but long-lasting spheres of energy. This deals blunt and some stamina damage.

Inducer

A portable recharger. It takes battery-cells and charges at a very slow rate. Possibly upgradable with Science.

Changes to current Features / Gamestate

Armory (Mapping)

The removal of all ballistic weaponry from the Armory, in favor of the new laser-based weaponry.

Kammerers should stay as they are explicitly very CQB weapons, as opposed to the longer-range, more reliable lasers.

The addition of a disabler safe to all armories for emergency Command-arming reasons.

The removal of the WT-550 from the Head of Security office.

The removal of disablers from Sec officer lockers.

The removal of ballistic ammo that no longer corresponds to armory/on-station weaponry. Keep rifle, revolver, and shotgun ammo printing for the Chaplain, Detective, and armory respectively.

Overall, Armory would now contain:

• 1 disabler safe (containing 5 disablers)
• 3 energy guns
• 3 laser rifles
• 3 Kammerers
• 1 ion rifle
• 1 temperature gun

Note: Although the weekly rollouts can simply migrate weapon safes in the armory through migrations.yml, it would be best to have them also mapped out by their respective map's maintainers where possible.

Cargo

• The removal of the WT-550 SMG crate from Cargo.
• Replacing the Enforcer crate with the Kammerer crate.
• Replacing the smg and pistols crates with the Energy Gun and Miniature Energy Guns crates.

Technical / Misc. Tweaks

• One unified Laser Projectile and one unified Disabler Projectile defined in Funkystation files.
• An overall increase in laser damage.
• The removal of self-recharging from the HoS' multiphase gun (why is it a better captain's laser?)
• The removal of self-recharging from the EG-4 energy revolver (Blueshield)
• Reduce the Warden's energy shotgun to 6 shots.
• The removal of the mk58 pistol and disabler from the Security Officer loadout for the miniature energy pistol.
• Changing all laser-based weaponry from hitscan to projectile, except for the retro laser blaster because it is funny.
• Remove ion damage from disabling bolts.
• Reduction of the total amount of disabler shots-per-charge.
• Reduce the reflective vest's deflect chance from 100% to 66%

Possible (Future) Tweaks and Concerns

New Arsenal research paths for better energy / ballistic weaponry, printable by Sec to make up for the reduction in overall roundstart firepower.

Certain antag's heat resistances, most probably Nukeops and Dragons, will likely need to be tweaked down a significant margin.

Blob health might need tweaking as a result of the now mainly-heat-based armory.

Game Design Rationale

Seriously Silly

Laser guns are as dangerous as they are silly-looking and sounding and a staple of retro sci-fi. In short: they're flavorful and iconic, much more so than generic ballistic assault rifles.

Maintaining Authenticity

In the future corporate hellscape that is Space Station 14, anachronistic current-day technology exists with futuristic-but-not-really tech. Fax machines exist in the same station as alien artifacts and extradimensional anomalies. Dinky laser guns just fit the environment of a space station much better than a gun that would fit in the hands of a Vietnam War-era soldier.

Roundflow & Player Interaction

This should ideally encourage players in combat to fight in more up-and-personal ways, using more game mechanics while in combat. Slips, stuns, shoves, and antagonist abilities will have a chance to thrive when not every fight is a shootout.

Technical Considerations

This is all possible to do with purely .yml and mapping changes. Coordination will be required from mapping maintainers for armory changes.

More input will be required from the maintainers, particularly concerning the specifics of numbers.

Company Scrip

Overview

Scrip, a currency for regular crew to gamble with, purchase goods and services, and pressure heads of staff! Scrip is only valid on NanoTrasen stations.

Background

Spesos are fine and dandy as currency that is used with the TSF, but in-lore NanoTrasen is a chartered corporation that is given a complete monopoly on authority on its stations and any planets it may colonize. This concept is more accurately reflected when workers are paid in Company Scrip rather than Spesos. This falls in-line with the long term vision maintainers have for the lore of NanoTrasen. NanoTrasen now becomes a paternalistic entity that can be compared to the coal and timber companies of the United States during the 1900's. This also helps us form a more coherent narrative of NanoTrasen being more overtly evil.

Scrip now also adds a lot of dynamic interactions with crew, as there is now a viable currency that players can be bribed with.

Features to be added

For company scrip to be given the proper attention it deserves, it requires a large overhaul of these systems:

• Vending Machines
• New PDA Cartridge

Additional Systems should be added, for example:

• On-Demand Payment Square
• ATMs
• Station-wide Payout System
• Kiosks ran by Service Workers
• BankApp (CashApp rip off)
• Currency Exchanger

Scrip will also have an exchange rate of 3,000 to 1 speso. Yeah, it's worthless outside of NanoTrasen stations.

Vending Machines

Vending Machines need to automatically withdraw from a players spesos balance. This also means that Vending Machines should either have a flat price of all of the items they contain, or a method of specifying which items cost what. Vending Machines should also just not work when the ACC wire is snipped.

PDA Cartridge

PDA's should now come with a banking app that outlines how much Scrip they are getting next pay routine, their transactions, and their balance.

On-Demand Payment Square

An item that accepts payments when prompted by a user. These are handheld devices that can be used by Tidershops, Service Workers, etc. NanoTrasen issued payment squares have their funds sent to the Station Scrip Bank Account, which is then used as a means to pay out workers. Squares owned by individual people will have their funds deposited to their bank account, with a 5% tax.

Station-wide Payout System

The Station-wide Payout System is a system that, every 10 minutes, issues a set amount of scrip to the station. That money is then sorted through and given out to everyone. Salaries can be set by the HoP and bonuses can be given out by heads of staff if they observed their workers doing great work. It could also be used for anything else, for example, embezzeled by the Captain.

BankApp

The BankApp is another cartridge that players can aquire through Cargo or through the HoP. This Cartridge allows players to send funds to eachother, with the funds being recorded on the Station Records computer.

Players can use the BankApp to pay each other for favors, or whatever. A new entry to Space Law should be added, something along Circumventing Taxes. This law only applies if someone is considered to be running a business and using a non-NanoTrasen approved method to accept payment for goods or services, in order to avoid taxes.

Currency Exchanger

The currency exchanger bluespaces scrip out of the station and gives the player an appropriate amount of spesos; charged to their balance with a 2% conversion fee.

Game Design Rationale

Seriously Silly

Company Scrip sets the tone for what NanoTrasen is. Adding another tool that shows the player how evil NanoTrasen is and a tool that can be used as leverage against someone is perfect for this Seriously Silly sentiment.

Maintaining Authenticity

As said in Seriously Silly, Company Scrip sets the atmosphere. It reinforces the idea that you really are just a cog in a larger machine that's designed to make money. Exploited and easily replaced. This sentiment is what makes the atmosphere of Space Station 14 unique.

Dynamic Environment

Company Scrip can mean different things to different people. Some people don't care, others want to get rich quick. Adding another medium that can allow players to express themselves gives more weight to this dynamic environment as scrip could be used to brag, bribe, or not be used at all.

Roundflow & Player interaction

I don't forsee this having any major impact on round flow persay, an antagonist will still antagonize, but between players, this new feature opens up the door to many potential roleplay opportunities.

Bribes will have more of a weight to them, because scrip can be converted to spesos.

Administrative & Server Rule Impact (if applicable)

No additional stuff needed. Maybe more lenience for players who do choose to accept a bribe for a reasonable amount. No accepting bribes for 1 scrip or something.

Technical Considerations

Several new UI windows need to be made.

• BankApp
• ATM
• Balance App
• Vending Machines now need to display how much an item is worth in Scrip

A mass rebalancing of Cargo things need to take place as well, as there will be a way to generate spesos from Scrip.

More input will be required from the maintainers.

Medical Department: Direction & Overview

Overview

This is meant to be a guiding document for the entirety of the medical system and department. These can overall be summarized into design principles, however, some outlining systems are included. The principles themselves take precedence over any example systems listed in this document, as it is meant to be a guiding direction rather than a strict timeline. If you have any questions about this document, feel free to discuss them in the medical workgroup or contact @correspond on Discord directly.

Design Principles

I. Suspend Your Disbelief (in the Name of Slapstick)

Above all else, the primary principle to consider for medical is the aesthetic of it. The why or how we get there don't actually matter that much, the primary goal is that there is a story to be told through the game. When players get hurt, they should get hurt. Simple as that. But the ways we flavor this depend on the primary goal of each fork.

For us, Funky Station, we're looking for a world that takes itself serious, even in the face of silly interactions. The best way to do this is to create a system that represents real biology just enough to push it into the suspension of disbelief; by backing these situations with science, we can push them to contemplate even the fantastical.

Similarly, though, the systems that we are basing this world off of are interesting! Okay, sadly, I am not a STEM major or doctor or anything. But genuinely, biology and all of its subdisciplines are really interesting and seeking to emulate those very interesting parts is a primary goal of the system. The aesthetic we are seeking, on top of this seriously-silly slapstick, is a genuine interest and passion for the systems being created.

For example: An assistant comes into medical after being half turned into a green goop slime. The MDs have no idea what's going on, though they're able to treat the surface level of cleaning up burns, administering painkillers, replacing completely gooped limbs, etc. The assistant can leave at this point, though slightly goopy, and be fine. But if someone wants, they can also dig deeper: A space-borne virus has caused their immune cells to go haywire and attack and replace their own tissues with green goop. Effectively, the player develops a mid-round autoimmune disorder that can be treated by transplanting them into a new, slimy body.

II. Respect Player Autonomy

The medical system, as a whole, will impact every single player regardless of how much they want to interact with it. Because of this, the system should be divided into two layers: simplified, and complex. The average player should only be required to interact with a simplified surface layer of the medical system. Injuries should generally be kept to simplified aspects: cuts cause slash wounds, and can be bandaged up to stop bleeding. Things like potential infections should be kept to the complex layer of the system, a layer that only the medical department should be required to interact with.

These systems, if grounded in reality, are pretty complex systems and knowledge that not everyone has access to. Similarly, as we abstract and simplify these systems to be in a video game, then there's a disconnect between that knowledge and knowledge of the game itself. Relying on people to be able to interact with these systems at all, without the safety net of in-game training, will likely just cause people to become frustrated with the entirety of the system as a whole.

Another thing to keep in mind with this is how we communicate systems to players. There will be a disconnect between the game and the player, so with certain systems, we have to keep in mind how game information is communicated to the player. For example, moodlets and pain are not things that can easily be communicated to the player (because the player is not their character). Expecting players to adhere to and even recognize abstract things like emotions through their character does not respect their autonomy.

III. Represent What You Can, Respect What You Can't

By attempting to simulate real biology, we are also simulating medical problems that people face in their lives. Not everything will be the same as it is in real life, but there will still be parallels regardless of if we try to move away from that. Instead, it is better for us to embrace this representation. People may be chronically ill, and maybe they want their characters to represent them and their medical issues. This is fine, and we should strive to represent this! This is especially true because we, inadvertently, can help bring more understanding to how these medical problems work to people who may not be directly impacted by them.

However, the flip side is true: we can't represent everything with the accuracy that these issues may require. From this, we should still be respectful of the fact that chronic medical issues do impact many people, regardless of if we personally know about that particular medical issue or anyone impacted by it.

IV. Let Things Progress Naturally

Again, the primary goal is to tell a story from these systems. With the medical system in particular, it is important to remember that this story should have a natural, emergent progression. This is particularly important when deciding things like chronic illnesses or blood types--people should not have to deal with the exact same issues, at the exact same time, every single shift. The game is ultimately about improv, and when creating systems that can be persistent, it is still important to make sure that they allow for emergent storytelling.

For example, in the case of blood types (a system we are likely not implementing regardless): assuming blood is cross-compatible between species, should the types be a persistent player trait or randomized every shift? Both have their pros and cons, it's kind of silly for players to need to check their own blood type every shift instead of just being able to know that. However, letting it be a trait also creates the issue where it promotes players memorizing other players blood types, instead creating a stagnant story.

V. Above All, Have Fun

Ultimately, these should be fun systems! This is especially important to remember when we seek to emulate real biology, memorizing chemical structures or enzymes or proteins is not that fun for everyone. Spending the entire shift completely rotted because of a small mistake or misunderstanding is not that fun. Spending 30 minutes in crit because you can't be revived just yet, but also can't ghost out because you're almost up, is not that fun. We want a fun and interesting system!

Health Analyzer Redesign

Overview

One of the Medical department's largest flaws is its insistence on being a very direct approach to health and wounds. There is a verifiable existence of a "health bar" for players and bodies as whole, and the department largely focuses on simply matching the right types of numbers to the correct chemicals. Despite the department being flavored to be based in semi-reality, there is no particular difference between, say, using a chemical to heal a wound versus drinking an HP potion.

Ultimately, this makes the gameplay loop of the department as a whole very boring: you match the right numbers to the right tool. This is particularly seen in the usage of the MedTek and medical scanners. Currently, players are able to see the exact type of damage and then use the according solution. Rather than continuing down this pathway, this proposes to adjust the way that medical doctors interact with the health system as a whole: doctors should use symptoms to diagnose wounds, then treat accordingly.

One of the first steps in order to accomplish this is to redesign the gameplay loop associated with diagnosing patients. MedTek scanners, health inspections, etc. are the primary object to be redesigned within this proposal.

Background

Baymed is the primary inspiration behind the actual implementation and gameplay loop with this proposal. This inspiration is really more abstract, though, so it likely won't end up actually looking very inspired to Baymed. The main idea is that there should be a more in-depth medical system, and looking at actual hospital practices is also fine for inspiration.

Proposed Gameplay Loop

The proposed gameplay loop is split into three sections:

1. An initial, surface-level inspection in order to triage the patients
2. A slightly more in-depth inspection to know the patient's injuries or ailments
3. If necessary, a specialty analysis to address more obscure ailments (for example, missing/injured organs, poison analysis, etc)

I. Initial Inspections

Currently, medical personnel know who to prioritize because of the medical HUD. Any damage is simplified into a health bar and icon denoting alive, crit, or dead above their head. The current usage of the HUD, allowing for quick triage, should be retained, but it should be reflavored to move away from the contextualization of health being a "bar" or "pool" of damage numbers.

Similarly, there should be some sort of way to encourage a step between initial triage and diagnosing a patient. Triage is primarily for high-intensity situations where doctors may not be able to do an in-depth examination, rather focusing on making sure as many patients as possible are back up on their feet. When the situation permits, we should encourage doctors to thoroughly inspect their patient and possibly roleplay with them (ex. "How are you feeling?" or "What happened?").

Option A). Simplifying the HUD health bar to reflect the same health states shown in the primary hud: Good, Okay, Poor, Bad, Bad! (about to crit), Crit, and Dead.

This gives a similar amount of information as health bars, it just isn't as exact as it currently is. While it solves the issue of reflavoring the design to better match the goals of this proposal, it does not entirely address the core problem. These states are still based off of pools of damage. This does not communicate any sort of "advanced" damage such as missing or broken limbs, which we possibly would want to communicate clearly and instantly. Additional sub icons for amputations or broken limbs should be considered (when the support for such is properly there).

Option B). Redesigning the medical inspect/shift-click menu to better communicate visible wounds.

Currently, the medical shift-click menu shows a list of color-coded sentences, displayed based on what kind of damage the entity has. This menu, hidden behind two sublayers (shift-click, then press the medical icon), is often ignored by players due to it being a very unintuitive menu that is objectively worse than other options (scanning with a health analyzer). The phrases become long and unwieldly quickly, but they also don't give very much information. There is no way to tell if someone is poisoned, irradiated, etc from this menu.

This menu should be redesigned to accomplish two tasks: immediately show any visible damage quickly and give hints to less visible information (such as poisoning). A visual aide, similar to the body dolls, can be used to accomplish communicating the visible damage. A base body doll would have certain states overlaid on top, communicating if a limb is healthy, broken, amputated, or if there are any wounds. Overlays for bleeding, bloodloss, and rot would also be necessary. The text should be repurposed to show symptoms of invisible wounds.

For example, "they are sweating profusely," "they are salivating," or "they are shaking" can all be ways to communicate that a patient is being poisoned (specifically by a poison targeting the nervous system, toxins should later get a pass to actually define how they poison people later). The symptoms can be made as general as necessary, such as "they seem disorientated" or "they seem feverish" to denote radiation poisoning.

This option, however, needs a lot more thought put into it before it can truly be redesigned. How do we ensure that this menu does not "powercreep" doctor-specific equipment, such as health analyzers? Should we tie this level of detail to having the medical HUD equipped, or should it be an inherent skill to doctors? How do we purposefully and clearly communicate the difference between types of visual damage, such as cold, burns, lacerations, blunt, pierce, without these visuals becoming too graphic?

II. In-depth Diagnosis

This step would actually use the health analyzer, along with any other possible tools we wish to give functionality to (the penlight or stethoscope). The health analyzer should be redesigned to give a good overall analysis of a patient, at the cost of being unable to fully identify special ailments. Overall, the analyzer should favor information that is easy to visually identify and treat, such as brute and burn damage, and only hint towards invisible injuries, such as poisoning or organ damage.

Information that points towards more complex treatments should be limited. For example, only medical chemicals should show in the bloodstream. Otherwise, "unknown reagent detected" should show up.

III. Specialty Symptoms

In the case that there is a need for more in-depth information, doctors should then swap from the basic handheld scanners to full body scanners. These scanners should be specialized based on the information hinted at in the handheld scanner. All of this damage should be not immediately life threatening, as splitting up this process forces medical to take more time to see the issue. These scans should also not take very long to do, as the act of splitting them up into different machines slows them down considerably.

For example:

• Full body x-ray scanners to diagnose damaged organs, bones, or internal bleeding
• Toxicology tests to see traces of poisons and currently ingested reagents
• Biopsy scans to see any genetic damage

Game Design Rationale

my rationale is i already wrote 1k+ words and im genius and should always be followed

Technical Considerations

• ui code
• medical system being good

Maintainers

A maintainer means a lot of different things. There are Art Directors, Wikitainers, and regular Maintainers. Funky Stations development structure is organized to make sure the flattest possible hierarchy exists.

In order for someone to be a maintainer, they must agree and adhere to these principles.

What is a Funky Station maintainer?

A Funky Station maintainer is someone who is trusted with certain responsibilities. Different maintainers are responsible for different things, but generally, to whatever feature or service they are tasked with maintaining, come the following expectations:

• A promise to the community that they will manage features with the best interest of the Funky Station community in-mind
• An expectation that a maintainer will not involve themselves with administrative actions taken against community members or themselves
• An expectation that a maintainer will discuss features with the community in a faithful and honest manner
• That anything a maintainer creates is to the best possible quality they can provide
• That features are discussed with other maintainers before they are fully implemented, and not just the Head Maintainer

The description is kept brief, because a maintainer does not only do things related to game code / content. There are also services that need to be kept updated, servers that need to be checked on, documentation that has to be written, wiki's that need to be kept up to date, etc. It is better to ask a maintainer directly what it is they manage / are working on.

Maintainers can also organize workgroups on their own, for features or initiatives that require a substantial amount of work.

Workgroups

Workgroups are the biggest organizational unit for a feature. Members within workgroups can be players, contributors, even other maintainers, with the appropriate Workgroup Leader being either the Author of the feature in question, or someone else appointed by the Head Maintainer. Workgroup Leaders may not even be maintainers at all, but they are someone who the Maintainers can have a discussion with about the feature in question.

A workgroup is typically formed after a design document that is PR'ed to the Docs repository is accepted by the Maintainer team. Otherwise, Workgroups are organized by Maintainers.

A Workgroup can be made up of hundreds of people, or made up of one.

A Workgroup can also have positions within them, so long as they are approved by the Workgroup Leader.

Workgroup names are typically "[name of feature] Workgroup." For example, if someone was working on the Xenobio design document, the workgroup for that would be the Xenobio Workgroup.

After a feature is considered complete, the workgroup may continue to exist or be disbanded by the discretion of either the workgroup leader, a maintainer, or the Head Maintainer.

If a feature is considered abandoned by a Maintainer or the Head Maintainer, work may either be picked up by someone else who is interested and makes the appropriate contact to the Maintainer, or by a Maintainer. Otherwise, the feature is considered dead, and work is archived.

A Maintainer or a group of Maintainers may choose to sponsor a workgroup and offer guidance and support to a specific feature.

PR Review

Any Maintainer can review a PR for quality, although not every Maintainer can speak for the features involved in a PR. Maintainers are always encouraged to bring up these discussions in the appropriate Discord Chat or on the PR itself. A Maintainer is not to merge a PR unless it is labelled as a critical fix. Smaller tweaks, like balance changes, are encouraged to be brought up to other Maintainers first before it is merged, even if the consensus is just a quick "Yup" or "No".

Any Maintainer may hold a PR to not be merged unless concerns about it are addressed by the rest of the Maintainers.

Some specific reasons for why a Maintainer might want to hold a PR for review could be:

• Worry about Quality
• Goes against Funky Stations Design Principles
• Code and/or Assets may not be properly attributed or stolen

Feedback given on a PR must be addressed with the same level of care given by the author. Focus on the content of their PR when giving feedback.

Who should get involved with a PR

• The Art Director(s)

They are in-charge of making sure art assets in the game are consistent. A PR may be denied because the art involved may not be up-to-standard.

• The Wikitainers

They are in-charge of making sure that features are properly documented, and a big enough feature that lacks guidebook documentation or other such documentation will need to be shared with them.

• Regular Maintainers

A standard Maintainer will check if code or content added in a PR is squared away and given the proper accreditation.

Stance on AI

AI being used to assist programmers with formulas or other such things is allowed. Disclosing that you used AI for said PR is encouraged.

No art made with AI is to be merged.

No music made with AI is to be merged.

Features built with a heavy reliance on AI are not to be merged.

Changing Policy

This policy can be changed at anytime by the Head Maintainer. The Head Maintainer will inform other Maintainers in a timely manner about when these changes are made (typically within a day.)

Funky Update Policy

Servers are restarted Weekly on Monday at around 9 AM CST.

Monday-Friday: Any Open PRs are to be considered and merged if possible. Any PRs that miss this deadline can just wait for next week. Bugfix PRs or other time-critical PRs are to be merged whenever possible.

Saturday: Maintainers come together and discuss PRs merged as well as possible future PRs. The Update Write-up on changes should be written up in preparation for publication for that week.

Sunday: The Update Write-up is published both on Discord and Forum, with discussion being encouraged on the Forum. The @Update Pings role will also be pinged with a link to the forum.