Ephemeral Space Logo

This is the development wiki for the Ephemeral Space project. If you're looking for information on game mechanics and guides, seek out the guidebook, accessible on the live server.

More resources pertaining to general Space Station 14 can be found on the main project development wiki.

Associated websites with the Ephemeral Space project.

What should I work on?

  • Check the list of issues for anything you can work on.
  • Talk to contributors and maintainers in Discord.

Guide to Editing Docs

Hello! As you may be able to notice, this docs site is completely open source and free to edit on GitHub. You can see the GitHub page for this site at https://github.com/EphemeralSpace/docs.

Keep in mind that while web-edit PRs (those made through the GitHub web UI) are not allowed on the main Ephemeral Space Repo, this is not the case here.

Style

Documentation should be written in a technical communications style. Effective technical communications are concise, precise, direct, and well organized and should be written in an appropriate voice and tone using correct mechanics and grammar, citing relevant sources where needed.

Making basic edits

If you just want to make a basic edit of a page, simply follow these steps--you don't need any of the fancy stuff talked about later:

  1. Create an account on GitHub, or log in if you already have one.

  2. Fork the EphemeralSpace/docs repo on GitHub.

editing-docs-create-fork.png

  1. Find the file corresponding to the page you want to edit on the documentation repository.

  2. Click the 'Edit this file' button at the top right of the file view.

editing-docs-edit-file.png

  1. Make your changes, then commit & create a pull request! We'll handle the rest.

Building

If you want to locally build the docs, the necessary dependencies are Rust and some binaries installed using cargo. It's recommended that you use cargo install or cargo quickinstall, as building can take a while.

From cargo, install:

  • mdbook
  • mdbook-admonish
  • mdbook-embedify
  • mdbook-emojicodes
  • mdbook-linkcheck
  • mdbook-mermaid
  • mdbook-template

Run mdbook serve to build and locally host the documentation from the book directory at localhost:3000.

Testing changes

If you've made a PR, the easiest way to test your changes, since they're just markdown, is to view them in GitHub's own markdown viewer in the Files changed tab. You can also use a local markdown previewer extension for something like VSCode.

If you want a slightly more authentic experience, every PR will have the Test mdBook Build & Upload Artifact action run, and you can download the built site like so:

Then, just unzip it and open index.html. Our custom CSS and stuff won't work super well but it'll look good enough.

For an authentic-authentic experience, just follow the build instructions above and run mdbook serve like normal.

Review

Maintainers will review pull requests for documentation for content and style. Maintainers understand that many contributors do not speak English as a native language and will be helpful with their review comments.

To help make best use of maintainers' review time, before submitting please:

  • Proofread your changes
  • Use a spell checker
  • Consider using grammar review tools like Grammarly

Code Conventions

In addition to the basic upstream conventions, Ephemeral Space has a multitude of custom conventions meant to aid in maintainability and reduce merge conflicts.

General Conventions

Mirrored Directories

When adding new files to the Ephemeral Space project, always include them under an "_ES" directory. Each project receives its own corresponding directory (Content.Client/_ES/, Content.Shared/_ES/, etc.) with the file structure of the _ES directory mirroring the folder it is in.

This is similarly done for each folder inside the Resources directory (Resources/Prototypes/_ES, Resources/Textures/_ES, etc.)

The goal of this is to organize specific Ephemeral Space contributions while maintaining a consistent file structure across the repo.

Fork Markers

All modifications to non-_ES files should be enclosed with the ES START and ES END markers, denoting that the edits were made to the Ephemeral Space project.

When making modifications, prefer to limit their size and place markers around as little code as possible. Ideally, all the lines within the markers should have been modified.

File Markers

When extensive modifications must be made to non-_ES files, prefer to create a header at the beginning of the file to denote the changes. This helps anyone in the future to see that the entire file has been modified.

Prefer Creating Over Editing

When faced with the option of editing an existing file or creating a new one, prefer creating new _ES-specific files. Limiting the amount of modifications made is ideal for development.

C# Conventions

Class Prefixes

All classes and structs should be prefixed with "ES".

Prototype Prefixes

Prototypes, like other classes, should be prefixed with "ES". The PrototypeAttribute needs to be specified to include the correct casing.

EX:

[Prototype("esTestCase")]
public sealed class ESTestCasePrototype : IPrototype

YAML Conventions

ID Prefixes

All prototypes should have their ID's prefixed with "ES".

Clothing

Clothing generally encompasses items worn by players for primarily aesthetic purposes. While articles of clothing may have utility functions, their primary purpose is their appearance and the social impacts of that.

Job Clothing

