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, Python 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.

After it's done (you'll know when), type python RUN_THIS.py. 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 run the runclient.bat file, as well as the runserver.bat file to get a local server and client up.

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.

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

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.

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.