Space Station 14

Is a vehicle for improvised comedy videogame fork of a 2001 atmospherics simulator. It’s like a multiplayer Rimworld, with the complexity of Dwarf Fortress¹. Twelve years ago I’d play as an uncannily helpful mime, an alcoholic detective, or usually a micro-managing chief medical officer. Rounds last 1-3 hours, involve 10-100 players, 0-3 admins functioning as dungeon masters, and a subset of players designated as antagonists ranging from xenomorph queen to corporate spy.

The Problem

Ss14 follows its predecessor, ss13, which still exists in a feature-crept, if complete, legacy codebase, collapsing under the 2-decade weight of the hobbyist game developer revolving door. To play ss13, you have to download BYOND, a graveyard of a game client buoyed by ss13 players. While ss13 emerged alongside the popularity of entity-component design, its codebase is largely functional. It is so engine-bottlenecked that the functional player cap sits around 80².

Enter the fully open-source C# rewrite. It has ECS design, its own engine, order-of-magnitude performance increases, etc…I was disappointed I couldn’t contribute to the codebase when I was learning python a few years ago. Things have changed!

Entity-Component-System Conceptual Hurdles

Coming from rust, which splits your 2000s-era-language classes into inheritance traits, data structs, and method impls, ECS was more approachable. Entities, components, and systems are almost 1:1. Zero experience³ with async programming or event structures was my main hurdle. C# was completely new to me, but that’s not the barrier it used to be with more language exposure⁴ and LLMs providing the basic syntax. I decided to stay with VSCode to learn fewer new things at the same time, despite Visual Studio’s better C# support⁵.

It’s an ideal learning experience because I’m familiar enough with the game to know the requirements ahead of time. I remember the little display screens counting down the arrival of the emergency escape shuttle; coding them is purely conceptual. Most others on the project have a similar background, or actively play both versions of the game already. Very little needs to be communicated relative to other projects, which only has a few downsides: sparse documentation, style isn’t rigidly enforced, lone devs prioritize features over fixes, etc.

Timeline

I committed around an hour a day to ss14.

• 6/25: I started seriously looking at the codebase.
• 6/27: I picked an issue and asked a maintainer about some of the code. I’m usually ignored in the help channel and feel like an annoyance, so I stop.

Half-week break

• 7/6: git loging the entitysystem for item reflection tells me that there is an entity in the game that reflects hitscan projectiles.
• 7/8?: I understand enough to attach a component to an entity to influence the reflection system. There is a single page of documentation about how to achieve this abstractly. I feel stupid, even though I manage to make an entity reflect a shot.

Another half-week here

• ~7/15: total documentation exhaustion; keyword-searching discord channels becomes my main information source⁶.
• 7/17: The event system makes sense after I reread a single line from the page: “Basically, we’re telling the game: Whenever a UseInHandEvent is raised on an entity that has the PlaySoundOnUse component, I want you to call my OnUseInHand method.”

One of my days was just learning to squash git commits. git rebase -i HEAD~10 is laser-etched into my hippocampus.

• 7/20?: I write the event handlers that govern reflection without crashing the debug environment for the first time. My solution for multiple separate entities providing the same reflection effect is beautiful.
• 7/21: PR Submitted.

I am grossly overconfident.

• 7/22?: The maintainer who wrote the issue likes my code and makes some value tweaks that introduce div0 errors I documented in the same PR. I immediately realize my solution won’t work because someone is going to set reflectprob to 1 even if // DON'T SET TO 1 is in the system and component files.
• 7/23: I decide to maintain a map of entity:reflectprobs. After I’m done, I realize this is just a subset of equipment entities outside their designated slots; this is deeply unsafe. I simplify my solution by iterating over the full set after I comprehend the resource-intensity of pressing a single movement key while helping someone in the help channel. People seem annoyed I’m wasting their time on a messy PR. My commit history is a mess and 3 maintainers are breathing down my neck about value tweaks like Office Space. I pick up my second issue.
• ~7/25: I understand the codebase enough to help people in the help channel. I commit to leaving nobody unanswered in the help channel⁷.
• 7/29: I understand the mess of 4 systems that interact⁸ for my second issue and finish the proof-of-concept.
• 7/30: The issue maintainer merges my first PR. I’m chuffed about it, but clearly generally insecure. A maintainer talks about how welcoming everyone is.

My second (slightly more complex) issue “solved” after 1/4 of the time, my first PR merge⁹, and the end of July, impart a sense of milestone that compels me to blog about “finally having learned C#, ECS, and the SS14 codebase” or something similarly masturbatory.