Job clothing refers to articles of clothing specifically related to a particular role on the station. Players most often spawn with these clothes equipped, though supplemental accessories can spawn inside of lockers in departments.

The standing of the job should correlate with the complexity of the job's outfit. Simple jobs like passengers, cargo techs, janitors, should have basic outfits that have only a few items associated with them. More renowned jobs, like the Captain or Warden, can have more complicated outfits with additional components.

Clothing elements like capes or fancy hats should be reserved only for the absolute top-brass of the station. Similarly, having multiple options for a slot should e reserved for only the highest roles. While the captain can have two jumpsuits, someone like a doctor shouldn't.

Accessing Job Clothes

A role's clothing should not be obtainable outside their area on the station, though you should not necessarily need access to acquire it. A scientist's clothing may be inside of science, but the wardrobe or dressers that contain them should not be locked by access.

While more complex tools and resources can be secured, clothing should be fairly easy to acquire for the purposes of deception, social engineering, or drip-hunting.

Reusing Articles of Clothing

While some aspects of an outfit are tailored to a job, the number of specific named elements should be kept to a minimum.

For example, instead of having specific "passenger sneakers" and "cargo tech kicks", opt to simply have a single pair of shoes that suit both jobs. Reducing the number of similar clothing items helps simplify imitating an outfit.

Fluff Clothing

Fluff encompasses all clothing that isn't directly associated with a specific role. Overall, the existence of an article of fluff clothing needs to add something substantial in order to justify the maintenance cost. For example:

  • The new clothing item should have a unique niche, be generally novel, or otherwise be something that is broadly appealing to wear
  • The new clothing item should not have overlap with already existing clothing items
  • The new clothing item should ideally have interesting mechanics associated with them. While this is not a hard requirement, having additional features can serve to give purpose to what would otherwise be fluff clothing

Fluff clothing should also ideally be limited to individual pieces rather than entire outfits. If a single article of clothing is all you need to sell an idea or outfit, then that is all that should be added. Refrain from adding "sets" of clothing meant to work together, especially items in the same slot which can't be worn simultaneously.

Examples

  • Good | Sombrero & Poncho: A generally funny set of items that has a specific niche. The addition of the accent while worn also gives it an extra comedic mechanical backing.
  • Bad | Touhou Clothes: The theme of the outfit is not broadly usable and the reference does not provide value
  • Good | Cardborg: Pretending to be a fake robot is a funny idea which integrates will with science and robotics. Additionally, the outfit is good for hiding one's identity, which is an interesting niche
  • Bad | Animal Masks: Comedic/fluff masks are a role generally already filled by the clown and mime clothing options. The theming of the masks are also generally pretty weak, not providing anything novel that isn't accomplished better by existing items
  • Good | Colored Caps: Despite being a relatively large and similar array of clothing options, the caps are generally usable for a variety of outfits. Additionally, the capacity to recolor the caps is an interesting mechanic that reduces the specific issue of color bloat.

Masks

Masks are roles that function similarly to antagonists in a traditional SS14 experience. Their actual design is most similar to the roles in hidden-role games like Town of Salem, Mafia, or Werewolf.

Every mask really only has a few core components: a name, a few objectives, and a genre. Masks are additionally able to have abilities, equipment, or other features associated with them, but this is not strictly necessary.

Purpose

Masks exist for a very simple reason: to prompt conflict in the game. Beyond an individual player's desires and the overarching station goal, masks introduce incentives that cause conflict and disrupt what would otherwise be largely peaceful cooperation.

As such, the objectives for a particular mask must accomplish the following goals:

  • Meaningfully encourage interaction with other players.
    • An objective that can be accomplished through complete inaction, alone, or through abstaining from gameplay is unsuitable for a mask.
  • Involve some level of conflict
    • Objectives should not be beneficial for everyone involved. Some people can benefit from them, but there should always be at least one person who wants to prevent the objective from being completed.
  • Allow for dynamic methods of completion
    • The solution should never be single-faceted or completely static. While the end result of an objective may be fixed (killing a certain target), the player should always have multiple options for approaching and completing it.

Grouping

Masks are organized into two levels: genres and troupes.

Genres

A genre is a high-level category used for influencing which masks are given to players. Every round, a random genre is selected, which weights certain masks higher than others, making them more likely to appear together.

Masks within a genre do not necessarily need to directly involve each other, but rather are just suited to creating interesting interactions when both are present.

For example, an assassin's mask would likely be in the same genre as a bodyguard mask. The two are not strictly reliant on each other (a bodyguard can function without an assassin, and vice versa), but the presence of both simultaneously creates an interesting situation.

Troupes

Troupes are the micro-level organization of masks. Not every mask must belong to a troupe, but it is an additional level that can be used to group masks together.

