Now that your development environment is configured, the next step is understanding how the Wayfarer repository is organized. Wayfarer is a large C# project made up of multiple applications, libraries, tools, and resource packages. Knowing where different systems are located will help you quickly find the correct files when creating features, fixing bugs, or reviewing code.

Most contributors will primarily work within the Content.* projects and the Resources directory. The remaining projects provide supporting tools, testing environments, documentation, packaging, and engine functionality.

Repository: https://github.com/project-wayfarer/wayfarer-14
Discord: https://discord.gg/QpVfma2eAp

Need help? Join the Discord server and ask questions in #mentorship-and-contributing. Everyone starts somewhere, and we're always happy to help new contributors.

Repository Overview

The top-level structure of Wayfarer contains the following major directories and files:

The Content Folders

The majority of Wayfarer development happens inside the Content.* projects and Resources. These contain the custom code that makes Wayfarer unique, while the engine itself remains separate inside RobustToolbox.

The client, server, and shared projects are some of the most important to understand.

Content.Server

Content.Server contains the authoritative game logic. This is where the server decides what happens in the world and ensures all players receive the same game state.

Most gameplay systems are located here, including:

• Entity systems
• Round management
• Game rules
• Jobs and roles
• Antagonist systems
• Station events
• Server-side interactions

If you are creating a mechanic that affects the actual game world, there is a good chance part of it belongs here.

Content.Client

Content.Client contains code that runs on the player's computer. It is responsible for displaying information and handling interactions that do not directly control the game state.

Some client-side work includes:

• User interfaces
• Rendering
• Visual effects
• Input handling
• Client-side animations

The client should generally display and interact with information provided by the server rather than making gameplay decisions itself.

Content.Shared

Content.Shared contains code that both the client and server need access to. This prevents duplicate implementations and keeps both sides synchronized.

Examples of shared code include:

• Components
• Network events
• Entity definitions
• Shared interfaces
• Most utility classes

When creating a new feature, you will often make changes across Content.Server, Content.Client, and Content.Shared.

The Resources Directory

The Resources directory contains the majority of Wayfarer's non-code content. If something exists in the game but is not written in C#, it is likely stored somewhere inside this directory. This includes things such as item definitions, entity prototypes, sprites, sounds, localization files, and config data.

Common resources include:

A large amount of content development involves editing YAML prototypes rather than writing C# code. For example, adding a new item often requires creating a prototype file, adding sprites, and connecting it to existing components.

Organization and Wayfarer Content

When browsing through directories inside Resources, you may notice that many folders are separated by prefixes or naming conventions. This is intentional and helps keep Wayfarer's custom content organized alongside content inherited from upstream projects.

Certain directories, especially Resources/Prototypes, may contain folders originating from other forks or the upstream projects. These folders allow Wayfarer to maintain compatibility with existing content while still keeping custom additions separate.

Wayfarer-specific content is typically stored in folders marked with the _WF prefix. For example:

Resources/
└── Prototypes/
    ├── Entities/
    ├── Items/
    ├── _WF/
    └── ...

The _WF folders are intended for content that is unique to Wayfarer and does not belong to upstream or shared content. If you are creating a new feature that is specifically designed for Wayfarer, it is recommended to place its resources inside the appropriate _WF directory whenever possible.

For example, a Wayfarer-exclusive item would generally have its prototype stored somewhere under:

Resources/Prototypes/_WF/

rather than modifying an upstream content folder.

Keeping custom content separated makes future updates easier, reduces merge conflicts, and clearly identifies which features are maintained by the Wayfarer development team.

Note: Not every file needs to go into _WF. If you are modifying existing shared content or fixing a general issue that applies beyond Wayfarer, follow the existing organization and place changes in the appropriate directory.

RobustToolbox

The RobustToolbox directory contains the game engine that powers Space Station 14. It provides the underlying framework for networking, rendering, physics, entities, and other low-level systems.

Engine changes should generally only be made when fixing engine-level issues or adding functionality that benefits the entire framework. They usually should NOT be merged onto the fork and should only be PRd to the main RobustToolbox repository.

Scripts

Space Station 14 repositories include several scripts that make common development tasks easier.

Using these scripts is recommended over manually entering long commands, especially when you're new to development.

Typical Development Workflow

Most contributions follow a similar cycle:

Finding Where to Make Changes

When starting a new feature, the hardest part is often knowing where to begin.

A general guideline:

Many larger features will touch multiple parts of the repository. For example, adding a new machine may require a server system, shared components, client UI, YAML prototypes, and sprite assets.

Remember: If you don't know where something is located, or supposed to go, don't be afraid to ask!

Keeping Your Changes Organized

Avoid making unrelated changes in the same branch. A pull request that only adds one feature or fixes one problem is much easier to review than one containing several unrelated modifications.

A good branch name could be:

feature/new-medical-machine

fix/incorrect-door-access

docs/development-setup

Keeping your work focused makes collaboration easier and increases the chance of your changes being merged quickly.

Next Page: PR Recommendations→