Masks that are part of a troupe are always assigned at the same time. The purpose of this is to create roles that directly respond to each other. Note that while this is can be used for combative roles, it can also include multiple roles that work together with each other in a positive way.

For example, a mafia troupe may include both mafia member masks and a godfather mask. This lets the roles be designed directly around the relationships between each other rather than simply being an occasional emergent relationship.

Assignment

Masks are always given out randomly when a player joins into a round and arrives at the station. All players receive some mask: not just a small subsection.

The mask that you receive is fully random, dependent only on the genres which have been selected at the start of the round.

Mask Tokens

When you successfully complete your mask's objectives, you receive a mask token that's associated with your account. Between rounds, the a few round's worth of tokens can be redeemed to pre-select your mask before the round begins.

This provides an incentive for completing mask objectives (to earn tokens) as well as way to occasionally mitigate randomness.

Lobby & Roundstart

The lobby, instead of just being a UI, is actually a map players can walk around in. All features that were UI buttons/menus previously (readying up, observing, the roundstart timer, etc) are instead diegetic elements contained within the lobby map itself.

Players spawn into the lobby as soon as they connect to the server and are shown a guidebook entry explaining what's happening, since it will ideally feel very strange compared to the regular SS14 experience.

The Theater

The lobby map is a theater, featuring a foyer area and the theater itself, with a stage and seating. The goal of this is to frame the entire round as an "immersive play" that is occurring within the theater, synergizing very well with the established design of randomized characters and relations, 'mask' roles, and focus on improvisational roleplay. Theatergoers can chat amongst themselves about anything they like.

The players within the lobby are "theatergoers", who are visiting the theater with the goal of starring in one of the plays. The theatergoers are not human, and the theater as a map is in a sort of "void" of indeterminate quality. The level of in-character "reality" that the theater and its plays are operating on is left up to interpretation.

The theater itself is an unnerving object. Mixed perspective, strange lighting, gaps in space and hallways that lead nowhere, a topology that doesn't quite seem to be possible, rooms with inscrutable function and design that seem to change every time you visit, as well as food items that seem more tangible and real than anything else you've seen. A lovely place to spend eternity.

Within the lobby, a piece of 'Lobby Art' designed for the play you're to perform is displayed prominently within the foyer. There is also diegetic 'Lobby Music' of sorts coming from a gramophone in the foyer.

NPCs

As opposed to the play itself, made up entirely of performers, the theater has many individuals who are simply not sentient and exist only to entertain and perform tasks for the theatergoers, such as opening menus, directing them to areas of the theater, just filling space, or generally spouting cryptic nonsense.

Accessorizing

The theatergoer sprite is a strange little sort of guy of undefined gender in a tuxedo and a square head. Players can interact with an NPC in the lobby to customize their lobby character, either by changing the sigil displayed on their face, adding small accessories or markings, or changing clothing.

Activities

Okay breaking character for a second. Imagine like a roblox lobby or minecraft hypixel lobby. you get what I mean right. Theres just random shit to do you can wander the backrooms or do weird inscrutable puzzles or engage in..

Pheemy Pharmer

The game where YOU can take care of your Pheemy (a weird round kind of guy) and try to create the rarest pheemy you can while keeping it healthy or killing it allways in all sorts of damaging ways and punching it to death and murdering it. Actions taken in the round can affect your pheemy in nonobvious ways and you can chat with other theatergoers about the state of your pheemies. Or feed it berries.

Roundstart

When all theatergoers entered the lobby from the previous play, the map and gamemode for the next performance has already been selected. Some time before the performance begins, you can adjust which roles (determined from the map and gamemode) you'd be okay with playing by stepping onto the stage and selecting them in a UI (sometimes you do just need a user interface).

This works as a sort of "approval voting" system, and you can see which roles other theatergoers are selecting and adjust your preferences accordingly. There is not necessarily a guarantee you will get the role you desire if you're too picky.

Readying Up

Theatergoers can opt to join the performance by entering the theater and simply standing on the stage. Others who simply wish to observe can melt into the theater's lush seating, and those who enter the theater during a showing can skulk onto the stage and try their best to fit into the existing performance. However, latejoiners must wait at least 10-15 minutes after the play starts before trying to make their entrance.

Starting the Play

Once the play begins, the curtains are drawn and all ready are taken into the other world. Roles are randomly selected based on the approval-selection mentioned previously, each theatergoer receives a random Mask, and they are expected to fully act in character, and to not mention the theater from now on. Those who fail to uphold kayfabe may find themselves ousted by the other actors.

Arrivals

Asteroid Control

WIP

Evac

WIP